Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-05-09 23h59 UTC
Le lundi 10 mai 2010 à 00:15 +, Robin H. Johnson a écrit : The attached list notes all of the packages that were added or removed from the tree, for the week ending 2010-05-09 23h59 UTC. Removals: gnome-base/gail 2010-05-03 22:28:28 ssuominen Erm, when this package got last-rited ? I see bug 299456 [1] was closed but no entry anywhere it went the usual way [2]. Is QA allowed to ignore policy when it sees fit (as in gail is now part of gtk+) ? I don't think it's good to introduce corner cases in a simple policy like that. [1] https://bugs.gentoo.org/show_bug.cgi?id=299456 [2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=5#doc_chap8 -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] About libpng-1.4 handling
Hello guys, as I'm sure some of you already experimented, the libpng upgrade didn't exactly went smoothly on my chroots. Reason seems to be that libpng usage is odd, it provides both libpng14.* and libpng.* files. Some packages likes to use versioned libs while some other don't and it seems to lead to giant mess in *.la files (for example). My question are: * is there a draft news item as a simple revdep-rebuild or portage preserved-libs feature doesn't cut it (for good reasons) that I could test ? * what is the recommended way to link to libpng (versioned lib or not) * corollary to previous question, should we enforce link to versioned lib only ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] About libpng-1.4 handling
Mask it. It's too new to adapt. 2010/5/11 Gilles Dartiguelongue e...@gentoo.org Hello guys, as I'm sure some of you already experimented, the libpng upgrade didn't exactly went smoothly on my chroots. Reason seems to be that libpng usage is odd, it provides both libpng14.* and libpng.* files. Some packages likes to use versioned libs while some other don't and it seems to lead to giant mess in *.la files (for example). My question are: * is there a draft news item as a simple revdep-rebuild or portage preserved-libs feature doesn't cut it (for good reasons) that I could test ? * what is the recommended way to link to libpng (versioned lib or not) * corollary to previous question, should we enforce link to versioned lib only ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] About libpng-1.4 handling
On 05/10/2010 08:11 PM, Gilles Dartiguelongue wrote: Hello guys, as I'm sure some of you already experimented, the libpng upgrade didn't exactly went smoothly on my chroots. Reason seems to be that libpng usage is odd, it provides both libpng14.* and libpng.* files. Some packages likes to use versioned libs while some other don't and it seems to lead to giant mess in *.la files (for example). Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' ( Replace lib with lib64 on multilib system. ) My question are: * is there a draft news item as a simple revdep-rebuild or portage preserved-libs feature doesn't cut it (for good reasons) that I could test ? -lpng12 vs. -lpng14 I guess, or then my big blockers in libpng ebuilds messed it up... those will go away soon, if arch's are fast enough with helping with the stable bug. * what is the recommended way to link to libpng (versioned lib or not) * corollary to previous question, should we enforce link to versioned lib only ? You get correct lib to link from `pkg-config --libs libpng` or if you need to avoid pkg-config, then e.g. AC_CHECK_LIB for unversioned png. Funny enough, I've also seen this done: libpng14 libpng12 libpng13 libpng In Cairo's configure. :) libpng13 for windows foo libpng for bsd foo libpng12 and 14 for linux foo bleh
Re: [gentoo-dev] About libpng-1.4 handling
On 5/10/10 7:27 PM, Samuli Suominen wrote: Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' lafilefixer --justfixit is easier to remember. Does it work equally well? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About libpng-1.4 handling
On 05/10/2010 08:34 PM, Paweł Hajdan, Jr. wrote: On 5/10/10 7:27 PM, Samuli Suominen wrote: Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' lafilefixer --justfixit is easier to remember. Does it work equally well? Paweł Last I tried, ... lafilefixer couldn't handle libpng migration
Re: [gentoo-dev] About libpng-1.4 handling
On 5/10/10 7:42 PM, Samuli Suominen wrote: On 05/10/2010 08:34 PM, Paweł Hajdan, Jr. wrote: On 5/10/10 7:27 PM, Samuli Suominen wrote: Should we advise users to do something like: find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' lafilefixer --justfixit is easier to remember. Does it work equally well? Last I tried, ... lafilefixer couldn't handle libpng migration But it's Gentoo's script, right? How about just adding the command you posted to lafilefixer? Some people are used to think of Gentoo as the distro where things break once a week. I don't think that, but I can easily imagine how having to run a different command on each upgrade is frustrating people. On the other hand, when we can ensure that emerge -uDNa world, revdep-rebuild, dispatch-conf and lafilefixer result in a working system without additional work, that makes updates more predictable. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About libpng-1.4 handling
On Monday 10 May 2010 13:27:48 Samuli Suominen wrote: On 05/10/2010 08:11 PM, Gilles Dartiguelongue wrote: * what is the recommended way to link to libpng (versioned lib or not) * corollary to previous question, should we enforce link to versioned lib only ? You get correct lib to link from `pkg-config --libs libpng` or if you need to avoid pkg-config, then e.g. AC_CHECK_LIB for unversioned png. i dont think we should attempt to enforce versioned linking. i imagine it would require quite a lot of package thrashing and would make use non-standard with everyone else. we're going to need some solution that doesnt break runtime SONAMEs when we stabilize; preferably way before that. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About libpng-1.4 handling
On Monday 10 May 2010 20:22:28 Peng Hsin-shun wrote: Mask it. It's too new to adapt. 2010/5/11 Gilles Dartiguelongue e...@gentoo.org Hello guys, as I'm sure some of you already experimented, the libpng upgrade didn't exactly went smoothly on my chroots. Reason seems to be that libpng usage is odd, it provides both libpng14.* and libpng.* files. Some packages likes to use versioned libs while some other don't and it seems to lead to giant mess in *.la files (for example). My question are: * is there a draft news item as a simple revdep-rebuild or portage preserved-libs feature doesn't cut it (for good reasons) that I could test ? * what is the recommended way to link to libpng (versioned lib or not) * corollary to previous question, should we enforce link to versioned lib only ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo Masking it is not an option anymore since the majority of ~arch systems are already using libpng-1.4. If you mask it you will create a confusion and you will have to rebuild the same packages again. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
Re: [gentoo-dev] About libpng-1.4 handling
lafilefixer is not the right tool for this. At least it's current scope is to replace usage of la files in la files, not to replace occurences of one lib with another. Plus the problem of lafilefixer not changing the hash of the installed files to match the one recorded in vdb is not solved so I'd rather have clear instructions on how to rebuild the minimum amount of packages if possible. I've seen something like emerge -1av $(egrep libpng12.la /usr/lib/*.la | qfile --someoption) which just as with xorg/libxcb migration should do just fine. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] About libpng-1.4 handling
On Monday 10 May 2010 23:09:22 Samuli Suominen wrote: On 05/10/2010 10:52 PM, Markos Chandras wrote: On Monday 10 May 2010 20:22:28 Peng Hsin-shun wrote: Mask it. It's too new to adapt. Gentoo's ~arch is now fully migrated to libpng-1.4. So is Arch Linux, btw. After releasing it in ~arch, we got some 3 valid bugs I've immediately fixed, total bugcount is 0. We moved on, now let's live with it Is that so? It is migrated successfully? Because, for me, it fails to build many packages. and NO, i don't want to use your tricky command to fix the lpng12 dependencies. Either revbump the ebuilds to include your fix or provide a user friendly way to migrate to the new libpng without the need to spend so many hours digging around on which packages to rebuild. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
Re: [gentoo-dev] About libpng-1.4 handling
On Monday 10 May 2010 23:10:48 Markos Chandras wrote: provide a user friendly way to migrate to the new libpng without the need to spend so many hours digging around on which packages to rebuild. if you're digging around then clearly you havent done the obvious and run revdep-rebuild ? that is pretty user-friendly. Samuli is right though ... this isnt really something that can be reverted without breaking things just as much. either help out with the problem (see the open bug report), or add yourself to the cc list and wait. harping on people only serves to annoy. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About libpng-1.4 handling
Mike Frysinger vap...@gentoo.org writes: if you're digging around then clearly you havent done the obvious and run revdep-rebuild ? that is pretty user-friendly. I do not know if I had done something wrong beforehand, but simply running revdep-rebuild did not work for me - a number of packages failed to rebuild during the revdep-rebuild. They were still failing to find libpng12 during the rebuild while doing gtk-doc scan. In every case, manually unmerging the package concerned and re-emerging it was successful. It is as though it was using the scan (which needed libpng12) from the already installed package in preference to the one it had built in /var/tmp/portage/...
