You are not logged in.
Hi all,
Every time I run "pacman -Syu" I get the same list of 21 packages, that pacman installs again and again
:: Starting full system upgrade...
resolving dependencies... done.
looking for inter-conflicts... done.
Targets: bluez-libs-3.13-1 bluez-utils-3.13-1 cairo-1.4.10-1
libcups-1.2.12-1 cups-1.2.12-1 dhclient-3.0.6-1
docbook-xsl-1.73.0-1 freetype2-2.3.5-1 gcc-4.2.1-3 gimp-2.2.17-1
imagemagick-6.3.5.3-1 imap-2006j2-1 klibc-udev-114-1 less-406-1
libarchive-2.2.5-1 man-pages-2.60-1 php-5.2.3-4 pycairo-1.4.0-3
tar-1.18-1 udev-114-1 wireshark-0.99.6-3
Total Package Size: 81,00 MB
Proceed with installation? [Y/n]
checking package integrity... done.
cleaning up... done.
checking for file conflicts... done.
upgrading bluez-libs... done.
upgrading bluez-utils... done.
upgrading cairo... done.
upgrading libcups... done.
upgrading cups... done.
upgrading dhclient... done.
upgrading docbook-xsl... done.
upgrading freetype2... done.
upgrading gcc... done.
upgrading gimp...
--> printing support in gimp depends on gutenprint. Install it if you need
--> printing.
update desktop mime database...
done.
upgrading imagemagick... done.
upgrading imap... done.
upgrading klibc-udev... done.
upgrading less... done.
upgrading libarchive... done.
upgrading man-pages... done.
upgrading php...
==>
==> PHP has been built with some optional modules.
==> To enable these modules, uncomment the modules from php.ini
==>
==> The optional modules included in php require extra packages
==> to be installed.
==>
==> - mysql : libmysqlclient
==> - pgsql : postgresql-libs
==> - ldap : libldap
==> - sqlite : sqlite3
==> - odbc : unixodbc
==> - snmp : net-snmp
==> - mcrypt : mcrypt
==> FOR PHP-CGI usage:
==> There are several cgi relevant settings in your /etc/php.ini. Make sure
==> you understand them and adjust them according to your needs. At least you
==> should activate the cgi.fix_pathinfo directive in php.ini by setting it
==> to 1 and uncommenting it.
done.
upgrading pycairo... done.
upgrading tar... done.
upgrading udev...
ATTENTION UDEV:
----------
udev >=098 rules syntax has changed, please update your own rules.
udev >=099 Added persistent network and CD/DVD Symlink generator rules.
Please read the instructions carefully before reboot.
They are located in /etc/udev/readme-udev-arch.txt
----------
done.
upgrading wireshark... done.
Is it possible somehow to mark these packages as installed?
Thanks in advance,
Oleg
Last edited by olegnitz (2007-08-10 11:03:32)
Offline
Never saw anything like that Did it work nice before, and it just broke recently ?
Could you paste output of pacman -Qi cairo, and then pacman -S cairo --debug ?
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Did it work nice before, and it just broke recently ?
Exactly! Originally there was 22 "sticky" packages, then one of them was updated with a new version and "unstuck".
# pacman -Qi cairo
Name : cairo
Version : 1.4.10-1
URL : http://cairographics.org/
License : LGPL MPL
Groups : None
Provides : None
Depends On : libpng libxrender fontconfig
Removes : None
Required By : pango poppler pycairo
Conflicts With : None
Installed Size : 1379,69 K
Packager : Jan de Groot <jgc@archlinux.org>
Architecture : i686
Build Date : Thu Jun 28 19:35:13 2007 UTC
Build Type : Unknown
Install Date : Fri Aug 10 11:24:15 2007 UTC
Install Reason : Explicitly installed
Install Script : No
Description : Cairo vector graphics library
# pacman -S cairo --debug
debug: config: new section 'options'
debug: config: logfile: /var/log/pacman.log
debug: config: holdpkg: pacman
debug: config: holdpkg: glibc
debug: config: xfercommand: /usr/bin/wget --passive-ftp -c -O 1001236141 3220489436
debug: config: new section 'current'
debug: registering database 'current'
debug: opening database 'current'
debug: opening database from path '/var/lib/pacman/current/'
debug: config: including /etc/pacman.d/current
debug: attempt to re-register the 'current' database, using existing
debug: adding new server to database 'current': protocol 'ftp', server 'ftp.linux.kiev.ua', path '/pub/Linux/ArchLinux/current/os/i686'
debug: config: new section 'extra'
debug: registering database 'extra'
debug: opening database 'extra'
debug: opening database from path '/var/lib/pacman/extra/'
debug: config: including /etc/pacman.d/extra
debug: attempt to re-register the 'extra' database, using existing
debug: adding new server to database 'extra': protocol 'ftp', server 'ftp.linux.kiev.ua', path '/pub/Linux/ArchLinux/extra/os/i686'
debug: config: new section 'community'
debug: registering database 'community'
debug: opening database 'community'
debug: opening database from path '/var/lib/pacman/community/'
debug: config: including /etc/pacman.d/community
debug: attempt to re-register the 'community' database, using existing
debug: adding new server to database 'community': protocol 'ftp', server 'ftp.linux.kiev.ua', path '/pub/Linux/ArchLinux/community/os/i686'
debug: config: including /etc/pacman.d/unstable
debug: attempt to re-register the 'community' database, using existing
debug: adding new server to database 'community': protocol 'ftp', server 'ftp.linux.kiev.ua', path '/pub/Linux/ArchLinux/unstable/os/i686'
debug: registering database 'local'
debug: opening database 'local'
debug: opening database from path '/var/lib/pacman/local/'
debug: loading package cache for repository 'current'
debug: loading package cache for repository 'local'debug: package 'cairo' not found in sync
debug: adding target 'cairo' to the transaction set
resolving dependencies...
debug: resolving target's dependencies
debug: started resolving dependencies
debug: depcmp: libpng-1.2.18-1 ~= libpng => match
debug: depcmp: libxrender-0.9.2-1 ~= libxrender => match
debug: depcmp: fontconfig-2.4.2-1 ~= fontconfig => match
debug: found package 'cairo-1.4.10-1' in sync
debug: started sorting dependencies
debug: sorting cairo
debug: sorting dependencies finisheddone.
debug: looking for unresolvable dependencies
debug: depcmp: cairo-1.4.10-1 ~= cairo => match
debug: depcmp: cairo-1.4.10-1 ~= cairo => match
debug: depcmp: cairo-1.4.10-1 ~= cairo => match
debug: depcmp: cairo-1.4.10-1 ~= cairo => match
debug: depcmp: cairo-1.4.10-1 >= cairo-1.4.10 => match
debug: depcmp: cairo-1.4.10-1 >= cairo-1.4.10 => match
debug: depcmp: libpng-1.2.18-1 ~= libpng => match
debug: depcmp: libxrender-0.9.2-1 ~= libxrender => match
debug: depcmp: fontconfig-2.4.2-1 ~= fontconfig => match
looking for inter-conflicts...
debug: looking for conflicts
debug: checkconflicts: db vs target 'cairo'done.
debug: check_freespace: total pkg size: 0, disk space: 105765457920
Targets: cairo-1.4.10-1
Total Package Size: 0,53 MB
debug: cairo-1.4.10-1.pkg.tar.gz is already in the cache
checking package integrity...
debug: md5(/var/cache/pacman/pkg/cairo-1.4.10-1.pkg.tar.gz) = 3c998112ce2e4ab9fc44fd236e1982a7
debug: sha1(/var/cache/pacman/pkg/cairo-1.4.10-1.pkg.tar.gz) = ae60f3833c960ef39147dbe12e16b23734e9d2fcdone.
debug: installing packages
debug: loading target '/var/cache/pacman/pkg/cairo-1.4.10-1.pkg.tar.gz'
debug: reading 'cairo' metadata
cleaning up...
debug: cleaning updone.
checking for file conflicts...
debug: looking for file conflicts
debug: searching for filesystem conflicts: cairodone.
debug: check_freespace: total pkg size: 560050, disk space: 105765457920
upgrading cairo...
debug: upgrading package cairo-1.4.10-1
debug: removing old package first (cairo-1.4.10-1)
debug: adding cairo in the targets list
debug: removing 27 files
debug: keeping directory /usr/share/
debug: unlinking /usr/lib/pkgconfig/cairo.pc
debug: unlinking /usr/lib/pkgconfig/cairo-xlib.pc
debug: unlinking /usr/lib/pkgconfig/cairo-xlib-xrender.pc
debug: unlinking /usr/lib/pkgconfig/cairo-svg.pc
debug: unlinking /usr/lib/pkgconfig/cairo-ps.pc
debug: unlinking /usr/lib/pkgconfig/cairo-png.pc
debug: unlinking /usr/lib/pkgconfig/cairo-pdf.pc
debug: unlinking /usr/lib/pkgconfig/cairo-ft.pc
debug: keeping directory /usr/lib/pkgconfig/
debug: unlinking /usr/lib/libcairo.so.2.11.5
debug: unlinking /usr/lib/libcairo.so.2
debug: unlinking /usr/lib/libcairo.so
debug: unlinking /usr/lib/libcairo.a
debug: keeping directory /usr/lib/
debug: unlinking /usr/include/cairo/cairo.h
debug: unlinking /usr/include/cairo/cairo-xlib.h
debug: unlinking /usr/include/cairo/cairo-xlib-xrender.h
debug: unlinking /usr/include/cairo/cairo-svg.h
debug: unlinking /usr/include/cairo/cairo-ps.h
debug: unlinking /usr/include/cairo/cairo-pdf.h
debug: unlinking /usr/include/cairo/cairo-ft.h
debug: unlinking /usr/include/cairo/cairo-features.h
debug: unlinking /usr/include/cairo/cairo-deprecated.h
debug: removing directory /usr/include/cairo/
debug: keeping directory /usr/include/
debug: keeping directory /usr/
debug: updating database
debug: removing database entry 'cairo'
debug: removing entry 'cairo' from 'local' cache
debug: cannot find 'cairo-1.4.10-1' in db 'local'
debug: updating dependency packages 'requiredby' fields for cairo-1.4.10-1
debug: updating 'requiredby' field for package 'libpng'
debug: writing libpng-1.2.18-1 DEPENDS information back to db
debug: updating 'requiredby' field for package 'libxrender'
debug: writing libxrender-0.9.2-1 DEPENDS information back to db
debug: updating 'requiredby' field for package 'fontconfig'
debug: writing fontconfig-2.4.2-1 DEPENDS information back to db
debug: extracting files
debug: decompression progress: 1,828408% (10240 / 560050)
debug: decompression progress: 1,828408% (10240 / 560050)
debug: decompression progress: 1,828408% (10240 / 560050)
debug: extracting /usr/
debug: decompression progress: 1,828408% (10240 / 560050)
debug: extracting /usr/lib/
debug: decompression progress: 1,828408% (10240 / 560050)
debug: extracting /usr/lib/libcairo.so.2.11.5
debug: decompression progress: 43,881796% (245760 / 560050)
debug: extracting /usr/lib/libcairo.a
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-ft.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-ps.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-svg.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-pdf.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-png.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-xlib-xrender.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/pkgconfig/cairo-xlib.pc
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/libcairo.so.2
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/lib/libcairo.so
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/share/
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/include/
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/include/cairo/
debug: decompression progress: 95,077225% (532480 / 560050)
debug: extracting /usr/include/cairo/cairo-deprecated.h
debug: decompression progress: 96,905633% (542720 / 560050)
debug: extracting /usr/include/cairo/cairo-ps.h
debug: decompression progress: 96,905633% (542720 / 560050)
debug: extracting /usr/include/cairo/cairo-pdf.h
debug: decompression progress: 96,905633% (542720 / 560050)
debug: extracting /usr/include/cairo/cairo-xlib-xrender.h
debug: decompression progress: 96,905633% (542720 / 560050)
debug: extracting /usr/include/cairo/cairo.h
debug: decompression progress: 98,171592% (549810 / 560050)
debug: extracting /usr/include/cairo/cairo-ft.h
debug: decompression progress: 98,171592% (549810 / 560050)
debug: extracting /usr/include/cairo/cairo-features.h
debug: decompression progress: 98,171592% (549810 / 560050)
debug: extracting /usr/include/cairo/cairo-xlib.h
debug: decompression progress: 98,171592% (549810 / 560050)
debug: extracting /usr/include/cairo/cairo-svg.h
debug: adding 'pango' in requiredby field for 'cairo'
debug: adding 'poppler' in requiredby field for 'cairo'
debug: adding 'pycairo' in requiredby field for 'cairo'
debug: updating database
debug: adding database entry 'cairo'
debug: writing cairo-1.4.10-1 DESC information back to db
debug: writing cairo-1.4.10-1 FILES information back to db
debug: writing cairo-1.4.10-1 DEPENDS information back to db
debug: adding entry 'cairo' in 'local' cache
debug: updating dependency packages 'requiredby' fields for cairo-1.4.10-1
debug: updating 'requiredby' field for package 'libpng'
debug: writing libpng-1.2.18-1 DEPENDS information back to db
debug: updating 'requiredby' field for package 'libxrender'
debug: writing libxrender-0.9.2-1 DEPENDS information back to db
debug: updating 'requiredby' field for package 'fontconfig'
debug: writing fontconfig-2.4.2-1 DEPENDS information back to dbdone.
debug: logaction called: upgraded cairo (1.4.10-1 -> 1.4.10-1)
debug: running "ldconfig -r /"
debug: running "ldconfig -r /"
debug: unregistering database 'local'
debug: freeing package cache for repository 'local'
debug: closing database 'local'
debug: removing DB current, 3 remaining...
debug: unregistering database 'current'
debug: freeing package cache for repository 'current'
debug: closing database 'current'
debug: removing DB extra, 2 remaining...
debug: unregistering database 'extra'
debug: closing database 'extra'
debug: removing DB community, 1 remaining...
debug: unregistering database 'community'
debug: closing database 'community'
Offline
I forgot to ask for pacman.conf as well.
I see you made a common mistake in it, you must have something like :
[community]
Include = /etc/pacman.d/community
#[unstable]
Include = /etc/pacman.d/unstable
You should either comment or uncomment both unstable lines.
But I don't think that should hurt anything, and it doesn't explain your problem.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Oh, really. Thank you for the tip. Now my pacman.conf looks this way:
#
# /etc/pacman.conf
#
# See the pacman manpage for option directives
#
# GENERAL OPTIONS
#
[options]
LogFile = /var/log/pacman.log
HoldPkg = pacman glibc
XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
#
#[testing]
#Include = /etc/pacman.d/testing
[current]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/current
[extra]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/extra
[community]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/community
[unstable]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/unstable
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs
Offline
I had a similar issue long time ago with fewer packages... Just pacman -Rd the packages and pacman -S them right after and that should solve the problem... No idea about the real issue here however...
HTH
Offline
Before doing that, could you tar your database :
tar cvjf pacman.tar.bz2 /var/lib/pacman
So that this bug is not totally lost (if there is indeed a bug in pacman).
You could send me this file (shiningxc at gmail dot com), to see if I can reproduce it on my box.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
bangkok_manouel, thank you, your recipe works.
However I had a trouble with libarchive (yes, I removed it :), but solved it by some manual operations with files.
Due to this adventure I've recalled that the problem of "sticky" packages probably appeared after another problem with libarchive that I had some time ago. During "pacman -Syu" (than I did this not very often) pacman was upgraded to a new version, which required a new version of libarchive, which wasn't installed yet. So I manually unpacked the libarchive archive to the filesystem and successfully finished "pacman -Syu". Probably since than something remained in a broken state.
shining, in order to keep the test case I processed all packages except one, "pycairo", other 20 packages are fixed. Having one such package (with small size and few dependencies) doesn't annoy me as much as 21 big packages did. So I am ready to keep this test case as long as you want.
pacman.tar.bz2 is on the way to you.
Offline
However I had a trouble with libarchive (yes, I removed it , but solved it by some manual operations with files.
my bad. to be honest, i didn't check your package list... i should have been more careful...
Offline
It's my light-mindedness, I understood what I was doing by "pacman -Rd", but I also didn't check the package list attentively.
I thought: "Interesting, will it crash the whole system?" - and pressed Enter :)
Offline
shining, in order to keep the test case I processed all packages except one, "pycairo", other 20 packages are fixed. Having one such package (with small size and few dependencies) doesn't annoy me as much as 21 big packages did. So I am ready to keep this test case as long as you want.
pacman.tar.bz2 is on the way to you.
Hopefully you kept at least one It would have been interesting to see the others too but well, it looks very weird any way :
ls -d var/lib/pacman/local/pycairo-1.4.0-*
var/lib/pacman/local/pycairo-1.4.0-2/ var/lib/pacman/local/pycairo-1.4.0-3/
You had two entries for the same package, no clue how that could ever happen. I didn't think it was possible
Probably pacman behavior isn't defined in this case, and sometimes it sees the old version (when doing -S pycairo), and sometimes it sees the newer one (when doing pacman -Q pycairo).
The real problem is how this happened, and that looks very difficult to find out.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
At least now we have (hopefully) more safe way to fix the problem: to delete older duplicated entries.
You had two entries for the same package, no clue how that could ever happen. I didn't think it was possible smile
That's easy: look at the code between creating new entry for a new version of package and removing of an old one. Assume that some fatal error happens in between (like not found library). Will pacman remove the new entry in such case?
Will you produce a new version of pacman that can process duplicated entries uniformly? If not, then I guess I can fix the "pycairo" package, can I?
Offline
Also let me point at the possible mistake in the algorithm of upgrading of pacman. As far as I see, if pacman's version changes, then the old pacman first of all upgrades the "pacman" package, and then the new pacman processes all other packages. But the new pacman may need new versions of libraries from other packages. I think the right sequence is:
1) the old pacman upgrades the "pacman" pacage and all packages it depends on;
2) the new pacman processes all other packages.
If the above text is stupid, just ignore it
Offline
At least now we have (hopefully) more safe way to fix the problem: to delete older duplicated entries.
That's easy: look at the code between creating new entry for a new version of package and removing of an old one. Assume that some fatal error happens in between (like not found library). Will pacman remove the new entry in such case?
pacman removes the old one first, then install the new one (you can see this in your --debug output above).
Maybe it's still possible in some odd cases that it fails removing the old one, but manage to install the new one.. I'm not sure.
Will you produce a new version of pacman that can process duplicated entries uniformly? If not, then I guess I can fix the "pycairo" package, can I?
I don't really know what should be done (I'm not a dev anyway), so I suppose it would be a good idea to report this on bugs.archlinux.org
You could just paste the output of pacman -Q pycairo, pacman -Su , and showing the two duplicated entries in the db (or attaching the whole pacman.tar.bz2).
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
pacman removes the old one first, then install the new one (you can see this in your --debug output above).
As for me, it's rather strange algorithm. What if creation of the new one fails?
I don't really know what should be done (I'm not a dev anyway), so I suppose it would be a good idea to report this on bugs.archlinux.org
Oh, sorry for misunderstanding and thank you very much for your help. I'll file the bug report on Monday (the computer with the problem in at my work).
Offline
shining wrote:pacman removes the old one first, then install the new one (you can see this in your --debug output above).
As for me, it's rather strange algorithm. What if creation of the new one fails?
The main thing to do when installing a package is extracting the files from the tarball to the filesystem.
I suppose it's easier to remove all the old ones first, then extract the new ones.
Rather than overwriting all files, and then removing the ones that were present in the old version, but not in the new one.
So pacman remove old files, then remove old entry, then extract new files and finally add new entry.
If anything goes wrong in the middle, I thought pacman would just fail and leaves the system in an inconsistent state.
At least that's what reading the code seems to indicate.
But your report seems to indicate pacman failed to remove old entry, but still successfully installed new one, which I can't really explain.
You're sure you didn't do anything weird ?
Maybe having a look at /var/log/pacman.log could be interesting.
shining wrote:I don't really know what should be done (I'm not a dev anyway), so I suppose it would be a good idea to report this on bugs.archlinux.org
Oh, sorry for misunderstanding and thank you very much for your help. I'll file the bug report on Monday (the computer with the problem in at my work).
ok, no problem
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
The main thing to do when installing a package is extracting the files from the tarball to the filesystem.
I suppose it's easier to remove all the old ones first, then extract the new ones.
Rather than overwriting all files, and then removing the ones that were present in the old version, but not in the new one.
Yes, surely.
So pacman remove old files, then remove old entry, then extract new files and finally add new entry.
I would remove old files, then extract new files, then add new entry and finally remove old entry. For me this is the only one right sequence.
You're sure you didn't do anything weird ? :)
I have unpacked libarchive tarball manually twice, see description of my actions above. I don't think this could break pacman's database consistency.
Maybe having a look at /var/log/pacman.log could be interesting.
No problem. Do you wish I sent it to you on Monday, or should I attach it to my bug report?
Offline
I have unpacked libarchive tarball manually twice, see description of my actions above. I don't think this could break pacman's database consistency.
I meant before you first noticed this bug.
No problem. Do you wish I sent it to you on Monday, or should I attach it to my bug report?
Maybe I could try having a look at it first, and if it looks interesting, it could be attached to the br.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
olegnitz wrote:I have unpacked libarchive tarball manually twice, see description of my actions above. I don't think this could break pacman's database consistency.
I meant before you first noticed this bug.
Nope, not guilty!
No problem. Do you wish I sent it to you on Monday, or should I attach it to my bug report?
Maybe I could try having a look at it first, and if it looks interesting, it could be attached to the br.
Okay!
Offline
I wonder if using pacman -A when there's an already-installed older version would cause this problem.
Offline
I wonder if using pacman -A when there's an already-installed older version would cause this problem.
Oh, I was wondering the same at one point yesterday, and then I forgot to check.
But no, I just did, and pacman just fails in that case (error : package already installed).
That's why I wanted to give a look at pacman.log though, to check nothing strange was made
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Maybe having a look at /var/log/pacman.log could be interesting.
I've just sent it to you.
Offline
shining wrote:Maybe having a look at /var/log/pacman.log could be interesting.
I've just sent it to you.
Well, it's hard to tell what happened.
Maybe that big upgrade of 2007-07-16 went wrong.
Something a little strange, at the beginning of it:
338 [2007-07-16 19:02] starting full system upgrade
339 [2007-07-16 19:03] >>> PLEASE READ THE FOLLOWING!
340 [2007-07-16 19:03] >>> Use of the new rankmirrors script on your /etc/pacman.d/ files is
341 [2007-07-16 19:03] >>> highly recommended. Python is required, and read rankmirrors --help
342 [2007-07-16 19:03] >>> for details. In addition, mirrors are now listed by country, so
343 [2007-07-16 19:03] >>> move those that are geographically close to you to the top and
344 [2007-07-16 19:03] >>> remove the others BEFORE running rankmirrors.
345 [2007-07-16 19:03] upgraded pacman (3.0.5-1 -> 3.0.5-2)
346 [2007-07-16 19:07] upgraded libarchive (1.3.1-2 -> 2.2.5-1)
347 [2007-07-16 19:08] >>> PLEASE READ THE FOLLOWING!
348 [2007-07-16 19:08] >>> Use of the new rankmirrors script on your /etc/pacman.d/ files is
349 [2007-07-16 19:08] >>> highly recommended. Python is required, and read rankmirrors --help
350 [2007-07-16 19:08] >>> for details. In addition, mirrors are now listed by country, so
351 [2007-07-16 19:08] >>> move those that are geographically close to you to the top and
352 [2007-07-16 19:08] >>> remove the others BEFORE running rankmirrors.
353 [2007-07-16 19:08] upgraded pacman (3.0.5-2 -> 3.0.5-2)
354 [2007-07-16 19:08] starting full system upgrade
355 [2007-07-16 19:14] upgraded kernel-headers (2.6.20-1 -> 2.6.21.1-1)
...
What's very strange here is that it upgraded pacman before libarchive.
pacman normally install dependencies first, then actual package, so it should have put libarchive before.
And that's indeed what happened on my system.
And then I suppose you did a second manual pacman -S pacman ? Anyway that doesn't really matter.
I don't see how these things could have a relation with your broken database.
That pacman.log is probably still worth including in the bug report if you make one.
I've little hope someone will be able to figure this out until we have a 100% reproducible test case, but who knows?
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
What's very strange here is that it upgraded pacman before libarchive.
pacman normally install dependencies first, then actual package, so it should have put libarchive before.
And that's indeed what happened on my system.And then I suppose you did a second manual pacman -S pacman ?
I have described this event above. Old pacman has upgraded itself before all other packages, and haven't upgraded libarchive. After that the new pacman finished with error "Can't find libarchive library". Then I have unpacked new libarchive.so.N manually to the filesystem and the re-run pacman to install the new libarchive version "officially".
Offline
shining wrote:What's very strange here is that it upgraded pacman before libarchive.
pacman normally install dependencies first, then actual package, so it should have put libarchive before.
And that's indeed what happened on my system.And then I suppose you did a second manual pacman -S pacman ?
I have described this event above. Old pacman has upgraded itself before all other packages, and haven't upgraded libarchive. After that the new pacman finished with error "Can't find libarchive library". Then I have unpacked new libarchive.so.N manually to the filesystem and the re-run pacman to install the new libarchive version "officially".
[Sorry, I totally missed that comment.]
Well, I didn't see anyone complaining about that 3.0.5-2 upgrade, and it worked fine for me as well.
However, pacman 2 didn't handle this case properly, and behaved as you described above, which caused this problem :
http://archlinux.org/news/320/
But pacman 3 should handle it properly (either when a new dependency is added like on pacman2 -> pacman3 transition, or when a dependency is upgraded, like libarchive on 3.0.5-2 upgrade).
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline