On Wed, 16 Mar 2011 22:30:47 +0200, Ionuț Bîru wrote:

On 03/16/2011 09:27 PM, Pierre Schmitz wrote:

...

On Wed, 16 Mar 2011 13:46:21 -0500, Dan McGee wrote:

...

Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS

Thanks to everybody involved!

I'll give my signoff after I was able to do some more testing. The upgrade itself went fine. (I also checked the case when not running pacman-db-upgrade and running it twice) Everybody using our devtools will need to either manually run that or simply recreate the chroot env using the -c switch.

if all were that simple...

right now all chroots for staging/testing are broken on our build system because they would be recreated using _system_ pacman (old database format) and there isn't any way to run pacman-db-upgrade.

if system pacman is updated to 3.5 then you can't create new extra-x86_64/i686 chroots because it would use the new database inside and pacman 3.4 is unable to use.

to tackle this problem, this should be fixed in devtools and run pacman-db-upgrade automatically after a pacman update.

You are right, I missed that. I have no idea how to fix the testing host with extra chroot problem. Is there a way to detect when running pacman-db-upgrade is needed? I guess to solve the first problem we would also need a pacman-db-downgrade script. The cleanest way would probably to not use the host pacman but do some kind of bootstrap. Any input on this is welcome; haven't really thought about that yet. -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Thu, 17 Mar 2011 06:50:30 +1000, Allan McRae wrote:

On 17/03/11 06:39, Pierre Schmitz wrote:

...

You are right, I missed that. I have no idea how to fix the testing host with extra chroot problem. Is there a way to detect when running pacman-db-upgrade is needed?

find /var/lib/pacman/local -name depends

Stupid me. I should have looked at the upgrade script before; it's quite simple. I guess we could allways run that.

...

I guess to solve the first problem we would also need a pacman-db-downgrade script.

pacman-db-downgrade would be basically impossible... you could symlink the desc file to depends in every local package database directory.

If I'd add those link pacman 3.4 would be able to read the db, right? But once we update to 3.5 the upgrade script will ad all entries again. Maybe I'll need to modify the upgrade script to remove the desc files if they are just links. Btw: Do you guys plan the same for the db files? (merging deps and desc entries) Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Wed, 16 Mar 2011 16:24:42 -0500, Dan McGee wrote:

On Wed, Mar 16, 2011 at 4:21 PM, Pierre Schmitz wrote:

...

...

...

I guess to solve the first problem we would also need a pacman-db-downgrade script.

pacman-db-downgrade would be basically impossible...  you could symlink the desc file to depends in every local package database directory.

I'm not following the logic in this thread at all. Won't this be a problem for all of like 3 days here when the pacman version in [testing] vs. non-testing is different? And after that who cares? Or you could just upgrade your chroots and system to pacman 3.5 and it wouldn't matter either; this package depends on nothing else in [testing].

Sure, if it wont be in testing for weeks we should just ignore the problem as it will fix itself once this is in [core].

...

If I'd add those link pacman 3.4 would be able to read the db, right? But once we update to 3.5 the upgrade script will ad all entries again. Maybe I'll need to modify the upgrade script to remove the desc files if they are just links.

Btw: Do you guys plan the same for the db files? (merging deps and desc entries)

Eventually, but there is this crazy thing called backward compatibility that we have to take into account...

But that's only a temporary issue. :-) -- Pierre Schmitz, https://users.archlinux.de/~pierre

On 17/03/11 15:51, Ray Rashif wrote:

On 17 March 2011 05:24, Dan McGee wrote:

...

On Wed, Mar 16, 2011 at 4:21 PM, Pierre Schmitz wrote:

...

On Thu, 17 Mar 2011 06:50:30 +1000, Allan McRae wrote:

...

On 17/03/11 06:39, Pierre Schmitz wrote:

...

You are right, I missed that. I have no idea how to fix the testing host with extra chroot problem. Is there a way to detect when running pacman-db-upgrade is needed?

find /var/lib/pacman/local -name depends

Stupid me. I should have looked at the upgrade script before; it's quite simple. I guess we could allways run that.

This will either take 5 seconds or 0 seconds to run; it never hurts to just call it anyway.

...

...

...

I guess to solve the first problem we would also need a pacman-db-downgrade script.

pacman-db-downgrade would be basically impossible... you could symlink the desc file to depends in every local package database directory.

