Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Aaron Griffin
On Sun, Dec 14, 2008 at 8:18 AM, Hubert Grzeskowiak wrote: > for the mirrorlist, i think an update script would suit best, but that > may be kind of not arch-way. i run vimdiff every time there is a new > mirrorlist, but actually you could do all that with a script, that adds > new and deletes old

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Aaron Griffin
On Sun, Dec 14, 2008 at 9:49 AM, Daenyth Blank wrote: > On Sun, Dec 14, 2008 at 09:18, Hubert Grzeskowiak > wrote: >> i like the idea. what would be the disadvantages, Daenyth? > I just think it's very ugly "solution". IMO, the current behavior is > fine. Keep it elegant. > I agree... Dan made t

Re: [arch-general] wrong file permissions in /var/lib/pacman/local

2008-12-14 Thread Hubert Grzeskowiak
setting user's umask to 0022 before sudo pacman works and it's independent of root's umask. H.G.

[arch-general] [signoff] kernel26 2.6.27.9-1

2008-12-14 Thread Tobias Powalowski
Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally s

Re: [arch-general] [arch-dev-public] request for toolchain signoffs

2008-12-14 Thread Andreas Radke
I've pushed a glibc 2.9-2 to testing. I have added all changes made in Fedora's FC10 2.9-3 rpm. They have included some minor fixes and a workaround for the name resolving issue. This should fix our FS #12215. Now we need to know if there are still DNS problems. If it's solved I'd like to push it

Re: [arch-general] Dovecot imap processes pinning CPU

2008-12-14 Thread David Rosenstrauch
Paul Ezvan wrote: I have just saw this message on the LKML : http://lkml.org/lkml/2008/12/13/95 It is the same behaviour, maybe it is related to our bug ? Sounds quite likely: a) it's the same kernel version as us, and b) it seems to involve inotify, which is where the dovecot people suspect

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Daenyth Blank
On Sun, Dec 14, 2008 at 09:18, Hubert Grzeskowiak wrote: > i like the idea. what would be the disadvantages, Daenyth? I just think it's very ugly "solution". IMO, the current behavior is fine. Keep it elegant.

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Hubert Grzeskowiak
Pierre Chapuis schrieb: > Le Sun, 14 Dec 2008 10:03:03 +0200, > "Grigorios Bouzakis" a écrit : > >> May i ask why pacman requires pacman-mirrorlist and not the other way >> around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can >> not operate without pacman.. > > Agreed, but I th

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Daenyth Blank
On Sun, Dec 14, 2008 at 06:01, Pierre Chapuis wrote: > Le Sun, 14 Dec 2008 10:03:03 +0200, > "Grigorios Bouzakis" a écrit : > >> May i ask why pacman requires pacman-mirrorlist and not the other way >> around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can >> not operate without p

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Pierre Chapuis
Le Sun, 14 Dec 2008 10:03:03 +0200, "Grigorios Bouzakis" a écrit : > May i ask why pacman requires pacman-mirrorlist and not the other way > around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can > not operate without pacman.. Agreed, but I think a lot of users would forget to in

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

2008-12-14 Thread Grigorios Bouzakis
On Sun, Dec 14, 2008 at 12:40 AM, Dan McGee wrote: > This is a dual signoff. I have split the pacman mirrorlist into its > own package because > 1) Pacman releases are not all that common (because its perfect > software, of course!) > 2) Our packaged mirrorlist often lags waaay behind the actual o