With deceptive silence and ease, libpng-1.4.2 broke most of the interesting apps on my system. No @preserved_rebuild, no note to revdep-rebuild, just broken build and broken apps. Please add some kind of warning/instruction to this one, thanks. Reproducible: Always Steps to Reproduce:
i can confirm this. the only way i was able to fix it was to reinstall libpng-1.2.43 (i don't think r1 or r2 matters, since apps complain about not having libpng12.so.0) i have 1.2.43-r1 in :1.2 slot and 1.4.2 in :0 slot and things are currently broken because through an update libpng-1.4.2 got installed again (it oscillates between upgrading and downgrading libpng). so the way to fix this is to make sure 1.2.43-r1 or -r2 is the active installation of libpng, and i guess masking 1.4.2? on a related note, see http://bugs.gentoo.org/show_bug.cgi?id=319029
As the two libs are sloted, this should not have broken anything on your install, strange. On my ~amd64 system, I did : emerge -Dvua world emerge -a --depclean libpng:1.2 And nothing was unmerged, nor broken. =lib-1.2.43-r1 and =lib-1.4.2 are still installed. You may then proceed with re-emerging any app linked against libpng1.2, for example using something like the following: revdep-rebuild -L /usr/lib/libpng12.so.0 -- -av1
(In reply to comment #0) > No @preserved_rebuild, I think FEATURES="preserve-libs" should have caught this. Reassigning to the portage folks. (In reply to comment #2) > As the two libs are sloted, libpng-1.4.2 blocks <media-libs/libpng-1.2.43-r1, causing portage to uninstall the media-libs/libpng-1.2.43 that was available before.
(In reply to comment #3) > (In reply to comment #0) > > No @preserved_rebuild, > > I think FEATURES="preserve-libs" should have caught this. Reassigning to the > portage folks. It doesn't because this version gets uninstalled, not replaced. Preserved libs still need a package they belong to. (In reply to comment #2) > As the two libs are sloted, this should not have broken anything on your > install, strange. > > On my ~amd64 system, I did : > emerge -Dvua world If that finishes successfully, you shouldn't have more than one slot of libpng installed.
regardless of whether i did this in any wisdom or not, i manually slotted 1.2 and 1.4 (because i thought that's how it was supposed to be, since there were both :0 and :1.2 slots). but as such it appears that whichever gets installed last and becomes the active install takes precedence...so for whatever reason libpng12 dissolves
his is a disaster. Initially many apps were broken. Then, having tried various approaches including preserved-rebuild (initially not an option), revdep-rebuild, and installing/re-installing both versions, the situation began to look normal but in fact is only broken differently in that apps are now linked against both(!) versions of libpng: # ldd /usr/bin/rrdtool | grep png libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f9886f8c000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007f9886893000) meaning that preserved-rebuild wants to go round the loop again: [ebuild R ] net-analyzer/rrdtool-1.4.2 USE="lua perl python rrdcgi ruby tcl -doc" Only libpng-1.4.2 is actually installed (no slots).
(In reply to comment #6) > his is a disaster. > > Initially many apps were broken. > > Then, having tried various approaches including preserved-rebuild (initially > not an option), revdep-rebuild, and installing/re-installing both versions, the > situation began to look normal but in fact is only broken differently in that > apps are now linked against both(!) versions of libpng: > > # ldd /usr/bin/rrdtool | grep png > libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f9886f8c000) > libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007f9886893000) > > meaning that preserved-rebuild wants to go round the loop again: > > [ebuild R ] net-analyzer/rrdtool-1.4.2 USE="lua perl python rrdcgi ruby > tcl -doc" > > Only libpng-1.4.2 is actually installed (no slots). > How do you manage to have two libpng slots installed?
i'm the one with two libpng slots installed and i use paludis so, $ paludis -i =media-libs/libpng-1.2.43.-r1:1.2 =media-libs/libpng-1.4.2:0
(In reply to comment #8) > i'm the one with two libpng slots installed > and i use paludis > so, > $ paludis -i =media-libs/libpng-1.2.43.-r1:1.2 =media-libs/libpng-1.4.2:0 > Yeah, you're right, I missed that 1.2.43-r1 is in slot 1.2. @base-system: Is it intentional that these two version can be installed together? In addition, you most likely want a strong block, because otherwise people using --jobs might have two (weak) blocking versions installed for some time.
(In reply to comment #3) > (In reply to comment #0) I see your point about preserve-rebuild, however, doing a regular emerge -D -u world does actually : - upgrade libpng from 1.2.43 to 1.2.43-r1 in slot :1.2 - and install 1.4.2 in slot :0 At least it is precisely what it did on my box.
Ok, people, i finally solved it for me. I had to emerge kdelibs first to find the new libpng, and then i ran revdep-rebuild and everything compiles smoothly again... Try it too (if you have kde).
(In reply to comment #10) > (In reply to comment #3) > > (In reply to comment #0) > > I see your point about preserve-rebuild, however, doing a regular emerge -D -u > world does actually : > - upgrade libpng from 1.2.43 to 1.2.43-r1 in slot :1.2 > - and install 1.4.2 in slot :0 > > At least it is precisely what it did on my box. It may do that if you have any packages installed that pull in libpng 1.2. If you don't, it will install libpng 1.4.2, and then uninstall 1.2.43. At least it is precisely what it did on my box. :)
Can you compile x11-misc/notification-daemon against new libpng? I get this: /bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -O2 -march=pentium-m -pipe -Wall -Wl,-O1 -Wl,--sort-common -o notification-properties notification-properties.o -lglade-2.0 -lxml2 -lgconf-2 -lnotify -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -ldbus-glib-1 -ldbus-1 -lpthread -lrt -lgobject-2.0 -lglib-2.0 libtool: link: i686-pc-linux-gnu-gcc -O2 -march=pentium-m -pipe -Wall -Wl,-O1 -Wl,--sort-common -o notification-properties notification-properties.o /usr/lib/libglade-2.0.so -L/usr/lib -lpng12 /usr/lib/libxml2.so /usr/lib/libgconf-2.so /usr/lib/libORBit-2.so /usr/lib/libgthread-2.0.so /usr/lib/libnotify.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libgio-2.0.so -lresolv /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libcairo.so /usr/lib/libpixman-1.so /usr/lib/libglitz-glx.so /usr/lib/libXmu.so /usr/lib/libXt.so /usr/lib/libSM.so -luuid /usr/lib/libICE.so /usr/lib/libXi.so /usr/lib/libXext.so -lGL /usr/lib/libglitz.so /usr/lib/libpng14.so /usr/lib/libxcb-render-util.so /usr/lib/libxcb-render.so /usr/lib/libXrender.so /usr/lib/libX11.so /usr/lib/libxcb.so /usr/lib/libXau.so /usr/lib/libXdmcp.so /usr/lib/libpango-1.0.so -lm /usr/lib/libfontconfig.so /usr/lib/libfreetype.so -lz /usr/lib/libexpat.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libdbus-glib-1.so /usr/lib/libdbus-1.so -lpthread -lrt /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -pthread /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status distcc[30451] ERROR: compile (null) on localhost failed make[3]: *** [notification-properties] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 I guess I should file a new bugreport?
(In reply to comment #11) > Ok, people, i finally solved it for me. I had to emerge kdelibs first to find > the new libpng, and then i ran revdep-rebuild and everything compiles smoothly > again... Try it too (if you have kde). > Update: I had to emerge libglade again :) everything compiled fine. :)
(In reply to comment #12) > > It may do that if you have any packages installed that pull in libpng 1.2. If > you don't, it will install libpng 1.4.2, and then uninstall 1.2.43. > > At least it is precisely what it did on my box. :) > That was my experience.
it broked the whole gnome desktop indeed. using emerge to do pakcage update it will upgrade libpng-1.2.43-r1/r2 to libpng-1.4.2, using paludis, libpng-1.2.43-r1 will take a new slot and installed side by side with 1.4.2, libpng-1.2.43-r2 will take the same slot with libpng-1.4.2 so that they replace each other when install one or the other. and "paludis -q libpng" shows this is the case. maybe 1.4.2 should take a slot alone; libpng-1.2.43-r1 and libpng-1.2.43-r2 take the same :1.2 slot.
Here's what I did: first I removed all versions of libpng, then I installed 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old lib and provided the preserved-rebuild set. I also noticed, that 1.2.43-r1 form slot 1.2 doesn't install the /usr/lib64/libpng12.so.0 symlink - and apps are unable to find id until I make that link by hand.
(In reply to comment #17) > Here's what I did: first I removed all versions of libpng, then I installed > 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old > lib and provided the preserved-rebuild set. > > I also noticed, that 1.2.43-r1 form slot 1.2 doesn't install the > /usr/lib64/libpng12.so.0 symlink - and apps are unable to find id until I make > that link by hand. > how to make that link by hand????
@blackdream cd /usr/lib ln -s libpng12.so.0.43.0 libpng12.so.0
(In reply to comment #19) > @blackdream > cd /usr/lib > ln -s libpng12.so.0.43.0 libpng12.so.0 > have U unmerge the libpng-1.2.43-r1???? the links is already exist................
How did you guys rebuild everything against the new libpng? Still kind of stuck. Some packages seem to recompile, others do not. Still fighting with the order (no revdep-rebuild does *NOT* get the order right). I'm on ~amd64 (fully unstable). Perhaps some packages are still looking for the old version (in fact, they try to link hard against the old version). Don't know where they get the version number from. The old version is in /usr/lib32 but this probably comes with a binary compatibility package. I run very little (if any) 32 bit software. flaptoppy / # cd /usr/lib32 flaptoppy lib32 # ls -l libpng* lrwxrwxrwx 1 root root 18 apr 15 21:50 libpng12.so -> libpng12.so.0.40.0 lrwxrwxrwx 1 root root 18 apr 15 21:50 libpng12.so.0 -> libpng12.so.0.40.0 -rwxr-xr-x 1 root root 140968 dec 30 15:27 libpng12.so.0.40.0 lrwxrwxrwx 1 root root 11 apr 15 21:50 libpng.so -> libpng12.so lrwxrwxrwx 1 root root 16 apr 15 21:50 libpng.so.3 -> libpng.so.3.40.0 -rwxr-xr-x 1 root root 153708 dec 30 15:27 libpng.so.3.40.0 flaptoppy lib32 # cd ../lib flaptoppy lib # ls -l libpng* -rw-r--r-- 1 root root 236542 mei 10 09:48 libpng14.a -rw-r--r-- 1 root root 935 mei 10 09:48 libpng14.la lrwxrwxrwx 1 root root 18 mei 10 09:48 libpng14.so -> libpng14.so.14.2.0 lrwxrwxrwx 1 root root 18 mei 10 09:48 libpng14.so.14 -> libpng14.so.14.2.0 -rwxr-xr-x 1 root root 158400 mei 10 09:48 libpng14.so.14.2.0 lrwxrwxrwx 1 root root 10 mei 10 09:48 libpng.a -> libpng14.a lrwxrwxrwx 1 root root 11 mei 10 09:48 libpng.la -> libpng14.la lrwxrwxrwx 1 root root 11 mei 10 09:48 libpng.so -> libpng14.so Still seeing how far I can get by putting the packages revdep-rebuild finds manually in a 'emerge -j 3 --keep-going -1 <pacagkes>'. The list slowly gets smaller, but although I think I have most base libs recompiled, there are still quite a few packages failing. Will see how far I can get. Eventually I should only have a list of packages left that won't compile now, since due to deps some compile now after I had some others.
(In reply to comment #17) > Here's what I did: first I removed all versions of libpng, then I installed > 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old > lib and provided the preserved-rebuild set. This was very useful advice. It worked perfectly on all my non-libpng-broken systems. Thanks.
I got many ld errors ... cannot find -lpng12 ... (I have both versions installed) Then I tried the following, since it needs the old one: cd /usr/lib ln -snvf libpng12.so.0.43.0 libpng12.so cd /usr/lib64 ln -snvf libpng12.so.0.43.0 libpng12.so THAT WORKED :D That means ld will find it for now, e.g.: ld -l png12 will give other output than "not found".
Been recompiling for a while, only had the new version installed. Even after unmerging all libpng versions, remerging 1.2.43-r2 and then upgrading it didn't get slotted. @preserved-rebuild doesn't have it either. These are the 18 packages I can't get past: dev-python/gnome-applets-python dev-python/gtkhtml-python dev-python/libbonobo-python dev-python/libgnomecanvas-python dev-python/libgnome-python gnome-base/gdm gnome-base/gnome-applets gnome-base/gnome-panel gnome-base/libbonoboui gnome-base/libgnomeprintui gnome-base/libgnomeui gnome-extra/gnome-power-manager gnome-extra/gnome-system-monitor gnome-extra/gnome-utils mail-client/evolution media-sound/grip net-analyzer/gnome-netstatus net-print/gnome-cups-manager For now I just emerged the older version, grabbed some files, upgraded, copied the files in and I have a working system now. Will have to remember to remove them eventually. Copied these back: -rw-r--r-- 1 root root 241214 mei 10 22:54 /usr/lib64/libpng12.a -rw-r--r-- 1 root root 934 mei 10 22:54 /usr/lib64/libpng12.la lrwxrwxrwx 1 root root 18 mei 10 22:57 /usr/lib64/libpng12.so -> libpng12.so.0.43.0 lrwxrwxrwx 1 root root 18 mei 10 22:57 /usr/lib64/libpng12.so.0 -> libpng12.so.0.43.0 -rwxr-xr-x 1 root root 158520 mei 10 22:54 /usr/lib64/libpng12.so.0.43.0
Btw, I also have kde4 installed, that recompiled fine. IIRC most of the order issues came from gnome and gnome packages seem to be much more dependent on it. Guessing in KDE it might be wrapped through kdelibs or something.
I have the same problems, for now my solution has been masking =media-libs/libpng-1.4.2 The only packages that on my system can't rebuild against libpng new version were =dev-python/pygtk-2.16.0-r1 and =app-emulation/virtualbox-ose-3.1.6
(In reply to comment #24) > Been recompiling for a while, only had the new version installed. Even after > unmerging all libpng versions, remerging 1.2.43-r2 and then upgrading it didn't > get slotted. @preserved-rebuild doesn't have it either. Try this: emerge -1 libglade pango cairo glitz libgnomecanvas fontconfig freetype I have no idea which ones are actually needed, but I managed to rebuild most of the Gnome stuff I have afterwards. If anything breaks, try a different order. In fact, the only thing I still can't get to link is dev-python/gtksourceview-python: ibtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/gtksourceviewmodule.o .libs/gtksourceview.o /usr/lib64/libgtksourceview-1.0.so -L/usr/lib64 /usr/lib64/libXmu.so /usr/lib64/libXt.so /usr/lib64/libSM.so -luuid /usr/lib64/libICE.so /usr/lib64/libXi.so /usr/lib64/libXext.so -lpng12 /usr/lib64/libgtk-x11-2.0.so /usr/lib64/libgnomeprint-2-2.so /usr/lib64/libgdk-x11-2.0.so /usr/lib64/libatk-1.0.so /usr/lib64/libgdk_pixbuf-2.0.so /usr/lib64/libgio-2.0.so -lresolv /usr/lib64/libpangocairo-1.0.so /usr/lib64/libpangoft2-1.0.so /usr/lib64/libcairo.so /usr/lib64/libpixman-1.so /usr/lib64/libglitz-glx.so -lGL -lpthread /usr/lib64/libglitz.so /usr/lib64/libpng14.so /usr/lib64/libxcb-render-util.so /usr/lib64/libxcb-render.so /usr/lib64/libXrender.so /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so /usr/lib64/libexpat.so /usr/lib64/libart_lgpl_2.so /usr/lib64/libxml2.so -lz /usr/lib64/libpango-1.0.so -lm /usr/lib64/libgobject-2.0.so /usr/lib64/libgmodule-2.0.so -ldl /usr/lib64/libglib-2.0.so -march=core2 -Wl,-O1 -Wl,-soname -Wl,gtksourceview.so -Wl,-version-script -Wl,.libs/gtksourceview.ver -o .libs/gtksourceview.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status
(In reply to comment #19) > @blackdream > cd /usr/lib > ln -s libpng12.so.0.43.0 libpng12.so.0 > i don't seem to have libpng12.so.0.43.0, and i followed the instructions in comment #17, but everything is still broken keeping 1.2.43-r2 installed has been my fix, most packages are okay with that, though my custom install of mplayer isn't...
I already posted the temporary solution for the linking-problem: ../i686-pc-linux-gnu/bin/ld: cannot find -lpng12 - needed of course is the old media-libs/libpng-1.2.43-r1 - that fixed my whole broken system (In reply to comment #23) > cd /usr/lib > ln -snvf libpng12.so.0.43.0 libpng12.so > cd /usr/lib64 > ln -snvf libpng12.so.0.43.0 libpng12.so
Actually, there are very few packages that don't compile with libpng-1.4, and most of them have already received a patch in the tree. To recompile everything against the new libpng: If temporary breakage is not a problem for you: 1) lafilefixer --justfixit 2) emerge -av1 =libpng-1.4.2 3) emerge -avC libpng:0 4) revdep-rebuild -- -av1 --keep-going 5) Now, some package will fail to recompile (thus --keep-going), because they use link-time flags from .la files of libraries belonging to some of their dependencies. To find the "faulty" packages, use something like: for item in $(ls -1R *.la); do if $(grep -q png12 $item); then qfile $item; fi; done and then recompile the package in the list from the output of above script. 6) Another run of revdep-rebuild, and your system should be clean (excepted packages that really fail with the new libpng. If you still require them, install the old libpng:0 and create the needed symlink in /usr/lib/) Anyway, this is ~arch, always fun. YMMV
this solution to put libpng-1.2.43-r2 in slot :1.2 : # cd /usr/portage/media-libs/libpng # sed -i 's/SLOT="0"/SLOT="1.2"/' libpng-1.2.43-r2.ebuild # ebuild libpng-1.2.43-r2.ebuild manifest # paludis -i1 =media-libs/libpng-1.2.43-r2 # paludis -i1 libpng then nothing will be broken, and no fixing needed any more.
(In reply to comment #31) > this solution to put libpng-1.2.43-r2 in slot :1.2 : > > # cd /usr/portage/media-libs/libpng > # sed -i 's/SLOT="0"/SLOT="1.2"/' libpng-1.2.43-r2.ebuild > # ebuild libpng-1.2.43-r2.ebuild manifest > # paludis -i1 =media-libs/libpng-1.2.43-r2 > # paludis -i1 libpng > > then nothing will be broken, and no fixing needed any more. > that's wrong in so many ways, just let's hope nobody will take your advise :)
My steps: 1. Upgrade to libpng-1.4.2 2. revdep-rebuild (or @preserved-rebuild) [ until one of them bails out at some point ] 3. Run something like "libpng-1.4.x-update.sh", a.k.a. fix broken .la files 4. Finish my revdep-rebuild (or @preserved-rebuild) Worked like a breeze. I can imagine also few --resume --skip-first or --keep-going's saving the day. At any rate it's just a bit more difficult upgrade than everyday jpeg or expat upgrade (just kidding). I don't think there's anything special required to do here.
(In reply to comment #33) > My steps: > > 1. Upgrade to libpng-1.4.2 > 2. revdep-rebuild (or @preserved-rebuild) > > [ until one of them bails out at some point ] > > 3. Run something like "libpng-1.4.x-update.sh", a.k.a. fix broken .la files > 4. Finish my revdep-rebuild (or @preserved-rebuild) Do you mean lafilefixer --justfixit ? > > Worked like a breeze. I can imagine also few --resume --skip-first or > --keep-going's saving the day. > Not for me many packaged still searching libpng12.la and stop emerging
(In reply to comment #34) > Not for me many packaged still searching libpng12.la and stop emerging After struggling with different approaches of install/uninstall, revdep-rebuild, lafilefixer, libpng-1.4.x-update.sh this worked: * Uninstall all libpng versions * Install libpng-1.4.2 * Unmask & Install libpng-1.2.43-r1 (because I still got packages depending on <1.4) * revdep-rebuild (didn't find any thing here, but i ran it multiple times before)
(In reply to comment #35) > * Unmask & Install libpng-1.2.43-r1 (because I still got packages depending on > <1.4) It's slotted in my case. I don't have to unmask anything. eix libpng [I] media-libs/libpng Available versions: (1.2) *1.2.40 1.2.43-r1 (0) 1.2.43-r2 (~)1.4.2 Installed versions: 1.2.43-r1(1.2)(21:00:49 10.05.2010) 1.4.2(10:30:58 11.05.2010) Nevertheless I'm recompiling half of the system due to this - including gcc. So I have to wait a couple of hours.
Hi, remerging, no matter what the order did not solve it for me. Note, portage does *NOT* slot here, I *only* have 1.4. There are also *NO* 1.2 files left behind (for people noticing I copied them from old install, I removed them again), as is the case with some others apparently (some people here only recreate 2 symlinks and have no issues then, the file (libpng12.so.0.43.0) the symlink points to is gone here as well). As you can see from my previous posts, rerunning emerge lots of times (over 20...) got it reduced to 18 packages. Then I saw mention of the /usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh script. Read it and saw it fixes la files. Recalled having issues with la files before and figured I'd just run 'lafilefixer --justfixit' and get it sorted out. Unfortunately, this doesn't work. Apparently lafilefixer only fixes a subnet (it did update over 90% of the libraries.... iek...). Don't quite get la files pointing to hard filenames in the first place and they apparently get updated badly. Anyways, after lafilefixer tried to emerge the 18 packages again, I run it with -j 3, first 3 it tried failed. Aborted emerge, ran the provided script (/usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh), emerges fine now (12 of 18 done, not done yet, but no errors so far). One does wonder why lafilefixer didn't get it. Apparently it doesn't fix everything.
Err gcc definitely doesn't depend on libpng... I presume you choose to do this?
Everybody except Portage developers: Please stop commenting on this bug and use e.g. Gentoo Forums.
(In reply to comment #37) > Hi, > > remerging, no matter what the order did not solve it for me. > > Note, portage does *NOT* slot here, I *only* have 1.4. There are also *NO* 1.2 > files left behind (for people noticing I copied them from old install, I > removed them again), as is the case with some others apparently (some people > here only recreate 2 symlinks and have no issues then, the file > (libpng12.so.0.43.0) the symlink points to is gone here as well). > > As you can see from my previous posts, rerunning emerge lots of times (over > 20...) got it reduced to 18 packages. > > Then I saw mention of the > /usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh script. Read it and > saw it fixes la files. > > Recalled having issues with la files before and figured I'd just run > 'lafilefixer --justfixit' and get it sorted out. Unfortunately, this doesn't > work. Apparently lafilefixer only fixes a subnet (it did update over 90% of the > libraries.... iek...). Don't quite get la files pointing to hard filenames in > the first place and they apparently get updated badly. Anyways, after > lafilefixer tried to emerge the 18 packages again, I run it with -j 3, first 3 > it tried failed. > > Aborted emerge, ran the provided script > (/usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh), emerges fine now > (12 of 18 done, not done yet, but no errors so far). > > One does wonder why lafilefixer didn't get it. Apparently it doesn't fix > everything. > All not working for me. I need to mask libpng-1.4.2 to receive a running system.
This problem caused **massive** headaches here. My desktop did not work until I rebuild over 100 packages. And then it worked only halfways, because I have 135 packages that do still expect libpng.1.2x when trying to rebuild them with revdep-rebuild. (Which fails) Only masking >=media-libs/libpng-1.3 did help. (At which point I did not need to rebuild them.) It took me from Sunday till now, and I still ain’t back to a working system. (Still revdep-rebuilding the already rebuilt packages back to 1.2.x after masking.) I know that one shouldn’t complain when one gets something for free, but who thought this was a good idea? :/ These problems are the reason you can’t put Gentoo on servers that have to work all the time... :/
(In reply to comment #41) > This problem caused **massive** headaches here. > > My desktop did not work until I rebuild over 100 packages. And then it worked > only halfways, because I have 135 packages that do still expect libpng.1.2x > when trying to rebuild them with revdep-rebuild. (Which fails) > Only masking >=media-libs/libpng-1.3 did help. (At which point I did not need > to rebuild them.) > > It took me from Sunday till now, and I still ain’t back to a working system. > (Still revdep-rebuilding the already rebuilt packages back to 1.2.x after > masking.) > > I know that one shouldn’t complain when one gets something for free, but who > thought this was a good idea? :/ > These problems are the reason you can’t put Gentoo on servers that have to > work all the time... :/ > Offtopic: Hey dude libpng-1.4.2 is ~amd64 ~x86, etc I think the reason why you use it is you WANT TO TEST for others, because you are an experienced user? I really can only hope that you don't use unstable versions of ANY distribution on critical servers?! P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild many packages, but that's something I know, instead I wouldn't use Gentoo if I don't want to compile).
<offtopic> (Feel free to ignore. That would only strengthen my argument. ;) (In reply to comment #42) > Hey dude libpng-1.4.2 is ~amd64 ~x86, etc First of all, I’m not your dude. :) > I think the reason why you use it is you WANT TO TEST for others, because you > are an experienced user? Second: Agreed. :) Sorry, this is true in this case. I should have specified that I did mean this in general, for stable packages too. > I really can only hope that you don't use unstable versions of ANY distribution > on critical servers?! No, I’m not insane. :) I would be as shocked as you. Unfortunately I tried stable, even hardened x86 on a dedicated testing server, to look it it would be an option to switch critical servers to it. After huge problems I switched it back to Debian. (And, yes, I am a very experienced user. I am usually the one giving support, not receiving it. :) > P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild > many packages, but that's something I know, instead I wouldn't use Gentoo if I > don't want to compile). Straw man argument. Nobody said I would not want to compile or that 1.2.x would not work. Even 1.4.x does work. The problem is that lots of packages still expect 1.2.x when only 1.4.x is installed, as their ebuild dependencies are apparently faulty. I’d bet you money that you will fall over that one when 1.4.x is going stable, as I know how such incidents were handled in the past, and that in that regard, policies and mechanics haven’t changed. </offtopic>
I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to 1.4 and mask 1.2.43-r2. Then 1.2.43 and 1.4.2 can co-exist happily.
(In reply to comment #44) > I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to > 1.4 and mask 1.2.43-r2. Then 1.2.43 and 1.4.2 can co-exist happily. > Nobody needs to repeat your mistake, they can be installed slotted from Portage fine as-is, $ sudo emerge -pv =libpng-1.2.43-r1 =libpng-1.4.2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB [ebuild R ] media-libs/libpng-1.4.2 0 kB Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB
I'll repeat for all those who ended up with a broken system (binaries linked against old libpng not working): 1)# emerge -C libpng 2)# emerge -1 =media-libs/libpng-1.2.43-r2 3)# emerge -1 libpng That way portage will keep the old libpng.12.so until all packages linking against it are rebuilt.
i have libpng-1.2.43-r2 installed, no other versions of libpng but i don't have libpng12.so or in fact ANYTHING with libpng12.so in the filename in /lib or /usr/lib however, all of my packages work. so i don't really understand what's going on but trying to update to libpng-1.4.2 breaks everything.
with 1.4.2 installed only without 1.2: and after revdep-rebuild, /usr/sbin/libpng-1.4.x-update.sh, revdep-rebuild, gnome-panel 2.28/2.30(both) crashed immediately after desktop startup, showing a bug budy message: ========================== Distribution: Gentoo Base System release 2.0.1 Gnome Release: 2.30.0 2010-05-11 (Gentoo) BugBuddy Version: 2.30.0 System: Linux 2.6.33-ccs-r2 #1 SMP Tue May 4 01:58:19 CST 2010 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10800000 Selinux: No Accessibility: Enabled GTK+ Theme: Clearlooks Icon Theme: gnome GTK+ Modules: canberra-gtk-module, gnomebreakpad, gail:atk-bridge Memory status: size: 475983872 vsize: 475983872 resident: 22700032 share: 17338368 rss: 22700032 rss_rlim: 18446744073709551615 CPU usage: start_time: 1273635414 rtime: 33 utime: 30 stime: 3 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/gnome-panel' Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2400.1-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace [Thread debugging using libthread_db enabled] Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.0/libstdc++.so.6.0.14-gdb.py", line 59, in <module> from libstdcxx.v6.printers import register_libstdcxx_printers ImportError: No module named libstdcxx.v6.printers 0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0 #0 0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0 #1 0x00007febbb0fdc21 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 #2 0x00007febbb0fe1a1 in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 #3 0x00007febb8600e38 in bugbuddy_segv_handle(int) () from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so #4 <signal handler called> #5 0x00007febba1b8bd5 in raise () from /lib/libc.so.6 #6 0x00007febba1ba415 in abort () from /lib/libc.so.6 #7 0x00007febbb0c05de in g_logv () from /usr/lib/libglib-2.0.so.0 #8 0x00007febbb0c0673 in g_log () from /usr/lib/libglib-2.0.so.0 #9 0x00007febbb0be4dc in g_malloc () from /usr/lib/libglib-2.0.so.0 #10 0x00007febbb08ff9d in g_base64_encode () from /usr/lib/libglib-2.0.so.0 #11 0x00007febad10f557 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so #12 0x00007febbd21b807 in png_push_read_chunk () from /usr/lib/libpng14.so.14 #13 0x00007febbd21c84b in png_process_data () from /usr/lib/libpng14.so.14 #14 0x00007febad10eb12 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so #15 0x00007febbe23394a in gdk_pixbuf_loader_write () from /usr/lib/libgdk_pixbuf-2.0.so.0 #16 0x00007febbe231406 in gdk_pixbuf_new_from_file_at_scale () from /usr/lib/libgdk_pixbuf-2.0.so.0 #17 0x000000000043a005 in panel_load_icon () #18 0x000000000042e620 in button_widget_reload_pixbuf () #19 0x000000000042f1a6 in button_widget_size_allocate () #20 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #21 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #22 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #23 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #24 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 #25 0x000000000042adaf in panel_widget_size_allocate () #26 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #27 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #28 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #29 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #30 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 #31 0x000000000046041a in panel_frame_size_allocate () #32 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #34 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #36 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 #37 0x00007febbeadc9a4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #38 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #39 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #40 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #41 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #42 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 #43 0x00000000004567f1 in panel_toplevel_size_allocate () #44 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #45 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #46 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #47 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #48 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 #49 0x000000000045605b in panel_toplevel_check_resize () #50 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #51 0x00007febbbbc759c in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #52 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #53 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #54 0x00007febbe9d6700 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #55 0x00007febbe688316 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #56 0x00007febbb0b701e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #57 0x00007febbb0b78d0 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #58 0x00007febbb0b8092 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #59 0x00007febbea51ef7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #60 0x000000000042888c in main () Thread 1 (Thread 0x7febc53228a0 (LWP 8074)): #0 0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007febbb0fdc21 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007febbb0fe1a1 in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007febb8600e38 in bugbuddy_segv_handle(int) () from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so No symbol table info available. #4 <signal handler called> No symbol table info available. #5 0x00007febba1b8bd5 in raise () from /lib/libc.so.6 No symbol table info available. #6 0x00007febba1ba415 in abort () from /lib/libc.so.6 No symbol table info available. #7 0x00007febbb0c05de in g_logv () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #8 0x00007febbb0c0673 in g_log () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #9 0x00007febbb0be4dc in g_malloc () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #10 0x00007febbb08ff9d in g_base64_encode () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #11 0x00007febad10f557 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so No symbol table info available. #12 0x00007febbd21b807 in png_push_read_chunk () from /usr/lib/libpng14.so.14 No symbol table info available. #13 0x00007febbd21c84b in png_process_data () from /usr/lib/libpng14.so.14 No symbol table info available. #14 0x00007febad10eb12 in ?? () from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so No symbol table info available. #15 0x00007febbe23394a in gdk_pixbuf_loader_write () from /usr/lib/libgdk_pixbuf-2.0.so.0 No symbol table info available. #16 0x00007febbe231406 in gdk_pixbuf_new_from_file_at_scale () from /usr/lib/libgdk_pixbuf-2.0.so.0 No symbol table info available. #17 0x000000000043a005 in panel_load_icon () No symbol table info available. #18 0x000000000042e620 in button_widget_reload_pixbuf () No symbol table info available. #19 0x000000000042f1a6 in button_widget_size_allocate () No symbol table info available. #20 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #21 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #22 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #23 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #24 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #25 0x000000000042adaf in panel_widget_size_allocate () No symbol table info available. #26 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #27 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #28 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #29 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #30 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #31 0x000000000046041a in panel_frame_size_allocate () No symbol table info available. #32 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #33 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #34 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #35 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #36 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #37 0x00007febbeadc9a4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #38 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #39 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #40 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #41 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #42 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #43 0x00000000004567f1 in panel_toplevel_size_allocate () No symbol table info available. #44 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #45 0x00007febbbbc6e78 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #46 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #47 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #48 0x00007febbeb72a21 in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #49 0x000000000045605b in panel_toplevel_check_resize () No symbol table info available. #50 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #51 0x00007febbbbc759c in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #52 0x00007febbbbd16ab in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #53 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #54 0x00007febbe9d6700 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #55 0x00007febbe688316 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 No symbol table info available. #56 0x00007febbb0b701e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #57 0x00007febbb0b78d0 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #58 0x00007febbb0b8092 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #59 0x00007febbea51ef7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #60 0x000000000042888c in main () No symbol table info available. A debugging session is active. Inferior 1 [process 8074] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] ---- Critical and fatal warnings logged during execution ---- ** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes ----------- .xsession-errors (485198 sec old) --------------------- This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 925 error_code 8 request_code 3 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Launching a SCIM daemon with Socket FrontEnd... Loading simple Config module ... Creating backend ... Loading socket FrontEnd module ... Starting SCIM as daemon ... GTK Panel of SCIM 1.4.9 -------------------------------------------------- ==========================
(In reply to comment #45) > (In reply to comment #44) > > I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to > > 1.4 and mask 1.2.43-r2. Then 1.2.43 and 1.4.2 can co-exist happily. > > > > Nobody needs to repeat your mistake, they can be installed slotted from Portage > fine as-is, > > $ sudo emerge -pv =libpng-1.2.43-r1 =libpng-1.4.2 > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild NS ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB > [ebuild R ] media-libs/libpng-1.4.2 0 kB > > Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB > Ok, what's going on when you run after the above steps revdep-rebuild? I'll tried it that way and about ~165 packages should be rebuild, and the second one (dunno which one it was, I'm working on this problem since sunday) stops...
(In reply to comment #43) > <offtopic> (Feel free to ignore. That would only strengthen my argument. ;) offtopic I will not Ignore :D > (In reply to comment #42) > > Hey dude libpng-1.4.2 is ~amd64 ~x86, etc > First of all, I’m not your dude. :) Sorry, if I abused you, that wasn't my intention, so accept my appologies :) > > I think the reason why you use it is you WANT TO TEST for others, because you > > are an experienced user? > Second: Agreed. :) Sorry, this is true in this case. I should have specified > that I did mean this in general, for stable packages too. Ok, that's a point and yes you are right with this, I had the problems also in the past.... > > I really can only hope that you don't use unstable versions of ANY distribution > > on critical servers?! > No, I’m not insane. :) I would be as shocked as you. Unfortunately I tried > stable, even hardened x86 on a dedicated testing server, to look it it would be > an option to switch critical servers to it. After huge problems I switched it > back to Debian. (And, yes, I am a very experienced user. I am usually the one > giving support, not receiving it. :) > On critical system I also prefer Debian, but to be honest, on a Desktop System Debian (stable) has much too old packages in 90% (dunno for other, I'm talking from my experiences) and if you are using unstable, testing, squeeze the package-manager could be a pain (one time it wanted to delete my half X-System and gnome, because some dependencies were not in the tree during my update-time) > > P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild > > many packages, but that's something I know, instead I wouldn't use Gentoo if I > > don't want to compile). > Straw man argument. Nobody said I would not want to compile or that 1.2.x would > not work. Even 1.4.x does work. The problem is that lots of packages still > expect 1.2.x when only 1.4.x is installed, as their ebuild dependencies are > apparently faulty. Ok, that's really an argument, but that's life and I think I can live with it. But that's something everybody need to decide for himself. > I’d bet you money that you will fall over that one when 1.4.x is going > stable, as I know how such incidents were handled in the past, and that in that > regard, policies and mechanics haven’t changed. > </offtopic> > We will see ;) And no I don't want to bet :P /offtopic
(In reply to comment #48) > with 1.4.2 installed only without 1.2: and after revdep-rebuild, > /usr/sbin/libpng-1.4.x-update.sh, revdep-rebuild, > > gnome-panel 2.28/2.30(both) crashed immediately after desktop startup, showing Not sure on where overlay bugs go, but I doubt it's here. 2.30 is not in portage and it's bugs don't appear related to libpng either. In either case, your report seems out of place here. You should probably take it up with the overlay maintainer. Just that 2.28 crashes now too, might very well be because of one of the other packages it depends on comes from overlay. I have no issues any more, everything rebuilt fine. You basically have several options 1) Install 1.2 and stay away from 1.4. 2) Try to get 1.2 and 1.4 next to each other. 3) Trying to get only 1.4. The latter will require rebuilding a lot. Middle one doesn't matter much First one, if you rebuilt stuff against 1.4 already, it will have to be rebuilt against 1.2 again. > ** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes GLib is quite essential. I'm quite sure however that allocating 187 TERRAByte!!! isn't going to work on your system. @Samuli -r1 slots, -r2, which is the latest 1.2, does not slot however: flaptoppy libpng # emerge =libpng-1.2.43-r1 =libpng-1.4.2 -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB [ebuild R ] media-libs/libpng-1.4.2 0 kB Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB flaptoppy libpng # emerge =libpng-1.2.43-r2 =libpng-1.4.2 -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] media-libs/libpng-1.2.43-r2 [1.4.2] 0 kB [ebuild R ] media-libs/libpng-1.4.2 0 kB Total: 2 packages (1 downgrade, 1 reinstall), Size of downloads: 0 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libpng:0 ('ebuild', '/', 'media-libs/libpng-1.4.2', 'merge') pulled in by =libpng-1.4.2 ('ebuild', '/', 'media-libs/libpng-1.2.43-r2', 'merge') pulled in by =libpng-1.2.43-r2 It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
After an initial revdep-rebuild, compilation failed on net-print/gnome-cups-manager which seemed to pick up -lpng12. After debugging for quite a while I did a "grep -r 'png12' /usr/lib/*.la" and found -lpng12 listed in the dependency_libs section of la files owned by google-gadgets, glade, gnome-bluetooth, gnome-media, libgnomeui, and vte. I remember that some if not all (certainly glade and google-gadgets) were previously emerged with revdep-rebuild. But after a "revdep-rebuild -piv" none were listed to be emerged. After manually unmerging and remerging the packages above, I was able to successfully build and install gnome-cups-manager. Is this a bug? Isn't revdep-rebuild supposed to pick those up after "revdep-rebuild -piv" ?
Confirming stated crash of gnome-panel: (In reply to comment #48) > ---- Critical and fatal warnings logged during execution ---- > > ** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes I noticed the following: $ ldd $(which gnome-panel) | grep png libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007fcdee502000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007fcde5545000) That might be the issue, hopefully being solved by (In reply to comment #52) [...] > for quite a while I did a "grep -r 'png12' /usr/lib/*.la" and found -lpng12 I just collected all issued packages by using the following commands, for which qfile from app-portage/portage-utils is needed: todo=$(for i in $(grep -r "png12" *.la -l); do qfile -qC b $i; done | sort | uniq | grep -v ncurses); emerge -C $todo; emerge $todo Before running you sould run this with the pretend flag: ...; emerge -Cp $todo; ... to be sure no very important libs are removed (which are currently used). I just added ncurses to "grep -v", which is important. Furthermore unmerge all old versions of libpng: emerge -C '<media-libs/libpng-1.4'
(In reply to comment #53) grep'ing *.la is not canonical source shared lib deps. Try readelf instead. :) This will give you a nice list of pkgs dep on libpng12 for i in $(find /lib* /usr/lib* -type f -name "lib*.so*"; find /bin* /usr/bin* -type f); do a=$(readelf -d $i 2> /dev/null | grep libpng12) if [[ -n "$a" ]]; then qfile -qC $i fi done | sort | uniq
Today I tested libpng-1.2.43-r3 (without any other slot installed at the same time). revdep-rebuild (or reconcilio in my case) tried to rebuild quite a lot of packages, but almost all of them failed, because /usr/lib/libpng12.la was missing. When downgrading to libpng-1.2.43-r2, the .la file is there. I think the difference is the --disable-static in src_configure() { econf \ --disable-dependency-tracking \ --disable-static } in the -r3 ebuild. Why doesn't the new revision install the .la files?
another problem: I had libpng 1.2.43-r2 installed. Portage wanted to upgrade to libpng 1.4 and deleted the 1.2 version. revdep-rebuild then tried to recompile a lot of packages but it failed, since some applications seemed to definitely want libpng 1.2. So I manually unmerged lipng-1.4 and reinstalled 1.2.43-r2. Today, portage wanted to pull in libpng 1.2.43-r3. Apparently it wanted to install the -r3 version in a new slot. This resultet in a blocker with the installed 1.2.43-r2 version. So, I had to uninstall the r2 version and installed the 1.2.43-r3 version of lipng. At this point I unmasked libpng-1.4. Portage now wanted to install the 1.4 version in a new slot. So the 1.2.43-r3 did not get removed. Revdep-rebuild did not want to compile anything and all went fine. So I believe that this bug is a problem of the slots where the old libpng 1.2.43-r2 were installed to. They should go into other slots than the lipng-1.4 versions. Seeing that this is handled now with the -r3 revision of libpng, one should somehow tell portage to automatically replace the wrongly slotted -r2 version with the r3 ebuild. Portage should not report a blocker but do the update automatically.
(In reply to comment #56) > Seeing that this is handled now with the -r3 revision of libpng, one should > somehow tell portage to automatically replace the wrongly slotted -r2 version > with the r3 ebuild. Portage should not report a blocker but do the update > automatically. > Not before the -r3 ebuild bothers to install the .la files, see comment #55...
Why has ">=media-libs/libpng-1.2.43-r2:0" been added to x11-libs/cairo, x11-libs/gtk+, x11-libs/qt-gui and media-libs/libass? I copied then to my overlay and removed the ":0" and the then emerged OK.
(In reply to comment #58) > Why has ">=media-libs/libpng-1.2.43-r2:0" been added to x11-libs/cairo, > x11-libs/gtk+, x11-libs/qt-gui and media-libs/libass? This dependency is correct. Please continue your discussions in Gentoo Forums.
t
currently as now there is no stable libpng left in portage tree all there is upgrades to unstable :( 1.2.40 should have staged longer in portage tree, until new version really is stable here i have resolved by take the installed ebuild file from installed version over to my local overlay for now until it can be safely removed by me is there not a 30 days testing period ? such a problem here gets one to think its faster to leave gentoo and install os2 :)
you really need to read the actual ChangeLog and policy related to stabilization. security and "important" issues do not require 30 days.
(In reply to comment #42) > (In reply to comment #41) > I think the reason why you use it is you WANT TO TEST for others, because you > are an experienced user? There are other reasons for use ~arch. For example, the packages you _need_ for work may be only in ~arch. what should you do in such case? Yep, I do know about per-package unmasking, but it deliviers you about same amount pain in ass, the only difference is a way it does it... Ontopic: I have same problems with update - no proper libpng12.la simlink, so many, many packages refuses to compile (no lpng12 found linker error). gdm/kdm refused to start, by the way.
(In reply to comment #63) > Ontopic: > I have same problems with update - no proper libpng12.la simlink, so many, many > packages refuses to compile (no lpng12 found linker error). gdm/kdm refused to > start, by the way. That's 100% off-topic, the *only* on-topic discussion here is at Comment #3: http://bugs.gentoo.org/show_bug.cgi?id=319061#c3 Please use http://forums.gentoo.org/ instead.
*** This bug has been marked as a duplicate of bug 286714 ***
(In reply to comment #23) > I got many ld errors ... cannot find -lpng12 ... > (I have both versions installed) > Then I tried the following, since it needs the old one: > cd /usr/lib > ln -snvf libpng12.so.0.43.0 libpng12.so > cd /usr/lib64 > ln -snvf libpng12.so.0.43.0 libpng12.so > > THAT WORKED :D > That means ld will find it for now, e.g.: > ld -l png12 > will give other output than "not found". It works for me. x11-misc/notification-daemon complains "cannot find -lpng12". My system only has libpng14.so.14.5.0. I run "ln -snvf libpng14.so.14.5.0 libpng12.so" then I can emerge x11-misc/notification-daemon
