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

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

03 Aug '13

=== 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 * 12 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] (12 total) == * bbswitch-0.7-7 (i686) 0/1 signoffs * r8168-8.036.00-4 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-37 (i686) 0/1 signoffs * tp_smapi-0.41-28 (i686) 0/1 signoffs * vhba-module-20130607-7 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-4 (i686) 0/1 signoffs * bbswitch-0.7-7 (x86_64) 0/2 signoffs * r8168-8.036.00-4 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-37 (x86_64) 0/2 signoffs * tp_smapi-0.41-28 (x86_64) 0/2 signoffs * vhba-module-20130607-7 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-4 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours ==

1 0

[aur-general] Status of Compiz on AUR
by Edoardo Maria Elidoro 02 Aug '13

02 Aug '13

Hi everyone, I think someone should really take care of Compiz and its PKGBUILD because it's quite a mess. It installs almost two DE (I know it's an exaggeration) just to compile the main package. When it was on Community (if I'm not wrong) the PKGBUILD was fine because only a person has to compile it, but now that it's on AUR I think it should be better to split it in different packages based on the DE in use. I'm writing here just to have some feedback about this "issue" and maybe to encourage someone to adopt it and fix it. I don't feel like it's something I will be able to do otherwise I'd have already adopted it. Have a nice day, Edoardo

4 4

[aur-general] Upstream seeking contact with package maintainer
by Thomas Schmitt 02 Aug '13

02 Aug '13

Hi, i am the developer of xorriso, and first want to thank you for including it and its frontend script xorriso-tcltk https://aur.archlinux.org/packages/xorriso/ https://aur.archlinux.org/packages/xorriso-tcltk/ Is there a mail address by which i could reach the maintainer of those two packages: dreieck ? Please Cc: me with replies. Depending on the traffic here, i may have to unsubsribe soon. -------------------------------------------------------------- I ask, because the /usr/bin files of both packages overlap with https://www.archlinux.org/packages/?name=libisoburn libisoburn installs among others the script xorriso-tcltk but is currently lacking the script's Tcl/Tk dependencies. I would not advise to add those dependencies, anyway. So despite the currently existing overlap, i believe both AUR packages are worth to exist. - xorriso for users who would not expect to find it in a thing called "libisoburn". - xorriso-tcltk for users who want to pull in its Tcl/Tk dependencies. Would the following AUR packages be technically possible ? - xorriso doing not more than depending on libisoburn - xorriso-tcltk doing not more than depending on libisoburn, Bwidget, tcl, tk>=8.4 After such a change, they would need no maintainance when i release new revisions. Similar could be done with - cdrskin which is installed by package libburn (cdrskin is a cdrecord compatible wrap around libburn.) ------------------------------------------------------------ Background: Both packages stem from my software releases and probably i am to blame for the confusion by putting reference applications into the library tarballs. For archlinux users, both xorriso binaries should be fully equivalent. Only Jigdo production for Debian and Ubuntu installation ISOs would require the AUR package. The AUR package contains GNU xorriso, a static compilation of libburn, libisofs, libjte, and libisoburn. One may use its binary xorriso without installation and it will not collide with the installed dynamic libraries. Intended for self-admins and for testing newer versions before installing system-wide libraries. The packages libisoburn and https://www.archlinux.org/packages/?name=libburn https://www.archlinux.org/packages/?name=libisofs contain with the same revision number the same source code as GNU xorriso's library copies. Most object code of xorriso is in the dynamic library libisoburn from where xorriso offers an own API. The xorriso binary is therefore very small. I decided against checking for Tcl/Tk during configuration of libisoburn from the release tarball, because Tcl/Tk is not needed for its main purpose. Several distros split libburn and libisoburn into packages "libburn", "cdrskin", "libisoburn", "xorriso". AUR is among the first to package "xorriso-tcltk". Thanks again. Have a nice day :) Thomas

2 1

[aur-general] Removal request: stone-soup-tile05
by Allen Li 02 Aug '13

02 Aug '13

stone-soup-tile05 It's extremely out of date and orphaned. stone-soup is in community and also includes tiles, so I see no reason for this to still exist. Allen Li

2 1

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

02 Aug '13

=== 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 * 12 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] (12 total) == * bbswitch-0.7-7 (i686) 0/1 signoffs * r8168-8.036.00-4 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-37 (i686) 0/1 signoffs * tp_smapi-0.41-28 (i686) 0/1 signoffs * vhba-module-20130607-7 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-4 (i686) 0/1 signoffs * bbswitch-0.7-7 (x86_64) 0/2 signoffs * r8168-8.036.00-4 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-37 (x86_64) 0/2 signoffs * tp_smapi-0.41-28 (x86_64) 0/2 signoffs * vhba-module-20130607-7 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-4 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. tomegun - 3 signoffs

1 0

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

01 Aug '13

=== 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 * 12 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] (12 total) == * bbswitch-0.7-7 (i686) 0/1 signoffs * r8168-8.036.00-4 (i686) 0/1 signoffs * rt3562sta-2.4.1.1-37 (i686) 0/1 signoffs * tp_smapi-0.41-28 (i686) 0/1 signoffs * vhba-module-20130607-7 (i686) 0/1 signoffs * virtualbox-modules-4.2.16-4 (i686) 0/1 signoffs * bbswitch-0.7-7 (x86_64) 0/2 signoffs * r8168-8.036.00-4 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1-37 (x86_64) 0/2 signoffs * tp_smapi-0.41-28 (x86_64) 0/2 signoffs * vhba-module-20130607-7 (x86_64) 0/2 signoffs * virtualbox-modules-4.2.16-4 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. lcarlier - 4 signoffs

1 0