2014-05-26 15:14 GMT+01:00 Ron <[email protected]>:
>
> 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?
As far as I know, all of them have support with autoconf/libtool.
The issue with packages for which bugs "dh-autoreconf" bugs are filled
(close to a thousand now) is because packages usually ship
config.{guess,sub} files locally, instead of using the ones from
autoconf upstream, and a similar case with libtool. It is these local
files that packages ship which are out of date, and lack the
definitions necessary for new architectures.
So the only solutions are to either use dh-autoreconf, patching the
local files or new upstreams of these packages which are not ready
(but sometimes it takes years for upstream to update these files).
> 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).
debian-ports has space problems, that's why these ports (mips64el and
OpenRISC/or1k at least) are not yet in debian-ports machine. I think
that ppc64el is in the same situation (
https://wiki.debian.org/ppc64el/ ). I could not find any reference to
this recently in public mailing lists, but basically this is the same
situation as in the extract below from last year.
https://lists.debian.org/debian-devel/2013/12/msg00044.html
"I have been contacted by Wookey earlier this year about adding arm64
port to debian-ports, and everything is now ready. I am still waiting
for the buildds email addresses and ssh key though.
It is already possible to upload packages, as space is not an issue on
debian-ports since we moved to the machine offered by DSA. That said
adding a new architecture is a problem (I had to add mips64el on the
waiting list recently), as we are lacking CPU and disk I/O. Remember we
have about 2/3 of the architectures in the official Debian archive, on
a single virtual machine."
For or1k, we have roughly 2/3rds of the "any" packages built already
(naturally, "arch: all" are also valid), more than 6600, and building
new ones as they are uploaded to Debian:
http://wannabuild.cmd.nu/architecture.php?a=or1k&suite=sid
>> 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.
As I explained above, it's not a special version of autotools, it's
basically updating config.{guess,sub} shipped in the .orig.tar, and in
some cases libtool local files, but always with the version in Debian
-- not a strange one.
>> 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).
I believe that using dh-autoreconf is the best way to do that, I did
that with my packages using autotools since last year (mostly SDL
ones, the most popular with ~65% popcon, and cwidget which aptitude
uses at 99%), and have been pretty happy since, zero problems.
People have been discussing lately in debian-devel though that perhaps
it's better to use mechanisms akin to dh-autoreconf either forcibly or
at least by default.
https://lists.debian.org/debian-devel/2014/04/msg00445.html
https://lists.debian.org/debian-devel/2014/04/msg00449.html
If you prefer to do it in some other way, it's fine as well, but it
will require refreshing every now and then. One way to do that is to
add patches to ltmain.sh and config.{guess,sub}, as you would add
patches to any other file in the .orig.tar. The patches tend to be
huge and ugly, but they work. I didn't do anything like that before,
so I cannot guide you there.
This is the patch that I created for libogg, in the case that it
serves you (attached): libogg_1.3.1-1.1.dsc.patch
I can provide a patch for your other packages, please tell me if you
want them, but the URL provided previously explain what's needed and
it's quite straightforward (specially if you move to dh compat 9):
https://wiki.debian.org/qa.debian.org/FTBFS
> 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.
I mistook opus and opus-tools (I don't know yet if opus also needs
patching), but I told you already, that for example this is a blocker
(only in main, not counting contrib or non-free):
Found a total of 77 reverse build-depend(s) for libogg-dev.
These 77 r-b-deps are direct dependencies, which in turn have another
r-b-deps themselves, so they account for a big part of the archive not
being able to build.
Since arm64 hardware cannot be purchased yet (the porters are hired by
the company behind it to create the Debian port), similar with
mips64el, and OpenRISC/or1k has to be synthetised in a FPGA, there's
no easy way to have access to the hardware yet. You can use qemu to
emulate some of those though.
I checked with a conversion tool using libogg and the resulting file
sounds the same, so at least it's working fine for that.
> 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."
One has to be able to build the packages before being able to test
them. Almost one thousand bugs have been filed already because we
cannot build packages for these (at least) 4 new arches that we're
bootstrapping at the same time. The time that we are wasting doing
this could be better spent elsewhere, like testing, as you say.
Many of the packages have comprehensive test suits that go a long way
to ensure that they work fine.
Sometimes, packages built don't work because we found that there are
problems in libc, gcc or others... but's it's a chicken and egg
problem really, without packages being able to build cleanly first we
cannot find if they actually work and other problems.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
diff -u libogg-1.3.1/debian/rules libogg-1.3.1/debian/rules
--- libogg-1.3.1/debian/rules
+++ libogg-1.3.1/debian/rules
@@ -49,12 +49,14 @@
dh_testroot
$(RM) build-stamp install-stamp
$(RM) -r $(objdir)
+ dh_autoreconf_clean
dh_clean
$(objdir)/config.status: configure
dh_testdir
mkdir -p $(objdir)
+ dh_autoreconf
cd $(objdir) && ../configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
diff -u libogg-1.3.1/debian/control libogg-1.3.1/debian/control
--- libogg-1.3.1/debian/control
+++ libogg-1.3.1/debian/control
@@ -2,7 +2,7 @@
Section: libs
Priority: optional
Maintainer: Ron Lee <[email protected]>
-Build-Depends: debhelper (>= 8.1.3)
+Build-Depends: debhelper (>= 8.1.3), dh-autoreconf
Standards-Version: 3.9.4.0
Homepage: http://xiph.org/ogg/
Vcs-Git: git://git.debian.org/users/ron/libogg.git
diff -u libogg-1.3.1/debian/changelog libogg-1.3.1/debian/changelog
--- libogg-1.3.1/debian/changelog
+++ libogg-1.3.1/debian/changelog
@@ -1,3 +1,11 @@
+libogg (1.3.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Bootstrap for or1k by updating config.{guess,sub} at build time
+ using dh-autoreconf
+
+ -- Manuel A. Fernandez Montecelo <[email protected]> Sat, 29 Mar 2014 13:15:37 +0000
+
libogg (1.3.1-1) unstable; urgency=low
* Fix the hardening LDFLAGS.
