Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
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?
On Mon, Dec 5, 2011 at 5:41 PM, Adam Jackson a...@redhat.com 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?
Adam Jackson a...@redhat.com 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?
On Mon, Dec 05, 2011 at 17:44:12 +, Peter Robinson pbrobin...@gmail.com 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?
On Mon, Dec 5, 2011 at 12:52 PM, Bruno Wolff III br...@wolff.to wrote: On Mon, Dec 05, 2011 at 17:44:12 +, Peter Robinson pbrobin...@gmail.com 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?
Michael Schwendt mschwe...@gmail.com 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?
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?
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?
On Wed, 2011-11-09 at 10:42 -0500, Tom Lane wrote: Nils Philippsen n...@redhat.com 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?
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?
Nils Philippsen n...@redhat.com 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
Upgrading libpng: shall we move to 1.4.x or 1.5.x?
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
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
...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
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
Once upon a time, Tom Lane t...@redhat.com 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 cmad...@hiwaay.net 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?
Kevin Fenzi ke...@scrye.com 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?
On Fri, 04 Nov 2011 14:54:28 -0400 Tom Lane t...@redhat.com wrote: Kevin Fenzi ke...@scrye.com 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?
Chris Adams cmad...@hiwaay.net writes: Once upon a time, Tom Lane t...@redhat.com 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?
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?
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?
Dr Andrew John Hughes ahug...@redhat.com 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?
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=libpngbaseproject=openSUSE%3AFactorylang=enexclude_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?
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?
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
