- Aur-general - lists.archlinux.org

[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

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

17 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 * 4 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] (4 total) == * ibus-skk-1.4.1.20140813-1 (i686) 0/1 signoffs * libskk-1.0.1-3 (i686) 0/1 signoffs * ibus-skk-1.4.1.20140813-1 (x86_64) 0/2 signoffs * libskk-1.0.1-3 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours ==

1 0

[aur-general] replacing packages with split packages: how to merge?
by Xyne 16 Aug '14

16 Aug '14

Hi, Is there a standard procedure for replacing packages with split packages while preserving votes? For example, lets say there are two normal packages in the AUR, "foo-bar" and "foo-baz". foo-bar has 20 votes, foo-baz has 15. The maintainer realizes that he can produce both packages using a split package "foo", but name collision detection will prevent him from uploading foo if it contains foo-bar or foo-baz, which must be deleted first. If they are deleted, the votes are lost. At first I thought that the pkgbase could be uploaded without anything in the pkgnames array as a placeholder for merging, but that would lump all the votes into the pkgbase and not the individual packages. Am I missing something? If not then it seems that we need some sort of pending merge queue. Thoughts? Regards, Xyne

2 3

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

16 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 * 4 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] (4 total) == * ibus-skk-1.4.1.20140813-1 (i686) 0/1 signoffs * libskk-1.0.1-3 (i686) 0/1 signoffs * ibus-skk-1.4.1.20140813-1 (x86_64) 0/2 signoffs * libskk-1.0.1-3 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. bisson - 6 signoffs 2. fyan - 3 signoffs

1 0

[aur-general] Removal of kla
by Omid Nikta 15 Aug '14

15 Aug '14

Please remove the out of date package kla. https://aur.archlinux.org/packages/kla/

2 1