July 2013 - Aur-general - lists.archlinux.org

[aur-general] Merge request for two GTK Themes
by Edoardo Maria Elidoro 09 Jul '13

09 Jul '13

Hi, following Maxime suggestions, I renamed two of my packages. Please merge: https://aur.archlinux.org/packages/gtk-theme-stepintofreedom/ into https://aur.archlinux.org/packages/gtk-theme-step-into-freedom/ and https://aur.archlinux.org/packages/gtk-theme-ubuntusunrise/ into https://aur.archlinux.org/packages/gtk-theme-ubuntu-sunrise/ Thanks, have a nice day. Edoardo

2 1

[aur-general] Deletion request: quodlibet-plugins-hg
by Gary van der Merwe 09 Jul '13

09 Jul '13

Please delete quodlibet-plugins-hg. I have now include this in quodlibet-hg as a split package. Thanks, Gary

2 2

[aur-general] Are split packages ok for aur.
by Gary van der Merwe 09 Jul '13

09 Jul '13

Hi Is it OK to submit split packages to aur, using the workaround used by linux-zen (https://aur.archlinux.org/packages/li/linux-zen/PKGBUILD)? This is the PKGBUILD I would like to submit: http://fpaste.org/23879/ Are there any implications that I need to take into account? How do aur helpers handle split packages? (I started reading this bug report to try find the answers: https://bugs.archlinux.org/task/16394 , but there is much noise and little signal, hence I'm asking here.) Thanks, Gary

2 2

[aur-general] Removal of: quodlibet-pygobject-hg and quodlibet-pygobject-plugins-hg
by Pedro Martinez-Julia 09 Jul '13

09 Jul '13

Hi, I, as submitter and maintainer, hereby request the removal of: quodlibet-pygobject-hg https://aur.archlinux.org/packages/quodlibet-pygobject-hg/ quodlibet-pygobject-plugins-hg https://aur.archlinux.org/packages/quodlibet-pygobject-plugins-hg/ The reason for both removals is that they are based on branches which are now merged into the main packages, which already are in [extra]. Thank you very much for your support. Regards, Pedro -- Pedro Martinez-Julia Department of Communication and Information Engineering Faculty of Computer Science University of Murcia Email: pedromj(a)gmail.com, pedromj(a)um.es --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem ***

2 1

[aur-general] Merge request: various gtk-theme
by Edoardo Maria Elidoro 09 Jul '13

09 Jul '13

2 1

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

09 Jul '13

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 30 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 (2 total) == * perl-gd-2.50-2 (i686) * perl-gd-2.50-2 (x86_64) == Incomplete signoffs for [community] (30 total) == * apcupsd-3.14.10-7 (i686) 0/1 signoffs * bbswitch-0.7-5 (i686) 0/1 signoffs * fceux-2.2.1.1-2 (i686) 0/1 signoffs * fswebcam-20110717-3 (i686) 0/1 signoffs * mrtg-2.17.4-2 (i686) 0/1 signoffs * openlierox-0.58_rc3-5 (i686) 0/1 signoffs * perl-gd-2.50-2 (i686) 0/1 signoffs * r8168-8.036.00-2 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-35 (i686) 0/1 signoffs * sage-mathematics-5.10-1 (i686) 0/1 signoffs * sarg-2.3.6-3 (i686) 0/1 signoffs * tp_smapi-0.41-26 (i686) 0/1 signoffs * vhba-module-20130607-5 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-2 (i686) 0/1 signoffs * vnstat-1.11-7 (i686) 0/1 signoffs * apcupsd-3.14.10-7 (x86_64) 0/2 signoffs * bbswitch-0.7-5 (x86_64) 0/2 signoffs * fceux-2.2.1.1-2 (x86_64) 0/2 signoffs * fswebcam-20110717-3 (x86_64) 0/2 signoffs * mrtg-2.17.4-2 (x86_64) 0/2 signoffs * openlierox-0.58_rc3-5 (x86_64) 0/2 signoffs * perl-gd-2.50-2 (x86_64) 0/2 signoffs * r8168-8.036.00-2 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-35 (x86_64) 0/2 signoffs * sage-mathematics-5.10-1 (x86_64) 0/2 signoffs * sarg-2.3.6-3 (x86_64) 0/2 signoffs * tp_smapi-0.41-26 (x86_64) 0/2 signoffs * vhba-module-20130607-5 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-2 (x86_64) 0/2 signoffs * vnstat-1.11-7 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. foutrelis - 2 signoffs

1 0

[aur-general] Remove AUR packages
by Svetkin Mikhail 09 Jul '13

09 Jul '13

Hi, Since I'm a new PKGBUILD creator and learning. I create pkbuild for pymodbus-git (https://aur.archlinux.org/packages/pymodbus-git/), but i don't know about ( https://wiki.archlinux.org/index.php/Python_Package_Guidelines#Package_nami…), and then i create second package with other name (python2-modbus-git https://aur.archlinux.org/packages/python2-modbus-git/) and now i can't delete pymodbus-git. I'm sorry to bother you but could you remove the pymodbus-git( https://aur.archlinux.org/packages/pymodbus-git/) ?

2 1

[aur-general] Massive orphan request II
by Frank Vanderham 09 Jul '13

09 Jul '13

>> That list is huge. I can certainly pick up a couple, but some of them look >> horribly outdated; is it an option to delete the ones that haven't been >> updated in - say - 12 months just to bring it down to a manageable number? >> It would be a waste of resources to spend time on a package that nobody is >> using anymore. > I'm afraid it's not possible to remove old and unmaintained packages, > unless e.g. the upstream is dead i.e. the source is missing: > https://mailman.archlinux.org/pipermail/aur-general/2013-June/023923.html [sorry, accidentally hit Send too soon] Can we create a "zombie / placeholder" status for those packages that need to be kept as Xyne mentions: " Even if the PKGBUILD is an ancient relic from the age of Judd in need of a complete rewrite, we tend to leave them as placeholders." I just don't think it's feasible to maintain all packages that were created once upon a time, since *anyone* can create a package on AUR?

3 2

[aur-general] Massive orphan request II
by Frank Vanderham 08 Jul '13

08 Jul '13

>> That list is huge. I can certainly pick up a couple, but some of them look >> horribly outdated; is it an option to delete the ones that haven't been >> updated in - say - 12 months just to bring it down to a manageable number? >> It would be a waste of resources to spend time on a package that nobody is >> using anymore. > I'm afraid it's not possible to remove old and unmaintained packages, > unless e.g. the upstream is dead i.e. the source is missing: > https://mailman.archlinux.org/pipermail/aur-general/2013-June/023923.html Can we create a "zombie" status for those

1 0

[aur-general] Removal requests
by Karol Blazewicz 08 Jul '13

08 Jul '13

1 1