- Arch-dev-public - lists.archlinux.org

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 13 Dec '13

13 Dec '13

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 9 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 12 fully signed off packages * 15 packages missing signoffs * 2 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 [testing] in last 24 hours (9 total) == * man-pages-3.55-1 (any) * linux-3.12.5-1 (i686) * linux-lts-3.10.24-1 (i686) * make-4.0-2 (i686) * linux-3.12.5-1 (x86_64) * linux-lts-3.10.24-1 (x86_64) * make-4.0-2 (x86_64) * gdb-7.6.2-1 (i686) * gdb-7.6.2-1 (x86_64) == Incomplete signoffs for [core] (13 total) == * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * iproute2-3.12.0-1 (i686) 0/1 signoffs * iptables-1.4.21-1 (i686) 0/1 signoffs * linux-lts-3.10.24-1 (i686) 0/1 signoffs * binutils-2.24-1 (x86_64) 1/2 signoffs * gcc-4.8.2-6 (x86_64) 1/2 signoffs * inetutils-1.9.1.341-2 (x86_64) 1/2 signoffs * iptables-1.4.21-1 (x86_64) 0/2 signoffs * linux-api-headers-3.12.4-1 (x86_64) 1/2 signoffs * linux-lts-3.10.24-1 (x86_64) 1/2 signoffs * make-4.0-2 (x86_64) 1/2 signoffs * mpfr-3.1.2.p5-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (2 total) == * gdb-7.6.2-1 (i686) 0/1 signoffs * gdb-7.6.2-1 (x86_64) 0/2 signoffs == Completed signoffs (12 total) == * man-pages-3.55-1 (any) * binutils-2.24-1 (i686) * gcc-4.8.2-6 (i686) * glibc-2.18-11 (i686) * linux-3.12.5-1 (i686) * linux-api-headers-3.12.4-1 (i686) * make-4.0-2 (i686) * mpfr-3.1.2.p5-1 (i686) * btrfs-progs-3.12-1 (x86_64) * glibc-2.18-11 (x86_64) * iproute2-3.12.0-1 (x86_64) * linux-3.12.5-1 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * btrfs-progs-3.12-1 (i686), since 2013-11-27 * btrfs-progs-3.12-1 (x86_64), since 2013-11-27 == Top five in signoffs in last 24 hours == 1. eric - 6 signoffs 2. allan - 4 signoffs 3. foutrelis - 2 signoffs

1 0

[arch-dev-public] core repo build report 2013-12-12
by Allan McRae 12 Dec '13

12 Dec '13

Seems there is nothing broken by the binutils update. Mostly source issues from changes made to files on svn trunk without updating checksum. FAIL curl 0001-glob-fix-regression-from-commit-5ca96cb844.patch ... FAILED FAIL dhcpcd dhcpcd.service ... FAILED FAIL grub util/grub-mkfont.c:46:30: fatal error: freetype/ftsynth.h: No such file or directory FAIL ipw2100-fw ==> ERROR: Failure while downloading ipw2100-fw-1.3.tgz FAIL ipw2200-fw ==> ERROR: Failure while downloading ipw2200-fw-3.1.tgz FAIL isl ==> ERROR: Failure while downloading isl-0.12.1.tar.bz2 FAIL libarchive 22531545514043e04633e1c015c7540b9de9dbe4.patch ... FAILED FAIL licenses mpl-1.1.txt ... FAILED ruby-license.txt ... FAILED FAIL logrotate logrotate.conf ... FAILED FAIL shadow ==> ERROR: Failure while downloading shadow-4.1.5.1.tar.bz2 FAIL xinetd ==> ERROR: Failure while downloading xinetd-2.3.15.tar.gz

3 2

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 12 Dec '13

12 Dec '13

