[arch-dev-public] [signoff] pacman 3.3.0-3
This rebuild just makes the libarchive dependency >=2.7.0-2 rather than 2.7.0. This stops the SyncFirst option updating pacman and not libarchive, thus ensuring xz-utils gets installed as a dep. This is an issue for people who last updated between 2009-04-16 and 2009-06-10. Signoff both. Allan
On Thu, Aug 6, 2009 at 6:33 AM, Allan McRae<allan@archlinux.org> wrote:
This rebuild just makes the libarchive dependency >=2.7.0-2 rather than 2.7.0. This stops the SyncFirst option updating pacman and not libarchive, thus ensuring xz-utils gets installed as a dep. This is an issue for people who last updated between 2009-04-16 and 2009-06-10.
Signoff both.
Signoff x86_64, -Sy and --version working fine. -Dan
Em Quinta-feira 06 Agosto 2009, às 09:00:20, Dan McGee escreveu:
On Thu, Aug 6, 2009 at 6:33 AM, Allan McRae<allan@archlinux.org> wrote:
This rebuild just makes the libarchive dependency >=2.7.0-2 rather than 2.7.0. This stops the SyncFirst option updating pacman and not libarchive, thus ensuring xz-utils gets installed as a dep. This is an issue for people who last updated between 2009-04-16 and 2009-06-10.
Signoff both.
Signoff x86_64, -Sy and --version working fine.
-Dan
Signoff x86_64, working ok too.
Douglas Soares de Andrade wrote:
Em Quinta-feira 06 Agosto 2009, às 09:00:20, Dan McGee escreveu:
On Thu, Aug 6, 2009 at 6:33 AM, Allan McRae<allan@archlinux.org> wrote:
This rebuild just makes the libarchive dependency >=2.7.0-2 rather than 2.7.0. This stops the SyncFirst option updating pacman and not libarchive, thus ensuring xz-utils gets installed as a dep. This is an issue for people who last updated between 2009-04-16 and 2009-06-10.
Signoff both.
Signoff x86_64, -Sy and --version working fine.
-Dan
Signoff x86_64, working ok too.
Anyone for i686? Allan
On Thu, Aug 6, 2009 at 11:04 AM, Allan McRae<allan@archlinux.org> wrote:
Douglas Soares de Andrade wrote:
Em Quinta-feira 06 Agosto 2009, às 09:00:20, Dan McGee escreveu:
On Thu, Aug 6, 2009 at 6:33 AM, Allan McRae<allan@archlinux.org> wrote:
This rebuild just makes the libarchive dependency >=2.7.0-2 rather than 2.7.0. This stops the SyncFirst option updating pacman and not libarchive, thus ensuring xz-utils gets installed as a dep. This is an issue for people who last updated between 2009-04-16 and 2009-06-10.
Signoff both.
Signoff x86_64, -Sy and --version working fine.
-Dan
Signoff x86_64, working ok too.
Anyone for i686?
Allan
signoff i686
I'm running into trouble with pacman 3.3.0-3 update. I've run -Syu in my i686 chroot and it failed in the install script with the same msg like now from outside. Now I can't resolve it from outside with -r. Any idea? [root@workstation64 /]# export LANG=C && pacman -Syu bash: /usr/bin/pacman: No such file or directory it seems all pacman files are gone. [root@workstation64 ~]# export LANG=C && pacman -r /home/andyrtr/arch64/chroots/i686/extra/ -S pacman warning: pacman-3.3.0-3 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets (1): pacman-3.3.0-3 Total Download Size: 0.00 MB Total Installed Size: 1.99 MB Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [-------------------------------------------------------------------------------------------------------------------------] 100% (1/1) upgrading pacman [-------------------------------------------------------------------------------------------------------------------------] 100% /tmp/alpm_iSpAFu/.INSTALL: line 5: /usr/bin/vercmp: No such file or directory /tmp/alpm_iSpAFu/.INSTALL: line 5: [: : integer expression expected I'm a bit out of clue what to do. A pacman.static would be nice in such case! -Andy
urgh. after changing stuff on my local mirror i had pointed in pacman.conf to the x86_64 mirror :S fixed now. anyways, a pacman.static could save a lot of time in such cases. -Andy
On Fri, Aug 7, 2009 at 11:10 AM, Andreas Radke<a.radke@arcor.de> wrote:
urgh. after changing stuff on my local mirror i had pointed in pacman.conf to the x86_64 mirror :S
fixed now. anyways, a pacman.static could save a lot of time in such cases.
2 things here: 1. pacman.static is in the pacman package, so it wouldn't have helped much, no? 2. You were missing vercmp (or the wrong arch), so that didn't work anyway If someone wants to readd a pacman.static to the pacman package, I welcome a patch *to the PKGBUILD*, but it doesn't belong in the pacman code base. And I'm still not convinced it can get you out of a lot of situations, e.g. a missing glibc still screws you. -Dan
participants (5)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Douglas Soares de Andrade
-
Eric Bélanger