2014-05-26 20:09 GMT+01:00 Ron <r...@debian.org>: >> 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.
The problem that we are facing with hundreds of packages is that the builds stop completely because the machine is not recognised by the script "configure": Invalid configuration `or1k-linux-gnu': machine `or1k' not recognized configure: error: /bin/bash ../config.sub or1k-linux-gnu failed With arm64 and one of your packages: http://buildd.debian-ports.org/status/fetch.php?pkg=mingw32-binutils&arch=arm64&ver=2.20-0.2&stamp=1397413026 As you probably know, config.{guess,sub} are kind of ancillary files copied verbatim from autotools into the source package to detect the machine/OS/toolchain. I don't know if all, but most upstreams don't pay much attention to it and only update them every now and then, or when asked explicitly, and updating them does not change behaviour in autoconf other than allowing to compile in architectures that the package previously didn't know about. So, this is not a problem with the rest of autoconf, just with these particular files. Updating them without touching the packages individually can be achieved with autotools-dev and without autoreconf, but ppc64el needs updating ltmain.sh and libtool macros (not sure about the details, I don't work with it) and so dh-autoreconf was recommended. Anyway, I am not going to discuss here the pros and cons, much less in this bug report. This was discussed already in debian-devel@ and elsewhere, like the wiki entry that I pointed initially, you can take the discussion there if you wish. The timelines is: the sooner that new architectures can get libogg compiling cleanly the better, so the reverse build-deps are also compiled, and then use time to fix other integration issues and be ready for Jessie or Jessie+1 (or do some kind of unofficial release in the meantime). That's why we've filed bug reports a while ago, they became blockers previous to that point. >> 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 don't like the approach, you will then better start to convince the rest of Debian developers, because according to the opinions in the thread that I pointed things are moving in this way with most packages using autotools (regenerating everything needed from configure.ac with the latest autoconf), and it might very well become policy at some point. And as I pointed previously, there are hundreds of bugs filed to that effect, 40% or so already addressed: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autoreconf;users=debian-de...@lists.debian.org > 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 pointed initially to the place where it explains which packages are problematic: https://wiki.debian.org/qa.debian.org/FTBFS#A2014-01-21_using_dh-autoreconf_during_the_build "To check that the libtool change was picked up, grep the regenerated files for the powerpc64le string. To check that the config.* changes were picked up, grep for the aarch64-linux-gnu string." Please check also for the string "or1k" and "mips64el". >> 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. The problem is not to ignore autoconf warnings, the problem is that the builds stop completely because the machine is not recognised by the script "configure", as I explained you above. Only when we are past that point is when we can start paying attention to autoconf warnings or real errors, if any. It's not a problem of using newer autoconf per se, it's that config.{guess,sub} need updating to know that the machine architecture exists. > 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 didn't say what you claim, what I said in the initial email is: "Please, apply this patch (or tweak it, or create your own if you prefer) and include it in your next uploads, in order to keep these ancillary files up to date in the future without maintainer intervention, and make easier the task of introducing new ports in Debian." This is exact and true. I didn't claim that it will solve all problems, it will solve the specific problem of machine/OS/toolchain detection by updating these files, and that's what the tool does. Adding a build-depend and a couple of word in rules is hardly a lot of work, and lots of people are doing it this way, but if you prefer to do it in another way, it's up to you. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
