On Tue, Apr 08, 2014 at 03:25:30PM +0200, John Paul Adrian Glaubitz wrote: > On 04/08/2014 02:57 PM, Mark Brown wrote:
> > Could you be more specific as to what you believe the issues in the > > control file are? Is it just the hard coded architectures thing, that's > > the only reported issue and there's nothing terribly obvious to > > inspection? > xmeacs21 is still missing the libpng transition which is something very > important you should have done with the first upload. Frankly I just didn't see the bug because it was buried in a list of other closed non-RC bugs; the first priority with the initial upload was to close all the RC issues (the symlink one was obviously missed, that was a mistake). I've now uploaded a fix for that and a few other things. > Further things I can find: > - standards version is still 3.8.4 Right, but I'm not sure there's any actual changes to go with that - I've not been through the list. It's useful to do the check every once in a while but it's hardly critical stuff, the overwhelming majority of standards version updates are noops. > - package still uses dpatch It doesn't actually use it, that was fixed in the initial upload - I just forgot to remove the build dep when I moved over. Now gone. > - debhelper version is 5 That's not a control file issue really; that will go away when the package stops autogenerating files during the build (or at least does so in a more controlled fashion). > - missing Vcs-* fields There's nothing to put in them - the package isn't in version control yet. I've been experimenting with what to use, dgit looks interesting there, and the autogeneration is annoying. > - missing homepage fields Yeah, should do that. This is the only one with a user visible impact. > > There doesn't seem to be any particularly useful way of discovering what > > they might be, and I rather suspect that 90% of them are just never > > going to be looked at usefully anyway - there's no point in having so > > many old things nobody cares about floating around and obscuring the > > listings, it's a similar problem to things like KDE. > There are at least two bugs which result in xemacs21 crashing or > freezing [2] [3]. Do you really want people to continue using > xemacs21 knowing that these issues exist? I think most users don't care; they're definite bugs but they're on the edges of the functionality not in the mainstream. Yes, they should be fixed but saying that people need to stop using the program when they don't use that functionality isn't constructive. > >> xemacs21 should not be released under these circumstances. > > That seems like a substantial overreaction, we only have the one RC > > issue that I wasn't able to find in the closed bugs for some reason > I am having trouble believing that. It took me around half an hour to > dig up all these bugs. xemacs21 was accepted by the FTP team under > the premise that you would take proper care of the package and > addressing those issues, yet the vast majority of them are still > present. My goal here is to keep the packaging reasonably modern and avoid disrupting anything else so people can continue to use the program and it doesn't get in the way; unfortunately there's quite a bit of cruft to unpick which isn't helping make progress as fast as I'd like. Fixing Bill's circular dependency thing will help a lot, aside from the symlink issue it's probably the most urgent thing (and AFAICT the circularity is half the reason the symlink bug exists). The libpng transition and the symlink removal definitely need to be fixed urgently, no question about that - I just hadn't been aware of either issue. Like I say libpng is already done. > > (which TBH looks to have been present for something like a decade > > without anyone caring outside of explicit testing). > Just because a bug has been there for a long time doesn't mean it > shouldn't be fixed. Sure, of course - but it does impact the urgency. > We have high quality standards in Debian and I am working very hard to > keep these standards up. Packages like xemacs21 which slip through > the testing make us look bad. These issues are there and the bugs should > therefore still be open and the high severity should prevent xemacs21 > from entering testing. The only bug that's RC is the one with the symlink cleanup and like I say I agree that is RC. For the rest of it my call would be that while they should be fixed having the program available is useful enough to keep it around. I'm not saying they're irrelevant, I'm just saying let's keep things in proportion.
signature.asc
Description: Digital signature
