[gentoo-dev] About libpng-1.4 handling

[gentoo-dev] About libpng-1.4 handling

[Gilles Dartiguelongue]

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 <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] About libpng-1.4 handling

[Peng Hsin-shun]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Mask it. It's too new to adapt.

2010/5/11 Gilles Dartiguelongue <eva@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 <eva@gentoo.org>
> Gentoo
>
>
>

[-- Attachment #2: Type: text/html, Size: 1220 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Samuli Suominen]

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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Samuli Suominen]

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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

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ł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 736 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Markos Chandras]

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 <eva@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 <eva@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

[Samuli Suominen]

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

Re: [gentoo-dev] About libpng-1.4 handling

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

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 <eva@gentoo.org>
Gentoo

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Markos Chandras]

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 604 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Graham Murray]

Mike Frysinger <vapier@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/...

Re: [gentoo-dev] About libpng-1.4 handling

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

Le mardi 11 mai 2010 à 06:35 +0100, Graham Murray a écrit :
> Mike Frysinger <vapier@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/...

gtk-doc should probably be disabled when rebuilding because a lot of
packages probably load already installed library when running gtk-doc
scanner which would cause this kind of problem. This has been reported
upstream but upstream says gtk-doc using packages should fix
LD_LIBRARY_PATH or whatever before running the scanner.

In any case, gnome team decided to remove the doc building option in the
mid-term so this problem will just vanish.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About libpng-1.4 handling

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On 05/11/2010 01:41 AM, Gilles Dartiguelongue wrote:
> 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.
> 

Wouldn't this be essentially the same as revdep-rebuild --library?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: About libpng-1.4 handling

[Peter Hjalmarsson]

mån 2010-05-10 klockan 23:52 -0400 skrev Mike Frysinger:
> 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.
> 

I did, but revdep-rebuild did not take *.la into account (I did run it
as "revdep-rebuild --ignore -- --jobs 10 --keep-going" if that has any
impact) and many of the things it wanted to rebuild plainly failed
because a library that did not link against libpng12 had it in its *.la
(libgnomeui is on example of this). This led to that the library
(example: libgnomeui) was not set to be rebuilt, but the packages
pulling libgnomeui in broke because while linking they could not find
libpng12.

Re: [gentoo-dev] About libpng-1.4 handling

[George Prowse]

On 11/05/2010 04:52, Mike Frysinger wrote:
> 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

I have run revdep-rebuild about 30 times and I still can't fix it. 
revdep-rebuild does not fix it and libpng needs to have some serious 
action before it goes stable because I booted into, basically a 
completely broken machine because I had to stop a large upgrade on the 
previous emerge (~300 packages) in the middle.

Re: [gentoo-dev] About libpng-1.4 handling

[Markos Chandras]

On Tuesday 11 May 2010 16:05:19 George Prowse wrote:
> On 11/05/2010 04:52, Mike Frysinger wrote:
> > 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
> 
> I have run revdep-rebuild about 30 times and I still can't fix it.
> revdep-rebuild does not fix it and libpng needs to have some serious
> action before it goes stable because I booted into, basically a
> completely broken machine because I had to stop a large upgrade on the
> previous emerge (~300 packages) in the middle.
I am still trying to find a decent solution to fix all the ~arch systems. 
Currently they are totally broken because of this upgrade. If you think that 
the onliner that Samuli suggested works, please prepare a news item as quickly 
as possible
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] About libpng-1.4 handling

[Graham Murray]

George Prowse <george.prowse@gmail.com> writes:

> I have run revdep-rebuild about 30 times and I still can't fix
> it. revdep-rebuild does not fix it and libpng needs to have some
> serious action before it goes stable because I booted into, basically
> a completely broken machine because I had to stop a large upgrade on
> the previous emerge (~300 packages) in the middle.

Are the failures during a gtk-doc scan? If so then try unmerging the
affected package and then manually re-emerging it.

Re: [gentoo-dev] About libpng-1.4 handling

[Francesco R]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

2010/5/11 Graham Murray <graham@gmurray.org.uk>

> George Prowse <george.prowse@gmail.com> writes:
>
> > I have run revdep-rebuild about 30 times and I still can't fix
> > it. revdep-rebuild does not fix it and libpng needs to have some
> > serious action before it goes stable because I booted into, basically
> > a completely broken machine because I had to stop a large upgrade on
> > the previous emerge (~300 packages) in the middle.
>
> Are the failures during a gtk-doc scan? If so then try unmerging the
> affected package and then manually re-emerging it.
>
> For me not, possibly it's a problem with la files, steps done by me follow:

revdep-rebuild -- --keep-going
lafilefixer --justfixit
# this does not work `revdep-rebuild -- --keep-going`

export PKGLIST="$(qfile --slots  --quiet  --nocolor $(grep -l png12
 /usr/lib64/*.la))"
# PKGLIST="gnome-base/libgnomecanvas:0 gnome-base/libbonoboui:0
gnome-base/libgnomeui:0 gnome-base/gnome-keyring:0
#                 gnome-base/libglade:2.0 dev-cpp/gtkmm:2.4
dev-cpp/gtkmm:2.4 gnome-extra/evolution-data-server:0"
sudo rm $(grep -l png12  /usr/lib64/*.la)
gnome-extra/evolution-data-server:0"
sudo emerge -1av $PKGLIST

revdep-rebuild -- --keep-going

# should do

[-- Attachment #2: Type: text/html, Size: 1795 bytes --]