Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
On 04/08/2014 02:04 PM, Mark Brown wrote: On Tue, Apr 08, 2014 at 01:41:38AM +0200, John Paul Adrian Glaubitz wrote: This bug is still present in the current version of xemacs21 in the archives, therefore re-opening. You've reopened several bugs, have you verified all of them are actually present? Yes, I have verified all of them. Bugs which I couldn't verify were not opened, I skipped them. I still think, however, that most of the bugs that were closed with the removal are still present but I haven't managed to skim through all of them yet. In particular, xemacs21 still hasn't properly made the libpng transition, the piuparts bug which showed xemacs21-nomule removing files which belong to xemacs21-support is still present and several other issues in the control file have to be fixed. Please, for the sake of Debian's quality, re-open all bugs which have not been fixed or have the package removed from testing. xemacs21 should not be released under these circumstances. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
On Tue, Apr 08, 2014 at 01:41:38AM +0200, John Paul Adrian Glaubitz wrote: This bug is still present in the current version of xemacs21 in the archives, therefore re-opening. You've reopened several bugs, have you verified all of them are actually present? signature.asc Description: Digital signature
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
On Tue, Apr 08, 2014 at 02:10:30PM +0200, John Paul Adrian Glaubitz wrote: In particular, xemacs21 still hasn't properly made the libpng transition, the piuparts bug which showed xemacs21-nomule removing files which belong to xemacs21-support is still present and several other issues in the control file have to be fixed. 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? I guess you might be thinking of stuff like the patch system which is definitely annoying but isn't really a control file thing? Please, for the sake of Debian's quality, re-open all bugs which have not been fixed or have the package removed from testing. 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. 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 (which TBH looks to have been present for something like a decade without anyone caring outside of explicit testing). signature.asc Description: Digital signature
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
On Tue, Apr 08, 2014 at 01:57:50PM +0100, Mark Brown wrote: I guess you might be thinking of stuff like the patch system which is definitely annoying but isn't really a control file thing? Oh, actually I did fix the patch system but left the build dep hanging. Ho hum. signature.asc Description: Digital signature
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
Hi! On 04/08/2014 02:57 PM, Mark Brown wrote: On Tue, Apr 08, 2014 at 02:10:30PM +0200, John Paul Adrian Glaubitz wrote: In particular, xemacs21 still hasn't properly made the libpng transition, the piuparts bug which showed xemacs21-nomule removing files which belong to xemacs21-support is still present and several other issues in the control file have to be fixed. 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. Further things I can find: - standards version is still 3.8.4 - package still uses dpatch - debhelper version is 5 - missing Vcs-* fields - missing homepage fields Many of these issues are reflected in the lintian report [1]. Running lintian locally with -i -E -I --pedantic options will probably reveal even more. Please, for the sake of Debian's quality, re-open all bugs which have not been fixed or have the package removed from testing. 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? 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. (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. 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. Adrian [1] http://lintian.debian.org/maintainer/broo...@debian.org.html#xemacs21 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589138 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542492 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
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
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
This bug is still present in the current version of xemacs21 in the archives, therefore re-opening. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696146: xemacs21-nomule, xemacs21-mule-canna-wnn: prerm deletes files owned by xemacs21-support: /usr/lib/xemacs-21.4.22/{etc, lisp}
Package: xemacs21-nomule,xemacs21-mule-canna-wnn Version: 21.4.22-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package removes files that were installed by another package. The removed files were already present before the package was installed, they may have been shipped or created by a dependency. From the attached log (scroll to the bottom...): 0m28.2s ERROR: FAIL: After purging files have disappeared: /usr/lib/xemacs-21.4.22/etc - /usr/share/xemacs-21.4.22/etc owned by: xemacs21-support /usr/lib/xemacs-21.4.22/lisp - /usr/share/xemacs-21.4.22/lisp owned by: xemacs21-support The prerm contains if [ -L /usr/lib/xemacs-21.4.22/etc ]; then rm -f /usr/lib/xemacs-21.4.22/etc fi if [ -L /usr/lib/xemacs-21.4.22/lisp ]; then rm -f /usr/lib/xemacs-21.4.22/lisp fi cheers, Andreas xemacs21-nomule_21.4.22-4+b1.log.gz Description: GNU Zip compressed data
