Bug#729289: Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
2013/11/12 Steven Chamberlain <steven@pyro.eu.org>:
>> The current cause of this blockage is actually
>> problems/delays in MIPS toolchain and bad timing.
>
> If you mean the delayed build of openscenegraph on mips, happening after
> libav9 transition started, I'm not sure that makes a difference because
> it would be stuck until rdepends are ready (and they're still not).
> libav9 transition started only a few days later so openscenegraph would
> have failed on *all* arches when binNMUd?
That's correct, I was trying to set the matter in perspective, and why
the breakage occured in OSG without us being notified by libav people.
I uploaded the last OSG package on ~8th of August, around which date
most buildds built it successfully. mips didn't try to build until
the 26th, when it failed to build for other reasons (buildd fault, not
the package), and the 29th when it failed to build due to the new
libav9 being there (it was uploaded in mid August).
We didn't have any warning in the BTS or by email of the libav9
affecting OSG, excep possibly the PTS, cannot remember. Even if we
had in the PTS, certainly nobody rebuilt OSG against the newer libav9
and tell us that it would break, offering help or suggesting patches
(before the breakage). So I only noticed this by the end of August
with #720816 after a archive-wide rebuild of all packages in sid
(amd64).
Granted, the archive is getting big and some of these packages are
big, but still we did that for our upgrade of OSG with our rdepends;
and I built not long ago ~450 pages with rdepends to libsdl to check
for possible breakages of important changes.
Which bring us to the following point:
>> 5) So as a summary and in short, having an open transition process is
>> not going to speed-up the transition [...]
>> (libcitygml didn't respond or upload for more than 3 months, for
>> example).
>
> Conversely, that's why I suggested having a tracker; having more eyes
> on the problem and making it easier to see what needs to happen.
So even when transition trackers are set up, as it was the case with
libav9 (just picking the example at hand, nothing particularly bad),
this doesn't help to avoid breakages, and libav maintainers were less
pro-active than us in warning rdepends.
Informing rdepends, sending patches and eventually NMUing if feasible
and maintainers inactive or removing from the archive (if the packages
are hopeless) are the things that can move things forward. So I still
don't think that having a tracker is not useful in our case (mostly
bureaucracy and a waste of time, IMO).
>> Since the transition requested already mentions libopenscenegraph100,
>> but 3.2.1 is not released, I think that it's actually more risky (or
>> prone to more delays) if to tie the current transition to these future
>> ones of OSG.
>
> ... the tracker will need updating with whatever you decide to aim for
> (99 or 100). I would think 99 is the quickest and safest resolution to
> the libav9 tangle. As Rebecca said, it implies another round of binNMUs
> as soon as 3.2.1 is uploaded. But IMHO that will be much easier and
> less urgent if nothing else is waiting on it by then.
>
> Are you decided that you are aiming for libopenscenegraph99 to migrate
> first?
A change in package names, such as libopenscenegraph99->100 or
libopenthreads to whatever SOVERSION, will force the package to go
through the new queue, so it's not the speediest of the routes.
OTOH there're many other packages, and much more important than OSG,
still pending to be built against libav9, so I don't think that this
is so urgent though, and also depends on what happens with 3.2.1.
We will discuss it and see what to do.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: