Bug#650601: transition: libpng 1.5

2016-01-04 Thread Aníbal Monsalve Salazar
On Sun, 2015-12-27 13:49:02 +0100, Tobias Frost wrote:
> Hi,
> 
> Now the stats read:
> Built: 417
> Failed: 112
> OK: 304
> 
> To get forward, I drafted some MBF announcement on the Titanpad. Would
> be cool if some can check it and maybe improve it (writing is not my
> strength)
> 
> https://titanpad.com/libpng16-transistion
> 
> In the draft propose the following plan:
> 
> 0. Assess situation (rebuld) -- done
> 1. MBF announcement
> 2. File bugs for packages failing to build or needing updates in the
>B-Ds
> 2. Upload libpng1.6 to unstable, providing libpng-dev (after "GO" from
>the release team)
> 2a Upload libpng1.2 without providing libpng-dev to unstable
> 3. Raise severity to RC
> 4. Prepare patches and NMU them
> 5. binNMU
> 6. fix remaining issues to finish transition
> 7. Remove libpng12 from unstable
> 
> I'd go to upload 16 package with providing libpng-dev from day 1. and
> then in a second step (as it needs to pass NEW) provide libpng-dev as
> real package to allow versioned depends later. This second-step
> package can be cleared via experimental.
> 
> Nobuhiro, what do you think? As said, now I'd have time
> Emilio/Release-Team: The plan sounds OK with you?

Dear Release-Team,

Do you agree with the plan above?

Regards,

Anibal


signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2015-12-30 Thread Tobias Frost
Dear all,

rebuilt is now complete. 
 
The final stats are:
Built: 463*
Failed: 117
OK: 346

The summary is also here: https://libpng.sviech.de/!summary.txt
On the same server are also the complete buildlogs:
https://libpng.sviech.de/

I will no proceed with the preparations of the MBF announcement.

Tobi



* libreoffice is the only package I did not rebuild



Bug#650601: transition: libpng 1.5

2015-12-28 Thread Tobias Frost
On Sun, 27 Dec 2015 14:25:29 +0100 Pedretti Fabio  wrote:
> Hi, I could provide a fast server (16+ xeon cores, 32gb+ ram)
accessible
> via ssh for test rebuild. If it can be useful let me know.
> Il 27/dic/2015 14:08, "Tobias Frost"  ha scritto:
> 
> > Hi,
> >
> > Now the stats read:
> > Built: 417
> > Failed: 112
> > OK: 304
> >
> > To get forward, I drafted some MBF announcement on the Titanpad.
Would
> > be cool if some can check it and maybe improve it (writing is not
my
> > strength)
> >
> > https://titanpad.com/libpng16-transistion
> >
> > In the draft propose the following plan:
> >
> > 0. Assess situation (rebuld) -- done
> > 1. MBF announcement
> > 2.  File bugs
> > for packages failing to build or needing updates in the B-Ds
> > 2. Upload
> > libpng1.6 to unstable, providing libpng-dev (after "GO" from the
> > release team)
> > 2a Upload libpng1.2 without providing libpng-dev to
> > unstable
> > 3. Raise severity to RC
> > 4. Prepare patches and NMU them
> > 5. binNMU
> > 6. fix remaining issues to finish transition
> > 7. Remove libpng12 from
> > unstable
> >
> > I'd go to upload 16 package with providing libpng-dev from day 1.
and
> > then in a second step (as it needs to pass NEW) provide libpng-dev
as
> > real package to allow versioned depends later. This second-step
package
> > can be cleared via experimental.
> >
> > Nobuhiro, what do you think? As said, now I'd have time
> > Emilio/Release-Team: The plan sounds OK with you?
> >
> > --
> > To unsubscribe, send mail to 650601-unsubscr...@bugs.debian.org.
> >

Thanks for the offer!
Currently not needed, but in case we'll do another rebuild I willl
contact you!

Tobi



Bug#650601: transition: libpng 1.5

2015-12-27 Thread Tobias Frost
Hi,

Now the stats read: 
Built: 417
Failed: 112
OK: 304

To get forward, I drafted some MBF announcement on the Titanpad. Would
be cool if some can check it and maybe improve it (writing is not my
strength)

https://titanpad.com/libpng16-transistion

In the draft propose the following plan:

0. Assess situation (rebuld) -- done
1. MBF announcement 
2.  File bugs
for packages failing to build or needing updates in the B-Ds
2. Upload
libpng1.6 to unstable, providing libpng-dev (after "GO" from the
release team)
2a Upload libpng1.2 without providing libpng-dev to
unstable
3. Raise severity to RC
4. Prepare patches and NMU them
5. binNMU
6. fix remaining issues to finish transition
7. Remove libpng12 from
unstable

I'd go to upload 16 package with providing libpng-dev from day 1. and
then in a second step (as it needs to pass NEW) provide libpng-dev as
real package to allow versioned depends later. This second-step package
can be cleared via experimental. 

Nobuhiro, what do you think? As said, now I'd have time 
Emilio/Release-Team: The plan sounds OK with you?



Bug#650601: transition: libpng 1.5

2015-12-27 Thread Pedretti Fabio
Hi, I could provide a fast server (16+ xeon cores, 32gb+ ram) accessible
via ssh for test rebuild. If it can be useful let me know.
Il 27/dic/2015 14:08, "Tobias Frost"  ha scritto:

> Hi,
>
> Now the stats read:
> Built: 417
> Failed: 112
> OK: 304
>
> To get forward, I drafted some MBF announcement on the Titanpad. Would
> be cool if some can check it and maybe improve it (writing is not my
> strength)
>
> https://titanpad.com/libpng16-transistion
>
> In the draft propose the following plan:
>
> 0. Assess situation (rebuld) -- done
> 1. MBF announcement
> 2.  File bugs
> for packages failing to build or needing updates in the B-Ds
> 2. Upload
> libpng1.6 to unstable, providing libpng-dev (after "GO" from the
> release team)
> 2a Upload libpng1.2 without providing libpng-dev to
> unstable
> 3. Raise severity to RC
> 4. Prepare patches and NMU them
> 5. binNMU
> 6. fix remaining issues to finish transition
> 7. Remove libpng12 from
> unstable
>
> I'd go to upload 16 package with providing libpng-dev from day 1. and
> then in a second step (as it needs to pass NEW) provide libpng-dev as
> real package to allow versioned depends later. This second-step package
> can be cleared via experimental.
>
> Nobuhiro, what do you think? As said, now I'd have time
> Emilio/Release-Team: The plan sounds OK with you?
>
> --
> To unsubscribe, send mail to 650601-unsubscr...@bugs.debian.org.
>


Bug#650601: transition: libpng 1.5

2015-12-25 Thread Alexandre Detiste
> After building 288 packages some intermediate result:
> 
> 288 built
> 85 failed
> 200 built ok
> (3 currently rebuilding due some BD needed to be rebuilt themselves
> too)
> 
> Short analysis of the build errors are on this titanpad:
> https://titanpad.com/libpng16-transistion
> I will continue update the pad with new results.
> 
> To build the packages, I modified the libpng16 package from
> experimental to provides also libpng-dev and libpng12-dev.

Hi,

There's one game from this list for which nobody should waste time on: 
freecraft.

The Stratagus + Wargus fork is now really active again;
indirectly thanks to it's own fork Wyrmsun that is
commercial sold GPL game which bugfixes gets now integrated
back in Stratagus.

