Re: Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1
Hi,
On 22/01/16 14:59, Tobias Frost wrote:
> Hi Emilio and release team
> (sorry for the previous mail and thanks for the untag, I fixed the uploa
> d)
>
> as you have noticed yesterday and today I NMUed the remaining "please
> switch from libpng-{3,12,12-0}-dev to libpng-dev" bugs.
> (around ~30 NMUs that will hit unstable hopefully in 7 days)
>
> there are a couple of packages with a build-dependency on
> libpng-dev | libpng12-dev but I didn't NMU them because I don't think
> they are going to give troubles in the transition context.
>
> Now, we should be left with ~50 packages currently FTBFS, but I think
> for most of them we could easily have patches from Fedora or upstream
> new versions (many of them already have patches on BTS)
>
> This is a list of packages, according to the bug blocking this one.
> pngnq: patch, but should wait for the transition to start
> libtheora: patch
> openmsx: patch (should wait the transition to start)
> calligra: no patch, out of testing, arch linux has the latest version
> and seems to build against libpng16
> libcoyotl: has an RC bug (license issue), no patch
> xcftools: testsuite failure fedora has the latest, maybe they have a pat
> ch
> neverball: patch, but should wait for the transition to start
> openjfx: no patch, but new upstream release
> tucnak: no patch, but new upstream release
> xemacs21: FTBFS against gcc-5
> openlayer: mailed the bug report with a patch (not sure if enough)
> armagetronad: patch? I think it is a matter of changing the configure
> script
> aseprite: should be a matter of a define (new upstream release)
> libpgplot-perl: patch, fixed in git
> mathgl: patch from fedora?
> https://lists.fedoraproject.org/pipermail/scm-commits/2011-December/6932
> 05.html
> abiword: patch, fixed, but failing for another reason now
> nagios3: not in testing, RC buggy
> celestia: RM ROM Dead upstream
> warzone2100: new upstream release: according to google fedora builds
> it fine with new libpng
> netpbm-free: ZLIB_VERSION undeclared, should be trivial to fix
> (missing include), if it isn't still not fixed (mailed the bug report)
> exult: no patch, but new upstream release (snapshot)
> fw4spl: double RC buggy
> rbdoom3bfg: no patch
> exrtools: patch
> libapache2-mod-qos: missing b-d patch
> ifeffit: seems to be failing because of missing b-d, and needs
> probably rebuilds of other build-dependencies, RC buggy
> matplotlib: should be fine now
> pcsx2: probably needs some rebuilds to make build-dependencies installab
> le
> root-system: FTBFS for unrelated reasons? RC buggy
> ctsim: needs some rebuilds to be fixed (e.g. libgdk-pixbuf2.0-dev)
> should be easy to patch
> wine-development: I think no issue, unrelated build failure
> scorched3d: FTBFS, but should be trivial to fix (pointer change)
> libtk-img: FTBFS but fedora has patches
> https://pkgs.fedoraproject.org/cgit/rpms/tkimg.git/tree/
>
>
> so, basically the ~50 FTBFS are now down to 31 (some of them have been
> NMUed while writing this email), and the "no patch" bugs are currently
> only 6, and I suspect some of them even will rebuild fine (probably
> transition related issues).
>
> So, if we exclude the RC buggy packages we are down to really a couple
> of packages, but I think we should start the transition and fix them
> later, specially because the build failures logs are from libpng15 in
> some cases, and it isn't worth the effort to double check them.
>
> Can we have a transition slot if possible, or should we fix something
> more?
>
> Please note: all the NMUs will need 6/7 days to go in unstable.
>
> (there is also a bug against texlive-base to stop using the embedded
> libpng version, but obviously it can't be fixed until the transition
> starts)
>>
>
> Many thanks Gianfranco for the summary!
>
> Regarding the packages requiring libpng-config, I proposed to the maintainers
> do another libng16 upload, so that that tool will be pulled in as depdenceny
> (Otherwise we'll have the soversion hardcoded again in some B-D; I'd like to
> avoid that.)
>
> Please, Anibal & Nobuhiro shout STOP if you do not like this otherwise I'll
> NMU my proposal tomorrow evening to experimental..
>
> The packages affected by this are (list might be incomplete):
> armagetronad
> pngnq
> openmsx (probably)
> neverball
>
>
> I'm continuing to rebuild packages on my server and will also NMU a few
> packages on the weekend to get the number of real libpng16 caused FTBFSs
> minimized. (atm most of the FAIL marked packages are caused by tricky B-D
> chains or broken B-Ds. My list has currently 16 packages needing an patch &
> NMU)
>
> I think we are quite close to throw the switch...
> Release-Team: Ready?
Thank you all for your work on this.
Can send another summary with your proposed plan here? Currently libpng12-dev
provides libpng-dev but libpng16-dev doesn't. Are you going to switch that? Or
do you plan to build a libpng-dev package from src:libpng1.6?
Another thing I want to confirm before starting this transition is what Cyril
asked earlier today in another mail. What happens if libpng12.so and libpng16.so
are both loaded into a process? Does that work properly, because of versioned
symbols et al? E.g.
gimp depends on libpng12-0.
gimp also depends on libgtk2.0-0, which depends on libgdk-pixbuf2.0-0, which in
turn depends on libpng12-0.
If one of gimp or libgdk-pixbufs2.0-0 get rebuilt, but the other doesn't, when
gimp runs then both libpng12.so and libpng16.so will get loaded. Is that supported?
Assuming that works fine, this is looking good and should be ready to start soon.
Cheers,
Emilio
Reply to: