Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-12-05 Thread Jon Ciesla
On Mon, Dec 5, 2011 at 12:52 PM, Bruno Wolff III  wrote:

> On Mon, Dec 05, 2011 at 17:44:12 +,
>  Peter Robinson  wrote:
> >
> > Go for it, I think it makes sense. For those that don't support 1.5
> > they can stay against the compat in the mean time.
>
> Based on the sample I worked with, most of the ones with failed builds
> are likely to be easy to fix.
>
> Are bugs going to be created for the failed builds, perhaps with a tracking
> bug like we do occasionally for general FTBFS packages? It would make it
> easier for people to help out as they have time.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


I second that.  It would also raise visibility, which would help us all
find those that need fixing.  I'm sure someone else out there can fix the
ones of mine I'm stumped by, and vice-versa.

-J

P.S. Yes, I have a new email address.  I'll be updating my FAS and BZ soon.


-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-12-05 Thread Bruno Wolff III
On Mon, Dec 05, 2011 at 17:44:12 +,
  Peter Robinson  wrote:
> 
> Go for it, I think it makes sense. For those that don't support 1.5
> they can stay against the compat in the mean time.

Based on the sample I worked with, most of the ones with failed builds
are likely to be easy to fix.

Are bugs going to be created for the failed builds, perhaps with a tracking
bug like we do occasionally for general FTBFS packages? It would make it
easier for people to help out as they have time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-12-05 Thread Tom Lane
Adam Jackson  writes:
> I've been doing driveby rebuilds for some of these that happen to have
> been in a default install on my machine, but we still have a huge pile
> of things built against the old libpng in rawhide:
> [ajax@f17 cairomm]$ repoquery --whatrequires libpng-compat | wc -l
> 786

> Does anyone object to me just kicking a mass rebuild for this?  I'll
> happily follow up with the list of build failures.

I had been wondering whether there wouldn't be a mass rebuild during the
F17 cycle for other reasons.  If you don't see one on the horizon, then
pushing this forward seems like a good plan.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-12-05 Thread Peter Robinson
On Mon, Dec 5, 2011 at 5:41 PM, Adam Jackson  wrote:
> On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
>
>> I did test rebuilds in mock of all rawhide packages that are reported to
>> be dependent on libpng.  Out of 964 packages with dependencies on libpng,
>> we have:
>>
>> Packages that rebuilt successfully with 1.5   658
>> Packages that FTBFS for non-libpng reasons    186
>> Packages that rebuilt with 1.4, but not 1.5   74
>> Packages that need help even with 1.4         46
>
> I've been doing driveby rebuilds for some of these that happen to have
> been in a default install on my machine, but we still have a huge pile
> of things built against the old libpng in rawhide:
>
> [ajax@f17 cairomm]$ repoquery --whatrequires libpng-compat | wc -l
> 786
>
> Does anyone object to me just kicking a mass rebuild for this?  I'll
> happily follow up with the list of build failures.

Go for it, I think it makes sense. For those that don't support 1.5
they can stay against the compat in the mean time.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-12-05 Thread Adam Jackson
On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:

> I did test rebuilds in mock of all rawhide packages that are reported to
> be dependent on libpng.  Out of 964 packages with dependencies on libpng,
> we have:
> 
> Packages that rebuilt successfully with 1.5   658
> Packages that FTBFS for non-libpng reasons186
> Packages that rebuilt with 1.4, but not 1.5   74
> Packages that need help even with 1.4 46

I've been doing driveby rebuilds for some of these that happen to have
been in a default install on my machine, but we still have a huge pile
of things built against the old libpng in rawhide:

[ajax@f17 cairomm]$ repoquery --whatrequires libpng-compat | wc -l
786

Does anyone object to me just kicking a mass rebuild for this?  I'll
happily follow up with the list of build failures.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-21 Thread Michael Schwendt
On Mon, 21 Nov 2011 16:26:02 -0500, TL (Tom) wrote:

