Hi Manuel, On Sat, May 24, 2014 at 05:34:42PM +0100, Manuel A. Fernandez Montecelo wrote: > Hi, > > I plan to upload a NMU to fix this bug. It's pretty straightforward > and it's affecting some ports being prepared for Debian right now > (e.g. OpenRISC/or1k, ppc64el) and also it will solve the issue for new > arches in the future.
Can you confirm which of these ports are currently actually in progress for Debian, and whether or not they all already have the necessary support in sid autoconf/libtool? OpenRISC still isn't listed on the debian ports page (though I'm aware there was some interest in it), and last time I asked around nobody could confirm there was actually a Debian ppc64el port going to happen (only that ubuntu was doing one). > I plan to upload NMUs as well for other opus tools and other packages > that you maintain, as libogg that I told you a few days ago. These > packages are preventing hundreds or reverse build-dependencies to > build cleanly in new arches, and thus causing us to do a lot of dull > manual work. I'd much prefer that they be updated, and tested, and confirmed to work correctly with a sufficiently new version of autotools, which can then be used everywhere, including for backports. Randomly generating them, with a random version of those tools just moves confusing and difficult failures, and the dull manual work of dealing with that, onto somebody else - rather than giving everybody a tested and known working build system. I'm not unsympathetic to the work of porters, but I'm also keenly aware that many of these packages also get rebuilt by people doing back (or forward) ports of them, and I firmly believe in the importance of that remaining as painless as it so far has been too. > For example, there are 18 reverse build-deps of libopus-dev in main, > including libav, which in turn has 86 reverse build-depends on main > for libavcodec-dev alone; etc etc. Worse is the case of libogg-dev, > which has 77 direct reverse build-depends in main. I'm happy to update anything which needs it if these ports are actually now really in progress for Debian. For many of them it's just a case of balancing the timing of new upstream releases with actual work on the ports really being started, since I always pull and test the latest autotools boilerplate for those, and send patches upstream where things have been deprecated or need modifying to work correctly with them (which in the last few autotools releases has become a more frequent necessity again). If you can give me a concrete list of what's actually holding you up and for which ports (or somewhere I can look at to see that), then I'll expedite updates of the things that are actually bottlenecks. If you can confirm that they actually build *and work* on those new ports without needing other mods sent upstream then even better. Handwaving about "some ports", and packages like opus-tools, which is very much a leaf, and has only one other leaf that *suggests* it, isn't as helpful as giving actual specifics, and actual timelines for when things are going to be bottlenecks. There is no magic "this will fix everything forever" that trumps doing actual testing - and the whole point of packages having maintainers is so that the testing can be done. There's more to building a distro than "it seems to build from source. ship it." Cheers, Ron -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
