- Aur-general - lists.archlinux.org

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

09 Jul '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 * 1 package 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] (1 total) == * python-urllib3-1.9-1 (any) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. bisson - 3 signoffs

1 0

[aur-general] Troll account
by Rob McCathie 09 Jul '14

09 Jul '14

Hello AUR General, I am a Manjaro team member and have been an Arch user for ~5 years. I still run Arch proper on many systems and test my AUR packages on Arch proper (just thought i'd get that out of the way ;-p ) We've had to remove someone from our team recently due to their abusing of their forum account's moderation privileges and some other stuff. This person has gone on to prove just how right we were to get rid of them by launching malicious attacks on our wiki and attempts on some other web services. (There's no doubt it's the same person, he directly threatened us with malicious action.) It appears now he is attacking Manjaro team members with any avenue he can find. This account here: https://aur.archlinux.org/account/kingrobbo Has been made for no reason but to troll (myself and possibly other Manjaro devs with AUR accounts). It flagged all of my AUR packages out-of-date (of which none are) and sent a delete request for one (aqualung). The name "kingrobbo" tells me with 100% certainty that it's the same now-troll we've been dealing with, if any AUR admins want more information on this and why i know it's the same person please feel free to email me privately. For now i haven't set all my packages to not-out-of-date, so the AUR admins get a chance to see what i mean. I cannot apologise enough for our problems spilling onto AUR, obviously this is the last thing we want. Of course how to respond is up to you, but my hope is, obviously, that you'll delete their AUR account. Regards and apologies, Rob McCathie

2 1

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

08 Jul '14

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 1 new package in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 9 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 (1 total) == * python-urllib3-1.9-1 (any) == Incomplete signoffs for [community] (9 total) == * python-urllib3-1.9-1 (any) 0/2 signoffs * acpi_call-lts-1.1.0-6 (i686) 0/1 signoffs * r8168-lts-8.038.00-3 (i686) 0/1 signoffs * tp_smapi-lts-0.41-28 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.12-2 (i686) 0/1 signoffs * acpi_call-lts-1.1.0-6 (x86_64) 0/2 signoffs * r8168-lts-8.038.00-3 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-28 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.12-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. bpiotrowski - 4 signoffs 2. fyan - 3 signoffs 3. tpowa - 2 signoffs

1 0

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

07 Jul '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) == * acpi_call-lts-1.1.0-6 (i686) 0/1 signoffs * r8168-lts-8.038.00-3 (i686) 0/1 signoffs * tp_smapi-lts-0.41-28 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.12-2 (i686) 0/1 signoffs * acpi_call-lts-1.1.0-6 (x86_64) 0/2 signoffs * r8168-lts-8.038.00-3 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-28 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.12-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. tpowa - 8 signoffs 2. thomas - 5 signoffs 3. thestinger - 4 signoffs

1 0

[aur-general] Package requests & wiki cleanup strategy
by Jakub Klinkovský 07 Jul '14

07 Jul '14

Hello all, few months ago, in April and May, I have organized a community action to clean up broken links to AUR (and official) packages on the Arch wiki (see [0-2]). This has been done with a bot [3], which goes through all pages on Arch wiki with at least one package link and detects broken links. This is not very good strategy for multiple reasons: 1) It relies on one man to run the bot, process the log and create the appropriate wiki page. It is also very demanding task as one pass takes over four hours to execute and currently requires manual intervention about every 30 minutes. 2) It is safe to assume that only the newest broken links will be updated or removed. There are hundreds of broken links on unmaintained pages, usually in a language that no Archer speaks. These links clutter the list and make finding the recent broken links difficult. 3) Finding the information necessary to update the link (or the relevant section if necessary) is lengthy, sometimes impossible if the person is not directly involved in the software or its (re)moval in the repos. (Not all package deletions/merges/moves are "logged" in the ML, right?) There are solutions for 1 and 2 (improve the bot and make it run on a server, filter out ancient broken links), but 3 is the main reason. I would like to discuss a strategy that would take the issue more "from the source". The recently introduced "File Request" feature of the AUR backend should come in handy. Ideally, the wiki would be updated by the person responsible for the package's (re)moval (i.e. the person filing the request, if there is one), so I was thinking that something like "please update the wiki" (along with some useful information, e.g. link to wiki search query with the package's name) could be added to the file request form. Also some instructions could be put in the wiki and linked to. Next, it should be ensured that the information necessary for updating the link is searchable, even after longer time. The aur-requests ML is perfect for this, but there are actions not going through the file request feature (e.g. action on TU's initiative), right? Plus also the actions over official repos. I haven't given much thought to this yet, but there could be a public log of all actions in the AUR and (separately) official repositories. The information necessary are timestamp, pkgname, action type and reason (link to aur-requests if available). Any other ideas, comments, improvements? I haven't followed the development of AUR for the past two months, so I might have missed something... Regards, [0]: https://mailman.archlinux.org/pipermail/arch-general/2014-April/035793.html [1]: https://wiki.archlinux.org/index.php/User:Lahwaacz.bot/Report_2014-04-05 [2]: https://wiki.archlinux.org/index.php/User:Lahwaacz.bot/Report_2014-05-11 [3]: https://wiki.archlinux.org/index.php/Wiki_Monkey -- jlk

1 0

[aur-general] AUR package deletion request – Google Music Manager
by Dave Blair 06 Jul '14

06 Jul '14

Hi, I screwed up yesterday and submitted a package to the AUR only to discover that the package was already there, No clue how this happened, I can only guess that I was using the wrong search terms to look for the package before I created nine and couldn't find it (using google play instead of google music in the search string), or maybe just misspelled something in the search. The original package is here: https://aur.archlinux.org/packages/google-musicmanager Mine is here: https://aur.archlinux.org/packages/google-musicmanager-beta Sorry for all the bother! Best, Dave

2 1

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

06 Jul '14

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 10 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 18 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 (10 total) == * gitg-0.3.3-1 (i686) * libgit2-1:0.21.0-1 (i686) * libgit2-glib-0.0.18-1 (i686) * python-pygit2-0.21.0-0 (i686) * subsurface-4.1-2 (i686) * gitg-0.3.3-1 (x86_64) * libgit2-1:0.21.0-1 (x86_64) * libgit2-glib-0.0.18-1 (x86_64) * python-pygit2-0.21.0-0 (x86_64) * subsurface-4.1-2 (x86_64) == Incomplete signoffs for [community] (18 total) == * acpi_call-lts-1.1.0-6 (i686) 0/1 signoffs * gitg-0.3.3-1 (i686) 0/1 signoffs * libgit2-1:0.21.0-1 (i686) 0/1 signoffs * libgit2-glib-0.0.18-1 (i686) 0/1 signoffs * python-pygit2-0.21.0-0 (i686) 0/1 signoffs * r8168-lts-8.038.00-3 (i686) 0/1 signoffs * subsurface-4.1-2 (i686) 0/1 signoffs * tp_smapi-lts-0.41-28 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.12-2 (i686) 0/1 signoffs * acpi_call-lts-1.1.0-6 (x86_64) 0/2 signoffs * gitg-0.3.3-1 (x86_64) 0/2 signoffs * libgit2-1:0.21.0-1 (x86_64) 0/2 signoffs * libgit2-glib-0.0.18-1 (x86_64) 0/2 signoffs * python-pygit2-0.21.0-0 (x86_64) 0/2 signoffs * r8168-lts-8.038.00-3 (x86_64) 0/2 signoffs * subsurface-4.1-2 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-28 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.12-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. fyan - 5 signoffs 2. tpowa - 4 signoffs 3. anatolik - 3 signoffs 4. eric - 2 signoffs 5. thestinger - 1 signoffs

1 0

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

05 Jul '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) == * acpi_call-lts-1.1.0-6 (i686) 0/1 signoffs * r8168-lts-8.038.00-3 (i686) 0/1 signoffs * tp_smapi-lts-0.41-28 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.12-2 (i686) 0/1 signoffs * acpi_call-lts-1.1.0-6 (x86_64) 0/2 signoffs * r8168-lts-8.038.00-3 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-28 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.12-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. bisson - 9 signoffs

1 0

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

04 Jul '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) == * acpi_call-lts-1.1.0-6 (i686) * r8168-lts-8.038.00-3 (i686) * tp_smapi-lts-0.41-28 (i686) * virtualbox-modules-lts-4.3.12-2 (i686) * acpi_call-lts-1.1.0-6 (x86_64) * r8168-lts-8.038.00-3 (x86_64) * tp_smapi-lts-0.41-28 (x86_64) * virtualbox-modules-lts-4.3.12-2 (x86_64) == Incomplete signoffs for [community] (8 total) == * acpi_call-lts-1.1.0-6 (i686) 0/1 signoffs * r8168-lts-8.038.00-3 (i686) 0/1 signoffs * tp_smapi-lts-0.41-28 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.12-2 (i686) 0/1 signoffs * acpi_call-lts-1.1.0-6 (x86_64) 0/2 signoffs * r8168-lts-8.038.00-3 (x86_64) 0/2 signoffs * tp_smapi-lts-0.41-28 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.12-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. allan - 7 signoffs 2. fyan - 6 signoffs 3. thestinger - 5 signoffs

1 0

[aur-general] AUR 3.2.0 released
by Lukas Fleischer 03 Jul '14

03 Jul '14

Hello, I am pleased to announce that AUR 3.2.0 has just been released. The official AUR setup [1] has already been updated. You can now send deletion, merge and orphan requests by using the "File Request" link in the package actions box. Please use the web interface instead of manually sending mails to aur-general or aur-requests from now on. Note to all AUR helper maintainers: There also is a new version of the RPC interface (v3) that makes the result values types a bit more consistent. See FS#40963 [2] for details. For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4]. [1] https://aur.archlinux.org/ [2] https://bugs.archlinux.org/task/40963 [3] https://projects.archlinux.org/aur.git/log/?id=v3.2.0 [4] https://bugs.archlinux.org/index.php?project=2

2 1