Freecraft should instead be removed from the archive
and a transitional "freecraft" package would be provided by
yet-to-be packageed wargus.

I'm currently working on how to modify upstream to make "Warcraft II" 
(non-free, with G-D-P) 
& "Aleona's Tales" (DFSG-free) campaignq co-installable,
but I can already file an ITP today.

Well stratagus was previously in Debian & got removed, but things have changed 
since 2008:
- now freecraft is not active anymore; and this name is linked to MineCraft 
stuff
- stratagus is active again, long standing bugs got fixed
- boswars only provide a futuristic (I would say, ugly) campaign and no way to 
play medieval/fantasy quests
  title of #472278 is misleading "RM: stratagus -- RoQA; abandoned upstream; 
superseded by boswars"
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472278


Someone may want to file an ITP for Wyrmsun too
(game is already packaged there: http://www.playdeb.net/game/Wyrmgus),
but I find more convenient to update it with Steam for now,
because upstream is making very regular releases (sometimes daily) and Steam 
uses some
delta-copy protocol like rsync or bittorrent
& there's a bit of extra non-free nice artwork in the Steam release
& that's a way to indirectly thanks author for fixing old bug in Stratatagus.

http://store.steampowered.com/app/370070/

Greets,

Alexandre



Bug#650601: transition: libpng 1.5

2015-12-25 Thread Tobias Frost
After building 288 packages some intermediate result:

288 built
85 failed
200 built ok
(3 currently rebuilding due some BD needed to be rebuilt themselves
too)

Short analysis of the build errors are on this titanpad:
https://titanpad.com/libpng16-transistion
I will continue update the pad with new results.

To build the packages, I modified the libpng16 package from
experimental to provides also libpng-dev and libpng12-dev.

--
tobi



Bug#650601: transition: libpng 1.5

2015-12-25 Thread Tobias Frost
Am Freitag, den 25.12.2015, 20:28 +0100 schrieb Alexandre Detiste:
> 
> There's one game from this list for which nobody should waste time
> on: freecraft.

Noted on the pad*. Thanks Alexandre



* anyone feel free to add such notes to the pad themselves...



Bug#650601: transition: libpng 1.5

2015-12-25 Thread Gianfranco Costamagna
Hi,

I see *many* packages are failing to build because of completely unrelated 
reasons (e.g. insighttoolkit4 and gambas3),
and many of them needs some rebuilds to see if everything works (e.g. freetype6 
rdeps).

However something like 80 packages, with many of them just needing a few tweaks 
(and many of them not even in testing
for other RC bugs), makes me think about going just on unstable, without 
splitting the transition in two parts.

Nobuhiro, what is your opinion? We are talking about something like ~50 
packages to fix (about 10% of the total packages count),
I don't see the need of two transitions, and keeping both 12 and 16 at the same 
time on unstable.

But this is just my opinion, for sure I can help with ~10-20 packages during 
the VAC :)
(BTW gambas3 is right now in deferred queue, and I think it will be fixed as 
soon as it is accepted on unstable).

(I see Fedora probably did drop the old 12 at all, so we might even find 
patches on their repo if needed, but I'm unsure about this
statement, since I just quickly had a look to their repo)


cheers,

Gianfranco



Bug#650601: transition: libpng 1.5

2015-12-24 Thread Tobias Frost
Hi Nobuhiro,

Am Mittwoch, den 23.12.2015, 05:29 +0900 schrieb Nobuhiro Iwamatsu:
> Hi Tobias, Gianfranco and Emilio.
> 
> Thanks for your help!
> Sorry, about this transition.
> 
> I don't upload libpng16 with providing libpng-dev now. Because Depend
> of libpng
> is very large and effect for system is large too.
> I was considering to gradually transition in a way that was proposed
> by Michael.
> I just sent a mail about this. Could you check this mail, and
> comment?
> 
> Best regards,
>   Nobuhiro

For me this plan sounds good. 

Some steps couls be parallized thouhg, so for example I think we do not
need to wait libpng to transistion to testing before filing bugs and
making packages ready to compile with (libpng12 and) libpng16.

I think we should also recommend people to B-D on libpng-dev to help
subsequent transistions, maybe in combination with stop providing
libpng-dev when the transistion is completed but having a real package
depending on the latest -dev package. (As Michael pointing out,
Versioned depends are not working with Provided packages.)  
 
(But the release team should give the ok to start)

I'm currently rebuilding all reverse B-Ds (on libpng-dev and libpng12-
dev), but this will still take a few days to complete (currently done
~150packages out of ~450) to sasess the situation -- A summary will be
posted to this bug when ready.

--
tobi



Bug#650601: transition: libpng 1.5

2015-12-24 Thread Tobias Frost
On Thu, 24 Dec 2015 12:12:31 +0100 Tobias Frost 
wrote:

> I'm currently rebuilding all reverse B-Ds (on libpng-dev and
libpng12-
> dev), but this will still take a few days to complete (currently done
> ~150packages out of ~450) to sasess the situation -- A summary will
be
> posted to this bug when ready.

buildlogs / status are available here:

http://libpng.sviech.de

(*build are the logs, the other files are just helpers for the script)

(Note: the local libpng16 package is configured to provide libpng12-dev 
and libpng-dev)

(I did not yet closely look at the failures, but there might be a few
failures due to the brute-force nature of the rebuilding. :))

Tobi



Bug#650601: transition: libpng 1.5

2015-12-22 Thread Nobuhiro Iwamatsu
Hi Tobias, Gianfranco and Emilio.

Thanks for your help!
Sorry, about this transition.

I don't upload libpng16 with providing libpng-dev now. Because Depend of libpng
is very large and effect for system is large too.
I was considering to gradually transition in a way that was proposed by Michael.
I just sent a mail about this. Could you check this mail, and comment?

Best regards,
  Nobuhiro

2015-12-21 2:19 GMT+09:00 Gianfranco Costamagna :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Emilio,
>
>> It helps if you Cc the necessary addresses...
>
> I didn't cc the necessary addresses on purpose (see below).
>
>> Before starting anything, please coordinate with the right people,
>> prepare a plan (e.g. make libpng16-dev provide libpng-dev, see how
>> many packages would ftbfs), and wait for a transition slot.
>>
>
> and this is the reason, I *do* not want to start the transition, I
> don't want to be part of libpng* maintainers, just offered my help in
> fixing bugs and uploading packages.
>
> Nobuhiro, it is up to you to start the transition. I see many packages
> that needs just a change from libpng12-dev to libpng-dev, and some of
> them are FTBFS but with patches.
>
> a test rebuild should be done, but I hope we will be able to finally
> sort this long and old issue.
>
> cheers,
>
> Gianfranco
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJWduM/AAoJEPNPCXROn13ZEPoQANG2/jWgX+aOEgvX2rLkNE2F
> 3VLx3nUBdHEEPcbydENfm5E38wqauZn3jzLZQkYV1OPUPBj5FHaGIFbR9AQVEndS
> xhFee6L3EEisvZN27TJmzXWOOz7MpjeFSneAAgVnCgqwtsP199VPT/sXNikhfcoS
> CO2+ji0vzGTN0uVwXlBn6S2TZNOxnHAFACqncYBFpX7w2KkZjh4lfeJSDjX5ZAcP
> 6dWweLtF/pJtVJ50FLwLwSYHBSsVLIynKJPXURalP349QYZrP7WbyzOmBXXgVwZg
> 45NppqrQzYIi/JyOR18l8toman1mfOuECqRIdvcKfnJBjzlcl41g2JLjtkkZSv/u
> VuAuVFM6cpZRJjd6E8L2LB5zRc8fieiyGQ89VFPUSSseJXwzMX4cyjsIQrWSI0RX
> NOZc/YD/0jAkguMNu6C700EcZgKv1miU/ea89jSIJL5HTCf7Qx2Mt4cHFVJdO+WP
> 9ouhyeesPJ8cLph5gYLxjBXXcxQjp2HAgLLobnBl/P1RJiNhyXc902edFXt14RhP
> 4xEh/T24R/QCd1tcb/+mcnDsbDkR+BmnMicb8RFz9If+jwpsJOvgxxoUBuha1Gq8
> /e1niqXzuDw5xDfjhi/bPKg7e8CeGGPVu+at0IjssaqgZpE18miJxlKRxOCqS2LL
> 3JEbjYfqe+XKQ+0gyoi0
> =WSo+
> -END PGP SIGNATURE-



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



Bug#650601: transition: libpng 1.5

2015-12-22 Thread Nobuhiro Iwamatsu
Dear Release Team,

I restart transition of libpng version 1.2(libpng12) to libpng version
1.6 (libpng16).
Sorry about late this work.

I previously had proposed the replacement of libpng12 and libpng16.
But because libpng has a lot of dependent package, there was pointed out that
it is difficult to replacement in a short period of time.

I just like libjpeg, change at the same time or we can install the
package constitutes
libpng12 and libpng16, will propose a gradual transition.
I will proceed in a way that me proposed by Michael.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#55

Here is the plan:

1. Upload to libpng1.6 to unstable.
2. libpng1.6 migrate to testing.
3. Test packages that depend libpng16 on testing with maintainer.

   1/ if it builds against both libpng12 and libpng16, change the b-depends
to libpng-dev
   2/ if it needs updates for libpng16 and the change is not backwards
   compatible, b-depends on libpng16-dev
   3/ File bugs against packages which already b-depends on
   libpng-dev but will ftbfs against libpng16

Note: I already sent patch to most packages.
  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org

4. Finish checking build with libpng12 and libpng16.
5. Remove "Provides: libpng-dev" from libpng12-dev(src: libpng), and
upload to unstable.
6. Add "Provides: libpng-dev" to libpng16-dev (src:libpng1.6), and
upload to unstable.
7. Start binNMU.
8. If we need, NMU.
9. Finish transition.
10. Remove libpng12 from unstable.

How about this plan?

Best regards,
  Nobuhiro

2011-12-01 9:16 GMT+09:00 Nobuhiro Iwamatsu :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi Release Team,
>
> Libpng maintainers want to update libpng from 1.2 to 1.5.
> libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
> needs a transition from libopng12 to libpng15.
> We tested building of the package depending on libpng12.
> FTBFS by this change is reported and is summarized below.
>   
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
> Almost all packages have not been corrected yet.
>
> And it is necessary to change Build-depends of almost all packages
> into libpng-dev from libpng12-dev.
> The present status is as follows.
>
> So please let me know when you'd like me to upload libpng1.5 to unstable.
>
> Best regards,
>   Nobuhiro
>
> -
>
> 3depict:
> Build OK
> aaphoto:
> FTBFS 636555 (with patch)
> abiword:
> Not check
> ace-of-penguins:
> FTBFS 635741 (with patch)
> achilles:
> Build OK
> acovea:
> Build OK
> afterstep:
> FTBFS 649970
> alevt:
> FTBFS 650483
> alien-arena:
> Build OK
> ambdec:
> Build OK
> amoeba:
> FTBFS 650593
> amsn:
> FTBFS 648133
> amule:
> Build OK
> analog:
> Build OK
> antigrav:
> FTBFS 649793
> arb:
> Not check
> armagetronad:
> FTBFS 649547
> atari800:
> Build OK
> autotrace:
> Not check
> awffull:
> Build OK
> blender:
> Build OK
> blockout2:
> FTBFS 649550 (with patch)
> boswars:
> Build OK
> briquolo:
> FTBFS 649789 (with patch)
> bwbar:
> Build OK
> cairo:
> FTBFS 648141 (with patch)
> camlimages:
> Build OK
> camorama:
> Build OK
> caret:
> Build OK
> cegui-mk2:
> Build OK
> celestia:
> FTBFS 649551 (with patch)
> chimera2:
> FTBFS 635743 (with patch)
> chromium-browser:
> Build OK
> clanlib:
> FTBFS 649552 (with patch)
> cmtk:
> Build OK
> compiz:
> Build OK
> contextfree:
> Build OK
> crystalspace:
> Not check
> csound:
> Build OK
> ctsim:
> Build OK
> cultivation:
> Build OK
> cups:
> Build OK
> darkplaces:
> FTBFS 650594
> darktable:
> Build OK
> dcmtk:
> Build OK
> deng:
> FTBFS 650595
> devil:
> FTBFS 649554 (with patch)
> dia:
> FTBFS 649553 (with patch)
> digikam:
> Build OK
> dillo:
> Build OK
> directfb:
> FTBFS 648138 (with patch)
> dosbox:
> Build OK
> driftnet:
> Build OK
> dvdauthor:
> FTBFS 649971
> dvdisaster:
> FTBFS 649555
> dvipng:
> Build OK
> dx:
> Build OK
> eagle:
> Build OK
> ebumeter:
> Build OK
> elastix:
> Build OK
> emacs23:
> Build OK
> emboss:
> Build OK
> enblend-enfuse:
> Not check
> epm:
> Build OK
> evas:
> FTBFS 649556
> exactimage:
> Build OK
> exrtools:
> FTBFS 650484
> extremetuxracer:
> FTBFS 649557
> exult:
> FTBFS 649549
> fbdesk:
> Not check
> fbi:
> Build OK
> fenix:
> FTBFS 649548
> 

Bug#650601: transition: libpng 1.5

2015-12-21 Thread Tobias Frost
Package: release.debian.org
Followup-For: Bug #650601
User: release.debian@packages.debian.org
Usertags: transition

Dear release-team,

can you please update the transition tracker to libpng16?

Thanks!

Tobi

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#650601: transition: libpng 1.5

2015-12-21 Thread Emilio Pozuelo Monfort
On 21/12/15 09:38, Tobias Frost wrote:
> Package: release.debian.org
> Followup-For: Bug #650601
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release-team,
> 
> can you please update the transition tracker to libpng16?

Done (it may take an hour for the page to be re-generated).

Cheers,
Emilio



Bug#650601: transition: libpng 1.5

2015-12-20 Thread Gianfranco Costamagna
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Emilio,

> It helps if you Cc the necessary addresses...

I didn't cc the necessary addresses on purpose (see below).

> Before starting anything, please coordinate with the right people,
> prepare a plan (e.g. make libpng16-dev provide libpng-dev, see how
> many packages would ftbfs), and wait for a transition slot.
> 

and this is the reason, I *do* not want to start the transition, I
don't want to be part of libpng* maintainers, just offered my help in
fixing bugs and uploading packages.

Nobuhiro, it is up to you to start the transition. I see many packages
that needs just a change from libpng12-dev to libpng-dev, and some of
them are FTBFS but with patches.

a test rebuild should be done, but I hope we will be able to finally
sort this long and old issue.