I'm not following the logic in this thread at all. Won't this be a problem for all of like 3 days here when the pacman version in [testing] vs. non-testing is different? And after that who cares? Or you could just upgrade your chroots and system to pacman 3.5 and it wouldn't matter either; this package depends on nothing else in [testing].

...

If I'd add those link pacman 3.4 would be able to read the db, right? But once we update to 3.5 the upgrade script will ad all entries again. Maybe I'll need to modify the upgrade script to remove the desc files if they are just links.

Btw: Do you guys plan the same for the db files? (merging deps and desc entries)

Eventually, but there is this crazy thing called backward compatibility that we have to take into account...

If you have chroot perms - and most people do aside from remote users - you can just:

~# chroot $chrootdir/root/ pacman-db-upgrade

That will save you from recreating the chroot with mkarchroot -r (which is the "long-term" solution/fix IMO). I see no problem/issue here at all.

Most people will have sudo permissions for mkarchroot as that is needed to create the chroot.... so this will work: mkarchroot -r "pacman-db-upgrade" /path/to/chroot

On 03/16/2011 10:30 PM, Ionuț Bîru wrote:

On 03/16/2011 09:27 PM, Pierre Schmitz wrote:

...

On Wed, 16 Mar 2011 13:46:21 -0500, Dan McGee wrote:

...

Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS

Thanks to everybody involved!

I'll give my signoff after I was able to do some more testing. The upgrade itself went fine. (I also checked the case when not running pacman-db-upgrade and running it twice) Everybody using our devtools will need to either manually run that or simply recreate the chroot env using the -c switch.

if all were that simple...

right now all chroots for staging/testing are broken on our build system because they would be recreated using _system_ pacman (old database format) and there isn't any way to run pacman-db-upgrade.

if system pacman is updated to 3.5 then you can't create new extra-x86_64/i686 chroots because it would use the new database inside and pacman 3.4 is unable to use.

to tackle this problem, this should be fixed in devtools and run pacman-db-upgrade automatically after a pacman update.

i say to just run pacman-db-upgrade if exists. i tried to run it again and it doesn't do anything. -- Ionuț

On Wed, Mar 16, 2011 at 3:10 PM, Gaetan Bisson wrote:

[2011-03-16 13:46:21 -0500] Dan McGee:

...

Multiple signoffs per architecture would be great

With pacman-3.5.0-1, when I do:

       yes n | pacman -Syu

(which I use in a script to print possible upgrades without doing anything), pacman starts eating up all the RAM until OOM kills it.

1. pacman -Qu exists 2. This is a terrible bug report. :/ I need output when you run this by hand, maybe with --debug, etc. Help me help you by actually providing details. -Dan

On Wed, Mar 16, 2011 at 3:18 PM, Gaetan Bisson wrote:

[2011-03-16 15:10:08 -0500] Dan McGee:

...

2. This is a terrible bug report. :/ I need output when you run this by hand, maybe with --debug, etc. Help me help you by actually providing details.

I thought it was reproducible well enough. There is no debug output:

       yes | pacman -S --debug

prints nothing and just eats up RAM. I will try to investigate more and let you know if I find anything.

Damn! This is a huge regression disguised as a "feature" that I never quite felt comfortable with... http://projects.archlinux.org/pacman.git/commit/?id=4fb3cfc48f626f84329c7835... -Dan

On Wed, Mar 16, 2011 at 3:26 PM, Aaron Griffin wrote:

On Wed, Mar 16, 2011 at 3:24 PM, Dan McGee wrote:

...

On Wed, Mar 16, 2011 at 3:18 PM, Gaetan Bisson wrote:

...

[2011-03-16 15:10:08 -0500] Dan McGee:

...

2. This is a terrible bug report. :/ I need output when you run this by hand, maybe with --debug, etc. Help me help you by actually providing details.

I thought it was reproducible well enough. There is no debug output:

       yes | pacman -S --debug

prints nothing and just eats up RAM. I will try to investigate more and let you know if I find anything.

Damn! This is a huge regression disguised as a "feature" that I never quite felt comfortable with... http://projects.archlinux.org/pacman.git/commit/?id=4fb3cfc48f626f84329c7835...

You can do it "GNU style" and only read from stdin if the package list is "-"

OMG, Aaron is here! That sounds like the way to go, or we are going to cause regressions to anyone that expected prior behavior. Dave- does that make sense, only read from stdin if an '-' arg is provided? -Dan

[2011-03-16 21:10:22 +0100] Gaetan Bisson:

[2011-03-16 13:46:21 -0500] Dan McGee:

...

Multiple signoffs per architecture would be great

With pacman-3.5.0-1, when I do:

yes n | pacman -Syu

(which I use in a script to print possible upgrades without doing anything), pacman starts eating up all the RAM until OOM kills it.

I forgot to mention that except for that everything is very smooth. :) Great work guys! -- Gaetan

On Wed, 16 Mar 2011 16:31:07 -0400, Eric Bélanger wrote:

On Wed, Mar 16, 2011 at 2:46 PM, Dan McGee wrote:

...

Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS

@Everyone for FYI, Allan for suggestions:

13:39 < bash`> error: failed to commit transaction (conflicting files) 13:39 < bash`> pacman: /usr/bin/pactree exists in filesystem 13:39 < bash`> for example :P 13:39 < bash`> pacman-contrib conflicts 13:39 < toofishes> yeah 13:39 < toofishes> just rm that file for now and continue...good catch

Anything we can do here to make this suck less? Unless on -S vs -U it gets pulled into the transaction so things won't conflict, but we'd have to rebuild it at the same time and get it in [community-testing], right?

-Dan

I just noticed that the new CheckSpace option has some issues in chroot when I update the chroot with "mkarchroot -u". If I explicitely chroot in the chroot and run pacman -Syu there it works. The error message is below (ignore the missing repo warnings). I also suppose the warning messages should be on seperate lines.

Isn't CheckSpace disabled by default? -- Pierre Schmitz, https://users.archlinux.de/~pierre

On Wed, Mar 16, 2011 at 5:01 PM, Allan McRae wrote:

On 17/03/11 06:42, Pierre Schmitz wrote:

...

On Wed, 16 Mar 2011 16:31:07 -0400, Eric Bélanger wrote:

...

On Wed, Mar 16, 2011 at 2:46 PM, Dan McGee  wrote:

...

Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS

@Everyone for FYI, Allan for suggestions:

13:39<  bash`>  error: failed to commit transaction (conflicting files) 13:39<  bash`>  pacman: /usr/bin/pactree exists in filesystem 13:39<  bash`>  for example :P 13:39<  bash`>  pacman-contrib conflicts 13:39<  toofishes>  yeah 13:39<  toofishes>  just rm that file for now and continue...good catch

Anything we can do here to make this suck less? Unless on -S vs -U it gets pulled into the transaction so things won't conflict, but we'd have to rebuild it at the same time and get it in [community-testing], right?

-Dan

I just noticed that the new CheckSpace option has some issues in chroot when I update the chroot with "mkarchroot -u".  If I explicitely chroot in the chroot and run pacman -Syu there it works. The error message is below (ignore the missing repo warnings).  I also suppose the warning messages should be on seperate lines.

CheckSpace will not work in choots.  Run "df" in there to see why.  I never got around to documenting that...

Now that you mention it, I recall the numerous disscussions in the pacman ML. I'll just disable it.

The warning message is fixed in m git branch.  It was too late for a string change once I discovered it.

OK. I'll continue to use/test it in the next few days.

...

Isn't CheckSpace disabled by default?

Yes it is.

Allan

Am Mittwoch 16 März 2011 schrieb Allan McRae:

On 17/03/11 04:46, Dan McGee wrote:

...

Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS

@Everyone for FYI, Allan for suggestions:

13:39< bash`> error: failed to commit transaction (conflicting files) 13:39< bash`> pacman: /usr/bin/pactree exists in filesystem 13:39< bash`> for example :P 13:39< bash`> pacman-contrib conflicts 13:39< toofishes> yeah 13:39< toofishes> just rm that file for now and continue...good catch

Anything we can do here to make this suck less? Unless on -S vs -U it gets pulled into the transaction so things won't conflict, but we'd have to rebuild it at the same time and get it in [community-testing], right?

There is pacman-contrib-3.4.2-2 in [community] now that does not have pactree in it. Anyone using [testing] will still face this issue, but those who upgrade pacman-contrib before pacman goes to [core] should be fine.

You could add conflicts=(pacman-contrib<3.4.2-2) to the pacman package, but that solution is just as ugly as requiring deleting that file...

Allan No signoff for german locale, I cannot build anything with de_DE.utf8 locale, makepkg breaks: /usr/bin/makepkg: Zeile 99: printf: `D': Ungültiges Formatierungszeichen.

greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org