[arch-dev-public] [signoff] pacman 3.5.0-1
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
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. The new tar based db is way faster. Using menu based completion with zsh and grml-zsh-config is now a lot more fun as there is no noticeable delay anymore. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
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. -- Ionuț
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 17/03/11 06:39, Pierre Schmitz wrote:
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?
find /var/lib/pacman/local -name depends
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. Allan
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, Mar 16, 2011 at 4:21 PM, Pierre Schmitz <pierre@archlinux.de> 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... -Dan
On Wed, 16 Mar 2011 16:24:42 -0500, Dan McGee wrote:
On Wed, Mar 16, 2011 at 4:21 PM, Pierre Schmitz <pierre@archlinux.de> 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 March 2011 05:24, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Mar 16, 2011 at 4:21 PM, Pierre Schmitz <pierre@archlinux.de> 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.
On 17/03/11 15:51, Ray Rashif wrote:
On 17 March 2011 05:24, Dan McGee<dpmcgee@gmail.com> wrote:
On Wed, Mar 16, 2011 at 4:21 PM, Pierre Schmitz<pierre@archlinux.de> 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 17/03/11 07:21, Pierre Schmitz wrote:
Btw: Do you guys plan the same for the db files? (merging deps and desc entries)
Patch already available and running on my system! :P
tar -tf /home/arch/kernel64/kernel64.db bcm5974-2.6.37.3-1/ bcm5974-2.6.37.3-1/desc broadcom-wl-5.100.82.38-1/ broadcom-wl-5.100.82.38-1/desc kernel26-2.6.37.4-1/ kernel26-2.6.37.4-1/desc ...
Not that this one makes a heap of difference to the read speed... Allan
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ț
[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. -- Gaetan
On Wed, Mar 16, 2011 at 3:10 PM, Gaetan Bisson <bisson@archlinux.org> 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
[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. -- Gaetan
On Wed, Mar 16, 2011 at 3:18 PM, Gaetan Bisson <bisson@archlinux.org> 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:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Mar 16, 2011 at 3:18 PM, Gaetan Bisson <bisson@archlinux.org> 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 "-"
On Wed, Mar 16, 2011 at 3:26 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 16, 2011 at 3:24 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Mar 16, 2011 at 3:18 PM, Gaetan Bisson <bisson@archlinux.org> 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
On Wed, Mar 16, 2011 at 3:29 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Mar 16, 2011 at 3:26 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
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?
It's how a lot of tools do it. Usually for cases like this: where you have a mix of "bunch of args I want to pass" and "questions I want to ask the user" You might need to verify that getopt or whatever doesn't steal that arg, though.
[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, Mar 16, 2011 at 2:46 PM, Dan McGee <dpmcgee@gmail.com> 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. :: Synchronizing package databases... error: failed retrieving file 'repo.db' from disk : No such file or directory error: failed to update repo (No such file or directory) testing 8.5K 194.1K/s 00:00:00 [-----------------------------------------------] 100% core 37.4K 159.6K/s 00:00:00 [-----------------------------------------------] 100% extra 470.2K 584.1K/s 00:00:01 [-----------------------------------------------] 100% community-testing 0.5K 7.3M/s 00:00:00 [-----------------------------------------------] 100% community 430.9K 493.1K/s 00:00:01 [-----------------------------------------------] 100% error: could not open file /var/lib/pacman/sync/repo.db: Failed to open '/var/lib/pacman/sync/repo.db' :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): pciutils-3.1.7-4 [0.21 MB] Total Download Size: 0.21 MB Total Installed Size: 1.00 MB Proceed with installation? [Y/n] :: Retrieving packages from testing... pciutils-3.1.7-4-i686 215.0K 297.9K/s 00:00:01 [-----------------------------------------------] 100% (1/1) checking package integrity [-----------------------------------------------] 100% (1/1) checking for file conflicts [-----------------------------------------------] 100% (1/1) checking available disk space [-----------------------------------------------] 100% warning: could not determine mount point for file usr/include/pci/config.hwarning: could not determine mount point for file usr/include/ pci/header.hwarning: could not determine mount point for file usr/include/pci/pci.hwarning: could not determine mount point for file usr /include/pci/types.hwarning: could not determine mount point for file usr/lib/libpci.awarning: could not determine mount point for file usr/sbin/lspciwarning: could not determine mount point for file usr/sbin/setpciwarning: could not determine mount point for file usr/sbi n/update-pciidswarning: could not determine mount point for file usr/share/hwdata/pci.idswarning: could not determine mount point for fi le usr/share/man/man7/pcilib.7.gzwarning: could not determine mount point for file usr/share/man/man8/lspci.8.gzwarning: could not deter mine mount point for file usr/share/man/man8/setpci.8.gzwarning: could not determine mount point for file usr/share/man/man8/update-pcii ds.8.gzwarning: could not determine mount point for file /var/lib/pacman/warning: could not determine mount point for file usr/lib/libpc i.awarning: could not determine mount point for file usr/lib/libpci.so.3.1.7warning: could not determine mount point for file usr/lib/pk gconfig/libpci.pcwarning: could not determine mount point for file usr/include/pci/header.hwarning: could not determine mount point for file usr/include/pci/config.hwarning: could not determine mount point for file usr/include/pci/types.hwarning: could not determine mount point for file usr/include/pci/pci.hwarning: could not determine mount point for file usr/share/hwdata/pci.idswarning: could not determ ine mount point for file usr/share/man/man7/pcilib.7.gzwarning: could not determine mount point for file usr/share/man/man8/setpci.8.gzw arning: could not determine mount point for file usr/share/man/man8/update-pciids.8.gzwarning: could not determine mount point for file usr/share/man/man8/lspci.8.gzwarning: could not determine mount point for file usr/sbin/update-pciidswarning: could not determine mount point for file usr/sbin/setpciwarning: could not determine mount point for file usr/sbin/lspci(1/1) upgrading pciutils (1/1) upgrading pciutils [-----------------------------------------------] 100%
On Wed, 16 Mar 2011 16:31:07 -0400, Eric Bélanger wrote:
On Wed, Mar 16, 2011 at 2:46 PM, Dan McGee <dpmcgee@gmail.com> 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 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<dpmcgee@gmail.com> 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... The warning message is fixed in m git branch. It was too late for a string change once I discovered it.
Isn't CheckSpace disabled by default?
Yes it is. Allan
On Wed, Mar 16, 2011 at 5:01 PM, Allan McRae <allan@archlinux.org> 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<dpmcgee@gmail.com> 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
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
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
On 22/03/11 00:08, Tobias Powalowski wrote:
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.
That was a mistake in the translation. See https://bugs.archlinux.org/task/23315 . It is fixed an will appear in the 3.5.1 release (possibly later this week). Allan
participants (9)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Eric Bélanger
-
Gaetan Bisson
-
Ionuț Bîru
-
Pierre Schmitz
-
Ray Rashif
-
Tobias Powalowski