Re: Bug#739079: transition: libav10
On Thu, May 8, 2014 at 20:35:55 -0400, Reinhard Tartler wrote: On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote: When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. What's the status of the remaining 8 open bugs? (Mostly interested in vtk and opencv, since they're the ones with reverse deps, I think.) Cheers, Julien signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Sun, May 11, 2014 at 9:16 AM, Julien Cristau jcris...@debian.org wrote: On Thu, May 8, 2014 at 20:35:55 -0400, Reinhard Tartler wrote: On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote: When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. What's the status of the remaining 8 open bugs? (Mostly interested in vtk and opencv, since they're the ones with reverse deps, I think.) I've just uploaded NMUs for vtk and opencv to DELAYED/5, but I can reschedule them if you think that this would be appropriate. for the rest, I'd think that there is a very good chance that the respective maintainers are going to fix them before they turn out to be actual blockers of the transition. If they do, let's remove them temporarily from testing. I mean, uploading libav10 to unstable will require many additional sourceful uploads of package versions that are currently in experimental, which will take some time by itself. I'd suggest let's start with that. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Sun, May 11, 2014 at 11:25:49 -0400, Reinhard Tartler wrote: for the rest, I'd think that there is a very good chance that the respective maintainers are going to fix them before they turn out to be actual blockers of the transition. If they do, let's remove them temporarily from testing. I mean, uploading libav10 to unstable will require many additional sourceful uploads of package versions that are currently in experimental, which will take some time by itself. I'd suggest let's start with that. So the fact that it'll require sourceful uploads of lots of packages with many different maintainers is actually a big part of what makes this painful for us. The easiest transitions are the ones where a rebuild is all that's necessary, and fewer people need to be involved to upload things at more or less the same time. Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? For reference last time took 2 months. Cheers, Julien signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: On Sun, May 11, 2014 at 11:25:49 -0400, Reinhard Tartler wrote: for the rest, I'd think that there is a very good chance that the respective maintainers are going to fix them before they turn out to be actual blockers of the transition. If they do, let's remove them temporarily from testing. I mean, uploading libav10 to unstable will require many additional sourceful uploads of package versions that are currently in experimental, which will take some time by itself. I'd suggest let's start with that. So the fact that it'll require sourceful uploads of lots of packages with many different maintainers is actually a big part of what makes this painful for us. The easiest transitions are the ones where a rebuild is all that's necessary, and fewer people need to be involved to upload things at more or less the same time. I see. Unfortunately, it is unrealistic to prepare all of libav's reverse dependencies in this way, which is why I need I'm asking for assistance. I'm sorry to cause this amount of pain to you, but I don't see how to do better here. Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? That would be beautiful. From my side, I would appreciate it very much if we could make T==today. For reference last time took 2 months. I'll be doing my best to make it happen faster this time. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
Control: tag -1 confirmed On Sun, May 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? That would be beautiful. From my side, I would appreciate it very much if we could make T==today. For reference last time took 2 months. I'll be doing my best to make it happen faster this time. OK, let's go ahead then. Cheers, Julien signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Sun, May 11, 2014 at 12:20 PM, Julien Cristau jcris...@debian.org wrote: Control: tag -1 confirmed On Sun, May 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? That would be beautiful. From my side, I would appreciate it very much if we could make T==today. For reference last time took 2 months. I'll be doing my best to make it happen faster this time. OK, let's go ahead then. Thanks, uploaded and ACCEPTED. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On dom, mag 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: For reference last time took 2 months. I'll be doing my best to make it happen faster this time. If help is needed I can lend a hand. Cheers signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Sun, May 11, 2014 at 4:53 PM, Alessandro Ghedini gh...@debian.org wrote: On dom, mag 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: For reference last time took 2 months. I'll be doing my best to make it happen faster this time. If help is needed I can lend a hand. Absolutely. Please help with fixing these open RC issues in unstable: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote: When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
Hi Reinhard, 2014-03-01 17:01 GMT+01:00 Reinhard Tartler siret...@gmail.com: On Tue, Feb 18, 2014 at 4:48 PM, Moritz Mühlenhoff j...@inutil.org wrote: I made a rebuild and the transitions isn't ready to go at all. IMO the API changes are far too agressive; if 2/3 of all packages in the archive FTBFS, the affected APIs are clearly not that deprecated. I can understand the removal of ill-designed functions if it helps to streamline/robustify the code, but e.g. the removal of CODEC_ID* causes lots of churn for no measurable benefit. As Anton points out, the API changes are agressive, but done for good reason, most of which are documented in the transition guide. It is a wiki and will be extended as necessary. The CODEC_ID issue is indeed annoying, but kinda critical for C++ applications. Also note that the new names are supported even in debian/stable, so there is really no need for backwards compatibility here. Anyway, now two weeks after, I think things look much better now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org Most packages have patches readily available or need a new upstream version. Note that more and more packages require libav10 to build, and are held back in experimental for this reason. The todo list of bugs without a patch is also shrinking rapidly: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org;exclude=tags%3Apatch%2C+fixed-upstream From the velocity of how fast packages are being patched, I think we are in a rather good position to start this transition. When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#739079: transition: libav10
On Tue, Feb 18, 2014 at 4:48 PM, Moritz Mühlenhoff j...@inutil.org wrote: I made a rebuild and the transitions isn't ready to go at all. IMO the API changes are far too agressive; if 2/3 of all packages in the archive FTBFS, the affected APIs are clearly not that deprecated. I can understand the removal of ill-designed functions if it helps to streamline/robustify the code, but e.g. the removal of CODEC_ID* causes lots of churn for no measurable benefit. As Anton points out, the API changes are agressive, but done for good reason, most of which are documented in the transition guide. It is a wiki and will be extended as necessary. The CODEC_ID issue is indeed annoying, but kinda critical for C++ applications. Also note that the new names are supported even in debian/stable, so there is really no need for backwards compatibility here. Anyway, now two weeks after, I think things look much better now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org Most packages have patches readily available or need a new upstream version. Note that more and more packages require libav10 to build, and are held back in experimental for this reason. The todo list of bugs without a patch is also shrinking rapidly: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org;exclude=tags%3Apatch%2C+fixed-upstream From the velocity of how fast packages are being patched, I think we are in a rather good position to start this transition. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#739079: transition: libav10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We have a new libav transition pending. Libav 10 is prepared in debian/experimental, and I've started to build packges against this new version; in fact, more or more packages require Libav 10 and the new APIs it provides. Unfortunately, this new release does break a number of packages in the debian archive. At upstream, we are concerned about this and have conducted a survey about the fallout here: https://etherpad.mozilla.org/mnrZI5XlxP Most projects have been fixed upstream already, some other are rather easy to fix (e.g., simple renames such as CODEC_ID - AV_CODEC_ID, etc.). In order to help with porting, Libav provides a migration guide here: https://wiki.libav.org/Migration/10 I sincerly do hope that this libav10 transition will not be as painful as libav9, but we do have a number of undermaintained packages in the archive that require upstream work. For those, I'd suggest to be a bit more aggressive with removing them from testing for the sake of having this transition done more quickly. Thanks for your assistance. Ben file: title = libav; is_affected = .depends ~ /lib(avcodec|avformat|avutil|device|filter)-dev/ is_good = .depends ~ /lib(avcodec55|avformat55|avutil53|device54|filter4)/ is_bad = .depends ~ /lib(avcodec54|avformat54|avutil52|device53|filter3)/ -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-15-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