> > With
> 
> >   pkgconfig(libpng) = 1.2.46
> >   pkgconfig(libpng12) = 1.2.46
> 
> > once libpng12.pc gets removed from the distribution, the dep-chains
> > break, of course.
> 
> > As a temporary work-around, you could have provided that thing manually
> > in the libpng-devel upgrade instead of including the actual libpng12.pc
> > file:
> 
> >   Provides: pkgconfig(libpng12) = %{version}-%{release}
> 
> > Any configure script or .pc file using a hardcoded "libpng12" name
> > would fail to build, but that would be better IMO than offering an
> > incomplete broken compat package that confuses the buildroots.
> 
> Well, I don't have any objection to doing it that way, but exactly what
> about this "confuses the buildroots"?

In the buildroot, pkg-config queries on 'libpng12' succeed and let the
build job continue when in fact it should terminate early ... because
even if the source were compatible with the new headers, -lpng12 would
fail due to missing files.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-21 Thread Tom Lane
Michael Schwendt  writes:
> With

>   pkgconfig(libpng) = 1.2.46
>   pkgconfig(libpng12) = 1.2.46

> once libpng12.pc gets removed from the distribution, the dep-chains
> break, of course.

> As a temporary work-around, you could have provided that thing manually
> in the libpng-devel upgrade instead of including the actual libpng12.pc
> file:

>   Provides: pkgconfig(libpng12) = %{version}-%{release}

> Any configure script or .pc file using a hardcoded "libpng12" name
> would fail to build, but that would be better IMO than offering an
> incomplete broken compat package that confuses the buildroots.

Well, I don't have any objection to doing it that way, but exactly what
about this "confuses the buildroots"?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-20 Thread Michael Schwendt
On Wed, 09 Nov 2011 10:42:10 -0500, TL (Tom) wrote:

> > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
> >> I plan to provide the 1.2.x libpng shared library (and only the library,
> >> not its devel support files) in a libpng-compat subpackage for the time
> >> being.
> 
> > Any reason why the compat package ships the libpng-1.2.pc pkg-config
> > file?
> 
> Yeah: I tried it without first, and found that I couldn't rebuild
> anything.  There are boatloads of packages that have pkgconfig(libpng12)
> as an RPM-visible dependency, so if the compat package doesn't supply
> it, those packages won't install and you can't rebuild any of their
> dependencies.  I have no idea why it was considered a good thing for RPM
> to track this type of dependency, but it does.

It is fragile, unfortunately, but not bad. 

Automatic Provides/Requires for pkg-config interpackage dependencies are
helpful. Packagers have had problems getting the -devel dep-chains as
complete as necessary to not break the .pc file inter-dependencies.

However, one could say that you've injected a broken package into the
build-system by including a .pc file it in without including the
corresponding headers and library. A compat package is not supposed to
be a -devel package either (unless it is a special case of a compat -devel
package).

The fundamental problem with the automatic pkg-config provides is the
extra version in the .pc file name. Those extra versions are poor design,
a poor choice by the developers of the library's .pc file, because
pkg-config has means to query the internal version in the .pc file
instead.

With

  pkgconfig(libpng) = 1.2.46
  pkgconfig(libpng12) = 1.2.46

once libpng12.pc gets removed from the distribution, the dep-chains
break, of course.

As a temporary work-around, you could have provided that thing manually
in the libpng-devel upgrade instead of including the actual libpng12.pc
file:

  Provides: pkgconfig(libpng12) = %{version}-%{release}

Any configure script or .pc file using a hardcoded "libpng12" name
would fail to build, but that would be better IMO than offering an
incomplete broken compat package that confuses the buildroots.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-10 Thread Nils Philippsen
On Wed, 2011-11-09 at 10:42 -0500, Tom Lane wrote:
> Nils Philippsen  writes:
> > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
> >> I plan to provide the 1.2.x libpng shared library (and only the library,
> >> not its devel support files) in a libpng-compat subpackage for the time
> >> being.
> 
> > Any reason why the compat package ships the libpng-1.2.pc pkg-config
> > file?
> 
> Yeah: I tried it without first, and found that I couldn't rebuild
> anything.  There are boatloads of packages that have pkgconfig(libpng12)
> as an RPM-visible dependency, so if the compat package doesn't supply
> it, those packages won't install and you can't rebuild any of their
> dependencies.  I have no idea why it was considered a good thing for RPM
> to track this type of dependency, but it does.

Yuck :-/.

> > This made one of my packages use 1.5 headers, then later on
> > attempt to link to libpng12.so which failed.
> 
> I doubt that's coming from the libpng12 pkgconfig; more likely, you have
> some other package you're depending on that needs to be rebuilt first,
> because its pkgconfig file currently says to use -lpng12 in link commands.

Not really, I should have described it in more detail: the package
specifically asked pkg-config for libpng12 -- and since it exists, it
went building happily (with the 1.5 headers, from -devel) and only
failed when trying to link -lpng12. I'd have liked it to fail early
on ;-).

Nils
-- 
Nils Philippsen  "Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-09 Thread Tom Lane
Nils Philippsen  writes:
> On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
>> I plan to provide the 1.2.x libpng shared library (and only the library,
>> not its devel support files) in a libpng-compat subpackage for the time
>> being.

> Any reason why the compat package ships the libpng-1.2.pc pkg-config
> file?

Yeah: I tried it without first, and found that I couldn't rebuild
anything.  There are boatloads of packages that have pkgconfig(libpng12)
as an RPM-visible dependency, so if the compat package doesn't supply
it, those packages won't install and you can't rebuild any of their
dependencies.  I have no idea why it was considered a good thing for RPM
to track this type of dependency, but it does.

> This made one of my packages use 1.5 headers, then later on
> attempt to link to libpng12.so which failed.

I doubt that's coming from the libpng12 pkgconfig; more likely, you have
some other package you're depending on that needs to be rebuilt first,
because its pkgconfig file currently says to use -lpng12 in link commands.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-09 Thread Nils Philippsen
On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
> In either case, as per the discussion at
> http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html
> I plan to provide the 1.2.x libpng shared library (and only the library,
> not its devel support files) in a libpng-compat subpackage for the time
> being.  So existing programs that depend on 1.2.x will continue to work,
> but it won't be possible to rebuild a package that has source-level
> dependencies on 1.2.x until those are fixed.  I think this is enough
> to avoid needing a special build tag for staging the rebuilds.

Any reason why the compat package ships the libpng-1.2.pc pkg-config
file? This made one of my packages use 1.5 headers, then later on
attempt to link to libpng12.so which failed.

Nils
-- 
Nils Philippsen  "Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Xose Vazquez Perez
Henrik Nordström wrote:

> Documentaiton on how to adopt application code to work properly with
> libpng 1.4+ is readily available.

Some notes from upstream: http://www.libpng.org/pub/png/libpng.html

==cut==
Portability Note

The libpng 1.5.x series continues the evolution of the libpng API,
finally hiding the contents of the venerable and hoary png_struct
and png_info data structures inside private (i.e., non-installed)
header files. Instead of direct struct-access, applications should
be using the various png_get_xxx() and png_set_xxx() accessor
functions, which have existed for almost as long as libpng itself.
(Apps that compiled against libpng 1.4 without warnings about
deprecated features should happily compile against 1.5, too.) 

The above should not come as a particular surprise to anyone who
has added libpng support to an application this millenium; the
manual has warned of it since at least July 2000. (Specifically:
"Starting with version 2.0.0, both structures are going to be
hidden, and the contents of the structures will only be accessible
through the png_get/png_set functions." OK, so the version number
was off a bit...and the grammar, too, but who's counting?) Those
who are happy with the current level of PNG support in their apps
need not panic, however; libpng 1.2.x will continue to get
security fixes for the foreseeable future. (1.0.x has gotten them
for more than a decade even though Greg no longer bothers to list
that series here.)

The 1.5.x series also includes a new, more thorough test program
(pngvalid.c) and a new pnglibconf.h header file that tracks what
features were enabled or disabled when libpng was built. On the
other hand, it no longer internally includes the zlib.h header
file, so applications that formerly depended on png.h to provide
that will now need to include it explicitly. Complete differences
relative to libpng 1.4.x are detailed here.[1]

==end==

[1] Changes to Libpng from version 1.4.5 to 1.5.0 (January 6, 2011)
http://libpng.org/pub/png/src/libpng-1.4.x-to-1.5.x-summary.txt

Changes to Libpng from version 1.2.42 to 1.4.0 (January 4, 2010)
http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt

ftp://ftp.simplesystems.org/pub/png/src/history/libpng-1.4.0-README.txt
ftp://ftp.simplesystems.org/pub/png/src/history/libpng-1.5.0-README.txt

API changes/compatibility test results for the libpng library
http://linuxtesting.org/upstream-tracker/versions/libpng.html


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Xose Vazquez Perez
Kevin Fenzi wrote:

> Whats upstreams schedule like? How long will 1.4 and 1.5 continue to be
> supported, and when do they plan on a 1.6?

forever :-?

See http://libpng.sf.net/

UPDATE 2 November 2011: The latest released version is libpng-1.5.6 [DOWNLOAD].

* For legacy applications, libpng-1.4.8, libpng-1.2.46 and
  libpng-1.0.56 are also available and will only be updated if
  necessary for security reasons.

* Despite a previous announcement, we will continue to support
  libpng-1.0.x with security bugfixes for the forseeable future.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Xose Vazquez Perez
Dr Andrew John Hughes wrote:

> FYI, Gentoo already went to libpng 1.5 and so have patches floating around
> for a lot of stuff that breaks.

from a _quick_ search:

http://software.opensuse.org/search?q=libpng&baseproject=openSUSE%3AFactory&lang=en&exclude_debug=true
suse1.4.x/1.2.x stable - 1.5.x factory

ftp://ftp.osuosl.org/pub/slackware/slackware-current/ChangeLog.txt
ftp://ftp.osuosl.org/pub/slackware/slackware-13.37/ChangeLog.txt
slackware   1.4.x/1.2.x stable

http://www.archlinux.org/packages/?q=libpng
arch1.4.x stable

http://packages.gentoo.org/package/media-libs/libpng
gentoo  1.5.x stable

http://ftp.funet.fi/pub/mirrors/mandriva.com/devel/2012/SRPMS/main/release/
http://ftp.uni-erlangen.de/mirrors/Mageia/distrib/cauldron/SRPMS/core/release/
mandriva1.2.x stable - 1.5.x devel
mageia  1.2.x stable - 1.5.x devel
pclinux 1.2.x stable

http://packages.debian.org/libpng
http://packages.ubuntu.com/libpng
debian  1.2.x stable - 1.5.x experimental 
ubuntu  1.2.x stable
mint1.2.x stable
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Tom Lane
Dr Andrew John Hughes  writes:
> FYI, Gentoo already went to libpng 1.5 and so have patches floating around
> for a lot of stuff that breaks.

Oh, thanks, that's very useful to know!  I think the availability of
such patches should substantially reduce the pain involved.

Given that, I will proceed forward with 1.5, unless somebody thinks
of a very good reason not to.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Dr Andrew John Hughes
On 13:12 Fri 04 Nov , Tom Lane wrote:
> I have been looking into replacing Fedora's obsolete version of libpng
> (1.2.x release series) with something more modern.  The possible choices
> are the 1.4.x and 1.5.x release series.  The 1.5.x series adds some more
> features that 1.4.x did not have, but it also poses significantly more
> migration problems.  The reason is that 1.5.x no longer exposes the
> contents of the library's internal "png_info" struct.  Direct access
> to fields of png_info has been deprecated for a long time, in favor of
> using accessor functions, but up through 1.4 you can get away with it.
> 
> I did test rebuilds in mock of all rawhide packages that are reported to
> be dependent on libpng.  Out of 964 packages with dependencies on libpng,
> we have:
> 
> Packages that rebuilt successfully with 1.5   658
> Packages that FTBFS for non-libpng reasons186
> Packages that rebuilt with 1.4, but not 1.5   74
> Packages that need help even with 1.4 46
> 
> (The non-libpng failures seem to mostly be due to the recent upgrade to
> glib 2.0.  Some of those probably have libpng issues as well, but didn't
> get far enough in their builds to expose them.)
> 
> About half of the "need help anyway" group may just need their
> BuildRequires to be rebuilt first --- it looked like they had no
> source-code dependency, but were just absorbing "-lpng12" from library
> link flags reported by other packages.  I built each package independently
> rather than trying to chain the builds, so this wasn't catered for.
> 
> The vast majority of the 74 packages that would need extra work if we move
> to libpng 1.5 are trying to access the png_info struct directly, and so
> would need patches to use the accessor functions instead.  This is work
> that should be done and upstreamed anyway, but if we move to 1.4 we would
> not have to do it Right Now.  It looks like it would be a fairly large
> amount of work, too --- I count 1164 "incomplete type" failures in the
> build logs for those packages, and it's quite likely there are more in
> source files that the build runs didn't get to.  On the other hand, if we
> move to 1.4 there will not be any pressing reason for these fixes to get
> made, and so I'm not sure that we'll be any better off when we try to move
> to 1.5 later.  Another point is that we'd have to build these same 964
> packages over again if we plan a two-stage upgrade.
> 
> Any opinions on which way to jump?
> 
> In either case, as per the discussion at
> http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html
> I plan to provide the 1.2.x libpng shared library (and only the library,
> not its devel support files) in a libpng-compat subpackage for the time
> being.  So existing programs that depend on 1.2.x will continue to work,
> but it won't be possible to rebuild a package that has source-level
> dependencies on 1.2.x until those are fixed.  I think this is enough
> to avoid needing a special build tag for staging the rebuilds.
> 
>   regards, tom lane
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

FYI, Gentoo already went to libpng 1.5 and so have patches floating around
for a lot of stuff that breaks.  A lot of the issues I found when rebuilding
against 1.5 was the hardcoding in libtool files rather than any source code
issues, which means they have to rebuilt in the right order (e.g. a high-level
GNOME package doesn't build because one of its dependencies hasn't been rebuilt
and it still has the old -lpng12 hardcoded).

We already fixed IcedTea/OpenJDK to work with libpng 1.5 as a result
of Gentoo's work, and those packages should already be in Fedora.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


signature.asc
Description: Digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Henrik Nordström
fre 2011-11-04 klockan 13:12 -0400 skrev Tom Lane:

> Packages that rebuilt successfully with 1.5   658
> Packages that FTBFS for non-libpng reasons186
> Packages that rebuilt with 1.4, but not 1.5   74
> Packages that need help even with 1.4 46

With this data my gut feeling is to go for 1.5 in rawhide/f17.

1.4 is declared legacy, with no clear support schedule and certainly
won't evolve at all with any new features. And it also marks the
mentioned direct struct interface as deprecated anyway.

Documentaiton on how to adopt application code to work properly with
libpng 1.4+ is readily available.

As you plan on providing 1.2 .so library for binary compatibility with
old packages this pretty much reduces to an FTBFS for those packages
where upstream is not yet compatible with libpng 1.4 or later. (use of a
deprecated interface giving compile warnings is not seen as compatible
in my eyes).


> (The non-libpng failures seem to mostly be due to the recent upgrade to
> glib 2.0.  Some of those probably have libpng issues as well, but didn't
> get far enough in their builds to expose them.)
> 
> About half of the "need help anyway" group may just need their
> BuildRequires to be rebuilt first --- it looked like they had no
> source-code dependency, but were just absorbing "-lpng12" from library
> link flags reported by other packages.  I built each package independently
> rather than trying to chain the builds, so this wasn't catered for.
> 
> The vast majority of the 74 packages that would need extra work if we move
> to libpng 1.5 are trying to access the png_info struct directly, and so
> would need patches to use the accessor functions instead.  This is work
> that should be done and upstreamed anyway, but if we move to 1.4 we would
> not have to do it Right Now.  It looks like it would be a fairly large
> amount of work, too --- I count 1164 "incomplete type" failures in the
> build logs for those packages, and it's quite likely there are more in
> source files that the build runs didn't get to.  On the other hand, if we
> move to 1.4 there will not be any pressing reason for these fixes to get
> made, and so I'm not sure that we'll be any better off when we try to move
> to 1.5 later.  Another point is that we'd have to build these same 964
> packages over again if we plan a two-stage upgrade.
> 
> Any opinions on which way to jump?
> 
> In either case, as per the discussion at
> http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html
> I plan to provide the 1.2.x libpng shared library (and only the library,
> not its devel support files) in a libpng-compat subpackage for the time
> being.  So existing programs that depend on 1.2.x will continue to work,
> but it won't be possible to rebuild a package that has source-level
> dependencies on 1.2.x until those are fixed.  I think this is enough
> to avoid needing a special build tag for staging the rebuilds.
> 
>   regards, tom lane


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Tom Lane
Chris Adams  writes:
> Once upon a time, Tom Lane  said:
>> Any opinions on which way to jump?

> How hard is it to fix source that accesses the fields directly?  Do all
> the fields that were previously exposed have direct accessor functions?

AFAIK, they all do, and it should be a pretty straightforward matter to
fix things.  Just tedious.  FWIW, I did a bit more analysis and noted
that the majority of the problems are concentrated in just a few
packages, eg GraphicsMagick has 234 warnings and texlive 119.  The
majority of the 74 packages with such issues only have a couple.
(I'll post a complete list of affected packages once it's time to do
the work, of course.)

> Since all the packages that depend on libpng would have to be rebuilt
> twice if you don't go to the latest version now, I'd say go ahead and
> get it over with once (i.e. go to 1.5).

Yeah, that's sort of my feeling as well.  But I could understand
package maintainers getting ticked off over having to do this work
"right now" in order to rebuild their packages.  On the other hand,
it looks like the glib guys broke considerably more packages than
this without any by-your-leave, so maybe I'm just being too polite.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Kevin Fenzi
On Fri, 04 Nov 2011 14:54:28 -0400
Tom Lane  wrote:

> Kevin Fenzi  writes:
> > Some quick questions: 
> 
> > Whats upstreams schedule like? How long will 1.4 and 1.5 continue
> > to be supported, and when do they plan on a 1.6?
> 
> 1.4 will be supported for a long time, though presumably not as long
> as 1.5.  I don't think there are any active plans for an incompatible
> 1.6 at all.

ok. 

> My own agenda though is that I'd like Fedora to be on 1.5 in the next
> release or two, so that Red Hat isn't in a position of still needing
> support for 1.4 eight or ten years from now due to it being in future
> RHEL branches.

Yeah. 

I'd say we either move to 1.5 now and try and get it done by f17, or
move to 1.4 now and drop 1.5 in rawhide right after the f17 branch for
f18. 

> > Is there possibly a way to switch to 1.4, but warn (buildtime) about
> > this going away soon, etc? 
> 
> Well, 1.4 does put __attribute__((__deprecated__)) labels on all the
> png_info struct fields.  (They're actually there in the 1.2 headers
> as well, but not enabled by default.)  However, how many Fedora
> maintainers worry about fixing mere compiler warnings?  I know I can't
> claim to spend any time on that, except with my upstream hat on.

Yeah, true. Unless it caused a fatal error, many people wouldn't
notice. ;( 

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Tom Lane
Kevin Fenzi  writes:
> Some quick questions: 

> Whats upstreams schedule like? How long will 1.4 and 1.5 continue to be
> supported, and when do they plan on a 1.6?

1.4 will be supported for a long time, though presumably not as long as
1.5.  I don't think there are any active plans for an incompatible 1.6
at all.

My own agenda though is that I'd like Fedora to be on 1.5 in the next
release or two, so that Red Hat isn't in a position of still needing
support for 1.4 eight or ten years from now due to it being in future
RHEL branches.

> Is there possibly a way to switch to 1.4, but warn (buildtime) about
> this going away soon, etc? 

Well, 1.4 does put __attribute__((__deprecated__)) labels on all the
png_info struct fields.  (They're actually there in the 1.2 headers
as well, but not enabled by default.)  However, how many Fedora
maintainers worry about fixing mere compiler warnings?  I know I can't
claim to spend any time on that, except with my upstream hat on.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Chris Adams
Once upon a time, Tom Lane  said:
> Any opinions on which way to jump?

How hard is it to fix source that accesses the fields directly?  Do all
the fields that were previously exposed have direct accessor functions?
If that's the case, it should be straight-forward (although time
consuming) grunt work to get the necessary packages fixed (maybe some of
it can even be scripted?).  If you can give a basic "replace info.foo
with foo(info)" type script, it shouldn't be too hard to get enough help
to roll through it (I'd be willing if you can tell me what to do; I've
never used libpng directly myself, so I'm not familiar with what is
required).

Since all the packages that depend on libpng would have to be rebuilt
twice if you don't go to the latest version now, I'd say go ahead and
get it over with once (i.e. go to 1.5).
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Kevin Fenzi
...snip... 

Excellent background and detective work! Kudos!

Some quick questions: 

Whats upstreams schedule like? How long will 1.4 and 1.5 continue to be
supported, and when do they plan on a 1.6?

Is there possibly a way to switch to 1.4, but warn (buildtime) about
this going away soon, etc? 

Thanks for all the good info. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Upgrading libpng: shall we move to 1.4.x or 1.5.x?

2011-11-04 Thread Tom Lane
I have been looking into replacing Fedora's obsolete version of libpng
(1.2.x release series) with something more modern.  The possible choices
are the 1.4.x and 1.5.x release series.  The 1.5.x series adds some more
features that 1.4.x did not have, but it also poses significantly more
migration problems.  The reason is that 1.5.x no longer exposes the
contents of the library's internal "png_info" struct.  Direct access
to fields of png_info has been deprecated for a long time, in favor of
using accessor functions, but up through 1.4 you can get away with it.

I did test rebuilds in mock of all rawhide packages that are reported to
be dependent on libpng.  Out of 964 packages with dependencies on libpng,
we have:

Packages that rebuilt successfully with 1.5 658
Packages that FTBFS for non-libpng reasons  186
Packages that rebuilt with 1.4, but not 1.5 74
Packages that need help even with 1.4   46

(The non-libpng failures seem to mostly be due to the recent upgrade to
glib 2.0.  Some of those probably have libpng issues as well, but didn't
get far enough in their builds to expose them.)

About half of the "need help anyway" group may just need their
BuildRequires to be rebuilt first --- it looked like they had no
source-code dependency, but were just absorbing "-lpng12" from library
link flags reported by other packages.  I built each package independently
rather than trying to chain the builds, so this wasn't catered for.

The vast majority of the 74 packages that would need extra work if we move
to libpng 1.5 are trying to access the png_info struct directly, and so
would need patches to use the accessor functions instead.  This is work
that should be done and upstreamed anyway, but if we move to 1.4 we would
not have to do it Right Now.  It looks like it would be a fairly large
amount of work, too --- I count 1164 "incomplete type" failures in the
build logs for those packages, and it's quite likely there are more in
source files that the build runs didn't get to.  On the other hand, if we
move to 1.4 there will not be any pressing reason for these fixes to get
made, and so I'm not sure that we'll be any better off when we try to move
to 1.5 later.  Another point is that we'd have to build these same 964
packages over again if we plan a two-stage upgrade.

Any opinions on which way to jump?

In either case, as per the discussion at
http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html
I plan to provide the 1.2.x libpng shared library (and only the library,
not its devel support files) in a libpng-compat subpackage for the time
being.  So existing programs that depend on 1.2.x will continue to work,
but it won't be possible to rebuild a package that has source-level
dependencies on 1.2.x until those are fixed.  I think this is enough
to avoid needing a special build tag for staging the rebuilds.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel