- Aur-general - lists.archlinux.org

[aur-general] What stops more packages moving from AUR to Community?
by Steven Honeyman 27 May '14

27 May '14

Reading the wiki, I got the impression that AUR packages with more than 10 votes would be considered worthy enough to move to the Community repo. I understand that the ones with thousands of votes haven't moved due to licence type issues or binary requirements (e.g. spotify, minecraft, teamviewer, acrobat reader)... but something as simple as Archey https://aur.archlinux.org/packages/archey/ currently has 415 votes, and is used my many people for inclusions on screenshots etc (I found it by searching for it, after seeing it on the forums!) - that kind of thing I would have expected would be a "no-brainer" to be moved across into Community. I count roughly 9100 packages in the AUR with more than 10 votes! Is it a lack of TUs having time to maintain more than they currently do that's holding back many of them? (that's not meant as a criticism of the TUs; being understaffed is a valid explanation) Either way, perhaps the Wiki should be changed to say 1000 votes instead :D

4 3

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

27 May '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 * 8 fully signed off packages * 21 packages missing signoffs * 1 package 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] (21 total) == * waf-1.7.15-2 (any) 1/2 signoffs * alltray-0.7.5.1dev-3 (i686) 0/1 signoffs * bamf-0.5.0-3 (i686) 0/1 signoffs * electricsheep-2.7b33-16 (i686) 0/1 signoffs * gdesklets-0.36.3-5 (i686) 0/1 signoffs * metacity-2.34.13-6 (i686) 0/1 signoffs * nautilus-actions-3.2.3-3 (i686) 0/1 signoffs * alltray-0.7.5.1dev-3 (x86_64) 0/2 signoffs * bamf-0.5.0-3 (x86_64) 0/2 signoffs * caja-actions-1.7.0-3 (x86_64) 1/2 signoffs * electricsheep-2.7b33-16 (x86_64) 0/2 signoffs * gdesklets-0.36.3-5 (x86_64) 0/2 signoffs * marco-1.8.0-2 (x86_64) 1/2 signoffs * mate-applets-1.8.0-4 (x86_64) 1/2 signoffs * mate-netspeed-1.8.0-2 (x86_64) 1/2 signoffs * mate-nettool-1.8.1-8 (x86_64) 1/2 signoffs * mate-system-monitor-1.8.0-2 (x86_64) 1/2 signoffs * mate-utils-1.8.0-2 (x86_64) 1/2 signoffs * metacity-2.34.13-6 (x86_64) 0/2 signoffs * nautilus-actions-3.2.3-3 (x86_64) 0/2 signoffs * nemiver-0.9.5-2 (x86_64) 1/2 signoffs == Completed signoffs (8 total) == * caja-actions-1.7.0-3 (i686) * marco-1.8.0-2 (i686) * mate-applets-1.8.0-4 (i686) * mate-netspeed-1.8.0-2 (i686) * mate-nettool-1.8.1-8 (i686) * mate-system-monitor-1.8.0-2 (i686) * mate-utils-1.8.0-2 (i686) * nemiver-0.9.5-2 (i686) == All packages in [community-testing] for more than 14 days (1 total) == * waf-1.7.15-2 (any), since 2014-03-21 == Top five in signoffs in last 24 hours == 1. flexiondotorg - 14 signoffs 2. eric - 3 signoffs 3. anatolik - 2 signoffs

1 0

[aur-general] Package orphaning policy improvement - RFC
by Nowaker 26 May '14

26 May '14

Hey, Currently one has to contact the maintainer and wait 2 weeks before reaching a TU on the ML to take over the package. I think this is totally OK when the maintainer really maintains the package, e.g. has generally frequent updates, responds to the comments, etc. However, this is an overhead when it's obvious a package is no longer maintained. For example, those marked out-of-date for more than 3 months, or those that have numbers of comments requesting update with no single response from the maintainer. It includes a situation when a maintainer is otherwise active on AUR, e.g. they update their other packages. The fact is they don't upgrade the very one package that people are interested in - otherwise a package wouldn't have been marked out-of-date in the first place. What do you think about auto-orhpaning packages that stay marked out-of-date for more than, say, 3 months? Done automatically by AUR, with no request on ML. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu

9 9

[aur-general] Orphan request: zramswap
by JM 26 May '14

26 May '14

Hi, I am using the package zramswap 1.1.1 from AUR and I was surprised a few days ago to see an update making it bump from 1.1.1 to 2.8.1 (and 2.9.1 since yesterday), so I have taken a close look at the PKGBUILD then I headed to AUR: someone has created a script having for name systemd-swap, and published it on two different pages, the zramswap page where it has the name of zramswap -- and on a systemd-swap AUR page where it had the name "systemd-swap", removed very recently and ported to Community: https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/… as per the last comment on the zramswap page: https://aur.archlinux.org/packages/zramswap/ Currently, this is what zramswap used to look like: http://pastebin.fr/35980 and the start/stop zramswap.service script: http://pastebin.fr/35981 I don't have any bad feeling about the new script, but I really appreciate the job done by the "old" one, which has worked perfectly so far. I use the kernel 3.14.4-1-ARCH x86_64, a nvidia current driver, and zram is loaded and working everyday during several hours. And this is what it looks like now, after the new program has replaced this script which works well, with one script which provides other features: https://github.com/TimofeyTitovets/systemd-swap/blob/master/systemd-swap.sh So you can see the differences which are important. I posted an initial comment on the AUR zramswap page on 2014-05-21 22:39 to explain that I was in disagreement with the change done, as the zramswap did only one thing --and does it well-- take care of the zram module. My argument being rejected, I am asking here to the Trusted Users to see what you can do about it? I have been a long time user of the compcache package (from the original project: https://code.google.com/p/compcache/ ) and later when the main component became the zram kernel module I started using the script meant to load and set it up, having for name zramswap, which I am still using now as I said, at it's version 1.1.1. My machine has 4 Gb ram, but sometimes with Virtualbox running along with other greedy applications it is very good to have. I would appreciate it a lot if things where put back as they were with the script which takes care of zram only and nothing else, and be orphaned as it should have been, in order to allow anyone interested to adopt it and take care of it. I'll stay tuned. Regards, Mélodie

2 2

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

26 May '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 * 1 fully signed off package * 30 packages missing signoffs * 1 package 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] (30 total) == * waf-1.7.15-2 (any) 1/2 signoffs * alltray-0.7.5.1dev-3 (i686) 0/1 signoffs * bamf-0.5.0-3 (i686) 0/1 signoffs * caja-actions-1.7.0-3 (i686) 0/1 signoffs * electricsheep-2.7b33-16 (i686) 0/1 signoffs * gdesklets-0.36.3-5 (i686) 0/1 signoffs * marco-1.8.0-2 (i686) 0/1 signoffs * mate-applets-1.8.0-4 (i686) 0/1 signoffs * mate-netspeed-1.8.0-2 (i686) 0/1 signoffs * mate-nettool-1.8.1-8 (i686) 0/1 signoffs * mate-system-monitor-1.8.0-2 (i686) 0/1 signoffs * mate-utils-1.8.0-2 (i686) 0/1 signoffs * metacity-2.34.13-6 (i686) 0/1 signoffs * nautilus-actions-3.2.3-3 (i686) 0/1 signoffs * xbmc-13.0-4 (i686) 0/1 signoffs * alltray-0.7.5.1dev-3 (x86_64) 0/2 signoffs * bamf-0.5.0-3 (x86_64) 0/2 signoffs * caja-actions-1.7.0-3 (x86_64) 0/2 signoffs * electricsheep-2.7b33-16 (x86_64) 0/2 signoffs * gdesklets-0.36.3-5 (x86_64) 0/2 signoffs * marco-1.8.0-2 (x86_64) 0/2 signoffs * mate-applets-1.8.0-4 (x86_64) 0/2 signoffs * mate-netspeed-1.8.0-2 (x86_64) 0/2 signoffs * mate-nettool-1.8.1-8 (x86_64) 0/2 signoffs * mate-system-monitor-1.8.0-2 (x86_64) 0/2 signoffs * mate-utils-1.8.0-2 (x86_64) 0/2 signoffs * metacity-2.34.13-6 (x86_64) 0/2 signoffs * nautilus-actions-3.2.3-3 (x86_64) 0/2 signoffs * nemiver-0.9.5-2 (x86_64) 1/2 signoffs * xbmc-13.0-4 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * nemiver-0.9.5-2 (i686) == All packages in [community-testing] for more than 14 days (1 total) == * waf-1.7.15-2 (any), since 2014-03-21 == Top five in signoffs in last 24 hours == 1. arodseth - 2 signoffs

1 0

[aur-general] Deletion request: quark
by Aaron DeVore 25 May '14

25 May '14

I am the maintainer of the quark package. I can't get it to compile, there hasn't been an additional vote in years, and no upstream activity in almost 4 years. Please delete. https://aur.archlinux.org/packages/quark/

2 1

[aur-general] Account deletion request
by Ypnose 25 May '14

25 May '14

Hi, As I requested it on the forum[1], I would like to have my AUR account deleted. I already checked "Inactive" box, but I want to have it totally removed. My nickname is Ypnose Thanks Y. [1] https://bbs.archlinux.org/viewtopic.php?id=180319

3 3

Re: [aur-general] Package orphaning policy improvement - RFC
by Steven Honeyman 25 May '14

25 May '14

As a newcomer to packaging for the AUR, that was one of the things I thought "I wonder why they don't do that already" I'd read about some September cleanups (2011/2012 only?). Also, how about if orphaned for more than 3 months, then delete? There are some really outdated packages on there! On 25 May 2014 16:06, Nowaker <enwukaer(a)gmail.com> wrote: > Hey, > > Currently one has to contact the maintainer and wait 2 weeks before reaching > a TU on the ML to take over the package. I think this is totally OK when the > maintainer really maintains the package, e.g. has generally frequent > updates, responds to the comments, etc. > > However, this is an overhead when it's obvious a package is no longer > maintained. For example, those marked out-of-date for more than 3 months, or > those that have numbers of comments requesting update with no single > response from the maintainer. > > It includes a situation when a maintainer is otherwise active on AUR, e.g. > they update their other packages. The fact is they don't upgrade the very > one package that people are interested in - otherwise a package wouldn't > have been marked out-of-date in the first place. > > What do you think about auto-orhpaning packages that stay marked out-of-date > for more than, say, 3 months? Done automatically by AUR, with no request on > ML. > > -- > Kind regards, > Damian Nowak > StratusHost > www.AtlasHost.eu

2 1

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

25 May '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 * 32 packages missing signoffs * 1 package 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] (32 total) == * clusterssh-4.02.04-1 (any) 0/2 signoffs * waf-1.7.15-2 (any) 1/2 signoffs * alltray-0.7.5.1dev-3 (i686) 0/1 signoffs * bamf-0.5.0-3 (i686) 0/1 signoffs * caja-actions-1.7.0-3 (i686) 0/1 signoffs * electricsheep-2.7b33-16 (i686) 0/1 signoffs * gdesklets-0.36.3-5 (i686) 0/1 signoffs * marco-1.8.0-2 (i686) 0/1 signoffs * mate-applets-1.8.0-4 (i686) 0/1 signoffs * mate-netspeed-1.8.0-2 (i686) 0/1 signoffs * mate-nettool-1.8.1-8 (i686) 0/1 signoffs * mate-system-monitor-1.8.0-2 (i686) 0/1 signoffs * mate-utils-1.8.0-2 (i686) 0/1 signoffs * metacity-2.34.13-6 (i686) 0/1 signoffs * nautilus-actions-3.2.3-3 (i686) 0/1 signoffs * nemiver-0.9.5-2 (i686) 0/1 signoffs * xbmc-13.0-4 (i686) 0/1 signoffs * alltray-0.7.5.1dev-3 (x86_64) 0/2 signoffs * bamf-0.5.0-3 (x86_64) 0/2 signoffs * caja-actions-1.7.0-3 (x86_64) 0/2 signoffs * electricsheep-2.7b33-16 (x86_64) 0/2 signoffs * gdesklets-0.36.3-5 (x86_64) 0/2 signoffs * marco-1.8.0-2 (x86_64) 0/2 signoffs * mate-applets-1.8.0-4 (x86_64) 0/2 signoffs * mate-netspeed-1.8.0-2 (x86_64) 0/2 signoffs * mate-nettool-1.8.1-8 (x86_64) 0/2 signoffs * mate-system-monitor-1.8.0-2 (x86_64) 0/2 signoffs * mate-utils-1.8.0-2 (x86_64) 0/2 signoffs * metacity-2.34.13-6 (x86_64) 0/2 signoffs * nautilus-actions-3.2.3-3 (x86_64) 0/2 signoffs * nemiver-0.9.5-2 (x86_64) 0/2 signoffs * xbmc-13.0-4 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (1 total) == * waf-1.7.15-2 (any), since 2014-03-21 == Top five in signoffs in last 24 hours == 1. allan - 8 signoffs 2. anatolik - 2 signoffs

1 0

[aur-general] Removal request
by Nuno Araujo 25 May '14

25 May '14

Hi Could a TU please remove glade3-gtk2 [1]? It's a duplicate of glade-gtk2 [2]. Both packages were orphaned and I took ownership and updated the glade-gtk2 [2] to the latest release. Thank you [1] https://aur.archlinux.org/packages/glade3-gtk2/ [2] https://aur.archlinux.org/packages/glade-gtk2/ -- Nuno Araujo <nuno.araujo(a)russo79.com> http://www.russo79.com

2 1