[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 4 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 16 fully signed off packages * 32 packages missing signoffs * 3 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 (4 total) == * openssh-5.9p1-5 (i686) * openssh-5.9p1-5 (x86_64) * ypserv-2.26-3 (i686) * ypserv-2.26-3 (x86_64) == Incomplete signoffs for [core] (6 total) == * bison-2.5-3 (i686) 1/2 signoffs * openssh-5.9p1-5 (i686) 1/2 signoffs * shadow-4.1.4.3-3 (i686) 0/2 signoffs * syslog-ng-3.3.3-1 (i686) 1/2 signoffs * bison-2.5-3 (x86_64) 1/2 signoffs * shadow-4.1.4.3-3 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (26 total) == * apr-util-1.3.12-3 (i686) 0/2 signoffs * avahi-0.6.30-6 (i686) 1/2 signoffs * ghc-7.2.2-1 (i686) 0/2 signoffs * jack-0.121.3-3 (i686) 0/2 signoffs * lighttpd-1.4.29-3 (i686) 0/2 signoffs * mutt-1.5.21-6 (i686) 1/2 signoffs * ocaml-3.12.1-3 (i686) 0/2 signoffs * php-5.3.8-5 (i686) 0/2 signoffs * python-3.2.2-2 (i686) 0/2 signoffs * python2-2.7.2-4 (i686) 1/2 signoffs * ruby-1.9.3_p0-2 (i686) 0/2 signoffs * subversion-1.6.17-7 (i686) 0/2 signoffs * ypserv-2.26-3 (i686) 0/2 signoffs * zsh-4.3.12-3 (i686) 1/2 signoffs * apr-util-1.3.12-3 (x86_64) 0/2 signoffs * avahi-0.6.30-6 (x86_64) 1/2 signoffs * ghc-7.2.2-1 (x86_64) 0/2 signoffs * jack-0.121.3-3 (x86_64) 0/2 signoffs * lighttpd-1.4.29-3 (x86_64) 0/2 signoffs * ocaml-3.12.1-3 (x86_64) 0/2 signoffs * php-5.3.8-5 (x86_64) 0/2 signoffs * python-3.2.2-2 (x86_64) 0/2 signoffs * python2-2.7.2-4 (x86_64) 1/2 signoffs * ruby-1.9.3_p0-2 (x86_64) 0/2 signoffs * subversion-1.6.17-7 (x86_64) 1/2 signoffs * ypserv-2.26-3 (x86_64) 0/2 signoffs == Completed signoffs (16 total) == * mkinitcpio-0.8.0-1 (any) * gdbm-1.10-1 (i686) * man-db-2.6.0.2-3 (i686) * pacman-4.0.1-1 (i686) * perl-5.14.2-3 (i686) * gdbm-1.10-1 (x86_64) * man-db-2.6.0.2-3 (x86_64) * openssh-5.9p1-5 (x86_64) * pacman-4.0.1-1 (x86_64) * perl-5.14.2-3 (x86_64) * syslog-ng-3.3.3-1 (x86_64) * namcap-3.2.1-1 (any) * pyalpm-0.5.3-1 (i686) * mutt-1.5.21-6 (x86_64) * pyalpm-0.5.3-1 (x86_64) * zsh-4.3.12-3 (x86_64) == All packages in [testing] for more than 14 days (3 total) == * pyalpm-0.5.3-1 (i686), since 2011-10-15 * pyalpm-0.5.3-1 (x86_64), since 2011-10-15 * namcap-3.2.1-1 (any), since 2011-10-20 == Top five in signoffs in last 24 hours == 1. bpiotrowski - 8 signoffs 2. dreisner - 4 signoffs 3. tpowa - 3 signoffs 4. tomegun - 3 signoffs 5. jelle - 2 signoffs
[arch-dev-public] [RFC] dealing with fileconflicts
Hi guys, We have the following problem: At the moment /etc/mtab is being generated at boot (so it is not owned by any package). However, we want to replace it with a symlink pointing to /proc/self/mounts (preferably owned by util-linux). If we do this, there will be a conflict on upgrade and users have to manually delete /etc/mtab before upgrading. To avoid user intervention we could just create the symlink in a postupgrade/postinstall script in util-linux, but I'm not sure if that is something we want to be doing. Is there any way to tell pacman to ignore conflicts with this particular file, just overwrite it? Any thoughts? Tom
Re: [arch-dev-public] [RFC] dealing with fileconflicts
Am 27.11.2011 22:16, schrieb Tom Gundersen: Hi guys, We have the following problem: At the moment /etc/mtab is being generated at boot (so it is not owned by any package). However, we want to replace it with a symlink pointing to /proc/self/mounts (preferably owned by util-linux). If we do this, there will be a conflict on upgrade and users have to manually delete /etc/mtab before upgrading. To avoid user intervention we could just create the symlink in a postupgrade/postinstall script in util-linux, but I'm not sure if that is something we want to be doing. Is there any way to tell pacman to ignore conflicts with this particular file, just overwrite it? Any thoughts? Tom Afaik the install script solution wont work as pacman will check for file conflicts before running the script and thus abort. Imho it's OK to let the user manually delete that file. We could point to this in an announcement as we did many times before. We still aim for competent users so avoid user intervention at all costs is not our way; especially if the straight forward solution is that easy. Greetings, Pierre -- Pierre Schmitz, http://pierre-schmitz.com