Updating libpng: another libtool cockup?
 

On Sun, Sep 18, 2011 at 4:10 PM, walt <w41ter@gmail.com> wrote:
> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
>
> That's what I did. *I confess I wasn't watching, so I may have missed
> some important errors during the run.
>
> After that I ran plain revdep-rebuild as I do after every update, and
> saw that two gnome packages failed to rebuild properly because lpng14
> couldn't be found :/
>
> From painful experience I've learned that good-old libtool files (*.la)
> are the usual suspects, and grep found -lpng14 in about ten .la files
> even after both revdep-rebuilds. *Grrr!
>
> This fixed the problem for me (as similar moves have done in the past):
>
> #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'
>
> I ran revdep-rebuild again and the two broken packages emerged nicely
> this time.
>
> I hope no one else will hit this problem, but at least this is a good
> workaround if you do.

If you're not following Diego Pettenò's blog, you probably should. .la
files are one of the things he harps on in his blog.

http://blog.flameeyes.eu/

--
:wq

Updating libpng: another libtool cockup?
 

on 09/18/2011 11:10 PM walt wrote the following:
> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
><snip>
> This fixed the problem for me (as similar moves have done in the past):
>
> #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'

Thanks ! I didn't know we can just edit .la files.

Updating libpng: another libtool cockup?
 

On Sunday 18 Sep 2011 21:57:29 Thanasis wrote:
> on 09/18/2011 11:10 PM walt wrote the following:
> > I just did a routine update on my ~amd64 machine and saw the portage
> > warning that libpng14 has been replaced by libpng15, and I should run
> > revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> > obsolete library.
> >
> ><snip>
> >
> > This fixed the problem for me (as similar moves have done in the past):
> >
> > #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'
>
> Thanks ! I didn't know we can just edit .la files.

Isn't something like this that lafilefixer does (and now is part of the
default FEATURES in portage)?
--
Regards,
Mick

Updating libpng: another libtool cockup?
 

On Sun, Sep 18 2011, walt wrote:

> I just did a routine update on my ~amd64 machine and saw the portage
> warning that libpng14 has been replaced by libpng15, and I should run
> revdep-rebuild --library '/usr/lib/libpng14.so' and then delete the
> obsolete library.
>
> After that I ran plain revdep-rebuild as I do after every update, and
> saw that two gnome packages failed to rebuild properly because lpng14
> couldn't be found :/
>
> From painful experience I've learned that good-old libtool files (*.la)
> are the usual suspects, and grep found -lpng14 in about ten .la files
> even after both revdep-rebuilds. Grrr!
>
> This fixed the problem for me (as similar moves have done in the past):
>
> #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'

Thanks for the tip. I wonder when a routing update world tells you to
run
revdep-rebuild --library <some-lib>
should you run it before or after the normal
revdep-rebuild
that we normally run after updates?

thanks,
allan

Updating libpng: another libtool cockup?
 

On Sun, 18 Sep 2011 17:58:14 -0400
Allan Gottlieb <gottlieb@nyu.edu> wrote:

> On Sun, Sep 18 2011, walt wrote:
>
> > I just did a routine update on my ~amd64 machine and saw the portage
> > warning that libpng14 has been replaced by libpng15, and I should
> > run revdep-rebuild --library '/usr/lib/libpng14.so' and then delete
> > the obsolete library.
> >
> > After that I ran plain revdep-rebuild as I do after every update,
> > and saw that two gnome packages failed to rebuild properly because
> > lpng14 couldn't be found :/
> >
> > From painful experience I've learned that good-old libtool files
> > (*.la) are the usual suspects, and grep found -lpng14 in about
> > ten .la files even after both revdep-rebuilds. Grrr!
> >
> > This fixed the problem for me (as similar moves have done in the
> > past):
> >
> > #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'
>
> Thanks for the tip. I wonder when a routing update world tells you to
> run
> revdep-rebuild --library <some-lib>
> should you run it before or after the normal
> revdep-rebuild
> that we normally run after updates?

Neither.

revdep-rebuild checks everything, revdep-rebuild --library
checks just some things.

ebuilds sometimes issue messages to check just the libraries known to
have been updated, but a full revdep-rebuild after an update will catch
those anyway.


--
Alan McKinnnon
alan.mckinnon@gmail.com

Updating libpng: another libtool cockup?
 

On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
> On Sun, 18 Sep 2011 17:58:14 -0400
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>
> > On Sun, Sep 18 2011, walt wrote:
> >
> > > I just did a routine update on my ~amd64 machine and saw the portage
> > > warning that libpng14 has been replaced by libpng15, and I should
> > > run revdep-rebuild --library '/usr/lib/libpng14.so' and then delete
> > > the obsolete library.
> > >
> > > After that I ran plain revdep-rebuild as I do after every update,
> > > and saw that two gnome packages failed to rebuild properly because
> > > lpng14 couldn't be found :/
> > >
> > > From painful experience I've learned that good-old libtool files
> > > (*.la) are the usual suspects, and grep found -lpng14 in about
> > > ten .la files even after both revdep-rebuilds. Grrr!
> > >
> > > This fixed the problem for me (as similar moves have done in the
> > > past):
> > >
> > > #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}' ';'
> >
> > Thanks for the tip. I wonder when a routing update world tells you to
> > run
> > revdep-rebuild --library <some-lib>
> > should you run it before or after the normal
> > revdep-rebuild
> > that we normally run after updates?
>
> Neither.
>
> revdep-rebuild checks everything, revdep-rebuild --library
> checks just some things.
>
> ebuilds sometimes issue messages to check just the libraries known to
> have been updated, but a full revdep-rebuild after an update will catch
> those anyway.

Until recently I skipped the "--library" step exactly because I knew
revdep-rebuild will find and fix the broken packages after I delete
the old library. So, why bother with the --library step, right?

However. A few weeks ago I got caught when I deleted one of those
obsolete libraries and only then did I find out that gcc is one of
the packages that depend on it :(

I don't skip the --library step any more.

Updating libpng: another libtool cockup?
 

On Sun, Sep 18 2011, Alan McKinnon wrote:

> On Sun, 18 Sep 2011 17:58:14 -0400
> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>
>> I wonder when a routine update world tells you to run
>> revdep-rebuild --library <some-lib>
>> should you run it before or after the full
>> revdep-rebuild
>> that we normally run after updates?
>
> Neither.
>
> revdep-rebuild checks everything, revdep-rebuild --library
> checks just some things.
>
> ebuilds sometimes issue messages to check just the libraries known to
> have been updated, but a full revdep-rebuild after an update will catch
> those anyway.

thanks,
allan

Updating libpng: another libtool cockup?
 

On Mon, 19 Sep 2011 03:06:30 -0700
walt <w41ter@gmail.com> wrote:

> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
> > On Sun, 18 Sep 2011 17:58:14 -0400
> > Allan Gottlieb <gottlieb@nyu.edu> wrote:
> >
> > > On Sun, Sep 18 2011, walt wrote:
> > >
> > > > I just did a routine update on my ~amd64 machine and saw the
> > > > portage warning that libpng14 has been replaced by libpng15,
> > > > and I should run revdep-rebuild --library
> > > > '/usr/lib/libpng14.so' and then delete the obsolete library.
> > > >
> > > > After that I ran plain revdep-rebuild as I do after every
> > > > update, and saw that two gnome packages failed to rebuild
> > > > properly because lpng14 couldn't be found :/
> > > >
> > > > From painful experience I've learned that good-old libtool files
> > > > (*.la) are the usual suspects, and grep found -lpng14 in about
> > > > ten .la files even after both revdep-rebuilds. Grrr!
> > > >
> > > > This fixed the problem for me (as similar moves have done in the
> > > > past):
> > > >
> > > > #find /usr/lib64 -name *.la -exec sed -i s/png14/png15/ '{}'
> > > > ';'
> > >
> > > Thanks for the tip. I wonder when a routing update world tells
> > > you to run
> > > revdep-rebuild --library <some-lib>
> > > should you run it before or after the normal
> > > revdep-rebuild
> > > that we normally run after updates?
> >
> > Neither.
> >
> > revdep-rebuild checks everything, revdep-rebuild --library
> > checks just some things.
> >
> > ebuilds sometimes issue messages to check just the libraries known
> > to have been updated, but a full revdep-rebuild after an update
> > will catch those anyway.
>
> Until recently I skipped the "--library" step exactly because I knew
> revdep-rebuild will find and fix the broken packages after I delete
> the old library. So, why bother with the --library step, right?
>
> However. A few weeks ago I got caught when I deleted one of those
> obsolete libraries and only then did I find out that gcc is one of
> the packages that depend on it :(
>
> I don't skip the --library step any more.

That's odd behaviour, I wonder what caused the difference.

Surely revdep-rebuild itself can't do this different just because you
specified a library to compare? I wonder if that lib was maybe in the
revdep-rebuild exclude list.

I'd be interested to track it down for reference, do you remember the
library involved?


--
Alan McKinnnon
alan.mckinnon@gmail.com

Updating libpng: another libtool cockup?
 

On Mon, Sep 19 2011, Alan McKinnon wrote:

>> > revdep-rebuild checks everything, revdep-rebuild --library
>> > checks just some things.
>> >
>> > ebuilds sometimes issue messages to check just the libraries known
>> > to have been updated, but a full revdep-rebuild after an update
>> > will catch those anyway.
>>
>> Until recently I skipped the "--library" step exactly because I knew
>> revdep-rebuild will find and fix the broken packages after I delete
>> the old library. So, why bother with the --library step, right?
>>
>> However. A few weeks ago I got caught when I deleted one of those
>> obsolete libraries and only then did I find out that gcc is one of
>> the packages that depend on it :(
>>
>> I don't skip the --library step any more.
>
> That's odd behaviour, I wonder what caused the difference.
>
> Surely revdep-rebuild itself can't do this different just because you
> specified a library to compare? I wonder if that lib was maybe in the
> revdep-rebuild exclude list.
>
> I'd be interested to track it down for reference, do you remember the
> library involved?

It occurs exactly in the case we are discussing libpng

ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
* Configuring search environment for revdep-rebuild

* Checking reverse dependencies
* Packages containing binaries and libraries broken by a package update
* will be emerged.

* Collecting system binaries and libraries
* Generated new 1_files.rr
* Collecting complete LD_LIBRARY_PATH
* Generated new 2_ldpath.rr
* Checking dynamic linking consistency
[ 100% ]

* Dynamic linking on your system is consistent... All done.
* Configuring search environment for revdep-rebuild

* Checking reverse dependencies
* Packages containing binaries and libraries using /usr/lib64/libpng14.so.14
* will be emerged.

* Collecting system binaries and libraries
* Generated new 1_files.rr
* Checking dynamic linking
[ 8% ] * found /usr/bin/dia
[ 46% ] * found /usr/lib64/dia/libaadl_objects.so
* found /usr/lib64/dia/libart_filter.so
* found /usr/lib64/dia/libcairo_filter.so
* found /usr/lib64/dia/libcgm_filter.so
* found /usr/lib64/dia/libchronogram_objects.so
* found /usr/lib64/dia/libcustom_lines_objects.so
* found /usr/lib64/dia/libcustom_objects.so
* found /usr/lib64/dia/libdb_objects.so
* found /usr/lib64/dia/libdia.so
* found /usr/lib64/dia/libdxf_filter.so
* found /usr/lib64/dia/liber_objects.so
* found /usr/lib64/dia/libflowchart_objects.so
* found /usr/lib64/dia/libfs_objects.so
* found /usr/lib64/dia/libgrafcet_objects.so
* found /usr/lib64/dia/libhpgl_filter.so
* found /usr/lib64/dia/libistar_objects.so
* found /usr/lib64/dia/libjackson_objects.so
* found /usr/lib64/dia/libkaos_objects.so
* found /usr/lib64/dia/libmetapost_filter.so
* found /usr/lib64/dia/libmisc_objects.so
* found /usr/lib64/dia/libnetwork_objects.so
* found /usr/lib64/dia/libpgf_filter.so
* found /usr/lib64/dia/libpixbuf_filter.so
* found /usr/lib64/dia/libpostscript_filter.so
* found /usr/lib64/dia/libpstricks_filter.so
* found /usr/lib64/dia/libpython_plugin.so
^C * ...terminated. Removing incomplete 3_broken.rr 3_errors.rr.

Updating libpng: another libtool cockup?
 

On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote:
> On Mon, Sep 19 2011, Alan McKinnon wrote:
> >> > revdep-rebuild checks everything, revdep-rebuild --library
> >> > checks just some things.
> >> >
> >> > ebuilds sometimes issue messages to check just the libraries known
> >> > to have been updated, but a full revdep-rebuild after an update
> >> > will catch those anyway.
> >>
> >> Until recently I skipped the "--library" step exactly because I knew
> >> revdep-rebuild will find and fix the broken packages after I delete
> >> the old library. So, why bother with the --library step, right?
> >>
> >> However. A few weeks ago I got caught when I deleted one of those
> >> obsolete libraries and only then did I find out that gcc is one of
> >> the packages that depend on it :(
> >>
> >> I don't skip the --library step any more.
> >
> > That's odd behaviour, I wonder what caused the difference.
> >
> > Surely revdep-rebuild itself can't do this different just because you
> > specified a library to compare? I wonder if that lib was maybe in the
> > revdep-rebuild exclude list.
> >
> > I'd be interested to track it down for reference, do you remember the
> > library involved?
>
> It occurs exactly in the case we are discussing libpng
>
> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> '/usr/lib64/libpng14.so.14' * Configuring search environment for
> revdep-rebuild
>
> * Checking reverse dependencies
> * Packages containing binaries and libraries broken by a package update
> * will be emerged.
> ...
> * Checking reverse dependencies
> * Packages containing binaries and libraries using
> /usr/lib64/libpng14.so.14 * will be emerged.

First one emerges *broken* packages.
Second one emerge packages *using* png14 (not necessarily broken)

Best,
Michael