cheers,

Gianfranco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWduM/AAoJEPNPCXROn13ZEPoQANG2/jWgX+aOEgvX2rLkNE2F
3VLx3nUBdHEEPcbydENfm5E38wqauZn3jzLZQkYV1OPUPBj5FHaGIFbR9AQVEndS
xhFee6L3EEisvZN27TJmzXWOOz7MpjeFSneAAgVnCgqwtsP199VPT/sXNikhfcoS
CO2+ji0vzGTN0uVwXlBn6S2TZNOxnHAFACqncYBFpX7w2KkZjh4lfeJSDjX5ZAcP
6dWweLtF/pJtVJ50FLwLwSYHBSsVLIynKJPXURalP349QYZrP7WbyzOmBXXgVwZg
45NppqrQzYIi/JyOR18l8toman1mfOuECqRIdvcKfnJBjzlcl41g2JLjtkkZSv/u
VuAuVFM6cpZRJjd6E8L2LB5zRc8fieiyGQ89VFPUSSseJXwzMX4cyjsIQrWSI0RX
NOZc/YD/0jAkguMNu6C700EcZgKv1miU/ea89jSIJL5HTCf7Qx2Mt4cHFVJdO+WP
9ouhyeesPJ8cLph5gYLxjBXXcxQjp2HAgLLobnBl/P1RJiNhyXc902edFXt14RhP
4xEh/T24R/QCd1tcb/+mcnDsbDkR+BmnMicb8RFz9If+jwpsJOvgxxoUBuha1Gq8
/e1niqXzuDw5xDfjhi/bPKg7e8CeGGPVu+at0IjssaqgZpE18miJxlKRxOCqS2LL
3JEbjYfqe+XKQ+0gyoi0
=WSo+
-END PGP SIGNATURE-



Bug#650601: transition: libpng 1.5

2015-12-20 Thread Gianfranco Costamagna
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 18 Dec 2015 21:49:23 +0100 Tobias Frost  wrote:
> Package: release.debian.org Followup-For: Bug #650601 User:
> release.debian@packages.debian.org Usertags: transition
> 
> Dear libpng maintainers,
> 
> how's about starting the transistion NOW?
> 
> (I also volunteer to help out; bonus: I'm gonna have a few days off
> after the christmas...)
> 

Hi, +1 here.

I think after 4 years this transition should start. I can help in
fixing packages during the vacation.

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWdtNYAAoJEPNPCXROn13Z/G8P/1uBTM0i8GmGKOR4WkzIs4qD
KZ6NemQjk1DR24nOhIEd8xCws/goHDqQJQm3CbsIh8lPVSKB52vRMuQmqNJDjO+g
LGtPYT7x3xIrwlusj7yfDCXMDkuAtS6P0aB3iXhzPZFdj3CvSvkyTWtjwODqwLkz
IfBdkHk6zP4Qvc+VhxYOR45d2WYC/0ZdxD2Sltv/dDbn3/vr/b47FW+lDoNopw4U
8w3AOUmfopn0heVhhlYGsm+RuHB+v+T7ZyMPpBr6/hWYTJDbrNuCb2B9eapjkpqA
y3vvq/RqCTybaxB+mH6NlErLStNgnOzfO6vyTpJq95GG+hLFwUpiRjWjVBRYbZT9
mT3jwiUOMBc3QJdjMMp588HlYKKqQI2cALprghO1L4QO4IrSxiksK0JQ5KGcRufI
GvM3Od5MmGxtffG1WRpz62nNbRq2e2OtbZH0p1cqg7KfORrhc1lMnXTSywJBP+DX
Ke3IulpDo8S4MjS/mVoLvBRCUi1ArVtzX4sHdmauiWbZhxbRt7ADpxG+I66plOeI
iRenLlg8L5h19tPHKbnTC/ZmcEkQt8qlEvuA949IBC8ZXH5faXZ9B1nn6dhHRGRc
eigvIVTFhv/gqXllOvF5rUIkT9qo4az70rGvSRUhRnEXPvtEQ6OtBAInzpno5oZv
zHmilqi81dYhCifSX3dd
=W7+b
-END PGP SIGNATURE-



Bug#650601: transition: libpng 1.5

2015-12-20 Thread Emilio Pozuelo Monfort
On 20/12/15 17:12, Gianfranco Costamagna wrote:
> On Fri, 18 Dec 2015 21:49:23 +0100 Tobias Frost  wrote:
>> Package: release.debian.org Followup-For: Bug #650601 User:
>> release.debian@packages.debian.org Usertags: transition
> 
>> Dear libpng maintainers,

It helps if you Cc the necessary addresses...

> 
>> how's about starting the transistion NOW?
> 
>> (I also volunteer to help out; bonus: I'm gonna have a few days off
>> after the christmas...)
> 
> 
> Hi, +1 here.
> 
> I think after 4 years this transition should start. I can help in
> fixing packages during the vacation.

Before starting anything, please coordinate with the right people, prepare a
plan (e.g. make libpng16-dev provide libpng-dev, see how many packages would
ftbfs), and wait for a transition slot.

Thanks,
Emilio



Bug#650601: transition: libpng 1.5

2015-12-18 Thread Tobias Frost
Package: release.debian.org
Followup-For: Bug #650601
User: release.debian@packages.debian.org
Usertags: transition

Dear libpng maintainers,

how's about starting the transistion NOW?

(I also volunteer to help out; bonus: I'm gonna have a few days off after the 
christmas...)

--
tobi


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-06-29 Thread Neil McGovern
On Fri, Jun 29, 2012 at 02:45:14PM +0900, Nobuhiro Iwamatsu wrote:
 2012/6/27 Julien Cristau jcris...@debian.org:
  On Wed, Jun 27, 2012 at 08:45:03 +0900, Nobuhiro Iwamatsu wrote:
 
  Hi,
 
  I am still correcting FTBFS.
  However, almost packages can shift to libpng 1.5.
  May I upload libpng 1.5 to unstable?
 
  Absolutely not.
 
 OK. Does that already mean that it is too late in wheezy?
 

Yes, I'm afraid so.

Neil
-- 


signature.asc
Description: Digital signature


Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-06-28 Thread Nobuhiro Iwamatsu
Hi,

2012/6/27 Julien Cristau jcris...@debian.org:
 On Wed, Jun 27, 2012 at 08:45:03 +0900, Nobuhiro Iwamatsu wrote:

 Hi,

 I am still correcting FTBFS.
 However, almost packages can shift to libpng 1.5.
 May I upload libpng 1.5 to unstable?

 Absolutely not.

OK. Does that already mean that it is too late in wheezy?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnvkciqb-xelrqr50smxvbg3oxmebfb94p55q+ea9krp...@mail.gmail.com



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-06-27 Thread Julien Cristau
On Wed, Jun 27, 2012 at 08:45:03 +0900, Nobuhiro Iwamatsu wrote:

 Hi,
 
 I am still correcting FTBFS.
 However, almost packages can shift to libpng 1.5.
 May I upload libpng 1.5 to unstable?
 
Absolutely not.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-06-26 Thread Nobuhiro Iwamatsu
Hi,

I am still correcting FTBFS.
However, almost packages can shift to libpng 1.5.
May I upload libpng 1.5 to unstable?

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org

Best regards,
  Nobuhiro

2012/5/22 Julien Cristau jcris...@debian.org:
 On Mon, May 21, 2012 at 15:33:07 +1000, Aníbal Monsalve Salazar wrote:

 On Mon, May 21, 2012 at 01:48:55PM +0900, Nobuhiro Iwamatsu wrote:
 I am working with Anibal about package which supports libpng12 and 15 both.
 This already upload to experimental.

 Hello,

 Please review libpng/1.5.10-3 in experimental.

 I've built lots of packages to test a smooth transition to libpng 1.5
 using libpng/1.5.10-3 on my ia64 machine.

 Upstream is very responsive and both Nobuhiro and myself will help
 package maintainers with this transition.

 I will take a look post wheezy.

 Cheers,
 Julien



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CABMQnV+QJECsk7tX75wAoAeMsArAbVkoY9omg0RND8mz4Hn=f...@mail.gmail.com



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-05-22 Thread Julien Cristau
On Mon, May 21, 2012 at 15:33:07 +1000, Aníbal Monsalve Salazar wrote:

 On Mon, May 21, 2012 at 01:48:55PM +0900, Nobuhiro Iwamatsu wrote:
 I am working with Anibal about package which supports libpng12 and 15 both.
 This already upload to experimental.
 
 Hello,
 
 Please review libpng/1.5.10-3 in experimental.
 
 I've built lots of packages to test a smooth transition to libpng 1.5
 using libpng/1.5.10-3 on my ia64 machine.
 
 Upstream is very responsive and both Nobuhiro and myself will help
 package maintainers with this transition.
 
I will take a look post wheezy.

Cheers,
Julien



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120522122702.gd25...@coloquinte.cristau.org



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-05-20 Thread Nobuhiro Iwamatsu
Hi,

I misunderstood.
I am working with Anibal about package which supports libpng12 and 15 both.
This already upload to experimental.

Best regards,
  Nobuhiro

2012/4/19 Julien Cristau jul...@cristau.org:
 On Thu, Apr 19, 2012 at 16:01:28 +0900, Nobuhiro Iwamatsu wrote:

 However, when libpng15 is installed in unstable instead of libpng12,
 it will be in
  the state where many packages depending on libpng12 do not operate.
 Is the way which enabled it to install libpng12 and libpng15
 simultaneously safety?

 FWIW I don't understand what the above is supposed to mean, I can't
 even parse those sentences.

 Cheers,
 Julien



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnv+84jofygztgamgn9fhcy9bhay_7pazmhyrznfzphu...@mail.gmail.com



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-05-20 Thread Aníbal Monsalve Salazar
On Mon, May 21, 2012 at 01:48:55PM +0900, Nobuhiro Iwamatsu wrote:
I am working with Anibal about package which supports libpng12 and 15 both.
This already upload to experimental.

Hello,

Please review libpng/1.5.10-3 in experimental.

I've built lots of packages to test a smooth transition to libpng 1.5
using libpng/1.5.10-3 on my ia64 machine.

Upstream is very responsive and both Nobuhiro and myself will help
package maintainers with this transition.

Thank you,

Aníbal



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521053307.ga5...@debian.org



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-04-19 Thread Nobuhiro Iwamatsu
2012/4/5 Julien Cristau jcris...@debian.org:
 On Wed, Apr  4, 2012 at 08:17:29 +0900, Nobuhiro Iwamatsu wrote:

 Yes, libopng maintainers will upload libpng1.5 and libpng1.2 to
 unstable on this week.

 What?  At least I don't want another copy of libpng in wheezy without a
 plan to get rid of the other one.


However, when libpng15 is installed in unstable instead of libpng12,
it will be in
 the state where many packages depending on libpng12 do not operate.
Is the way which enabled it to install libpng12 and libpng15
simultaneously safety?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnv+9jz88uk2k6gndwwr8gl-ouyqhxxmy1rgdu0+zxgh...@mail.gmail.com



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-04-19 Thread Julien Cristau
On Thu, Apr 19, 2012 at 16:01:28 +0900, Nobuhiro Iwamatsu wrote:

 However, when libpng15 is installed in unstable instead of libpng12,
 it will be in
  the state where many packages depending on libpng12 do not operate.
 Is the way which enabled it to install libpng12 and libpng15
 simultaneously safety?
 
FWIW I don't understand what the above is supposed to mean, I can't
even parse those sentences.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120419082548.ga15...@coloquinte.cristau.org



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-04-04 Thread Julien Cristau
On Wed, Apr  4, 2012 at 08:17:29 +0900, Nobuhiro Iwamatsu wrote:

 Yes, libopng maintainers will upload libpng1.5 and libpng1.2 to
 unstable on this week.
 
What?  At least I don't want another copy of libpng in wheezy without a
plan to get rid of the other one.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2012-04-03 Thread Nobuhiro Iwamatsu
Hi, Michael.

Sorry, reply was late, and thanks for your comment.

2012/3/5 Michael Biebl bi...@debian.org:
 On 25.02.2012 21:22, Cyril Brulebois wrote:
 Adam D. Barratt a...@adam-barratt.org.uk (05/12/2011):
 On Mon, 2011-12-05 at 16:34 +0900, Nobuhiro Iwamatsu wrote:
 First, we had better upload libpng15, after changing libpng12-dev
 into libpng-dev.  Surely, I think that this method is easy for
 shift.

 We appear to have different definitions of easy.  Anything that
 involves changes to and uploads of over 300 packages is not what the
 release team classifies as easy.

 I set up a tracker in the meanwhile:
   http://release.debian.org/transitions/html/libpng1.5.html

 and it doesn't qualify as “easy” by my standards either.


 Seems there has been a MBF regarding changing the build-depedency from
 libpng12-dev to libpng-dev.
 Reading through #650601 and seeing the amount of packages affected, I
 think the proposed plan is not good for several reasons.
 a/ virtual provides can't safisfy versioned dependencies
 b/ switching blindly from libpng12-dev to libpng-dev doesn't mean the
 package will actually build against libpng15
 c/ testing migration will be a night mare.

 What about the following:
 - Make libpng12 and libpng15 co-installable, by using different source
 package names, e.g. src:libpng and src:libpng15
 - src:libpng12 builds libpng12-dev, src:libpng15 builds libpng15-dev
 - upload *both* packages to unstable
 - src:libpng12 builds a real package libpng-dev, which depends on
 libpng12-dev (with a strict dep), this way versioned build-depends can
 be satisfied.
 - let both packages migrate to testing
 - tell maintainers to test their packages against libpng15, and do the
 following:
   1/ if it builds against both libpng12 and libpng15, change the b-dep
 to libpng-dev
   2/ if it needs updates for libpng15 and the change is not backwards
 compatible, b-depend on libpng15-dev
 - when all packages have been updated to depend on either libpng-dev or
 libpng15-dev, make src:libpng15 build libpng-dev and make it depend on
 libpng15-dev and binNMU the remaining lot.

 This way, we don't need to start a huge transition, which has the
 potential to block other transitions due to testing migration.


 How does that sound?

I understood all it.
I am working about this with Anibal. We will upload libpng1.5 this week.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CABMQnVJ-zBNzNhHRpQAxg=Uv=us0c68wr5p4_w2d+xnlqlr...@mail.gmail.com



Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-04-03 Thread Nobuhiro Iwamatsu
Hi, Tobias.

Thanks for your comment.

2012/3/20 Tobias Hansen tobias@gmx.de:
 Am -10.01.-28163 20:59, schrieb Julien Cristau:
 On Mon, Mar  5, 2012 at 07:33:34 +0100, Michael Biebl wrote:

 How does that sound?

 I'd rather get as many FTBFS against libpng 1.5 bugs as possible fixed
 now.  Then after wheezy make the actual switch.

 Cheers,
 Julien

 Is that the current plan now or is there still the chance of a
 co-installable libpng15-dev in wheezy? I'm working on packaging
 something that needs libpng 1.5 and I would like to know if it has to be
 patched to work with libpng 1.2.


Yes, libopng maintainers will upload libpng1.5 and libpng1.2 to
unstable on this week.

Best regards,
  Nobuhiro


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnvkks5ocvunw7gkheo_pelt7+gk7k2vh7qfzyanvpso...@mail.gmail.com



Bug#650601: transition: libpng 1.5

2012-04-03 Thread Michael Biebl
Hi,

Am 04.04.2012 01:15, schrieb Nobuhiro Iwamatsu:

 I am working about this with Anibal. We will upload libpng1.5 this week.

Please keep in mind that I'm not a member of the release team.

So please wait for an ack from the release team before making any
uploads to unstable.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#650601: Re: Bug#650601: transition: libpng 1.5

2012-03-19 Thread Tobias Hansen
Am -10.01.-28163 20:59, schrieb Julien Cristau:
 On Mon, Mar  5, 2012 at 07:33:34 +0100, Michael Biebl wrote:

 How does that sound?

 I'd rather get as many FTBFS against libpng 1.5 bugs as possible fixed
 now.  Then after wheezy make the actual switch.

 Cheers,
 Julien

Is that the current plan now or is there still the chance of a
co-installable libpng15-dev in wheezy? I'm working on packaging
something that needs libpng 1.5 and I would like to know if it has to be
patched to work with libpng 1.2.

Best regards,
Tobias Hansen



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f67a072.8070...@gmx.de



Bug#650601: transition: libpng 1.5

2012-03-05 Thread Julien Cristau
On Mon, Mar  5, 2012 at 07:33:34 +0100, Michael Biebl wrote:

 How does that sound?
 
I'd rather get as many FTBFS against libpng 1.5 bugs as possible fixed
now.  Then after wheezy make the actual switch.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2012-03-04 Thread Michael Biebl
On 25.02.2012 21:22, Cyril Brulebois wrote:
 Adam D. Barratt a...@adam-barratt.org.uk (05/12/2011):
 On Mon, 2011-12-05 at 16:34 +0900, Nobuhiro Iwamatsu wrote:
 First, we had better upload libpng15, after changing libpng12-dev
 into libpng-dev.  Surely, I think that this method is easy for
 shift.

 We appear to have different definitions of easy.  Anything that
 involves changes to and uploads of over 300 packages is not what the
 release team classifies as easy.
 
 I set up a tracker in the meanwhile:
   http://release.debian.org/transitions/html/libpng1.5.html
 
 and it doesn't qualify as “easy” by my standards either.


Seems there has been a MBF regarding changing the build-depedency from
libpng12-dev to libpng-dev.
Reading through #650601 and seeing the amount of packages affected, I
think the proposed plan is not good for several reasons.
a/ virtual provides can't safisfy versioned dependencies
b/ switching blindly from libpng12-dev to libpng-dev doesn't mean the
package will actually build against libpng15
c/ testing migration will be a night mare.

What about the following:
- Make libpng12 and libpng15 co-installable, by using different source
package names, e.g. src:libpng and src:libpng15
- src:libpng12 builds libpng12-dev, src:libpng15 builds libpng15-dev
- upload *both* packages to unstable
- src:libpng12 builds a real package libpng-dev, which depends on
libpng12-dev (with a strict dep), this way versioned build-depends can
be satisfied.
- let both packages migrate to testing
- tell maintainers to test their packages against libpng15, and do the
following:
   1/ if it builds against both libpng12 and libpng15, change the b-dep
to libpng-dev
   2/ if it needs updates for libpng15 and the change is not backwards
compatible, b-depend on libpng15-dev
- when all packages have been updated to depend on either libpng-dev or
libpng15-dev, make src:libpng15 build libpng-dev and make it depend on
libpng15-dev and binNMU the remaining lot.

This way, we don't need to start a huge transition, which has the
potential to block other transitions due to testing migration.


How does that sound?

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#650601: transition: libpng 1.5

2012-03-04 Thread Michael Biebl
Two more points:

On 05.03.2012 07:33, Michael Biebl wrote:
 What about the following:
 - Make libpng12 and libpng15 co-installable, by using different source
 package names, e.g. src:libpng and src:libpng15
 - src:libpng12 builds libpng12-dev, src:libpng15 builds libpng15-dev
 - upload *both* packages to unstable
 - src:libpng12 builds a real package libpng-dev, which depends on
 libpng12-dev (with a strict dep), this way versioned build-depends can
 be satisfied.
 - let both packages migrate to testing
 - tell maintainers to test their packages against libpng15, and do the
 following:
1/ if it builds against both libpng12 and libpng15, change the b-dep
 to libpng-dev
2/ if it needs updates for libpng15 and the change is not backwards

 3/ File bugs against packages which already build-depends on
libpng-dev but will ftbfs against libpng15

 compatible, b-depend on libpng15-dev
 - when all packages have been updated to depend on either libpng-dev or
 libpng15-dev, make src:libpng15 build libpng-dev and make it depend on
 libpng15-dev and binNMU the remaining lot.

- Cleanup aftwards, i.e. remove the libpng12 source package.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#650601: transition: libpng 1.5

2012-02-25 Thread Cyril Brulebois
Adam D. Barratt a...@adam-barratt.org.uk (05/12/2011):
 On Mon, 2011-12-05 at 16:34 +0900, Nobuhiro Iwamatsu wrote:
  First, we had better upload libpng15, after changing libpng12-dev
  into libpng-dev.  Surely, I think that this method is easy for
  shift.
 
 We appear to have different definitions of easy.  Anything that
 involves changes to and uploads of over 300 packages is not what the
 release team classifies as easy.

I set up a tracker in the meanwhile:
  http://release.debian.org/transitions/html/libpng1.5.html

and it doesn't qualify as “easy” by my standards either.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2011-12-05 Thread Adam D. Barratt
On Mon, 2011-12-05 at 16:34 +0900, Nobuhiro Iwamatsu wrote:
 2011/12/1 Adam D. Barratt a...@adam-barratt.org.uk:
  On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote:
 
  Libpng maintainers want to update libpng from 1.2 to 1.5.
  libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
  needs a transition from libopng12 to libpng15.
  We tested building of the package depending on libpng12.
  FTBFS by this change is reported and is summarized below.
 
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
  Almost all packages have not been corrected yet.

That's quite a blocker; see below.

  And it is necessary to change Build-depends of almost all packages
  into libpng-dev from libpng12-dev.
 
 
  Is there a good reason why the new libpng-dev couldn't at least Provide
  libpng12-dev in the short term?
 
 libpng12-dev provides libpng-dev.
 This is provided from before.

Was this communicated to affected maintainers?  Looking at unstable's
Sources list, there appear to be around 100 packages already
build-depending on libpng-dev, but there's no easy way of telling how
long they've been doing so.

  Would this allow some (most?) packages to
  be binNMUed?
 
 No, almost all packages have described libpng12-dev to Build-Depends.

