Bug#650601: Processed: fvwm: diff for NMU version 1:2.6.5.ds-4.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWoh2BAAoJEPNPCXROn13Z56YP/iOUBrd6wkQl/B+EcbhmiT5F
aF8DMPoeh8zcKkvsXIjmvwg7XkMz0e/RlrVv1XsgYrnD5jt46N9Su+LZrscAlMFs
rMOPHaubnhueFLYAxK9nCxJUgPJ6m/abAp1BiNVQsq+kI1MNTECRkxAadtdcND5i
NlP/BbOJalwbpMWtcVF3SFrrdJmSrwcaSeXPg0coK8uCLt2xw4n1dMTAk2G3zFr4
F/JlOU2Aqyy6fhK5DeXewgBe1Bd5S/x+q+sy41d4hSQffJF039vk4ng/FzWJpuya
N6juMLL8RnBs7f/H7MgOXy8mkbo8Pov2jt/NCQqLWN7lLBS6heu5wQWQdtydM24u
n/KfDpALrJtHOHZLorg0ZUsHCncYqQmPNQJG7uiIosXy45iC2q+EKbU9sD8eKVly
epXloyUDV0ubphfp9Py0OYARpZCiQqFyUnnojQ47NBpabD6YMHece2fByfAoHJMr
H/1Vqw9yGWAwa4BJRDdMTWHDhTQH6IZOD/rhCnj4J2ORXJrpL4BVW6QwdKfn33BV
4x78LpOneGLe2IxlmMe68wNw+xX+8qXnt3PdIB/fKuOOxsQ45bTc7yKXpjBr6Q0I
kT7JtUGo0aW940TsW/yPWl3UewjUV89W0VE211HuVFBJNoVV8Z1IzoxJLPpgD35J
LW1DDVuMLushD6zkFLCr
=538b
-----END PGP SIGNATURE-----
Reply to: