On Thu, Oct 17, 2013 at 11:48:46AM +0100, Colin Watson wrote: > On Thu, Oct 17, 2013 at 08:46:27PM +1030, Ron wrote: > > I'm not unsympathetic to the work and pain of porters bootstrapping a new > > arch, but any 'solution' that is Debian-specific, isn't really a solution > > at all, it's just an SEP field. > > There are other distributions who update config.guess/config.sub in > their packaging too. I would say that *both* upstream and distributions > need to handle this, realistically; but I don't think the lack of > upstream handling it should hold back distributions.
Sure, but there was no lack of upstream handling it here. I can only speak of what is optimal for _this_ particular package, and knowing about this sooner rather than later is definitely the global optimum in this case, regardless of who spots it first. There is no one-size-fits-all answer here that doesn't just push the very same problem onto somebody else. I don't really want to trot out the old "we will not hide problems" chestnut, but reporting upstream issues to upstream is one of the clear hallmarks of being a good and effective downstream user. > > If you really want to fix this for new ports, maybe we need a tool to scan > > the archives and report these things before they become the bottleneck for > > porting work. > > That just moves the manual work earlier (filing bugs, discussing them > with maintainers, and NMUing when they ignore them is still quite a bit > of manual work when you compare it with having all the packages just > update themselves automatically); it isn't a fix. If there was no manual work needed for porting, then we wouldn't need porters. This isn't much different from other toolchain updates. If nobody reports the problem it will never get noticed to be fixed. Which means someone else will hit it and still have to do the same work. The distro is a perfect place for automated scanning of this sort of thing, and automated filing of reports if the check is sufficiently certain, and the need for a fix is sufficiently necessary. In this case, you haven't been ignored, you got a response within a few hours, and would have had a fix just as fast if it wasn't actually a false positive related to the way you 'manually' did this check. > > Lintian does already have a "too old" check -- but it doesn't > > actually bark about what would _really_ break (which 90% of the time is > > something utterly obscure that Debian won't run on anyway). > > Um, well. As a point of information: > > Tag: outdated-autotools-helper-file > Severity: normal > Certainty: possible > Info: The referenced file has a time stamp older than April of 2012 and the > package does not build-depend on autotools-dev or automake and therefore > apparently does not update it. This usually means that the source > package will not build correctly on ARM64, for which a Debian port is > currently in progress, and may not support other newer architectures. Ah, I stand (happily) corrected :) I'd have sworn the previous time I looked at these they mostly turned out to be false positives. But this is one of those cases where I'm quite glad if I'm mistaken. Of course I wouldn't have seen this warning on the last upload, because this package didn't have that problem. > Lintian's threshold is generally only updated when there's a specific > relevant new port. It helps, but it's not good enough since many of the > problematic packages simply aren't uploaded at all often enough so their > maintainers tend not to notice; and I fundamentally disagree that "let's > source-upload half the archive" is a sensible way to handle new ports, > even if those uploads are spread out. Not enough people garden their > pages on lintian.debian.org routinely enough for this not to be a > horrendous pain for porters, and we still have the problem of MIA > maintainers. Yes, it's true that some packages require manual porting, > but those are statistically rare and often have other indicators (e.g. a > specific limitation in their Architecture field). Which is why I suggested maybe it could be used to actually file bug reports, well before they become 'important' blockers for porting work. Just like other toolchain updates do. In this case, a properly automated check would _not_ have had a false positive on this package, and would have saved us both time. And you could have known about it much more easily than attempting a build and waiting for it to fail. > > Anyhow, I'll close this one if you've confirmed the current package is > > ok, but I don't want you to think I don't care about your pain. On the > > contrary, I think we need a _better_ solution than what this patch does > > to lay the groundwork for common problems seen when porting new arches, > > and I'm pretty sure that for this specific problem, lintian already > > implements 99% of what you'd need. > > I'm a Lintian committer, albeit a somewhat dormant one; I respectfully > disagree that it can ever deal with this problem adequately. > > Still, at least some other maintainers are switching to autotools-dev in > response to my patches, so that's reducing the pain for the next time > round. I wasn't expecting to be able to persuade everyone. And I still don't want you to think that just because you haven't persuaded me that this is the best answer for this package that I don't care about the problem, or about making life for the porters as pleasant as possible without just rearranging the furniture on the paintanic. This discussion has alerted me to check what other packages I have that are currently spotted by lintian with this issue, and it looks like there are a few, so I'll try to work through those RSN, and let you take me off your "people I'll need to hound still to make this port happen" list :) Hopefully that is at least some consolation and tangibly real time saved! Cheers, Ron -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
