On Mon, May 26, 2014 at 10:29:20PM +0100, Manuel A. Fernandez Montecelo wrote: > 2014-05-26 20:09 GMT+01:00 Ron <r...@debian.org>: > > > > 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. > > 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
I'm pretty sure that one isn't terribly interesting for the new ports in question here, and it's essentially been obsoleted by the w64 toolchain now anyway and living on borrowed time before its complete removal. You can fairly safely blacklist it for new ports. > 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. That's not a *timeline* for when this needs to be in sid. It's a todo list. Many of these packages will already naturally get an update which makes this no longer a problem, long before these ports are ready to be added to the buildd's tracking sid. If you can't give me an even rough date for when you expect that to happen, I can only assume it is still "a long way into the future". ... and so we have plenty of time to wait for the next actually planned update of them. and to deal with other actually urgent things that are on a known and short deadline. > If you don't like the approach, you will then better start to convince > the rest of Debian developers, Anyone who needs convincing that one size fits all is a poor answer to just about any problem can argue with someone else. There are plenty of actually soluble problems that need that time more urgently. > > 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 That's not a list of the packages holding up your port. I know how to manually check them all myself - I was asking if you had already done that, and if you had to share that information. If you haven't that's fine, I have a fair idea which a new port will need before the others. > > 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. You're still missing the point. You're saying "I don't care about the potential for other problems in the package so long as it seems to build on my new port". I'm telling you that there are maintainers and upstreams who very much do care about those things. And that saying "Don't worry about that" to them, or worse, hiding from them the normal cues to learn about that, is counterproductive in the long run. > Only when we are past that point is when we can start paying attention > to autoconf warnings or real errors, if any. I'm still waiting to receive *any* of the patches I was promised by porters for kludging things to assist problems with their port. I don't think I'm going to hold my breath for this to actually happen. If things aren't fixed properly when they first come to people's attention as an actual problem, they're unlikely to be revisited any time soon again once they are Somebody Else's Problem. I'd much rather do them right the first time than throw them on the pile and wait for the bonfire to come. > 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. With any long term stable software, it's a problem of bitrot. The arrival of new architectures are a good metronome for checking for that, and fixing things while they still typically are easy to fix. I'm trying to explain to you that removing that act from the process is like saying "It's ok, I only eat apples now, so I never need to brush my teeth anymore". Software still needs both if it's to remain healthy. If the current 'best practice' of porting new architectures doesn't account for that then maybe you need to think about what a better practice might be. > > 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: And I didn't claim to be quoting you. It doesn't take a lot of searching though to see that the history of people proposing these sort of "look ma, no maintainer needed" changes is invariably followed by the history of them saying "oh wait, no - if you just do this *other* thing we won't need you to maintain things anymore ..." All I'm explaining is that *none* of these things are an adequate replacement for someone actually familiar with the software actually doing periodic QA on it. And for software that isn't otherwise changing, these sort of events are often the only thing that prompts that to get a timeslice in otherwise full and busy schedules. Anyhow, we appear to be going in circles here. You seem to be trying to convince me that one problem, and one solution to it, trumps all others, and I seem to be failing to convey the experience of years of frontline software development and delivery which says the big picture is actually much, much, larger than that. So I'll just reiterate the one thing that we do care about in common. If you give me a precise list of the things that will block you from adding your port to sid, and the date that is expected to become a hard blocker, then I'll make sure they don't block you by that date. Otherwise, in the meantime I only have the natural schedule of those packages to work to, and you can still always trivially tweak them locally, without needing to change anything about the packaging, to get your port into a state to be ready for that. Since you've felt it was now urgent enough to prod, I'll get to at least the core ones as soon as I can coordinate with the upstreams about the best option for a new version of them - but do keep in mind the above for future ports you might do. You'll save more time and get better results by coordinating with people about when you need things than you will by trying to take shortcuts around them. I do believe we both want the same thing here :) Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
