On Mon, May 26, 2014 at 05:12:48PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2014-05-26 15:14 GMT+01:00 Ron <r...@debian.org>:
> >
> > Hi Manuel,
> >
> > 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.
Ok, just checking because I didn't know which port in particular you were
blocked on here, and it would have been silly to push something out that
didn't actually help with that. (if for instance you were still using a
patched autotools that hadn't yet been upstreamed and/or uploaded to sid)
> 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.
Yes, I'm familiar with the drill for what usually needs updating to
kick off a new arch. I'm just of the school that considers those
things to be part of the tested source release, and that updating
them constitutes making a new source release, which will once again
need testing before it can be released.
> 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).
Well it's certainly always going to take much longer for upstream to
do that if nobody ever tells them about it ...
But that is kind of exactly my point, for some of these packages it
will be a trigger to make a real new upstream release, for others we
may just re-roll the existing release with a regenerated build system
as a new point release.
Which is why I asked about timelines for when this might really become
a bottleneck for proceeding with getting the port(s) that you care about
into Debian.
As much as I'm generally happy enough with the view of Debian being the
center of the universe, most projects that I'm involved with would also
like their stuff to build everywhere else too, so hiding the need for
this under a debian-specific kludge isn't really doing our part to
contribute back to them in the spirit that I think we ought to be.
> 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.
I've done lots of crazy things before that I escaped from without a scratch
too. I've also been burned by newer autotools introducing subtle bugs with
some change in behaviour. I'm not terribly interested in wasting another
week of my life when someone reports an obscure bug that nobody else can
reproduce when that is so easy to avoid completely.
> If you prefer to do it in some other way, it's fine as well, but it
> will require refreshing every now and then.
Yes, but that happens at about the right intervals for having a careful
look at what has changed since it was last updated, and fixing anything
that is shaken out by newer toolchains. Whether that be warnings from
the compiler, or warnings from autotools about deprecated constructs
that will vanish in some subsequent version.
For solidly stable software, that isn't already being updated regularly
in any case, I consider this a feature.
> 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.
Ugh, no. Seriously. Creating a new source release with a freshly
generated build system is not rocket science. We don't need crazy
hacks to do this. You just make a new release.
> I can provide a patch for your other packages, please tell me if you
> want them,
Nah, I don't need a patch for this. I just need to have a chat with the
affected upstreams about whether we have something new to push out, or
whether we'll just reroll a point release with the build updates.
If you have a definite list of the packages of mine that you're stuck
behind, that will help me not miss any, (or know for sure what version
of autoconf/libtool added the support you need) - but otherwise I can
probably figure that out too.
> 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.
libogg might have a few new upstream things that will be worth doing a
new release for. I'll check on that.
> Since arm64 hardware cannot be purchased yet (the porters are hired by
> the company behind it to create the Debian port),
Most or all of mine should already be ok for arm64, it's only things
added since then which are still on the next event horizon.
> One has to be able to build the packages before being able to test
> them.
Yes, but running autoreconf in the source tree before building it
isn't orbital mechanics. Worst case you're going to get some bloat
in the diff.gz for the ported package. Best case you're going to
get some nice warnings about things that need updating which can be
reported. In both cases you can be pretty sure that nobody has yet
beaten you to building it for your new port, and that you ought to
be a little more attentive than usual when inspecting the result.
> 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.
Personally, I don't consider paying a bit of attention to a brand new
build, with untested source, on a brand new architecture to be a waste
of time. It's hardly unusual for interesting things to shake out on
them. And if you don't have time to do that personally, then maybe
what we need is better tools, and more scalable ways to get attentive
maintainers access to ports in the early bootstrap stages - rather
than filing bugs about automating away things that actually do need
some sort of informed human attention more times than not.
"It seems to work ok" is not the same as "there's some interesting
warnings here that someone ought to look at". I don't think it is
good value for our efforts for the latter to be completely ignored
in pursuit of the former. And so far just about every bug I've
ever had which said "please add dh_auto_something" has done exactly
that. I'm not asking you to care about fixing those, I'm just
pointing out that taking away the warning I get about them currently
so that I can care about them also comes with a cost.
> Many of the packages have comprehensive test suits that go a long way
> to ensure that they work fine.
neither libogg, nor opus-tools do.
(though libopus has a pretty good one)
patches welcome if you want to fix that! :)
> 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.
Sure, that's why it's called bootstrapping.
If you give me a heads up, with a definite timeline, about known things
that will need to happen (like updated config.{guess,sub}), then that
is usually easily manageable, and will usually result in a couple of
other interesting things getting fixed along the way too.
But if you tell me there is this magic thing I can do, that means I'll
never ever again have to care about new ports or things changing in the
future ... then all I can really do is grin and chuckle, and think of
the foolish things that I once believed were true too :)
I'm all for things that will make bootstrapping new ports better and
easier, but I don't believe that 'hiding' problems from the package
maintainers and upstream developers is really one of them.
Anyhow, I'll touch base with the upstreams for anything that needs
updating here, and push some updates out shortly. If there is anything
you're blocked on more urgently than that, you really can just copy in
the config.* or re-run autoreconf in them -- which should be a lot
quicker and easier than rewriting the debian packaging to do it for
you in each of them.
Best,
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
