Bug#631110: cvs: package description adjustment may help user
Hi, On Fri, Jun 24, 2011 at 04:03:22PM +, Thorsten Glaser wrote: Osamu Aoki dixit: ... Also here, I said I will do something. Don’t rush me, please. As a user, non-optimal dependency is quite annoying. Thanks for changing this. I may have responded a bit too strong on some parts of your message. I am happy with what you did. Other suggestion are non-critical. I meant to help you promote your cvs-switchroot to gain more attention without causing negative effects etc. with concrete suggestion. You can pick what you like. As for /usr/bin/cvsbug, I have no idea it is used or not. It seems more of question for you if you want to get bug report via this as the way it is written. At least for the Debian package, it seems to be better to disable this while providing proper bug script so Debian BTS get good Hm. You might have a point there. information. You can find its documentation in /usr/share/doc/reportbug/README.developers.gz (You can use this script to ask user not to file wishlist request for pserver etc. to cut down on useless bug report.) Good idea! Please send a file ;-) I usually do not bother for this somewhat obscure part of Debian infrastructure for my package but I have seen others have used for some similar case as yours. It actually took me a while to find this doc which used to be in the bug package. I do not know what you wish to say... but since you asked, I can send an example. What do you think of adding /usr/share/bug/cvs/presubj file with something along --- pserver functionality is disabled intentionally by the maintainer due to its security implication. Even wishlist bug reports are not accepted. --- If you happen to worry library dependency, it may help adding /usr/share/bug/cvs/script file with something along --- #!/bin/sh /usr/bin/ldd /usr/bin/cvs 13 --- You can find many examples on your Debian system under /usr/share/bug/. Please note I am not asking to do these. Just FYI. One packaging FEATURE I did not agree was removal of old Debian changelog entries. There was never a removal, because these were never part of this cvs packaging. I mentioned I would completely replace the old packaging before I tool over cvs. This is from your perspective. I see no policy on this matter. I am not in position to request you to change this based on the policy. Please remember SC#4 Our priorities are our users and free software. At least you created an iffy user. I wonder what happened on all security fixes done between upstream release of 2006 and last Debian package before yours in 2008. This is completly off-topic from the original bug. Let's discuss separately later with cooler head. As for epoch, the Policy 5.6.12 Version states: | It is provided to allow mistakes in the version numbers of older Yes, there was a mistake along the way, and the epoch was raised from 1 to 2 by me. Blame me for that, but it cannot be undone now. Thus, this epoch should not be used lightly. *cough* http://debblog.philkern.de/2011/06/about-versions.html Certainly, these are abuse. Sigh... inside. If you kept old changelog, it is clear this was done in 2006 by Steve McIntyre. Support for bz2 was added to dpkg 1.10.24 in 2004 and bzip2 is a joke, redundant with xz, and re-compressing already-compressed files does not gain us anything. Furthermore, using tarball-in-tarball packaging was deprecared in 2009 or so. I got told off for that myself, and the “new” cvs package provides the source that’s used for compiling on dpkg-source -x, as many people wanted. So I would have needed to change the .orig.tar.gz already, anyway. Besides, the +real will go away with cvs 1.12.14 release. Good to hear your intent but GNU upstream seems to be very quiet. Let's hope someday, we see cvs 1.12.14 release. (FYI: Your assertion of bzip2 is a joke was surprise to me. If you said lzma, it made sense to me. Anyway, both lzma and xz suffix are still too new if you think of supporting backports in Debian and Ubuntu. But here, I think you are making judgement as the maintainer and I am happy with you holding this position.) I did not experiment or tested, but most likely, since dpkg-scanpackage put priority to package.bz2 over package.gz, you could have used and uploaded real 1.12.13.orig.tar.bz2 while building package with dpkg-buildpackage option -sa. No. That’s what I tried first. Since there was already a .orig file in the archive, the upload got rejected. https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog.diff?r1=1.14;r2=1.15 https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog#rev1.15 You tried package.gz and it did not work. I am talking package.bz2. Anyway, it is history now. Let's move on. While I like cvs being used, and useful feedback, I do not like to be told how to make my package. If you wanted to have changed the cvs package, there were months in which you could have
Bug#631110: cvs: package description adjustment may help user
Osamu Aoki dixit: If you happen to worry library dependency, it may help adding I don’t think so, at least not yet. I couldn’t use the information. Please remember SC#4 Our priorities are our users and free software. At least you created an iffy user. I wonder what happened on all security fixes done between upstream release of 2006 and last Debian package before yours in 2008. ① I’m a user, too. ② I’ve closed about half of the open bugs in cvs, all but one of the bugs reported in Launchpad, written new functionality, etc. when I took over this package; if I created one or two new prob‐ lems, this is a small price to pay – especially since these can be addressed later (i.e. now). ③ I don’t think there were any security related fixes. I remember looking through the patches applied to Debian’s cvs package and porting them over to MirBSD, when needed; testing there; writing documentation for these that were kept, and dropping these that were buggy. If you really wonder I can dig out the relevant info for you, but that doesn’t belong into this bugreport. Or you can take my word on it. ④ If you want to help… regarding point ②, most of the remaining bug reports need to be forwarded upstream (either can’t do in Debian what they want, or won’t do the decision to deviate from upstream) or closed (as done, unreproducible, etc). But I personally think http://qa.debian.org/data/bts/graphs/c/cvs.png shows a good trend. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (256 (275) bugs: 0 RC, 177 (192) IN, 79 (83) MW, 0 FP) ‣ src:dash (81 (89) bugs: 3 RC, 43 (46) IN, 35 (40) MW, 0 FP) ‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631110: cvs: package description adjustment may help user
Hi, I think there are some oversights and misunderstandings of the Debian procedure by the maintainer. Instead of arguing point-by-point, let me point out few helpful facts. We all are human and makes oversights. So please do not feel bad. Lintian is there to help maintainers to package better quality packages compliant to the Policy. If there is any discrepancy between them, we need to file a bug report on Lintian to fix Lintian with better heuristics. So you can not reject the Policy based request using Lintian as an excuse. But does Lintian really suggest to use recommends but rejects using suggests? I do not find it so. This is Lintian output: --- W: cvs source: debian-rules-missing-recommended-target build-arch W: cvs source: debian-rules-missing-recommended-target build-indep I: cvs: arch-dep-package-has-big-usr-share 3342kB 81% E: cvs: missing-dep-for-interpreter mksh = mksh (usr/bin/cvs-switchroot) O: cvs: csh-considered-harmful usr/share/cvs/contrib/sccs2rcs O: cvs: missing-dep-for-interpreter csh = tcsh | csh | c-shell (usr/share/cvs/contrib/sccs2rcs) --- If you use -i option or parse this log with lintian-info, you get full explanation for E: cvs:... as: --- E: cvs: missing-dep-for-interpreter mksh = mksh (usr/bin/cvs-switchroot) N: N: You used an interpreter for a script that is not in an essential N: package. In most cases, you will need to add a Dependency on the N: package that contains the interpreter. If the dependency is already N: present, please file a bug against Lintian with the details of your N: package so that its database can be updated. N: N: In some cases a weaker relationship, such as Suggests or Recommends, N: will be more appropriate. N: N: Severity: important, Certainty: possible N: --- At least with the latest Lintian, the resolution proposed is very clear and right. You can use either Suggests or Recommends. (You may have seen a different message with the version you used.) As you know, putting package in Recommends set them autoinstall for most reasonable package managers while putting it in Suggests does not. This is where we felt unexpected action for the very obscurely documented command. I made a test build while putting mksh in Suggests and confirmed that Lintian was happy with it (no ERROR like above). As for manpage, if you read its file content, it contains: --- .\ This is the man page for CVS. It is auto-generated from the .\ cvs.man.header, cvs.texinfo, cvs.man.footer files. Please make changes .\ there. A full copyright license notice may also be found in cvs.texinfo. --- So autogenerated is no excuse. You can fix doc/cvs.man.footer to get your cvs-switchroot listed there :-) As for /usr/bin/cvsbug, I have no idea it is used or not. It seems more of question for you if you want to get bug report via this as the way it is written. At least for the Debian package, it seems to be better to disable this while providing proper bug script so Debian BTS get good information. You can find its documentation in /usr/share/doc/reportbug/README.developers.gz (You can use this script to ask user not to file wishlist request for pserver etc. to cut down on useless bug report.) One packaging FEATURE I did not agree was removal of old Debian changelog entries. If you have included any of the patches generated in Debian as you mention, removing their contribution record seems not right for me. What is wrong to keep them so people know the history before your complete repackage. Please reconsider. As for epoch, the Policy 5.6.12 Version states: | It is provided to allow mistakes in the version numbers of older | versions of a package, and also a package's previous version numbering | schemes, to be left behind. Thus, this epoch should not be used lightly. The rationale to use new epoch should not be the local unpublished packaging history. Such things should be fixed before uploading package to the Debian. It is interesting to see that the old orig.tar.gz contained tar.bz2 inside. If you kept old changelog, it is clear this was done in 2006 by Steve McIntyre. Support for bz2 was added to dpkg 1.10.24 in 2004 and not so popular yet to use this functionality (maybe for backport concern etc.) in 2006. I did not experiment or tested, but most likely, since dpkg-scanpackage put priority to package.bz2 over package.gz, you could have used and uploaded real 1.12.13.orig.tar.bz2 while building package with dpkg-buildpackage option -sa. Then archive size bloat did not happen. So you may have have a clean package upload without non-standard +real (Just a thought... I know it is too late now). Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631110: cvs: package description adjustment may help user
Osamu Aoki dixit: Lintian is there to help maintainers to package better quality packages I use lintian all the time, thank you very much. I even used linda, back then. But does Lintian really suggest to use recommends but rejects using suggests? I do not find it so. This is Lintian output: […] At least with the latest Lintian, the resolution proposed is very clear and right. You can use either Suggests or Recommends. (You may have I said I need to re-check whether Suggests is enough. I never said that lintian doesn’t accept Suggests, I only said that lintian told me to put a dependency on it and I didn’t remember whether Suggests would be enough.See pine.bsm.4.64l.1106201407310.8...@herc.mirbsd.org: | lintian tells me that, if there is a script with #!/bin/mksh as | shebang, I must put that as sort of dependency. I#ll evaluate | whether Suggests is enough (as *buntu demoted it already). As you know, putting package in Recommends set them autoinstall for most reasonable package managers while putting it in Suggests does not. This I still think this is a mistake, and I run several hundred systems with 「APT::Install-Recommends 0;」 in apt.conf ☺ but yes, I know about this. I did not tell you off, I just told you I will re-check it when I next have time to work on the cvs package. Your additional input at this time was not required, because I already agreed – se‐ veral times in fact – that something will be changed. I made a test build while putting mksh in Suggests and confirmed that Lintian was happy with it (no ERROR like above). Why, thank you for testing this for me ;-) it will become Suggests then. So autogenerated is no excuse. You can fix doc/cvs.man.footer to get your cvs-switchroot listed there :-) See Message-ID: pine.bsm.4.64l.1106211459150.1...@herc.mirbsd.org | * add cvs-switchroot listed at the bottom of SEE ALSO in cvs manpage | | Hm. Will have a look at that at least. Also here, I said I will do something. Don’t rush me, please. As for /usr/bin/cvsbug, I have no idea it is used or not. It seems more of question for you if you want to get bug report via this as the way it is written. At least for the Debian package, it seems to be better to disable this while providing proper bug script so Debian BTS get good Hm. You might have a point there. information. You can find its documentation in /usr/share/doc/reportbug/README.developers.gz (You can use this script to ask user not to file wishlist request for pserver etc. to cut down on useless bug report.) Good idea! Please send a file ;-) One packaging FEATURE I did not agree was removal of old Debian changelog entries. There was never a removal, because these were never part of this cvs packaging. I mentioned I would completely replace the old packaging before I tool over cvs. As for epoch, the Policy 5.6.12 Version states: | It is provided to allow mistakes in the version numbers of older Yes, there was a mistake along the way, and the epoch was raised from 1 to 2 by me. Blame me for that, but it cannot be undone now. Thus, this epoch should not be used lightly. *cough* http://debblog.philkern.de/2011/06/about-versions.html It is interesting to see that the old orig.tar.gz contained tar.bz2 inside. If you kept old changelog, it is clear this was done in 2006 by Steve McIntyre. Support for bz2 was added to dpkg 1.10.24 in 2004 and bzip2 is a joke, redundant with xz, and re-compressing already-compressed files does not gain us anything. Furthermore, using tarball-in-tarball packaging was deprecared in 2009 or so. I got told off for that myself, and the “new” cvs package provides the source that’s used for compiling on dpkg-source -x, as many people wanted. So I would have needed to change the .orig.tar.gz already, anyway. Besides, the +real will go away with cvs 1.12.14 release. I did not experiment or tested, but most likely, since dpkg-scanpackage put priority to package.bz2 over package.gz, you could have used and uploaded real 1.12.13.orig.tar.bz2 while building package with dpkg-buildpackage option -sa. No. That’s what I tried first. Since there was already a .orig file in the archive, the upload got rejected. https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog.diff?r1=1.14;r2=1.15 https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog#rev1.15 While I like cvs being used, and useful feedback, I do not like to be told how to make my package. If you wanted to have changed the cvs package, there were months in which you could have taken it over. Also, when I said I was going to replace the packaging, I included a link, and there still was a large period before. At the current point in time, I am the maintainer of cvs, and my decisions stand. They may not always be popular, but they usually have reasons. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the
Bug#631110: cvs: package description adjustment may help user
Hi, I was surprised to see mksh in recommends. No wonder Steve felt as he did after long day. It is late night here too. I understand this is required by cvs-switchroot written by the package maintainer and he certainly uses and loves mksh specific commands such as array variables and print command which absolutely require mksh and can not be dash. (Command itself seems quite useful for some spacial purposes.) So, what should we do to avoid such surprise and negative reaction? Good communication is essential here. Let's see the fact. $ dpkg -L cvs | xargs -n1 file |grep executable /usr/share/cvs/contrib/cvs2vendor: POSIX shell script text executable /usr/share/cvs/contrib/rcs2log: POSIX shell script text executable /usr/share/cvs/contrib/descend.sh: POSIX shell script text executable /usr/share/cvs/contrib/log_accum: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/clmerge: a /usr/bin/perl script text executable /usr/share/cvs/contrib/log: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/newcvsroot: POSIX shell script text executable /usr/share/cvs/contrib/commit_prep: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/mfpipe: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/rcs2sccs.sh: POSIX shell script text executable /usr/share/cvs/contrib/cvs_acls: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/validate_repo: a /usr/bin/perl -w script text executable /usr/share/cvs/contrib/pvcs2rcs: a /usr/bin/perl script text executable /usr/share/cvs/contrib/rcs-to-cvs: POSIX shell script text executable /usr/share/cvs/contrib/sandbox_status: POSIX shell script text executable /usr/share/cvs/contrib/sccs2rcs: C shell script text executable /usr/share/cvs/contrib/debug_check_log: POSIX shell script text executable /usr/share/cvs/contrib/rcslock: a /usr/bin/perl -T script text executable /usr/share/cvs/contrib/cln_hist: a /usr/bin/perl script text executable /usr/bin/cvsbug: POSIX shell script text executable /usr/bin/cvs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped /usr/bin/cvs-switchroot: a /bin/mksh script text executable Since all /usr/share/cvs/contrib/* are not in command path, these may be considered non-essential commands. It is true that in order for 1/3 of real command of cvs package to function, mksh is required and qualify as recommend. But cvs-switchroot is not mentioned in cvs manpage while cvsbug is mentioned. So this cvs-switchroot is very obscure command much like ones in /usr/share/cvs/contrib/ written in Perl. Actually, commands in /usr/share/cvs/contrib/ are mentioned in cvs.txt.gz cvs.html FAQ.gz while cvs-switchroot is not mentioned elsewhere except changelog.Debian.gz. (Actually its description is confusing since cvs-switchroot comes from debian/cvs-switchroot and not from src/scripts/mnt-cvsroot as I see it packaged.) At least, cvs package is quite useful and functional without cvs-switchroot which almost no one can know of as the way it is included. The use of cvs-switchroot is rare. Thus, installing cvs package without functioning mksh is perfectly reasonable set up. Just lack of corner case functionality. Debian policy 7.2 points me to chose suggest. | Suggests | This is used to declare that one package may be more useful with one or more | others. Using this field tells the packaging system and the user that the | listed packages are related to this one and can perhaps enhance its usefulness, | but that installing this one without them is perfectly reasonable. So there are 2 options I can think of for this package: Option 1: * install cvs-switchroot in usr/share/cvs/contrib/ * drop recommends of mksh * update FAQ and cvs.txt.gz and cvs.html to point people to this command in usr/share/cvs/contrib/ with mksh requirement. * Change package description Description: Concurrent Versions System CVS is a version control system, which allows you to keep old versions of files (usually source code), keep a log of who, when, and why changes occurred, etc., like RCS or SCCS. It handles multiple developers, multiple directories, triggers to enable/log/control various operations, and can work over a wide area network. The following tasks are not included; they can be done in conjunction with CVS but will tend to require some script-writing and software other than CVS: bug-tracking, build management (that is, make and make-like tools), and automated testing. . This is based on GNU CVS but does not support pserver operation while incorporating many patches from MirOS Project and Ubuntu. --- Option 2: * keep cvs-switchroot in current location * change recommends of mksh to suggests of mksh (You may disagree to keep it as recommends. This is weak point.) * add cvs-switchroot listed at the bottom of SEE ALSO in cvs manpage * update FAQ and cvs.txt.gz and cvs.html to
Bug#631110: cvs: package description adjustment may help user
Osamu Aoki dixit: can not be dash. Just look at the source code of ash some day. real command of cvs package to function, mksh is required and qualify as This is not open for discussion. recommend. This part is due to lintian – I originally had no mention of mksh anywhere, but lintian insists on having a dependency when it is used as shebang script. But cvs-switchroot is not mentioned in cvs manpage while cvsbug is The manpage is autogenerated, I will not touch it. But I might refer to cvs-switchroot from the texinfo page, which is easy to change and read. Thanks for the idea. ones in /usr/share/cvs/contrib/ written in Perl. Actually, commands in Well, it’s not from CVS, it’s from me. I don’t do Perl. (Actually, I tried to learn it thrice and failed every time, there are just _way too many_ ways to do “it” in Perl.) Even if I could, I probably wouldn’t do it. changelog.Debian.gz. (Actually its description is confusing since cvs-switchroot comes from debian/cvs-switchroot and not from src/scripts/mnt-cvsroot as I see it packaged.) It comes from src/scripts/mnt-cvsroot in the same CVS repository where the Debian cvs packaging is hosted. The reference is correct. (Might have written mircvs://src/scripts/mnt-cvsroot instead…) * install cvs-switchroot in usr/share/cvs/contrib/ Not really an option, because these aren’t real commands there, the manpage’ll be lost, etc. * update FAQ and cvs.txt.gz and cvs.html to point people to this command in No. * change recommends of mksh to suggests of mksh As you might have read from earlier mails in this thread, I was considering doing either this or just ignoring lintian. We’ll see what can be done. * add cvs-switchroot listed at the bottom of SEE ALSO in cvs manpage Hm. Will have a look at that at least. * Change package description No. /usr/bin/cvsbug: POSIX shell script text executable Does anyone actually use this, by the way? FYI: Debian web infrastructure still rely on CVS since we can just checkout one file over slow connection :-) So CVS still have advantage over others in some area. Yes, that’s one point I strongly like as well. Glad it’s of use! Do check out “cvs suck”, too. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