I'm not sure if something's getting lost in translation here, or if I
wasn't clear enough in my question.  If libpng12-dev was still Provided,
is there any reason we couldn't then binNMU the 100-or-so packages
marked as ok in your list?

 First, we had better upload libpng15, after changing libpng12-dev into
 libpng-dev.
 Surely, I think that this method is easy for shift.

We appear to have different definitions of easy.  Anything that
involves changes to and uploads of over 300 packages is not what the
release team classifies as easy.

Furthermore, your list indicates that you're aware of nearly 130 build
failures with the new library, and that less than a quarter of those
have patches in the BTS; that's really too large a number to be starting
a transition with.  How many of the failures which don't have patches
filed are directly attributable to the libpng changes?

Regards,

Adam




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1323112409.27651.10.ca...@hathi.jungle.funky-badger.org



Bug#650601: transition: libpng 1.5

2011-12-05 Thread Nobuhiro Iwamatsu
Hi,

2011/12/6 Adam D. Barratt a...@adam-barratt.org.uk:
 On Mon, 2011-12-05 at 16:34 +0900, Nobuhiro Iwamatsu wrote:
 2011/12/1 Adam D. Barratt a...@adam-barratt.org.uk:
  On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote:
 
  Libpng maintainers want to update libpng from 1.2 to 1.5.
  libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
  needs a transition from libopng12 to libpng15.
  We tested building of the package depending on libpng12.
  FTBFS by this change is reported and is summarized below.
 
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
  Almost all packages have not been corrected yet.

 That's quite a blocker; see below.

  And it is necessary to change Build-depends of almost all packages
  into libpng-dev from libpng12-dev.
 
 
  Is there a good reason why the new libpng-dev couldn't at least Provide
  libpng12-dev in the short term?

 libpng12-dev provides libpng-dev.
 This is provided from before.

 Was this communicated to affected maintainers?  Looking at unstable's
 Sources list, there appear to be around 100 packages already
 build-depending on libpng-dev, but there's no easy way of telling how
 long they've been doing so.

No, I do not yet notify you of this.
I work now.


  Would this allow some (most?) packages to
  be binNMUed?

 No, almost all packages have described libpng12-dev to Build-Depends.

 I'm not sure if something's getting lost in translation here, or if I
 wasn't clear enough in my question.  If libpng12-dev was still Provided,
 is there any reason we couldn't then binNMU the 100-or-so packages
 marked as ok in your list?

The thing depending on libpng12-dev is still included in my OK list, too.
I replaced the package which still depended on libpng12-dev with
libpng-dev and confirmed the build.
And at first in the package which I still depend on libpng12-dev for
for the correction because it is necessary,
I understand it when this method is wrong.


 First, we had better upload libpng15, after changing libpng12-dev into
 libpng-dev.
 Surely, I think that this method is easy for shift.

 We appear to have different definitions of easy.  Anything that
 involves changes to and uploads of over 300 packages is not what the
 release team classifies as easy.


I understand that package transition is difficult.
This means comparing with the case where there is a package depending
on libpng-dev and libpng12-dev.

 Furthermore, your list indicates that you're aware of nearly 130 build
 failures with the new library, and that less than a quarter of those
 have patches in the BTS; that's really too large a number to be starting
 a transition with.  How many of the failures which don't have patches
 filed are directly attributable to the libpng changes?

Yes, almost all packages are caused by change of ABI/API of libpng.

I think that I will solve these problems as follows from now on.
First, I request the transition to libpng-dev from libpng12-dev from a
package maintainer.
Second,  I correct FTBFS by libpng15.
A release team is again consulted with on shift to libpng15 after that.

How is it?

Best regards,
  Nobuhiro
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnv+syo2fdnjokq3iaaxbmvzoeuxpapfgreevhtyo6pe...@mail.gmail.com



Bug#650601: transition: libpng 1.5

2011-12-05 Thread Steve M. Robbins
On Mon, Dec 05, 2011 at 08:43:16AM +0100, Julien Cristau wrote:
 On Sun, Dec  4, 2011 at 23:34:37 -0600, Steve M. Robbins wrote:
 
  If the API has changed, as Nobuhiro states above, it would be
  incorrect for the new -dev package to provide the old, wouldn't it?
 
 No.  It would only be incorrect if the plan was to keep libpng12-dev
 around as a real package.

I'd have to disagree.  If I install something named libpng12-dev,
I'd expect it to have the same API as it always had.  This is untrue
for libpng 1.5.


  Nor can the provides be temporary; it would have to last until all the
  build-depends were changed, wouldn't it?
  
 That's what temporary means.

Touche.  The phrase I wanted was short term.  


  Wouldn't it be better, instead, to leave both old and new -dev
  packages in the archive until all 123 dependent packages are fixed?
  
 There are 400 reverse dependencies of libpng.  I don't think source
 changes to all of them (most just to switch a build-dependency) is a
 good plan.

I don't know if most are just switching a build-dependency.  I saw
quite a number with serious changes; e.g. the new version has hidden
at least one formerly-exposed class.  If you really switch libpng12-dev,
you instantly make these all unbuildable.  

Can we not keep both APIs around until all the upstreams switch over
to the new API?  This keeps everyone building and able to switch at
the proper pace.

Thanks,
-Steve




signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2011-12-04 Thread Arnaud Fontaine
Nobuhiro Iwamatsu iwama...@debian.org writes:

 And it  is necessary  to change Build-depends  of almost  all packages
 into libpng-dev from libpng12-dev.  The present status is as follows.
 [...]
   tuxonice-userui: FTBFS 648125

I wrote a patch and have a package ready to upload as soon as libpng 1.5
is in unstable.

Cheers,
-- 
Arnaud Fontaine


pgpCFbEeK2NwJ.pgp
Description: PGP signature


Bug#650601: transition: libpng 1.5

2011-12-04 Thread Steve M. Robbins
On Thu, Dec 01, 2011 at 11:30:19AM +, Adam D. Barratt wrote:
 On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote:
 Libpng maintainers want to update libpng from 1.2 to 1.5.
 libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
 needs a transition from libopng12 to libpng15.

 And it is necessary to change Build-depends of almost all packages
 into libpng-dev from libpng12-dev.
 
 Is there a good reason why the new libpng-dev couldn't at least
 Provide libpng12-dev in the short term?  Would this allow some
 (most?) packages to be binNMUed?

If the API has changed, as Nobuhiro states above, it would be
incorrect for the new -dev package to provide the old, wouldn't it?
Nor can the provides be temporary; it would have to last until all the
build-depends were changed, wouldn't it?


Wouldn't it be better, instead, to leave both old and new -dev
packages in the archive until all 123 dependent packages are fixed?

Cheers,
-Steve


signature.asc
Description: Digital signature


Bug#650601: transition: libpng 1.5

2011-12-04 Thread Nobuhiro Iwamatsu
Hi,

2011/12/1 Adam D. Barratt a...@adam-barratt.org.uk:
 On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote:

 Libpng maintainers want to update libpng from 1.2 to 1.5.
 libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
 needs a transition from libopng12 to libpng15.
 We tested building of the package depending on libpng12.
 FTBFS by this change is reported and is summarized below.



 http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
 Almost all packages have not been corrected yet.

 And it is necessary to change Build-depends of almost all packages
 into libpng-dev from libpng12-dev.


 Is there a good reason why the new libpng-dev couldn't at least Provide
 libpng12-dev in the short term?

