August 2014 - Aur-general - lists.archlinux.org

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 22 Aug '14

22 Aug '14

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 8 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (8 total) == * avr-libc-1.8.1-1 (any) 0/2 signoffs * sunpinyin-data-1:2.0.3.20140820-1 (any) 0/2 signoffs * avr-gcc-4.9.1-1 (i686) 0/1 signoffs * avr-gdb-7.8-1 (i686) 0/1 signoffs * sunpinyin-2.0.3.20140820-1 (i686) 0/1 signoffs * avr-gcc-4.9.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.8-1 (x86_64) 0/2 signoffs * sunpinyin-2.0.3.20140820-1 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours ==

1 0

[aur-general] Maintenance issues with metasploit-git package
by 21 Aug '14

21 Aug '14

I'd like to bring the community's attention to the following package: https://aur.archlinux.org/packages/metasploit-git/ It has multiple issues and does not follow pkgbuild guidelines and best practices: 1. The build script appends instructions into user-specific and shell-specific ~/.bash_profile on build time. 2. It dumps everything into /usr/local. This is against the very first point in https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_etiqu… 3. The post-install script tells the user to ignore a warning about breakage. It warns about breaking ruby for all other users when the instruction is run with root permissions. I haven't tested this one for obvious reasons. 4. The package appends to $PATH which overshadows the binaries of latest ruby package with those of 1.9 version for the current user (via same instruction as 1.). The current maintainer refuses collaboration. What's the best I can do in a situation like this? - Babken Vardanyan (axper)

4 4

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 21 Aug '14

21 Aug '14

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 8 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 8 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (8 total) == * avr-libc-1.8.1-1 (any) * sunpinyin-data-1:2.0.3.20140820-1 (any) * avr-gcc-4.9.1-1 (i686) * avr-gdb-7.8-1 (i686) * sunpinyin-2.0.3.20140820-1 (i686) * avr-gcc-4.9.1-1 (x86_64) * avr-gdb-7.8-1 (x86_64) * sunpinyin-2.0.3.20140820-1 (x86_64) == Incomplete signoffs for [community] (8 total) == * avr-libc-1.8.1-1 (any) 0/2 signoffs * sunpinyin-data-1:2.0.3.20140820-1 (any) 0/2 signoffs * avr-gcc-4.9.1-1 (i686) 0/1 signoffs * avr-gdb-7.8-1 (i686) 0/1 signoffs * sunpinyin-2.0.3.20140820-1 (i686) 0/1 signoffs * avr-gcc-4.9.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.8-1 (x86_64) 0/2 signoffs * sunpinyin-2.0.3.20140820-1 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. foutrelis - 4 signoffs 2. anatolik - 1 signoffs

1 0

[aur-general] Forgot AUR username
by Bruno Saraiva 20 Aug '14

20 Aug '14

I did already reset my password, AND I thought I knew the right username. Even tried different ones in hopes of hitting the right one before bothering you guys with this. Could you be so kind to send me my username, attached to this email account? Thanks and have a nice one, -- Bruno Saraiva

2 1

[aur-general] Pinning dependency versions in PKGBUILDs?
by Florian Bruhin 19 Aug '14

19 Aug '14

Hi, I'm maintaining the vim-full[1] package which is a vim with all the gvim features (Ruby/Lua/Python/Perl/Netbeans) but without GTK/X. Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package). However that makes upgrading vim-runtime difficult, because pacman doesn't know about the vim-full upgrade. A possible solution is to build via `makepkg -d` (ignoring the old vim-runtime version), then upgrading both vim-full and vim-runtime. Should I just not pin the version at all (as in "partial upgrades aren't supported anyways") to avoid these problems? Florian [1] https://aur.archlinux.org/packages/vim-full/ -- http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

6 11

[aur-general] AUR GIT and Bug Tracker
by mrlemux＠gmail.com 19 Aug '14

19 Aug '14

8 17

[aur-general] AUR notification emails don't mention which package they refer to
by Hugo Osvaldo Barrera 18 Aug '14

18 Aug '14

I just got the following email from AUR: ----- Forwarded message from notify(a)aur.archlinux.org ----- > Date: Sun, 17 Aug 2014 21:13:22 +0000 (UTC) > From: notify(a)aur.archlinux.org > Subject: [PRQ#467] Request Accepted > To: aur-requests(a)archlinux.org > Cc: hugo(a)barrera.io > X-Mailer: AUR > > Request #467 has been accepted by arcanis [1]: > > already orphaned > > [1] https://aur.archlinux.org/account/arcanis/ > ----- End forwarded message ----- I've put several requests up in the past, and I've no idea to which particular one this email is refering to. It does not mention the related package, so I've no way of knowing what package has been orphaned. Maybe TUs have access to requests, but normal users don't. So basically, I now know that some package has been orphaned, but not which one. Can a fix for this be considered for future update? Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?

2 2

[aur-general] [request] delete betaradio-svn
by Daniel YC Lin 18 Aug '14

18 Aug '14

Just found betaradio-svn have changed to betaradio-git. Please remove the old PKGBUILD in AUR.

3 2

[aur-general] AUR request mentality
by carstene1ns 17 Aug '14

17 Aug '14

While the new AUR request functionality is a good thing and widely accepted (over 500 requests yet), it also brings us some problems: (1)inhibition threshold - It is much easier to remove a package now. (2)response time - Requests get accepted before the package maintainer or others have time to explain or react. There may be other problems, but these two bugged me since it was implemented. ## For the tl;dr version, please skip the following remarks. ## (1)This goes for both the requester and the TU that accepts it. I have seen requests that consisted only of two words. Back then, when we were forced to use email, you could read at least a whole sentence and have a rationale. Also some TUs do not seem to care about providing a reason, why a certain request has been accepted or declined. There was a feedback mail back then, so the requester knew there was someone working on it. (2)Orphan requests have a grace period of 14 days. That is good, but for other requests there is none. So packages get deleted before they even could get fixed. Some TUs do not even question the reason for the request and just delete it without investigating. Now you might ask me to provide some evidence... Let's blame two users today: FredBezies and foutrelis. FredBezies seems to try finding "dead projects" in the AUR. He does so by clicking on the homepage link and if it does not display the project website, he files a deletion request stating the project/homepage is dead (no googling, no word to the maintainer). Otherwise (for VCS packages) he looks at the last commit date and files a deletion request, if it has not been updated in 3 years, again with the reason "dead project". For example in case of the 'tasque-git' package the url of all gnome-related packages changed to include "/Apps/" in the wiki link and there has been no redirection for this particular package. However, there have been commits this year and the package is therefore not dead. foutrelis seem to like clean lists, as he just accepted any deletion request that was open today (including the absurd ones by FredBezies), without reading the mailing list before and without providing a reason. If it does not really make sense to answer questions and remarks like Scimmia and I (and others!) did, the aur-requests mailing list should be read-only. tl;dr: What can we do to make things better? Should we (re)write the policy for TUs about accepting AUR requests? They should at least investigate. I think a good start would be to have users provide real reasons for deleting a package and trying to fix them otherwise (themselves or with help from the maintainer). best regards, carstene1ns

14 21

[aur-general] Package deletion request for sublime-text-beta
by Ronald Kinard 17 Aug '14

17 Aug '14

Hello, I accidentally uploaded a package which is an effective duplicate of sublime-text-dev, named sublime-text-beta. I'm requesting that my package sublime-text-beta be deleted. https://aur.archlinux.org/packages/sublime-text-beta/ https://aur.archlinux.org/packages/sublime-text-dev/ Thanks

4 3