=== Signoff report for [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 * 8 fully signed off packages * 16 packages missing signoffs * 2 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 [testing] in last 24 hours (10 total) == * binutils-2.24-1 (i686) * gcc-4.8.2-6 (i686) * glibc-2.18-11 (i686) * linux-api-headers-3.12.4-1 (i686) * binutils-2.24-1 (x86_64) * gcc-4.8.2-6 (x86_64) * glibc-2.18-11 (x86_64) * linux-api-headers-3.12.4-1 (x86_64) * php-5.5.7-1 (i686) * php-5.5.7-1 (x86_64) == Incomplete signoffs for [core] (14 total) == * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * iproute2-3.12.0-1 (i686) 0/1 signoffs * iptables-1.4.21-1 (i686) 0/1 signoffs * linux-3.12.4-1 (i686) 0/1 signoffs * util-linux-2.24-2 (i686) 0/1 signoffs * binutils-2.24-1 (x86_64) 1/2 signoffs * gcc-4.8.2-6 (x86_64) 1/2 signoffs * glibc-2.18-11 (x86_64) 1/2 signoffs * inetutils-1.9.1.341-2 (x86_64) 0/2 signoffs * iproute2-3.12.0-1 (x86_64) 0/2 signoffs * iptables-1.4.21-1 (x86_64) 0/2 signoffs * linux-api-headers-3.12.4-1 (x86_64) 1/2 signoffs * mpfr-3.1.2.p5-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (2 total) == * php-5.5.7-1 (i686) 0/1 signoffs * php-5.5.7-1 (x86_64) 0/2 signoffs == Completed signoffs (8 total) == * binutils-2.24-1 (i686) * gcc-4.8.2-6 (i686) * glibc-2.18-11 (i686) * linux-api-headers-3.12.4-1 (i686) * mpfr-3.1.2.p5-1 (i686) * btrfs-progs-3.12-1 (x86_64) * linux-3.12.4-1 (x86_64) * util-linux-2.24-2 (x86_64) == All packages in [testing] for more than 14 days (2 total) == * btrfs-progs-3.12-1 (i686), since 2013-11-27 * btrfs-progs-3.12-1 (x86_64), since 2013-11-27 == Top five in signoffs in last 24 hours == 1. allan - 10 signoffs 2. thomas - 2 signoffs 3. djgera - 2 signoffs

1 0

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 11 Dec '13

11 Dec '13

=== Signoff report for [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 * 3 fully signed off packages * 15 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 [testing] in last 24 hours (10 total) == * bison-3.0.2-1 (i686) * file-5.16-1 (i686) * iproute2-3.12.0-1 (i686) * iptables-1.4.21-1 (i686) * mpfr-3.1.2.p5-1 (i686) * bison-3.0.2-1 (x86_64) * file-5.16-1 (x86_64) * iproute2-3.12.0-1 (x86_64) * iptables-1.4.21-1 (x86_64) * mpfr-3.1.2.p5-1 (x86_64) == Incomplete signoffs for [core] (15 total) == * bison-3.0.2-1 (i686) 0/1 signoffs * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * iproute2-3.12.0-1 (i686) 0/1 signoffs * iptables-1.4.21-1 (i686) 0/1 signoffs * linux-3.12.4-1 (i686) 0/1 signoffs * mpfr-3.1.2.p5-1 (i686) 0/1 signoffs * util-linux-2.24-2 (i686) 0/1 signoffs * bison-3.0.2-1 (x86_64) 1/2 signoffs * file-5.16-1 (x86_64) 1/2 signoffs * inetutils-1.9.1.341-2 (x86_64) 0/2 signoffs * iproute2-3.12.0-1 (x86_64) 0/2 signoffs * iptables-1.4.21-1 (x86_64) 0/2 signoffs * mpfr-3.1.2.p5-1 (x86_64) 0/2 signoffs * util-linux-2.24-2 (x86_64) 1/2 signoffs == Completed signoffs (3 total) == * file-5.16-1 (i686) * btrfs-progs-3.12-1 (x86_64) * linux-3.12.4-1 (x86_64) == Top five in signoffs in last 24 hours == 1. eric - 5 signoffs

1 0

Re: [arch-dev-public] [arch-general] The Final Cleanup
by Rashif Ray Rahman 10 Dec '13

10 Dec '13

On 7 December 2013 01:15, Alexander Rødseth <rodseth(a)gmail.com> wrote: > If there are no protests, I will, after some time (say, three days I don't think that's enough time to get the representative opinion. Anyway, on topic, I know I have at least a couple of packages where I provide the desktop file, but don't know if upstream presently includes one in their sources. I will have to attend to these. So, I say +1 to include desktop files as long as upstream does not provide them. You can file a bug report with them, but the desktop file stays until they attend to it. Also, it doesn't matter how it was created, as long as the package includes it. If a packager wants to go out of her way to provide a desktop file for software that traditionally do not ship with one, I say we allow her to do it. -- GPG/PGP ID: C0711BF1

4 6

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 10 Dec '13

10 Dec '13

=== Signoff report for [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 * 7 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 [core] (7 total) == * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * linux-3.12.4-1 (i686) 0/1 signoffs * util-linux-2.24-2 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (x86_64) 0/2 signoffs * linux-3.12.4-1 (x86_64) 1/2 signoffs * util-linux-2.24-2 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * btrfs-progs-3.12-1 (x86_64) == Top five in signoffs in last 24 hours == 1. thomas - 1 signoffs

1 0

[arch-dev-public] Dropping sysvinit-tools
by Dave Reisner 09 Dec '13

09 Dec '13

The next release of procps-ng will contain pidof and clash with sysvinit-tools. The obvious decision is to use the maintained source of pidof. At this point, we'll be left with 3 binaries in sysvinit-tools, all which I propose are all obsolete: fstab-decode, killall5, and bootlogd. I'm open to arguments against this, but I suggest we drop sysvinit-tools after pidof is part of a release from procps-ng. Cheers, Dave

4 5

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 09 Dec '13

09 Dec '13

=== Signoff report for [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 * 1 fully signed off package * 13 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 [testing] in last 24 hours (8 total) == * linux-3.12.4-1 (i686) * linux-lts-3.10.23-1 (i686) * util-linux-2.24-2 (i686) * linux-3.12.4-1 (x86_64) * linux-lts-3.10.23-1 (x86_64) * util-linux-2.24-2 (x86_64) * sqlite-3.8.2-1 (i686) * sqlite-3.8.2-1 (x86_64) == Incomplete signoffs for [core] (9 total) == * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * linux-3.12.4-1 (i686) 0/1 signoffs * linux-lts-3.10.23-1 (i686) 0/1 signoffs * util-linux-2.24-2 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (x86_64) 0/2 signoffs * linux-3.12.4-1 (x86_64) 0/2 signoffs * linux-lts-3.10.23-1 (x86_64) 0/2 signoffs * util-linux-2.24-2 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (4 total) == * qwt-6.1.0-1 (i686) 0/1 signoffs * sqlite-3.8.2-1 (i686) 0/1 signoffs * qwt-6.1.0-1 (x86_64) 0/2 signoffs * sqlite-3.8.2-1 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * btrfs-progs-3.12-1 (x86_64) == Top five in signoffs in last 24 hours ==

1 0

[arch-dev-public] Fwd: The Final Cleanup
by Alexander Rødseth 08 Dec '13

08 Dec '13

Hi, This is the current situation: * Several packages in [community] (and maybe one package in [extra]) includes .desktop files * There is a 2 years, 8 months and 14 days old bug report, opened by Thomas Dziedzic, that opens with a few well chosen words, and is followed by a lengthy discussion: https://bugs.archlinux.org/task/23387 * For some packages, the lack of .desktop files has been reported upstream as bugs. * For some of those bug reports, upstream has: * Responded positively, and started to provide .desktop files (very few) * Responded that they will not provide .desktop files (even when provided in the bug report) * Not responded (seems to be the common case) * Several TUs and devs has had a go at moving things forward. The current effort is pretty spread out and has a long history: * Some are trying to keep the text in the bug report up to date. * Some are maintaining a wiki page about the topic: https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_files * Some are posting comments to the bug report. * A tool for generating .desktop files has been created, named "gendesk" (I'm guilty of this, and one or more of the above). * The bug has been closed and re-opened three times * We had an Arch Desktop Project going, that was started back in 2007, but is now obsolete: https://wiki.archlinux.org/index.php/Desktop_Project * Creating a TODO list has been suggested, some people are for this, others are against it. Here are the arguments so far for upstream being the ones providing the .desktop files: * It should not be the responsibility of the users * It should not be the responsibility of Arch Linux * It is increasingly common that upstream provides these * The real issue is that .desktop files should be provided by upstream Here are a few arguments against upstream being the ones providing the .desktop files: * Desktop shortcuts are not provided by upstream for other platforms, like Android, OS X or Windows (except when included in an installer) * Upstream should create the application, users should use it and packagers should make the application available to the user. This includes providing a .desktop file. * "Good luck trying to convince upstreams like dwm (and many others) to include them. IIRC the previous attempt didnt produce much either." Conclusion so far: Regardless of if it is correct that upstream should provide the .desktop files or not, the current plan is not working. TUs and devs are slow at reporting this as bugs and upstream are slow at responding. At the current rate, this will take years, perhaps decades. The current plan is not working. I think .desktop files should ideally be provided by upstream. But for cases where they are not currently being provided, we should provide them. Here are the arguments for removing .desktop files from packages (or not having them in the first place): * Arch Linux has vanilla packages, so we should try to avoid including files that are hand-crafted by packagers * It clutters the repository * Including .desktop files is basically the same as patching. And this quote: "Patching only occurs in extremely rare cases, to prevent severe breakage in the instance of version mismatches that may occur within a rolling release model." from https://wiki.archlinux.org/index.php/Arch_Linux * In all other connections, it is bad form to check in files to the repository that can otherwise easily be generated (like Makefile.am files, for instance) * Packages should be defined with as few text files as possible. Ideally just one PKGBUILD file. Here are the arguments for keeping .desktop files in packages: * If the existing ones are okay, there is no point in changing them * Upstream should fix them (this does not seem to be happening / this is happening at a rate that is too slow) I think .desktop files should not be kept in the packages, but either be provided by upstream or being generated by a tool. Here are the arguments for generating the .desktop files with a tool like "gendesk": * There is much duplication of code by having one .desktop file per (GUI) package * If the .desktop specification should change in the future, there is only one tool that has to be changed, not bazillions of little .desktop files * If there should be alternative ways of providing desktop shortcuts in the future, possibly for other desktop environments, the transition will be easier * It's more elegant than including manually crafted files everywhere * It provides one consistent look of .desktop files and avoids problems (for instance, one hand crafted (or upstream provided?) .desktop file used Terminal=1 instead of Terminal=true, which caused problems). Generated files are consistent, which avoids problems. * gendesk is already being used for several packages (and has been used for a while), and it seems to work fine * Many files are generating during the prepare or build process. .desktop files should be generated too. * "I've just tried gendesk and it's pretty neat actually." Here are the arguments against generating the .desktop files with a tool like "gendesk": * It is just like including base64 encoded files directly in the PKGBUILD. (no, it's not. Contrast with other build-time generated files) * It's better to just leave the current .desktop files as they are. * Generating the .desktop files does not make the packages more "vanilla". (.desktop files are inherently non-vanilla, though) * It takes a bit of work to create a package in the first place. Adding a .desktop file or not won't make a difference in the overall burden. * The functionality should rather be in makepkg. * The maintainer still needs to relate to .desktop files one way or the other I think .desktop files should be generated with "gendesk", or a similar tool. (Note that gendesk has evolved and improved quite a bit since the time when it was first introduced and commented on in the bug report). Here are the arguments for creating a TODO list: * It's time to get this done and close the age old bug report. * People can still choose to reserve their packages from being affected (simply by marking their packages as complete, for instance). * A TODO list is the appropriate method for solving this situation. * "I'm convinced TODO is more appropriate. Also I think the TODO interface (Complete/Incomplete) is better suited for this task." Here are the arguments against creating a TODO list: * Todos are things that require 100% completion ASAP for the distro to go forward I think we should have a TODO for this. Specifically, I think we should have a TODO for removing all .desktop files from our package sources. They should ideally be provided by upstream, but in the mean time, they should be generated. If there are no protests, I will, after some time (say, three days without any replies to this thread): * Create a TODO for this * Start fixing the packages (I will not fix the packages of maintainers that wish to reserve themselves from this, of course). We all appreciate a good discussion, but before replying with a flamey flame of a flaming reply, please think a minute if you have a better solution than this for achieving the goal of closing FS#23387 in the near future (not in 10 years). All the best. -- Sincerely, Alexander Rødseth xyproto / TU

7 12

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 08 Dec '13

08 Dec '13

=== Signoff report for [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 * 4 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.) == New packages in [testing] in last 24 hours (2 total) == * inetutils-1.9.1.341-2 (i686) * inetutils-1.9.1.341-2 (x86_64) == Incomplete signoffs for [core] (6 total) == * btrfs-progs-3.12-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (i686) 0/1 signoffs * linux-lts-3.10.22-1 (i686) 0/1 signoffs * inetutils-1.9.1.341-2 (x86_64) 0/2 signoffs * libpipeline-1.2.5-1 (x86_64) 1/2 signoffs * linux-lts-3.10.22-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (6 total) == * nvidia-304xx-lts-304.116-2 (i686) 0/1 signoffs * nvidia-lts-331.20-4 (i686) 0/1 signoffs * qwt-6.1.0-1 (i686) 0/1 signoffs * nvidia-304xx-lts-304.116-2 (x86_64) 0/2 signoffs * nvidia-lts-331.20-4 (x86_64) 1/2 signoffs * qwt-6.1.0-1 (x86_64) 0/2 signoffs == Completed signoffs (4 total) == * libpipeline-1.2.5-1 (i686) * procps-ng-3.3.9-1 (i686) * btrfs-progs-3.12-1 (x86_64) * procps-ng-3.3.9-1 (x86_64) == Top five in signoffs in last 24 hours == 1. djgera - 2 signoffs

1 0