[arch-dev-public] Signoff report for [testing]

2011-11-27 Thread Arch Website Notification
=== 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

2011-11-27 Thread 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


Re: [arch-dev-public] [RFC] dealing with fileconflicts

2011-11-27 Thread Pierre Schmitz
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