libpng12-dev provides libpng-dev.
This is provided from before.

 Would this allow some (most?) packages to
 be binNMUed?

No, almost all packages have described libpng12-dev to Build-Depends.
First, we had better upload libpng15, after changing libpng12-dev into
libpng-dev.
Surely, I think that this method is easy for shift.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cabmqnvljbwn0n9v0ezh8ds9xpk6y4f2k9xjh1zhu5uqfbus...@mail.gmail.com



Bug#650601: transition: libpng 1.5

2011-12-04 Thread Julien Cristau
On Sun, Dec  4, 2011 at 23:34:37 -0600, Steve M. Robbins wrote:

 If the API has changed, as Nobuhiro states above, it would be
 incorrect for the new -dev package to provide the old, wouldn't it?

No.  It would only be incorrect if the plan was to keep libpng12-dev
around as a real package.  Since the source package name was not
changed, I assume that's not the case.

 Nor can the provides be temporary; it would have to last until all the
 build-depends were changed, wouldn't it?
 
That's what temporary means.

 Wouldn't it be better, instead, to leave both old and new -dev
 packages in the archive until all 123 dependent packages are fixed?
 
There are 400 reverse dependencies of libpng.  I don't think source
changes to all of them (most just to switch a build-dependency) is a
good plan.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111205074316.gf3...@radis.cristau.org



Bug#650601: transition: libpng 1.5

2011-12-01 Thread Adam D. Barratt

On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote:

Libpng maintainers want to update libpng from 1.2 to 1.5.
libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
needs a transition from libopng12 to libpng15.
We tested building of the package depending on libpng12.
FTBFS by this change is reported and is summarized below.


http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
Almost all packages have not been corrected yet.

And it is necessary to change Build-depends of almost all packages
into libpng-dev from libpng12-dev.


Is there a good reason why the new libpng-dev couldn't at least Provide 
libpng12-dev in the short term?  Would this allow some (most?) packages 
to be binNMUed?


Regards,

Adam



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/35a47fa1112dc3effba6a16020fdb...@mail.adsl.funky-badger.org



Bug#650601: transition: libpng 1.5

2011-11-30 Thread Nobuhiro Iwamatsu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team,

Libpng maintainers want to update libpng from 1.2 to 1.5.
libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
needs a transition from libopng12 to libpng15.
We tested building of the package depending on libpng12.
FTBFS by this change is reported and is summarized below.
  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
Almost all packages have not been corrected yet.

And it is necessary to change Build-depends of almost all packages
into libpng-dev from libpng12-dev.
The present status is as follows.

So please let me know when you'd like me to upload libpng1.5 to unstable.

Best regards,
  Nobuhiro

-

3depict:
Build OK
aaphoto:
FTBFS 636555 (with patch)
abiword:
Not check
ace-of-penguins:
FTBFS 635741 (with patch)
achilles:
Build OK
acovea:
Build OK
afterstep:
FTBFS 649970
alevt:
FTBFS 650483
alien-arena:
Build OK
ambdec:
Build OK
amoeba:
FTBFS 650593
amsn:
FTBFS 648133
amule:
Build OK
analog:
Build OK
antigrav:
FTBFS 649793
arb:
Not check
armagetronad:
FTBFS 649547
atari800:
Build OK
autotrace:
Not check
awffull:
Build OK
blender:
Build OK
blockout2:
FTBFS 649550 (with patch)
boswars:
Build OK
briquolo:
FTBFS 649789 (with patch)
bwbar:
Build OK
cairo:
FTBFS 648141 (with patch)
camlimages:
Build OK
camorama:
Build OK
caret:
Build OK
cegui-mk2:
Build OK
celestia:
FTBFS 649551 (with patch)
chimera2:
FTBFS 635743 (with patch)
chromium-browser:
Build OK
clanlib:
FTBFS 649552 (with patch)
cmtk:
Build OK
compiz:
Build OK
contextfree:
Build OK
crystalspace:
Not check
csound:
Build OK
ctsim:
Build OK
cultivation:
Build OK
cups:
Build OK
darkplaces:
FTBFS 650594
darktable:
Build OK
dcmtk:
Build OK
deng:
FTBFS 650595
devil:
FTBFS 649554 (with patch)
dia:
FTBFS 649553 (with patch)
digikam:
Build OK
dillo:
Build OK
directfb:
FTBFS 648138 (with patch)
dosbox:
Build OK
driftnet:
Build OK
dvdauthor:
FTBFS 649971
dvdisaster:
FTBFS 649555
dvipng:
Build OK
dx:
Build OK
eagle:
Build OK
ebumeter:
Build OK
elastix:
Build OK
emacs23:
Build OK
emboss:
Build OK
enblend-enfuse:
Not check
epm:
Build OK
evas:
FTBFS 649556
exactimage:
Build OK
exrtools:
FTBFS 650484
extremetuxracer:
FTBFS 649557
exult:
FTBFS 649549
fbdesk:
Not check
fbi:
Build OK
fenix:
FTBFS 649548
ffmpegthumbnailer:
Build OK
fgfs-atlas:
FTBFS 648137
fim:
Not check 636968 (with patch)
flam3:
FTBFS 635945 (with patch)
fldigi:
Build OK
fltk1.1:
Build OK 648135
fltk1.3:
Build OK
fontforge:
FTBFS 649950
fox1.6:
Build OK
fraqtive:
Build OK
freeciv:
Build OK
freecraft:
FTBFS 649546
freegish:
FTBFS 649796
freeimage:
FTBFS 650485
freej:
Build OK
freesci:
Build OK
fsl:
Build OK
fsviewer:
Not check
fuse-emulator:
Build OK 649803
fvwm:
FTBFS 649802
g2clib:
FTBFS #650486
gambas2:
Not check
gamera:
Build OK
gargoyle-free:
Build OK
gd4o:
Build OK
gdal:
FTBFS 636053 (with patch)
gdcm:
Build OK
gdk-pixbuf:
Build OK
gegl:
FTBFS 649952
gerbv:
Build OK
ghostscript:
Build OK
gif2png:
FTBFS 650487
gimp-gap:
Build OK
gimp:
FTBFS 649972
gle-graphics:
Build OK
glhack:
FTBFS 649948
gltron:
FTBFS 625343 (with patch)
gmerlin-avdecoder:
Build OK
gmsh:
Build OK
gnash:
FTBFS 649384 (other FTBFS)
gnome-xcf-thumbnailer:
FTBFS 635946 (with patch)
gnubg:
Build OK
gnuplot:
Build OK
gnuradio:
FTBFS 642716
gnusound:
FTBFS 622013 (other FTBFS)
gnustep-gui:
Build OK
gpiv:
Build OK
gpivtools:
Build OK
grace:
Build OK
graphicsmagick:
FTBFS 649973
graphviz:
Build OK
grass:
Not check
gretl:
Build OK
grfcodec:
Build OK
grib-api:
Build OK
gst-plugins-bad0.10:
Build OK
gst-plugins-good0.10:
Build OK
gthumb:
Build OK
gtkatlantic:
Build OK
guvcview:
Build OK
h5utils:
FTBFS 650488
hatari:
Build OK
htmldoc:
FTBFS 650562
hugin:
Build OK
iceape:
FTBFS 649976
icedove:
Build OK 649977
iceowl:
Build OK
iceweasel: