- Aur-general - lists.archlinux.org

[aur-general] Account Suspended, No Reason Given
by shoober420 04 Nov '18

04 Nov '18

I recently tried to be the maintainer for an package that hasn't been updated in quite some time. I've been using my own PKGBUILD for the particular package with great success, and currently am maintaining the "lib32-sdl2-hg" 32 bit version of this package. Upon request of this package, It was denied for no reason given, except a disrespectful message from coderob and I quote. "come back with a better request, my dude" So I did, I requested to maintain the package again, and was denied, then my account got suspended. Whats the deal here? I wasn't warned about anything I may have done wrong, and I'm currently maintaining two packages, and co-maintaining another one, which I no longer can access. Please unsuspend my account so I can maintain my packages. Vincent Grande <shoober420>

9 26

[aur-general] Email Reset
by pellertson＠firemail.cc 02 Nov '18

02 Nov '18

I need help reseting my email address on my AUR account. Recently lost my old email address password so I've been migrating everything. I have the ssh keys for my account if proof is needed. - Parker

2 2

[aur-general] Found a spam account; please delete crystal01
by Andy Kluger 31 Oct '18

31 Oct '18

https://aur.archlinux.org/account/crystal01/comments Please delete this user, it's obviously a spam account.

2 1

Re: [aur-general] TU application: Maxim Baz
by Alad Wenter 29 Oct '18

29 Oct '18

For the record, I confirm that I support Maxim's application. I referred him to Morten as my time schedule did not allow sponsoring a new candidate. Best of luck! Alad

1 0

Re: [aur-general] Automatic package version
by Shay Gover 26 Oct '18

26 Oct '18

> > Date: Fri, 26 Oct 2018 19:09:36 +0100 > From: Konstantin Gizdov <arch(a)kge.pw> > To: aur-general(a)archlinux.org > Subject: Re: [aur-general] Automatic package version > Message-ID: <8cf660ad-d2cc-d275-7678-cbb32b0d4acf(a)kge.pw> > Content-Type: text/plain; charset="utf-8" > > On 26/10/2018 19:07, Shay Gover via aur-general wrote: > >> Message: 1 > >> Date: Fri, 26 Oct 2018 18:29:59 +0200 > >> From: Michael Kogan <michael.kogan(a)gmx.net> > >> To: "Discussion about the Arch User Repository (AUR)" > >> <aur-general(a)archlinux.org> > >> Subject: Re: [aur-general] Automatic package version > >> Message-ID: > >> < > >> CALsOv%2BBp9EZ_v_wfsv5mz9muariNgNCZXWYYx_1EndOfkJ_BBg(a)mail.gmail.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > >> First thing coming to mind: Did you possibly forget to update the > .SRCINFO > >> file? > >> > > Hoe do I update it from the PKGBUILD itself? > > I normally have an alias like this: > > $ which updpkgs > updpkgs: aliased to 'updpkgsums && makepkg --printsrcinfo > .SRCINFO' > > That's from outside the PKGBUILD. I already did that when I uploaded the package a month ago. But since then the package was updated. It's not automatic versioning if I need to update SRCINFO every time. > On 10/26/18 2:07 PM, Shay Gover via aur-general wrote: > >> First thing coming to mind: Did you possibly forget to update the > .SRCINFO > >> file? > > > > Hoe do I update it from the PKGBUILD itself? > > The PKGBUILD format is by definition separate from the .SRCINFO, you > don't update it automatically by the PKGBUILD. > > You update it separately. The general process is described here: > > https://wiki.archlinux.org/index.php/Arch_User_Repository#Uploading_packages > > The "aurpublish" package available in the community repositories can do > this for you. > > > OK. But I'll still need to create a local script that will do that, right? > >> The package is not *supposed* to > >> show an updated version in the AUR, that's the whole point of a pkgver() > >> function. > >> > >> So how does the automatic versioning suppose to work? > > It already does work. You download the PKGBUILD from the AUR, and use it > to build a package. A pkgver() function *allows* the package to be newer > than advertised in the AUR. > > It's okay for a package to be newer than advertised. That's how all > *-git packages work, by design. > > >> P.S. There's no such thing as a pkgrel() function. > >> > > > > Good to know. Since I need it, What can I do? > > I assert that you do not need it. > > The pkgver is supposed to be set by the version of the software itself. > The pkgrel is supposed to be the version of the PKGBUILD, and every time > the pkgver gets updated, the pkgrel resets back to "1". > > See https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel > > An "automatic" pkgrel violates the fundamental purpose of having a > pkgrel in the first place. > > You're correct. My fault. :/

4 4

Re: [aur-general] Automatic package version
by Shay Gover 26 Oct '18

26 Oct '18

> Message: 1 > Date: Fri, 26 Oct 2018 18:29:59 +0200 > From: Michael Kogan <michael.kogan(a)gmx.net> > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Subject: Re: [aur-general] Automatic package version > Message-ID: > < > CALsOv%2BBp9EZ_v_wfsv5mz9muariNgNCZXWYYx_1EndOfkJ_BBg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > First thing coming to mind: Did you possibly forget to update the .SRCINFO > file? > Hoe do I update it from the PKGBUILD itself? > > Message: 3 > Date: Fri, 26 Oct 2018 12:34:44 -0400 > From: Eli Schwartz <eschwartz(a)archlinux.org> > To: aur-general(a)archlinux.org > Subject: Re: [aur-general] Automatic package version > Message-ID: <6bbd283a-3587-d9f9-3dcc-3ba8e9f0739b(a)archlinux.org> > Content-Type: text/plain; charset="utf-8" > > On 10/26/18 12:26 PM, Shay Gover via aur-general wrote: > > Hi, > > > > I have a pakage in AUR that uses an automatic package versioning. I use a > > pkgver() and pkgrel(). > > However I just noticed that the package version in AUR is old. I checked > > the functions and everything is OK. Running makepkg gives the correct > > version. > > > > The package is: > > > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=virtualbox-ck-modules > > Are you Tharbad on the AUR? If so, you're using multiple email addresses... > As for the package itself, fake news! The package is not *supposed* to > show an updated version in the AUR, that's the whole point of a pkgver() > function. > > So how does the automatic versioning suppose to work? > P.S. There's no such thing as a pkgrel() function. > Good to know. Since I need it, What can I do? > > -- > Eli Schwartz > Bug Wrangler and Trusted User > >

3 2

[aur-general] Automatic package version
by Shay Gover 26 Oct '18

26 Oct '18

Hi, I have a pakage in AUR that uses an automatic package versioning. I use a pkgver() and pkgrel(). However I just noticed that the package version in AUR is old. I checked the functions and everything is OK. Running makepkg gives the correct version. The package is: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=virtualbox-ck-modules Ideas? Thanks, Shay Gover

4 3

[aur-general] flood of package adoption emails
by Johannes Wienke 26 Oct '18

26 Oct '18

Dear all, yesterday I received about 10 email notifications that my package pass-git-helper-git was adopted by some random user, differing in each email. Yet, the web interface shows myself as the maintainer and I never opened the package for adoption. Does anyone know what is going on here? I can provide such an email for debugging purposes if necessary. Johannes

3 2

[aur-general] Fwd: Re: How do I show a AUR Rebuild as a newer build?
by hagar 23 Oct '18

23 Oct '18

This was my thought - then I came across Mythtv - epoch=1 pkgrel=5 pkgver=29.1 The docs say that pkgrel should be for changes in the packaging files. Because of the Maintainers increasing pkgrel I was considering increasing the pkgrel by 0.01 each new build. This would allow for 99 subsequent builds on each pkgrel. The docs say that it can be of type ver.subver. would this work? Thanks Macca On 20/10/18 9:42 am, Ralf Mardorf wrote: > On Sat, 20 Oct 2018 08:59:06 +0800, hagar wrote: >> If I need to rebuild a package due to dependancy rebuilds/changes how >> do I mark the new package as newer? >> >> >> Do I increase the epoch? > No. > > From 'man PKGBUILD': > > "This is useful when the version numbering scheme of a package changes > (or is alphanumeric), breaking normal version comparison logic." > >> Or is there another way? > That is what the pkgrel is for. > > However, AUR provides PKGBUILDs, not packages, so a maintainer doesn't > bump the pkgrel each time a PKGBUILD gets edited, but a maintainer > might care about the need to build against newer releases of > dependencies and increase the pkgrel or the maintainer might ignore it. > What ever changed, I bump the pkgrel for my local builds for each > package, but that way the pkgrels of my local packages could get out of > sync with the pkgrels of some AUR PKGBUILDs. If you dislike this, > simply build a new package with the same pkgver-pkgrel or the same > epoch:pkgver-pkgrel, if there already should be an epoch.

8 22

[aur-general] How do I show a AUR Rebuild as a newer build?
by hagar 21 Oct '18

21 Oct '18

Good morning All, I understand that there are 3 version control tags in the PKGBUILD file. pkgver - The Actual Package version pkgrel - The Arch modification/release count - for changes to the patches, install file's. epoch - Special version control number. If I need to rebuild a package due to dependancy rebuilds/changes how do I mark the new package as newer? Do I increase the epoch? Or is there another way? Thanks Macca

4 4

[aur-general] Critique my pkgbuild
by Michael Straube 15 Oct '18

15 Oct '18

>Hello again, > >It took me a while to have some time, but I believe I have fixed all of the issues that were pointed out to me, with >some help from Scimmia and eschwartz. I think the package is in much more presentable shape, I have learned plenty, and >I fixed a lot of naive mistakes. Thanks everyone for the help. > >I would very much appreciate it if you would all take the time to read the latest PKGBUILD (from the git version of the >package) pasted below and see if there is anything I missed. Thanks! Hi Ethan, for git repos that have tags containing a release version number it is common to have a pkgver function that generates a pkgver that includes the version. In this case e.g. git describe --long --tags | sed 's/^master-v//;s/$[^-]*-g$/r\1/;s/-/./g' Regards, Michael

1 0

[aur-general] Critique my pkgbuild
by Ethan Rakoff 15 Oct '18

15 Oct '18

I have submitted a package called threemawebqt to the aur (mostly for me, and some friends who use arch). It is a VERY simple thin client for a webapp using Qt. This is my first pkgbuild from scratch (and my first time working with Qt) so even though it is a super simple one, I would like some others to look at it and let me know what I'm doing wrong. Thanks! Here is the pkgbuild for easy reading: # Maintainer: Ethan Rakoff <ethan(a)ethanrakoff.com> pkgname=threemawebqt pkgver=0.1 pkgrel=1 pkgdesc="Thin client for Threema Web, the web client for Threema, an E2E encrypted messaging app." arch=('i686' 'x86_64') url="https://github.com/ethanrakoff/${pkgname}" license=('MIT') depends=('qt5-base' 'qt5-webengine') makedepends=('make') source=("git+${url}") md5sums=('SKIP') build() { cd "${pkgname}/src" qmake make } package() { cd "${srcdir}/${pkgname}/src" make INSTALL_ROOT="${pkgdir}" install install -Dm644 icon.png "${pkgdir}/usr/share/icons/${pkgname}/icon.png" install -Dm644 ../threemawebqt.desktop "${pkgdir}/usr/share/applications/threemawebqt.desktop" install -Dm644 ../LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" }

4 6

Re: [aur-general] Questions about some of my packages being adopted in [community]
by Konstantin Gizdov 14 Oct '18

14 Oct '18

Hi all, Thanks for the comments and explanations. Firstly, I wanna say that I am not asking for special treatment or anything. Just wanted to discuss in detail what is going on. Secondly, a few comments stood out to me (in no particular order). I actually want to move the whole "root" tree, but considering its > number I just started with the easier "leaf" ones. This is what I suspected to be honest. The packages that were pulled were way too specific. Well, if you're going to do this, then I'd like to have a conversation about it. (below) Regarding FS#60248 > Just release the python2 version of the package in the AUR. Sure, just wanted to be sure that's the expected approach. What original intention? Packages don't need to meet any intention. > They should be packaged acording to the guidelines Of course, they do - packages exist for a reason and the way they are packaged expresses the intention - feature support, type of build, structure, etc. All of that is beyond scope of packaging standards. This is fairly common -- while it is nice to get in touch with the AUR > maintainer, we hardly need *permission* to package something for the > repos. As always, you can report bugs with the official packages. I was not implying *permission* is needed, this is not the point - the point is letting people, who put their time in, know what's up. In any case, I listed this as an observation, hence the reason my email was prompted. Denied resolution? > ... > I fail to see how you're being "denied" anything. Call it what you want, I tried to re-open all 3 bugs but was denied with little to no comment/explanation. I wanted to know if python2 is going to be added by Felix or not - instead I was scolded at the bug and here in emails. The other bug is a bug as confirmed - also denied to re-open without explanation/investigation. The third bug was re-opened by Filipe after my initial email - no need to bash me further about it. So all bugs were closed & denied to re-open until I made a fuss about it here. That to me is 'denied'. Whatever we want. Of course, but not helpful. I'll explain. You don't get to act as some sort of concerned citizen here to protect > your packages from the incompetent Devs/TUs when your PKGBUILD contains > this junk. > (Sorry for being harsh, but this is the reaction you invite when you set > yourself up as the superior packager.) I am not pertaining to be a superior packager and I am not calling anyone incompetent. This is completely beside the point. I will explain below. But to address the state of this particular package - it was added 2 weeks ago in a rush to push a new version upstream, because I maintain my packages well. This package and another from same time around need a complete rewrite, which I'm aware of. And this particular style of package was copied from another [community] package a long time ago, things have changed as it was pointed out to me here in the AUR. I had intentions to fix it as soon as I had time. Picking out one package out of the whole stack, which I have not had time to properly deal with, proves nothing, but that you aim to shame, rather than to understand where I'm coming from, why I am worried and that I'm actually looking to be heard and help. That's a message I entered manually each time, with respect :) This was not a complaint. Thanks, that's actually the only clue I had my packages were going somewhere and not just randomly deleted. I believe that is not true. I even enabled more functionality in > libafterimage, actually. You mean when you removed `--disable-svg` flag? I might be wrong, but I think there was a reason to leave it disabled. You'd have to check comments or Gentoo/Fedora package to be sure. I do not intend to package the python2 variant. For the other two, I > have replied in the tasks. Thanks for making that clear. So to make all of this more clear to everyone. I took on the task to maintain CERN's ROOT a couple of years ago and since then I've involved myself heavily, I'm a contributor to the project and I use it daily in my work. Colleagues at CERN that use Arch Linux have been depending on me for this. I have enabled a lot of new features and worked with upstream to make even more functionality, bug fixes, etc. Currently, I am working on two new features with upstream, namely to allow for full build without internal dependencies, only external, and secondly for python2 and python3 simultaneous support. This is semi possible at the moment, but depends on me having the time to debug fully 3 packages - Pythia, XRootD & ROOT itself. On top of that I have shipped several other projects related to this for people that work on Arch Linux to be able to enjoy - Docker images, GitLab CIs, SciKit-HEP packages like uproot and so on. All of this is not a brag, it's not to say I am a better packager, and I am not asking for special attention. But what I want to make something clear - not all things can be said in a PKGBUILD. Packaging intentions matter and simply taking over packages without looking for/listening to the maintainer's comments may be detrimental. For example, the new features I worked to bring to the ROOT ecosystem and ones which I plan to work on in the future are obviously not part of my PKGBUILD. There's precedence for maintainers of specialized software in the AUR to be sponsored to become a Trusted User (though it seems there's a preexisting relationship?). I am not sure how much this applies to me in this case, but if it does I can say the following. I am willing to apply for a Trusted User to maintain ROOT's stack for Arch. I use the ROOT software on a daily basis. I take great care of the package (the whole stack actually) as my work depends on it. I have a test bench and people in my professional area use it and depend on me to bring improvements and new possibilities. I have involved myself and consider it an on-going duty. I have the skills and know-how to maintain the ROOT stack and I can say with certainty that AUR's ROOT package is only second to Fedora's package across other distros. But I also understand it is not perfect and am interested in making it better as I've shown previously here and to its users. If that is not an option, however, then I would like to say to Felix thanks for taking over and to take `root-extra` as the template for his package and drop all other variants. This was always the plan after a few things finally got merged upstream. I can go into detail privately. Regards, Konstantin On Sun, Sep 30, 2018 at 7:49 PM Konstantin Gizdov <arch(a)kge.pw> wrote: > Hi all, > > Thanks for the comments and explanations. > > Firstly, I wanna say that I am not asking for special treatment or > anything. Just wanted to discuss in detail what is going on. Secondly, a > few comments stood out to me (in no particular order). > > I actually want to move the whole "root" tree, but considering its >> number I just started with the easier "leaf" ones. > > This is what I suspected to be honest. The packages that were pulled were > way too specific. Well, if you're going to do this, then I'd like to have a > conversation about it. (below) > > Regarding FS#60248 >> Just release the python2 version of the package in the AUR. > > Sure, just wanted to be sure that's the expected approach. > > What original intention? Packages don't need to meet any intention. >> They should be packaged acording to the guidelines > > Of course, they do - packages exist for a reason and the way they are > packaged expresses the intention - feature support, type of build, > structure, etc. All of that is beyond scope of packaging standards. > > This is fairly common -- while it is nice to get in touch with the AUR >> maintainer, we hardly need *permission* to package something for the >> repos. As always, you can report bugs with the official packages. > > I was not implying *permission* is needed, this is not the point - the > point is letting people, who put their time in, know what's up. In any > case, I listed this as an observation, hence the reason my email was > prompted. > > Denied resolution? >> ... >> I fail to see how you're being "denied" anything. > > Call it what you want, I tried to re-open all 3 bugs but was denied with > little to no comment/explanation. I wanted to know if python2 is going to > be added by Felix or not - instead I was scolded at the bug and here in > emails. The other bug is a bug as confirmed - also denied to re-open > without explanation/investigation. The third bug was re-opened by Filipe > after my initial email - no need to bash me further about it. So all bugs > were closed & denied to re-open until I made a fuss about it here. That to > me is 'denied'. > > Whatever we want. > > Of course, but not helpful. I'll explain. > > You don't get to act as some sort of concerned citizen here to protect >> your packages from the incompetent Devs/TUs when your PKGBUILD contains >> this junk. >> (Sorry for being harsh, but this is the reaction you invite when you set >> yourself up as the superior packager.) > > I am not pertaining to be a superior packager and I am not calling anyone > incompetent. This is completely beside the point. I will explain below. But > to address the state of this particular package - it was added 2 weeks ago > in a rush to push a new version upstream, because I maintain my packages > well. This package and another from same time around need a complete > rewrite, which I'm aware of. And this particular style of package was > copied from another [community] package a long time ago, things have > changed as it was pointed out to me here in the AUR. I had intentions to > fix it as soon as I had time. Picking out one package out of the whole > stack, which I have not had time to properly deal with, proves nothing, but > that you aim to shame, rather than to understand where I'm coming from, why > I am worried and that I'm actually looking to be heard and help. > > That's a message I entered manually each time, with respect :) > > This was not a complaint. Thanks, that's actually the only clue I had my > packages were going somewhere and not just randomly deleted. > > I believe that is not true. I even enabled more functionality in >> libafterimage, actually. > > You mean when you removed `--disable-svg` flag? I might be wrong, but I > think there was a reason to leave it disabled. You'd have to check comments > or Gentoo/Fedora package to be sure. > > I do not intend to package the python2 variant. For the other two, I >> have replied in the tasks. > > Thanks for making that clear. > > So to make all of this more clear to everyone. I took on the task to > maintain CERN's ROOT a couple of years ago and since then I've involved > myself heavily, I'm a contributor to the project and I use it daily in my > work. Colleagues at CERN that use Arch Linux have been depending on me for > this. I have enabled a lot of new features and worked with upstream to make > even more functionality, bug fixes, etc. Currently, I am working on two new > features with upstream, namely to allow for full build without internal > dependencies, only external, and secondly for python2 and python3 > simultaneous support. This is semi possible at the moment, but depends on > me having the time to debug fully 3 packages - Pythia, XRootD & ROOT > itself. On top of that I have shipped several other projects related to > this for people that work on Arch Linux to be able to enjoy - Docker > images, GitLab CIs, SciKit-HEP packages like uproot and so on. > > All of this is not a brag, it's not to say I am a better packager, and I > am not asking for special attention. But what I want to make something > clear - not all things can be said in a PKGBUILD. Packaging intentions > matter and simply taking over packages without looking for/listening to the > maintainer's comments may be detrimental. For example, the new features I > worked to bring to the ROOT ecosystem and ones which I plan to work on in > the future are obviously not part of my PKGBUILD. > > There's precedence for maintainers of specialized software in the AUR to be > > sponsored to become a Trusted User (though it seems there's a preexisting > > relationship?). > > I am not sure how much this applies to me in this case, but if it does I > can say the following. I am willing to apply for a Trusted User to maintain > ROOT's stack for Arch. I use the ROOT software on a daily basis. I take > great care of the package (the whole stack actually) as my work depends on > it. I have a test bench and people in my professional area use it and > depend on me to bring improvements and new possibilities. I have involved > myself and consider it an on-going duty. I have the skills and know-how to > maintain the ROOT stack and I can say with certainty that AUR's ROOT > package is only second to Fedora's package across other distros. But I also > understand it is not perfect and am interested in making it better as I've > shown previously here and to its users. > > If that is not an option, however, then I would like to say to Felix > thanks for taking over and to take `root-extra` as the template for his > package and drop all other variants. This was always the plan after a few > things finally got merged upstream. I can go into detail privately. > > Regards, > Konstantin > > > > On Sun, Sep 30, 2018 at 6:16 AM Felix Yan <felixonmars(a)archlinux.org> > wrote: > >> On 9/30/18 3:57 AM, Konstantin Gizdov wrote: >> > 3. The packages do not provide the same functionality as before, but >> > conflict with the AUR ones. >> >> I believe that is not true. I even enabled more functionality in >> libafterimage, actually. >> >> > 4. I wasn't told anything - my AUR package was deleted with a 'thanks >> for >> > maintaining it' message. >> >> That's a message I entered manually each time, with respect :) >> >> > 5. I've reported a few bugs FS#6024{6,7,8}, but have been denied >> resolution. >> >> I do not intend to package the python2 variant. For the other two, I >> have replied in the tasks. >> >> > - Why? >> > - How many & which will be put into [community]? >> >> I actually want to move the whole "root" tree, but considering its >> number I just started with the easier "leaf" ones. >> >> > - How can I effectively communicate the nuts & bolts to the new >> > maintenaners so to say, to make sure users still get what's expected? >> >> By opening bugs or send me an email directly if it's urgent. >> >> Sorry for the confusion and late reply, it was very late in my TZ when I >> work on the packages. >> >> -- >> Regards, >> Felix Yan >> >>

4 6

[aur-general] PKGBUILD for an .AppImage
by Tom Hale 14 Oct '18

14 Oct '18

I searched through the forums and can't find anything on packaging an AppImage. The only app referenced (upwork-appimage) is no longer available. The particular AppImage in question is: https://github.com/robert7/nixnote2/releases How do I search this mailing list online? What advice would you give with .AppImages? I *could* rip it open, but the only snag I hit was the binary is linked to `libhunspell-1.3.so.0` whereas Arch has `/usr/lib/libhunspell-1.6.so.0`. Would it be a no-no to install this previous libhunspell version in /usr/lib? If using an unextacted AppImage, where should I install the .AppImage itself? /usr/bin/$pkgname.AppImage with a simlink from /usr/bin/$pkgname? Cheers, -- Tom Hale

5 8

[aur-general] Become TU
by Islam Bahnasy 13 Oct '18

13 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I see that 'usbguard' is very useful tool and I depend on it my self so I hope if it's merged to the community repo. I never had a patch to any Arch project yet however I do have a lot of passion towards becoming a TU and maintaining usbguard. https://usbguard.github.io/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZTuDEAsuVmnVQRUQ10eBRotj8oQFAlvB8koACgkQ10eBRotj 8oQNKw//WIpNFGdOEqFCN6eKEr50XzleFZhAEkexa+iVq+gKxGyqwfnNRrXW+K2Q hkP42G0okpIb3Q2PEL+7VLxARMVUSGtMByKHGZfx/SGsjOKbA5XWCoQxVBD9A/ZA CB2hugkZpbW+qajv8jow92poYPOLgnUQfADMJ0c+rRbSdhu7I/+XjSfV8LA6agmR uoLRZDfagEky5UOJhATG+2oQyxqrwpHB4r6CC/+avlNhg/OhHRaYeKo908NmOBMy AOBSHdjWJFbaO7wlnwCjEymhoeNCgUly/NdugBYLzeSV1Vi+ZUGkgXj8jirgndVQ BntW9Zmr/lRu3TU+tByO2jFV4mPtZeCKY/IAsWRfm6rmquzXKqbOS4zAxyX8fIjx PdnDyR2AfTqpuYhJyFVBi9pCsTX9a94BRms9I0exkE6LwVGKfNvJww65+MTjvme/ U/4A/Qyu7D1UoG87mw23quqSu5evdjgGpM+0cB9WaVKVMTduObnDl7RQT+RhD1cL uE/vxC5qgjghtTDBLKXN5WsxHRtZvbSgIeMaSsfYJQ5USNWJoQV+xTMUvFC8Zb/G bKlCZ3MGwOXWGbLFuHHZPncSS21nHIi9VHjI2GU99LfLBvvsh62juMy6FbT07jhF xco9zI63feLzOXgkdHpNM1xIXSKm8EtqHe623WfL7wONHDtcl4o= =q2MX -----END PGP SIGNATURE-----

3 2

[aur-general] Greetings and Documentation Proposals
by Brett Cornwall 09 Oct '18

09 Oct '18

Hello, fellow Archers. My name is Brett and I've been making PKGBUILDs for the AUR for some time under the moniker 'Ainola'. A number of these packages have been kindly pulled into [community] by David Runge. I've since had a desire to get some of my other packages into [community], so I'm interested in working towards getting TU status. I'm also involved in the LibreOffice community (I just got back from the conference in Albania). David has been kind enough to give suggestions to my current packages; I'd love to nab some other packages throughout the AUR, improve them, and get them included in the repositories for mass consumption. I would also like to improve the documentation for the devtools: There are no manpages, /usr/share/docs/ items, or wiki articles. Unless I'm mistaken it appears that the only documentation that currently exists is just invoking the program with -h. I'd like to fix that. :)

4 5

[aur-general] Spam account in AUR
by Rafael Fontenelle 08 Oct '18

08 Oct '18

User brownwilliams [1] seems to be spamming in the AUR, as can be seem in the comments of skypeforlinux-stable-bin [2]. Can this be taken care of? [1] https://aur.archlinux.org/account/brownwilliams/ [2] https://aur.archlinux.org/pkgbase/skypeforlinux-stable-bin/ Best regards, Rafael Fontenelle

2 1

[aur-general] Fwd: FS#60333: namcap exits 0 when errors found (Task closed)
by Tom Hale 08 Oct '18

08 Oct '18

I noticed that even when namcap prints out errors, it still exits 0. I raised this at: https://bugs.archlinux.org/task/60333 It was closed: Reason for closing: Not a bug Additional comments about closing: namcap runs fine, so exiting with an error makes no sense To me the "reason for closing" is like saying that diff should exit 0 when two files are different because diff ran fine. If namcap is to be used in any automated packaging tools (or even my dodgy script), then it makes sense to have meaningful exit codes. And possibly an option to also have warnings also exit non-0 for the persnickety amongst us. I note that the python source returns 0 and 2, but never 1. I'm a newbie here, but I believe my argument has merit, so I raise it here for possible discussion. -- Tom Hale

3 4

[aur-general] RFC: PKGBUILD for nixnote2-git
by Tom Hale 08 Oct '18

08 Oct '18

I took over the disowned package nixnote2-git. Attached is my first attempt at a PKGBUILD. I would appreciate constructive feedback. Thanks in advance, -- Tom Hale

4 10

[aur-general] keep debugging symbols in AUR package
by Friedrich Strohmaier 06 Oct '18

06 Oct '18

Hi all, I use to install AUR package fotoxx. I get some zappcrash message when closing the application an would like to help the author finding the bug. The author sent adapted source packages to get more debugging information. I tried change the PKGBUILD's "pkgrel"- variable to generate several packages containing debugging symbols, but at the end of the build this message looks suspicous: .. -> Stripping unneeded symbols from binaries and libraries... .. What makes packages keep debugging symbols? Tips? Keywords for wiki search? Any hints welcome :o)) -- Friedrich

2 2

[aur-general] Questions about some of my packages being adopted in [community]
by Konstantin Gizdov 30 Sep '18

30 Sep '18

Hi all, I'm writing to hopefully get some clarity on some packages that I maintained in AUR (python-awkward-array, unuran), but have been overtaken now in [community]. Also one other package that I have not maintained 'libafterimage', but dear to me. Firstly, thanks to Felix Yan for picking them up and sorry if the following questions have been asked before and obvious to everyone. This is what I know: 1. Nothing in the core repos depends on them and they are libraries. I've not seen requests to add them before. 2. 'libafterimage' includes a bug that has been reported to AUR, but has not been fixed. I've had to include a patch in my local chain. 3. The packages do not provide the same functionality as before, but conflict with the AUR ones. 4. I wasn't told anything - my AUR package was deleted with a 'thanks for maintaining it' message. 5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution. The reason I'm asking is because over the years I've added and been maintaining some professional software and these packages are part of that chain. Colleagues in the field have become accustomed to me for packaging with care and updating with new features. But now, obviously that is changing and people are going to flock if something doesn't work as expected. So this is sort of me getting ahead of the wind and basically asking the question: - Why? - How many & which will be put into [community]? - How can I effectively communicate the nuts & bolts to the new maintenaners so to say, to make sure users still get what's expected? - Is there anything I can do if new packages do not meet what the original intention was - apart from making a conflicting AUR package? Thanks in advance. -- Regards, Konstantin

6 6

[aur-general] [News] DigitalOcean "supporting" Arch Linux
by Eduardo Machado 26 Sep '18

26 Sep '18

Hi folks, Firstly, i am not a digitalocean affiliated, but i use their services. A long time ago, Arch Linux was one the supported OSes, latter they dropped this support. Now, although it is not officially supported again they just launched the ability to upload Custom Images into DigitalOcean. You can now import the OS of your choice directly into DigitalOcean and start a Droplet. [1] [1] https://blog.digitalocean.com/custom-images/ --- Eduardo M. Machado

1 0

[aur-general] Spam account: jennyhannb
by WorMzy Tykashi 26 Sep '18

26 Sep '18

Hi TUs, there's another spam account making the rounds: https://aur.archlinux.org/account/jennyhannb/ Cheers, WorMzy

2 1

[aur-general] nextcloud-client: suggestion of moving to [community]
by Damian Nowak 21 Sep '18

21 Sep '18

Hello! Back in 2014, I sent the same request for owncloud-client. This time, I'd like to suggest nextcloud-client [1] as a potential candidate for [community]. It has 240 votes, nextcloud (the webapp) is already in [community], while owncloud (webapp) was moved to AUR a long time ago. Please note Nextcloud client is fully compatible with Owncloud server, and vice versa. I still use Owncloud server from AUR on my server, while using Nextcloud client across all my devices (Arch Linux, OSX and Android). Thank you for you consideration. CC Antonio, a TU maintainer of owncloud-client [2] [1]: https://aur.archlinux.org/packages/nextcloud-client/ [2]: https://www.archlinux.org/packages/community/x86_64/owncloud-client/ -Nowaker

2 1

[aur-general] Spam account: vedant
by Florian Bruhin 17 Sep '18

17 Sep '18

Yet another spambot: https://aur.archlinux.org/account/vedant/comments Florian -- https://www.qutebrowser.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/

1 0