Re: Lintian based autorejects
On Mon, Nov 23, 2009 at 09:02:05PM +, Philipp Kern wrote:
Everybody should pipe his uploads through lintian. That's nothing
that should be in the upload tool, IMHO. A unixy tool does one job,
not two.
Counter example: everybody should pipe his .changes through
debchange. Still the check for unsigned .changes is in dput and it's
pretty damn useful.
Besides, nobody said that there should be two tools, the tool can always
be the same (lintian) and probably with some twiddling we can even avoid
running it twice (e.g. lintian leaving around a log file, dput checking
for its presence with some timestamp care).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On Tue, Nov 24 2009, Stefano Zacchiroli wrote: On Mon, Nov 23, 2009 at 09:02:05PM +, Philipp Kern wrote: Everybody should pipe his uploads through lintian. That's nothing that should be in the upload tool, IMHO. A unixy tool does one job, not two. Counter example: everybody should pipe his .changes through debchange. Umm, what? I thought dch was something used to create or modify ./debian/changelog file. What does piping .changes file through debchange buy one? manoj -- 'Course, that doesn't work when 'a' contains parentheses. Larry Wall in 199710211647.jaa17...@wall.org Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 24, 2009 at 10:45 AM, Manoj Srivastava sriva...@debian.org wrote: On Tue, Nov 24 2009, Stefano Zacchiroli wrote: On Mon, Nov 23, 2009 at 09:02:05PM +, Philipp Kern wrote: Everybody should pipe his uploads through lintian. That's nothing that should be in the upload tool, IMHO. A unixy tool does one job, not two. Counter example: everybody should pipe his .changes through debchange. Umm, what? I thought dch was something used to create or modify ./debian/changelog file. Pretty sure zack meant debsign, given some extra context that got snipped, Still the check for unsigned .changes is in dput and it's pretty damn useful. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
we are turning on lintian based autorejects within the next few days.
This means that packages failing a defined set of lintian tags will no
longer be accepted into the archive, but get rejected immediately.
This should help to get rid of the worst policy violations before
wasting time and resources of other people.
Those automated rejects will only be done on sourceful uploads to
unstable and experimental.
I've noticed that for DELAYED/XX uploads, the lintian rejects are
triggered not when the package hits DELAYED/XX, but rather when the
package eventually hits the archive. The annoyance of this is that the
uploader losts focus on the specific fix.
Any chance/plan to fix this so that lintian rejects are checked at
DELAYED entrance time? (sorry if it has been asked before, I didn't find
it with a quick in the thread)
If for some architectural reasons this is hard / not worth to fix, I
guess we can alternatively add a corresponding check to dput, which
refuses to upload when it finds non-overridden fatal lintian errors
(unless --forced or something).
TIA,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
I've noticed that for DELAYED/XX uploads, the lintian rejects are triggered not when the package hits DELAYED/XX, but rather when the package eventually hits the archive. The annoyance of this is that the uploader losts focus on the specific fix. Any chance/plan to fix this so that lintian rejects are checked at DELAYED entrance time? (sorry if it has been asked before, I didn't find it with a quick in the thread) No. Long answer: Delayed is nothing dak knows about at all. It is all handled by debianqueued, which is a perl script running far before dak. Due to its age it is also not quite of the standard one wants to have when editing code, so supporting anything like rejects in there is not done. So for that, yes, you want to think about the dput solution. Which would have the nice added benefit to actually save people form uploading and wasting bandwidth and time. Also, should there be someone with a little too much free time ( :) ) and willing to code a bit in python, there are various thoughts and plans around for a rewrite of the queued with much nicer functionality and stuff. Just none of us existing team members has the time to do it, there are always more important things (and debianqueued works). If someone is interested, either mail me or join #debian-dak on irc.oftc.net. -- bye, Joerg 16. What should you do if a security bug is discovered in one of your packages? 1) Notify t...@s.d.o ASAP. 2) Notify upstream. 3) Try to create a patch. 4) Find out that Joey was faster. [...] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On 2009-11-23, Joerg Jaspert jo...@debian.org wrote: So for that, yes, you want to think about the dput solution. Which would have the nice added benefit to actually save people form uploading and wasting bandwidth and time. Everybody should pipe his uploads through lintian. That's nothing that should be in the upload tool, IMHO. A unixy tool does one job, not two. Of course the Lintian standards for rejects could vary between package build and upload time and it hitting the archive. But then that's nothing a dput hook would catch neither. Kind regards, Philipp Kern PS: A working p-u-new would be much appreciated. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Steve Langasek vor...@debian.org writes: I've put together a hand-rolled test package that demonstrates this: http://people.debian.org/~vorlon/test-package_1_all.deb lintian reports the 'wrong-file-owner-uid-or-gid' error for this package, but you'll see that unpacking it results in a file /usr/share/doc/test-package/dynamically-owned owned by 'dynamic-test' regardless of which UID dynamic-test ends up with. To be honest, the last package I saw making use of such behavior was qmail-src, which is hardly an exemplary package; to land a package with these characteristics in the archive, you would effectively need to both build-depend on and pre-depend on another package which creates the user you need. (And in the case of qmail-src, the packages doing this were never in the archive - they were built on the end-user's system.) Nevertheless, if we're going to prohibit this behavior, that change should be ratified via the consensus-based Policy process. I've added a note to the long description of this tag asking for a bug to be filed against Lintian if anyone ever encounters a need to do things this way, but left the severity at certain. Lintian will almost certainly change here to use the other boilerplate of dh-make as opposed to keying off of Author(s). Once that's done, I think it's a fairly reliable indicator that the upstream author section of the dh-make boilerplate hasn't been edited. Personally, I'm happy to reject packages on that basis; it seems like the least that we could ask for maintainers to handle. Policy does require that debian/copyright be filled out, which is what this is trying to check. We already have more correct checks for this, such as copyright-without-copyright-notice. That tag is significantly more prone to false positives than checking for the template strings. But see my separate message on this topic; I think you'll agree given what Lintian is now looking for. [ binary-file-compressed-with-upx ] I suspect that this tag has never triggered, at least in the last few years. I've never devised a test case for it, and I've never seen it appear in the archive. /usr/share/lintian/checks/binaries includes a check for it. Really needs to be discussed on debian-policy before it's being made a fatal error. Yes, I know Lintian has a check for it, but I've never devised a *test case* for it. In other words, I've never seen or been able to create a package that will trigger it. I suspect doing so would require looking at the magic from file and figuring out what it thinks would make a UPX binary. I think this tag is the equivalent of binary-package-contains-unicorns. (Oh, but upstream-version-not-numeric? Why should we *force* maintainers to mangle upstream version numbers to fit this schema?) That one always struck me as weird. Why have a should constraint on version numbers? What does that even mean? It seems to me that a version number is a syntax thing: either it's accepted or it isn't. Is there some subtle problem that's solved by mangling the version number to make it numeric? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Please do. For now, and I think until squeeze or this tag no longer visible on lintian.d.o (ie no package affected), whatever comes first, this tag is in nonfatal. I think you shall find that most already have bugs filed. Yes, and I really like that I do not have to do this myself, thanks. -- bye, Joerg If you are using an Macintosh e-mail program that is not from Microsoft, we recommend checking with that particular company. But most likely other e-mail programs like Eudora are not designed to enable virus replication -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Steve Langasek wrote: On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote: Do you understand why people are getting annoyed ? They have a lot of bloody gall to be annoyed thatpeople file bugs about serious policy violations that they have signed up to follow, and neglected in their packages, and instead of thanking peple who find out and point to these policy violations, they feel angry at the bug reporter, instead of ashamed at how they neglect bugs in their packages. Yes, you have completely failed to understand the issue. I'm not complaining about you filing bugs on *my* packages. I'm complaining about a mass bug filing on *any* packages, using standards that have not previously been approved by the project, because *doing so skews priorities for the project as a whole*. Marking bugs as severity: serious means *the project* has to deal with the resulting I think this is mostly false. 90% of the bugs filed were on target, and the remaining were only bumped up one level; and usertagged for easy changes. Note that the vast majority of bugs I have filed as serious are violations of Must directives: ,[ http://www.debian.org/Bugs/Developer#severities ] | serious | is a severe violation of Debian policy (roughly, it violates a | must or required directive), or, in the package maintainer's or | release manager's opinion, makes the package unsuitable for release. ` 25 out of 240 bugs were upgraded from important to serious, and these are the tags in these 25 bugs: arch-dependent-file-in-usr-share binary-with-bad-dynamic-table control-file-has-bad-permissions depends-on-build-essential-package-without-using-version dir-or-file-in-tmp invalid-standards-version missing-build-dependency missing-build-dependency-for-dh_-command no-standards-version-field package-installs-python-pyc All of these are policy violations, and would normally result in at least important bugs. bugs. The bugs get mixed into the RC bug list and take up resources of participants in bug squashing parties; the release team has to go back and mark bugs as release-ignore or downgrade them if they're not actually release-critical issues; The amount of effort needed to fix these is about comparable to kvetching about it or downgrading them, And, anyway, given that the bugs are all usertagged, it is trivial to reset them. These would be low hanging fruit in bug squash parties, and the QA team winds up with these packages on their radar even if the package quality doesn't warrant it. None of the packages belonging to the QA team are affected. All because you're jumping at the chance to slap serious bugs on people's packages without waiting for consensus to emerge on whether those issues, some of which are entirely cosmetic, should actually be serious. There is already consensus on the severity of bugs that violate must directives in policy. That is 90% of the bugs filed. The other bugs are still important. And trivial for the maintainer to download/ That's not improving the quality of Debian, that's just being a jerk. Bullshit. A researched, usertagged set of bugs that takes 5 minutes to change the severity gets your panties in such a twist? Where rules lawyering about who is entitled to file what bugs is more important than discovering long neglected bugs? Finally, these violations of policy are added to the blacklist, since these serious policy violations are adjudged too buggy for Debian The use of passive voice here masks the fact that the adjuge-er is not the Debian project as a whole. The debian project as a whole does not adjudicate a whole lot of things -- like which bugs ought to get a pass in a release. There are a whole lot of decisions made by the DPL and delegates, and I for one think that the people in charge of the archive get the same leeway that the people in charge of the release do. manoj -- Professional wrestling: ballet for the common man. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Joerg Jaspert wrote: Please do. For now, and I think until squeeze or this tag no longer visible on lintian.d.o (ie no package affected), whatever comes first, this tag is in nonfatal. I think you shall find that most already have bugs filed. Yes, and I really like that I do not have to do this myself, thanks. So. An overview of the policy related bug filing I have been doing recently can be found at: http://tinyurl.com/yk8p3rx Coming up with that URL was ... interesting. manoj -- We promise according to our hopes, and perform according to our fears. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04 2009, Steve Langasek wrote: I'm not complaining about you filing bugs on *my* packages. I'm complaining about a mass bug filing on *any* packages, using standards that have not previously been approved by the project, because *doing so skews priorities for the project as a whole*. Marking bugs as severity: serious means *the project* has to deal with the resulting bugs. The bugs get mixed into the RC bug list and take up resources of participants in bug squashing parties; the release team has to go back and mark bugs as release-ignore or downgrade them if they're not actually release-critical issues; the QA team winds up with these packages on their radar even if the package quality doesn't warrant it. Now that the ftp-masters have changed the blacklist, all the bugs that were reported at serious severity due to the blacklist have been downgraded to important, and it was fairly trivial to do the severity change. All must violations of policy remain at severity serious; if you think policy needs to be changed, please follow the policy change process. If you do not understand policy, please ask for help. If you think your package is special, and should get an exemption from policy MUST directives, please explain why on the debian-policy list; it might be an indication that the debian policy needs changing. Please do not just downgrade the bugs. manoj -- Prejudice: A vagrant opinion without visible means of support. Ambrose Bierce Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote: E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) So false-positives are possible with this lintian check, and it should be overrideable. We currently only have 1 package in the whole archive triggering this. Thats why it is listed. Fine, moved to nonfatal. Yes, and that package is not a false-positive - it is genuinely broken and should be fixed. Still, the check itself is unreliable. E: ftp-master: section-is-dh_make-template Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. We tend to simply reject such packages from NEW. So the maintainer can see it instantly triggered this way or has to wait until NEW is processed. I tend to think this way is better. I would agree with you except for two things: - the check will also be applied to existing packages in the archive which already have overrides, where the source package's section doesn't really matter - the check only worries about the default template value, and ignores the infinite variety of other possible invalid section values Is there a way the check could be applied only to new packages? E: ftp-master: library-in-debug-or-profile-should-not-be-stripped This is obviously true for debug, and it makes sense to reject such packages because they're shipping broken debug files; is it certain for profile as well? Thats a question for the library overlords, I have far to less experience in that area. If not then maybe lintian needs adjustments/a new check and we take that. $ zgrep lib/profile/ ~/ftp/dists/unstable/Contents-i386.gz usr/lib/profile/liblockdev.adebug/liblockdev1-dbg usr/lib/profile/liblockdev.so.1 debug/liblockdev1-dbg $ shrug apparently not really an issue in practice; yes, lintian can be fixed if/when this proves necessary. E: ftp-master: binary-file-compressed-with-upx Where is this documented? There's no mention of UPX in Debian Policy, and the only mention in the lintian changelog is a 2001 bug about adding support for /reading/ UPX executables. There is no such tag, nothing currently in the archive. Absent a basis in Policy, nothing uses it is not really a reason to reject new packages that might start using it. AFAICS, this is basically an unreviewed lintian error. E: ftp-master: html-changelog-without-text-version E: ftp-master: upstream-version-not-numeric E: ftp-master: build-depends-on-essential-package-without-using-version E: ftp-master: depends-on-build-essential-package-without-using-version E: ftp-master: build-depends-on-build-essential E: ftp-master: no-standards-version-field E: ftp-master: invalid-standards-version I dont buy your reasoning *at all*, but until further notice I removed them. Ok, thanks. When should we expect this to be reflected on ftp-master and http://ftp-master.debian.org/~joerg/lintian/lintian.tags? Both still show these tags in effect. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
Steve Langasek wrote: On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote: E: ftp-master: section-is-dh_make-template Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. We tend to simply reject such packages from NEW. So the maintainer can see it instantly triggered this way or has to wait until NEW is processed. I tend to think this way is better. I would agree with you except for two things: - the check will also be applied to existing packages in the archive which already have overrides, where the source package's section doesn't really matter - the check only worries about the default template value, and ignores the infinite variety of other possible invalid section values Is there a way the check could be applied only to new packages? Is there any package in the archive that is triggering this tag? It seems to me there isn't, so it would already be the case this tag would only be applied for new packages: http://lintian.debian.org/tags.html Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Lintian based autorejects
Joerg Jaspert wrote: On 11921 March 1977, Steve Langasek wrote: E: ftp-master: debian-rules-is-symlink Not a requirement that's derived from Policy at all. If you think this is important to require for all packages due to the side effect on lintian's ability to do further checking, please discuss it on debian-policy; in the meantime, please drop. Dropped. Doesn't Policy say debian/rules must be a make file? I'd say a make file is not the same as a symlink to a make file and thus this is covered by Policy, but if that's just me we could bring this to debian-policy@ and see if there's consensus to explicitly forbid symlinks. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Lintian based autorejects
Steve Langasek vor...@debian.org writes: On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote: E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) So false-positives are possible with this lintian check, and it should be overrideable. We currently only have 1 package in the whole archive triggering this. Thats why it is listed. Fine, moved to nonfatal. Yes, and that package is not a false-positive - it is genuinely broken and should be fixed. Still, the check itself is unreliable. I must say, that's a pretty high level of reliability, certainly enough to keep using certain as the certainty in Lintian. But yes, I suppose it makes sense to let people override it in the rare case they want to do this. Absent a basis in Policy, nothing uses it is not really a reason to reject new packages that might start using it. AFAICS, this is basically an unreviewed lintian error. Correct, I don't believe it's ever triggered. I suspect it doesn't matter one way or the other what we do with it for that reason. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03, 2009 at 09:28:01AM +0900, Charles Plessy wrote:
I reproduce here the one from Brian May, which I think is very
relevant and was asked in many different ways, and always ignored:
http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au
I want to perform a NMU upload on a package, say to fix a security issue,
or some
other major issue (as allowed by NMUs).
Actually, it's a couple of days that I'm pondering about that, trying to
make up my mind about that, I'll try only now to post that. The issue is
surely relevant.
On Mon, Nov 02, 2009 at 05:00:53PM -0800, Russ Allbery wrote:
Surely the answer to that question is obvious: fix the bugs Lintian is
finding that prevent upload. They're the equivalent of RC bugs (not
precisely the same, but similar), which if you're already doing an NMU are
certainly fair game.
I don't think it is that simple. nitpickFor once, we need to refine
some of our guidelines (that's the easy part). Devref §5.11.1 authorizes
to upload only changes that fix RC bugs older than X days, so if lintian
is complaining about issues not corresponding to RC bugs (e.g. because
it is a new check in lintian, not yet reported), in theory you shouldn't
upload with specific delays./nitpick (As I anticipated, that's the
easy part, just fix the guidelines.)
In general though, I wonder whether that would be the right
approach. Why should the NMUer be forced to fix other issues than her
own (RC) itch, considering that other (indubitably grave) issues were in
the archive _before_? The ideal solution would be to have dak know the
previous state and do not accept _regressions_ wrt the previous set of
fatal upload errors (according to the proposed wording). I'm not sure
it is worth though, maybe Russ' solutions is the one NMUers would
implement anyhow and hence is overkilling to look for something more
complicated.
This answer is independent of what we decide should go into that set of
checks.
ACK.
Cheers.
PS Charles: I do believe I've limited myself to one post per day on the
average, and at least one of them was a simple thank you. Also,
this thread have been rather acceptable, if you exclude the
debate/flame on Manoj' bug filing. The fact that archive admins stop
in participating is most likely related to their ongoing meeting, I'm
confident they'll come back to some of the raised criticisms in the
next few days; anyhow, the fact that they stop participating is not
an argument for stop discussing among us else.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On Tue, Nov 03 2009, Stefano Zacchiroli wrote: I don't think it is that simple. nitpickFor once, we need to refine some of our guidelines (that's the easy part). Devref §5.11.1 authorizes to upload only changes that fix RC bugs older than X days, so if lintian is complaining about issues not corresponding to RC bugs (e.g. because it is a new check in lintian, not yet reported), in theory you shouldn't upload with specific delays./nitpick (As I anticipated, that's the easy part, just fix the guidelines.) Or recall that guidelines do not trump common sense, and do the only thing that works in this case. In general though, I wonder whether that would be the right approach. Why should the NMUer be forced to fix other issues than her own (RC) itch, considering that other (indubitably grave) issues were in the archive _before_? Thanks for asking. The solution, past a transition period, is to get these packages fixed or removed from the archive; hence we should be aggressively filing RC bugs on them. The ideal solution would be to have dak know the previous state and do not accept _regressions_ wrt the previous set of fatal upload errors (according to the proposed wording). I'm not sure it is worth though, I beg to differ. In the long run, there should not be *any* such violations in the archive; so it is not really worth spending time writing code for dak that will shortly be a dead path. maybe Russ' solutions is the one NMUers would implement anyhow and hence is overkilling to look for something more complicated. This answer is independent of what we decide should go into that set of checks. ACK. manoj -- My, how you've changed since I've changed. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote:
The ideal solution would be to have dak know the previous state and do
not accept _regressions_ wrt the previous set of fatal upload errors
(according to the proposed wording). I'm not sure it is worth though,
I beg to differ. In the long run, there should not be *any* such
violations in the archive; so it is not really worth spending time
writing code for dak that will shortly be a dead path.
For packages that are now in the archive with lintian errors that would
have prevented them to be uploaded, you're right. However, as a corner
case, you can imagine a new lintian check added 10 years from now, and
that check be used to refuse uploads. All packages upload starting from
now to that moment might be prone to that error. That error would upload
to upload NMUs which do not fix it (but possibly fix other serious
errors).
This argument is moot only if you assume that we will never add a new
check to the dak black list which has at least one matching package in
the archive. Are you sure that will never be the case? I'm not that
confident.
Still, one might argue that this is too much nitpicking for such cases,
and that we should leave with the inability to NMU them unless the
dak-blacklisted bug is fixed too.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
Stefano Zacchiroli wrote: On Tue, Nov 03, 2009 at 09:28:01AM +0900, Charles Plessy wrote: On Mon, Nov 02, 2009 at 05:00:53PM -0800, Russ Allbery wrote: Surely the answer to that question is obvious: fix the bugs Lintian is finding that prevent upload. They're the equivalent of RC bugs (not precisely the same, but similar), which if you're already doing an NMU are certainly fair game. I don't think it is that simple. nitpickFor once, we need to refine some of our guidelines (that's the easy part). Devref §5.11.1 authorizes to upload only changes that fix RC bugs older than X days, so if lintian is complaining about issues not corresponding to RC bugs (e.g. because it is a new check in lintian, not yet reported), in theory you shouldn't upload with specific delays./nitpick (As I anticipated, that's the easy part, just fix the guidelines.) In general though, I wonder whether that would be the right approach. Why should the NMUer be forced to fix other issues than her own (RC) itch, considering that other (indubitably grave) issues were in the archive _before_? The ideal solution would be to have dak know the previous state and do not accept _regressions_ wrt the previous set of fatal upload errors (according to the proposed wording). I'm not sure it is worth though, maybe Russ' solutions is the one NMUers would implement anyhow and hence is overkilling to look for something more complicated. It's quite clear that not fixing the issue in the NMU will mean no NMU as it would get rejected. It's comparable to fixing an unrelated FTBFS bug (even if not filed), there are some preconditions to get your upload accepted in the archive. The automated upload rejections are just an additional hurdle to be able to get your upload into the archive, so should certainly be fixed in whatever upload you do IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
* Stefano Zacchiroli z...@debian.org [091103 17:32]: For packages that are now in the archive with lintian errors that would have prevented them to be uploaded, you're right. However, as a corner case, you can imagine a new lintian check added 10 years from now, and that check be used to refuse uploads. All packages upload starting from now to that moment might be prone to that error. That error would upload to upload NMUs which do not fix it (but possibly fix other serious errors). If you do an NMU you hopefully will look at the lintian output of your upload. With old or hardly maintained packages that will be complicated because you have to look at the lintian messages for the unmodified packages and for the modified packages and check if anything is new and because of your modifications. Having to fix some minor things that mostly need a trivial one-line fix (like many in the list that started this massive subthread), that does not really prevent the NMU. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
I don't think it's appropriate to make, for instance, dir-or-file-in-var-www instantly fatal without following the usual mass-bug-filing procedure. If you'd like mass bugs to be filed based on these lintian tags but don't have time, let me know if I can help (I can't promise to deal with all of them). Please do. For now, and I think until squeeze or this tag no longer visible on lintian.d.o (ie no package affected), whatever comes first, this tag is in nonfatal. Some examples of tags where I do not consider this reasonable until bugs have been filed: - statically-linked-binary - mknod-in-maintainer-script These are nonfatal for the reason that they are, unless the maintainer did think about it, something that shouldn't be there. So if they really need to be there, fine, override. - debian-rules-not-a-makefile Policy must. - dir-or-file-in-var-www Nonfatal with my next commit. On 11916 March 1977, Lucas Nussbaum wrote: Also, lots of packages currently in our archive already have those errors. What do you plan to do with those? If you auto-reject packages that introduce those errors, it would be logical to file RC bugs and/or remove them from the archive. By simply removing them I don't even give the chance of fixing it up. On 11921 March 1977, Steve Langasek wrote: Since I'm not familiar with most of these lintian errors by name, I've run the list of fatal errors through lintian-info with the following script: $ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \ | sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info Replace error by fatal to have this line work again. Also, remember to rerun this every now and then during this discussion, the file is still regularly updated based on input we get. E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) So false-positives are possible with this lintian check, and it should be overrideable. We currently only have 1 package in the whole archive triggering this. Thats why it is listed. Fine, moved to nonfatal. E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. Already removed this check, instead added copyright-contains-dh_make-todo-boilerplate to nonfatal (will move to fatal at some point). E: ftp-master: section-is-dh_make-template Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. We tend to simply reject such packages from NEW. So the maintainer can see it instantly triggered this way or has to wait until NEW is processed. I tend to think this way is better. E: ftp-master: library-in-debug-or-profile-should-not-be-stripped This is obviously true for debug, and it makes sense to reject such packages because they're shipping broken debug files; is it certain for profile as well? Thats a question for the library overlords, I have far to less experience in that area. If not then maybe lintian needs adjustments/a new check and we take that. E: ftp-master: binary-file-compressed-with-upx Where is this documented? There's no mention of UPX in Debian Policy, and the only mention in the lintian changelog is a 2001 bug about adding support for /reading/ UPX executables. There is no such tag, nothing currently in the archive. E: ftp-master: executable-in-usr-share-doc Clearly a bug, but just as clearly not anything that breaks the package to the point of making it unsuitable for the archive. Please drop. I do think it should stay out, but fine. E: ftp-master: debian-rules-is-symlink Not a requirement that's derived from Policy at all. If you think this is important to require for all packages due to the side effect on lintian's ability to do further checking, please discuss it on debian-policy; in the meantime, please drop. Dropped. The following checks are also marked as should requirements in Debian Policy, not musts. The ftp team has no authority to escalate these to must at the archive level. Now there is a long flame waiting to start about what authority there is, or
Re: Lintian based autorejects
Le Tue, Nov 03, 2009 at 01:01:02PM -0600, Manoj Srivastava a écrit : when we do add such a lintian check to the blacklist, we also file serious bugs against those packages in the archive; and aggressively work to either fix the packages, or remove them from the archive. It is very unclear who ‘we’ is in this sentence. To me, the situation looks more like: when [they] do add such a lintian check to the blacklist, [you] file serious bugs against those packages in the archive; and [expect others to] aggressively work to either fix the packages, or [go through the long process that may allow to] remove them from the archive. Do you understand why people are getting annoyed ? -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Stefano Zacchiroli wrote: On Tue, Nov 03, 2009 at 09:30:04AM -0600, Manoj Srivastava wrote: The ideal solution would be to have dak know the previous state and do not accept _regressions_ wrt the previous set of fatal upload errors (according to the proposed wording). I'm not sure it is worth though, I beg to differ. In the long run, there should not be *any* such violations in the archive; so it is not really worth spending time writing code for dak that will shortly be a dead path. For packages that are now in the archive with lintian errors that would have prevented them to be uploaded, you're right. However, as a corner case, you can imagine a new lintian check added 10 years from now, and that check be used to refuse uploads. All packages upload starting from now to that moment might be prone to that error. That error would upload to upload NMUs which do not fix it (but possibly fix other serious errors). This argument is moot only if you assume that we will never add a new check to the dak black list which has at least one matching package in the archive. Are you sure that will never be the case? I'm not that confident. That is not what I meant. I meant that when we do add such a lintian check to the blacklist, we also file serious bugs against those packages in the archive; and aggressively work to either fix the packages, or remove them from the archive. I think our effort should be spent in the fixing/removal, rather than perpetuating buggy packages in the archive. If a package is too buggy to be i Debian, we should not do more work in order for it to remain in. manoj -- How wonderful opera would be if there were no singers. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03, 2009 at 09:06:25PM +0100, Bernhard R. Link wrote:
If you do an NMU you hopefully will look at the lintian output of your
upload. With old or hardly maintained packages that will be complicated
because you have to look at the lintian messages for the unmodified
packages and for the modified packages and check if anything is new and
because of your modifications.
I do, and I've recently documented my NMU workflow (on my blog)
detailing that I consider mandatory to look at the *diff* between
lintian output in the version before the NMU and in the NMU-ed
version. I think you missed my point about doing an NMU that fixes only
one specific RC bug and that the delay of that NMU should be authorized
(by our best practices) on the basis of the age of that specific bug.
But let's drop this sub-topic, from the various replies I've read to the
NMU-issue originally raised by Brian May, I think we can agree that
there is consensus on considering it a non-issue: either you also fix
the blacklisted lintian error, or you refrain from NMUing.
Cheers.
PS most of the issues do indeed require single line fixes, but some
of them requires more invasives changes, e.g. dir-or-file-in-var-www,
since fixing that usually implies changing the interface of the user
with the package (i.e. its URL)
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On Tue, Nov 03 2009, Joerg Jaspert wrote: I don't think it's appropriate to make, for instance, dir-or-file-in-var-www instantly fatal without following the usual mass-bug-filing procedure. If you'd like mass bugs to be filed based on these lintian tags but don't have time, let me know if I can help (I can't promise to deal with all of them). Please do. For now, and I think until squeeze or this tag no longer visible on lintian.d.o (ie no package affected), whatever comes first, this tag is in nonfatal. I think you shall find that most already have bugs filed. Some examples of tags where I do not consider this reasonable until bugs have been filed: - statically-linked-binary - mknod-in-maintainer-script These are nonfatal for the reason that they are, unless the maintainer did think about it, something that shouldn't be there. So if they really need to be there, fine, override. Bugs already filed about the latter. I have not gotten around to the statically-linked-binary ones yet. - debian-rules-not-a-makefile Policy must. - dir-or-file-in-var-www Nonfatal with my next commit. Bugs already filed. E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) So false-positives are possible with this lintian check, and it should be overrideable. We currently only have 1 package in the whole archive triggering this. Thats why it is listed. Fine, moved to nonfatal. Bugs filed after manual checks to remove false positives. E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. Already removed this check, instead added copyright-contains-dh_make-todo-boilerplate to nonfatal (will move to fatal at some point). Bugs filed after manual checks. Yes, there were a huge number of false positives. E: ftp-master: section-is-dh_make-template Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. We tend to simply reject such packages from NEW. So the maintainer can see it instantly triggered this way or has to wait until NEW is processed. I tend to think this way is better. Have not yet gotten around to this one. E: ftp-master: executable-in-usr-share-doc Clearly a bug, but just as clearly not anything that breaks the package to the point of making it unsuitable for the archive. Please drop. I do think it should stay out, but fine. Bugs filed. E: ftp-master: build-depends-on-essential-package-without-using-version E: ftp-master: depends-on-build-essential-package-without-using-version E: ftp-master: build-depends-on-build-essential E: ftp-master: no-standards-version-field E: ftp-master: invalid-standards-version Bugs filed for these. E: ftp-master: html-changelog-without-text-version E: ftp-master: upstream-version-not-numeric I dont buy your reasoning *at all*, but until further notice I removed them. manoj -- Pick another fortune cookie. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03 2009, Charles Plessy wrote: Le Tue, Nov 03, 2009 at 01:01:02PM -0600, Manoj Srivastava a écrit : when we do add such a lintian check to the blacklist, we also file serious bugs against those packages in the archive; and aggressively work to either fix the packages, or remove them from the archive. It is very unclear who ‘we’ is in this sentence. To me, the situation looks more like: Sigh*. Why is it relevant who it is? when [they] do add such a lintian check to the blacklist, [you] file serious bugs against those packages in the archive; and [expect others to] aggressively work to either fix the packages, or [go through the long process that may allow to] remove them from the archive. So. Given what the process being talked about is, we first create policy via a consensus based process, and policy has these directives. Policy tries not to create directives where tonns of packages are insta-buggy. Lintian checks are written for these directives, and over time, people get to see if their packages are affected. Again, new policy directives do not come in as must rules, so these have been in effect for ages. Finally, these violations of policy are added to the blacklist, since these serious policy violations are adjudged too buggy for Debian -- but this is after a looong period of time after people have known that their packages are buggy. Someone (perhaps me), now files these violations as bugs that they are. In other words, after people ignore what lintian tells them are policy violations, someone does a lot of research, verifies there is a bug, and files reports. Do you understand why people are getting annoyed ? They have a lot of bloody gall to be annoyed thatpeople file bugs about serious policy violations that they have signed up to follow, and neglected in their packages, and instead of thanking peple who find out and point to these policy violations, they feel angry at the bug reporter, instead of ashamed at how they neglect bugs in their packages. manoj irritated -- Sex, Drugs Linux Rules MaDsen Wikholm, mwikh...@at8.abo.fi Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote: Do you understand why people are getting annoyed ? They have a lot of bloody gall to be annoyed thatpeople file bugs about serious policy violations that they have signed up to follow, and neglected in their packages, and instead of thanking peple who find out and point to these policy violations, they feel angry at the bug reporter, instead of ashamed at how they neglect bugs in their packages. Yes, you have completely failed to understand the issue. I'm not complaining about you filing bugs on *my* packages. I'm complaining about a mass bug filing on *any* packages, using standards that have not previously been approved by the project, because *doing so skews priorities for the project as a whole*. Marking bugs as severity: serious means *the project* has to deal with the resulting bugs. The bugs get mixed into the RC bug list and take up resources of participants in bug squashing parties; the release team has to go back and mark bugs as release-ignore or downgrade them if they're not actually release-critical issues; the QA team winds up with these packages on their radar even if the package quality doesn't warrant it. All because you're jumping at the chance to slap serious bugs on people's packages without waiting for consensus to emerge on whether those issues, some of which are entirely cosmetic, should actually be serious. That's not improving the quality of Debian, that's just being a jerk. Finally, these violations of policy are added to the blacklist, since these serious policy violations are adjudged too buggy for Debian The use of passive voice here masks the fact that the adjuge-er is not the Debian project as a whole. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
On Sun, 01 Nov 2009, Steve Langasek wrote: My only concern is that the ftp archive checks not be used to force changes in Policy. If the set of tags being drawn from is limited to those that are recognized as violations of Policy must requirements, then I have no opinion on who should decide which tags are blockers and which ones are not. If the candidate tags are *not* limited to that set, then I think we have a governance problem regardless of who's driving. What about using those tags to achieve release goals? For example, the support of 3.0 (quilt) by default would benefit from getting rid of: http://lintian.debian.org/tags/patch-modifying-debian-files.html http://lintian.debian.org/tags/quilt-patch-with-non-standard-options.html Otherwise, I generally agree with your point of view. I welcome this new infrastructure but the set of tags used should be limited to clear violations of must directives, really broken packages, and other consensual tags that allow us to reach our current set of goals. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 04:13:48PM -0800, Steve Langasek wrote:
On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote:
So, I revamp a proposal I made in a corner of this thread:
Let the QA team decide upon the non overridable lintian errors.
My only concern is that the ftp archive checks not be used to force changes
in Policy.
If the set of tags being drawn from is limited to those that are recognized
as violations of Policy must requirements, then I have no opinion on who
should decide which tags are blockers and which ones are not. If the
candidate tags are *not* limited to that set, then I think we have a
governance problem regardless of who's driving.
Agreed.
I was splitting the issues in two sub-issues actually: (1) being sure
that lintian E: messages are only those coming from violated must
requirements, (2) deciding which among them are upload blockers.
I confess I was pretty much assuming that lintian maintainers ensure (1)
is always verified. Beside bugs in lintian that can always, I now
realize that (1) is probably not so strict. For instance, for OCaml
packages we do have custom lintian checks that do not appear in policy,
but rather in our own packaging policy, but which we do want to be
E:. Surely we do not want those to be upload blockers.
All in all, your requirement can be probably be implemented by setting
the general rule that all upload blockers should match violated must
requirements, no matter who is in charge of defining the list.
That rule being clear, we can decide upon anyone team to be in charge of
defining the list, I just found QA a good balance of factors like: not
too big (to avoid consensus reaching problem), not too small (to
avoid bottlenecks), on topic (in charge of archive QA).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On 01/11/09 at 15:31 +0100, Stefano Zacchiroli wrote: [ Adding -qa to Cc ] On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote: For future handling: If we are adding tags to the list that will hit more than a few packages we will send a notice to the d-d-a list. I don't think it's appropriate for the ftp team to add any other checks without notifying the project, regardless of how many packages are currently affected. Please make sure you notify the project of /any/ additional rules you apply at archive accept time. ACK on this. While I heartly welcome this addition, I see the centralization of the tag decision process as potentially dangerous; not for power reasons, but rather for the bad feelings (and related flamefests!) such changes can leave behind and for the potential bottleneck risks (nowadays FTP master is luckily and finally more stuffed than in the past, but tomorrow who knows?). So, I revamp a proposal I made in a corner of this thread: Let the QA team decide upon the non overridable lintian errors. Rationale: the QA mailing list is considered to be a rather good venue to discuss and reach consensus, also it is one of the places where lintian maintainers discuss various issues, and (trivially) QA is the supposed place where to enforce project-wide QA. (Full disclosure: yes, I'm currently an active QA member.) I don't think that it's a good idea to give the reviewing power to the QA team: QA team membership is loosely defined, and if we were to make policy decisions, we would have to have a clear process to determine who is empowered to take those decisions. I'm fine with letting ftpmasters take that decision. However, they should consult the project before adding new tags (mail to -devel: We are thinking of adding those new tags to our list, comments? instead of a mail to -devel saying We just blocked the following tags), and listen to feedback. If someone feel that they made a mistake, it's always possible to appeal to the TC. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote: I'd recommend that others do likewise, to get an appropriately large set of eyeballs on this change. Question: (apologies if this has already been addressed and I missed it) I want to perform a NMU upload on a package, say to fix a security issue, or some other major issue (as allowed by NMUs). Unfortunately the package fails lintian checks required to perform an upload. Since this is a NMU though, I am not suppose to make unrelated changes. What do I do? Can I fix these unrelated issues that prevent me uploading the package as well as fixing the original issue? -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Lucas Nussbaum wrote: I'm fine with letting ftpmasters take that decision. However, they should consult the project before adding new tags (mail to -devel: We are thinking of adding those new tags to our list, comments? instead of a mail to -devel saying We just blocked the following tags), and listen to feedback. If someone feel that they made a mistake, it's always possible to appeal to the TC. Is it? By my interpretation, I don't think that the TC has any authority here since the ftp-masters are DPL delegates and not individual maintainers. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Russ Allbery wrote: Luk Claes l...@debian.org writes: As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. On behalf of the other four Policy maintainers who aren't Manoj and who so far as I know you don't have personal conflicts with, let me just say gee, thanks. This is how we can ensure that Policy continues not to be the document that it should be and people have to keep reading multiple documents to figure out what they're required to do. Note that this predates me joining the Release Team, so I don't think it's just a personal issue between Manoj and me... I have a limited amount of time to spend on Debian as a whole, which is divided between Lintian, Policy, and my own packages. Reading things like the above is extremely demoralizing and both tends to reduce that overall time committment and the amount of time I'm willing to invest in Policy in particular. If people are going to undercut or ignore that work, what's the point of me trying to fight upstream? Exactly, I have only a limited amount of time and don't want to spend it on demotivating discussions with Manoj about why he uses two standards. Though just ignoring these is also of no help, so in general I just point out when he does it (probably not in a very objective way due to how hard it demotivates me to see people in such positions doing that). For the actual matter at hand I think it's very wrong to do a MBF without going through d-devel for several reasons: - it gives developers a chance to fix bugs before they are filed to decrease high bug traffic that is normal for MBFs - it gives developers a chance to discuss the severity and tags that should be used without the need to change them afterwards - it gives developers a chance to change the preconditions for bugs before they are filed - it gives developers a chance to share ideas on how to fix the bugs and include that information in the bug reports - it gives developers a chance to update any relevant documentation before the bugs are filed Cheers Luk Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Mon Nov 02 11:40, Luk Claes wrote: For the actual matter at hand I think it's very wrong to do a MBF without going through d-devel for several reasons: snip reasons Otoh, this is a slightly special case, since they are things which are causing the package to become non-uploadable. In this case the correct place to have the discussion about the scope et al of the bugs is with ftp-master about what constitutes rejection criteria; the bug filing is purely a reflection of that. I certainly don't think that having packages with an upload-critical bug with no bug filed against them is a good idea Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Lintian based autorejects
Matthew Johnson wrote: On Mon Nov 02 11:40, Luk Claes wrote: For the actual matter at hand I think it's very wrong to do a MBF without going through d-devel for several reasons: snip reasons Otoh, this is a slightly special case, since they are things which are causing the package to become non-uploadable. In this case the correct place to have the discussion about the scope et al of the bugs is with ftp-master about what constitutes rejection criteria; the bug filing is purely a reflection of that. Right, though filing bugs already is ignoring that step completely. I certainly don't think that having packages with an upload-critical bug with no bug filed against them is a good idea I'm not saying that bugs should not be filed, though the content and meta information of bugs can be very much improved by discussing before filing them. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Mon, Nov 02 2009, Luk Claes wrote: Exactly, I have only a limited amount of time and don't want to spend it on demotivating discussions with Manoj about why he uses two standards. Though just ignoring these is also of no help, so in general I just point out when he does it (probably not in a very objective way due to how hard it demotivates me to see people in such positions doing that). If you could actually point out which two standards I am using, it could be somewhat useful. But in this case you were factually incorrect, in others you jump to conclusions and ascribe motivations to me that you make out of whole cloth, and none of that is even remotely helpful. For the actual matter at hand I think it's very wrong to do a MBF without going through d-devel for several reasons: - it gives developers a chance to fix bugs before they are filed to decrease high bug traffic that is normal for MBFs The same developers who have been ignoring lintian telling them that their packages are buggy for ages? - it gives developers a chance to discuss the severity and tags that should be used without the need to change them afterwards There are standard definitions for tags for bugs that are violations of must directives in policy (look at policy and bugs.d.o), as well as packages determined too buggy to be in the archive by folks to are in charge of what goes in the archive. Any opinion contrary to that would not likely have changed my set of bug filings at all. - it gives developers a chance to change the preconditions for bugs before they are filed Why was this not done long ago, when lintian has been screaming its little head off? - it gives developers a chance to share ideas on how to fix the bugs and include that information in the bug reports They can do so now. It is not as if these bugs did not have a user tag. - it gives developers a chance to update any relevant documentation before the bugs are filed Why had this not been done when lintian was warning them about these errors, then? manoj -- Trespassers will be violated! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Stefano Zacchiroli z...@debian.org writes: I was splitting the issues in two sub-issues actually: (1) being sure that lintian E: messages are only those coming from violated must requirements, (2) deciding which among them are upload blockers. I confess I was pretty much assuming that lintian maintainers ensure (1) is always verified. Beside bugs in lintian that can always, I now realize that (1) is probably not so strict. For instance, for OCaml packages we do have custom lintian checks that do not appear in policy, but rather in our own packaging policy, but which we do want to be E:. Surely we do not want those to be upload blockers. Right. Lintian E: tags are not now and never have been only Policy must directives. They correspond to tags that, were one to file a bug about them, would be either severity serious or higher or severity important with a certainty of possible or higher. This includes things that aren't in Policy at all but that denote broken packages, Policy should directives that are easy to fix, misuses of tools according to the documentation of that tool that aren't mentioned in Policy at all, and a few other things. All in all, your requirement can be probably be implemented by setting the general rule that all upload blockers should match violated must requirements, no matter who is in charge of defining the list. I do think it's reasonable to not allow people to upload packages with obvious and easily-correctable errors even if they're not must directives, although I suppose we could implement that by upgrading all such errors to must in Policy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Luk Claes l...@debian.org writes: Exactly, I have only a limited amount of time and don't want to spend it on demotivating discussions with Manoj about why he uses two standards. I really think the best solution to this is to stop having demotivating discussions with Manoj, particularly in this case where I'm not seeing where he's doing any significant harm even if you completely disagree with the bugs he's filing and the severity at which he's filing them. It's not that hard to downgrade severity if the project doesn't agree with the initial bug severity. We're all human, which means that some of us are just not going to get along with others of us. There will be clashes in communication style, in opinions about how to approach a problem, and in aggressiveness about things like filing bugs. There is usually some better way to deal with it than get into a long, demotivating argument. A lot of things I get upset about initially I sit on for a day or two and usually they look like less of a big deal after that. For things that don't feel that way, this is one of the reasons why teams like Policy have multiple members. Please always feel free to approach me if you don't want to approach another team member, and likewise feel free to approach Manoj if I'm making you upset for some reason. We all work together fairly well and can generally serve as go-betweens and help with the discussion in those cases. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
CTTE deciding technical policy [Re: Lintian based autorejects]
On Mon, 02 Nov 2009, Faidon Liambotis wrote: By my interpretation, I don't think that the TC has any authority here since the ftp-masters are DPL delegates and not individual maintainers. The intersection of §5.1.1 (DPL delegation) and §6.1.1 (CTTE decides technical policy) is kind of uncharted, but assuming that this decision is a matter of technical policy, §6.1.1 seems to apply directly, even if the decision has been delegated. [Though the CTTE probably needs 3:1 if §6.1.4 (overriding DD needs 3:1) applies.] That said, see Kurt Roeckx's response[1] to me[2] when this was last raised. Don Armstrong 1: http://lists.debian.org/debian-ctte/2009/09/msg00012.html 2: http://lists.debian.org/debian-ctte/2009/09/msg00010.html -- It is easier to build strong children than to repair broken men. -- Frederick Douglass http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On 02/11/09 at 12:10 +0200, Faidon Liambotis wrote: Lucas Nussbaum wrote: I'm fine with letting ftpmasters take that decision. However, they should consult the project before adding new tags (mail to -devel: We are thinking of adding those new tags to our list, comments? instead of a mail to -devel saying We just blocked the following tags), and listen to feedback. If someone feel that they made a mistake, it's always possible to appeal to the TC. Is it? By my interpretation, I don't think that the TC has any authority here since the ftp-masters are DPL delegates and not individual maintainers. I don't think that this was raised as a blocker when the TC was asked to overrule ftpmasters about the ia32-lib-tools removal. (but please correct me, I'm clearly not a constitution expert) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Le Mon, Nov 02, 2009 at 08:49:40AM -0800, Russ Allbery a écrit : I'm not seeing where he's doing any significant harm By killing the discusssion with a flood of emails. Here are the top posters for this month in this thread: 3 Charles Plessy (+1 with this one) 3 Michael Banck 3 Stefano Zacchiroli 5 Luk Claes 8 Russ Allbery 10 Steve Langasek 12 Manoj Srivastava People left the discussion, in particular our archive administrators, which makes the whole thread pointless. In addition, some important questions are left unanswered. I reproduce here the one from Brian May, which I think is very relevant and was asked in many different ways, and always ignored: http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au I want to perform a NMU upload on a package, say to fix a security issue, or some other major issue (as allowed by NMUs). Unfortunately the package fails lintian checks required to perform an upload. Since this is a NMU though, I am not suppose to make unrelated changes. What do I do? As for all difficult discussions on this high-traffic mailing list, I think that we would collectively achieve much more by self-limiting our contributions to one or two message per day. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Charles Plessy ple...@debian.org writes: In addition, some important questions are left unanswered. I reproduce here the one from Brian May, which I think is very relevant and was asked in many different ways, and always ignored: http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au I want to perform a NMU upload on a package, say to fix a security issue, or some other major issue (as allowed by NMUs). Unfortunately the package fails lintian checks required to perform an upload. Since this is a NMU though, I am not suppose to make unrelated changes. What do I do? Surely the answer to that question is obvious: fix the bugs Lintian is finding that prevent upload. They're the equivalent of RC bugs (not precisely the same, but similar), which if you're already doing an NMU are certainly fair game. This answer is independent of what we decide should go into that set of checks. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Russ Allbery wrote: Charles Plessy ple...@debian.org writes: In addition, some important questions are left unanswered. I reproduce here the one from Brian May, which I think is very relevant and was asked in many different ways, and always ignored: http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au I want to perform a NMU upload on a package, say to fix a security issue, or some other major issue (as allowed by NMUs). Unfortunately the package fails lintian checks required to perform an upload. Since this is a NMU though, I am not suppose to make unrelated changes. What do I do? Surely the answer to that question is obvious: fix the bugs Lintian is finding that prevent upload. They're the equivalent of RC bugs (not precisely the same, but similar), which if you're already doing an NMU are certainly fair game. So there are two NMUs for each package? One for the lintian blocker, and then finally for the security upload? What about those packages that have multiple lintian blockers? One NMU for each, as they are unrelated, and have the problem that they are all blocked due to other outstanding lintian blockers, or have one giant NMU that touches various pieces parts? -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
John H. Robinson, IV jaq...@debian.org writes: Russ Allbery wrote: Surely the answer to that question is obvious: fix the bugs Lintian is finding that prevent upload. They're the equivalent of RC bugs (not precisely the same, but similar), which if you're already doing an NMU are certainly fair game. So there are two NMUs for each package? One for the lintian blocker, and then finally for the security upload? Generally you make all RC-level changes to a package at the same time with one NMU. This case isn't any different than the case of a package with multiple RC bugs that you're uploading an NMU for. In the specific case of security fixes for stable and stable updates, I believe the ftp team has already said that Lintian won't be used to test such uploads for obvious reasons. What about those packages that have multiple lintian blockers? One NMU for each, as they are unrelated, and have the problem that they are all blocked due to other outstanding lintian blockers, or have one giant NMU that touches various pieces parts? Looking at the Lintian tags that are being checked, I'm having a hard time seeing what sort of package would need a giant NMU to deal with them, except maybe for packages with FHS problems. Most of these tags are one or two line fixes. I'm sure you can always ask the ftp team for an exception in exceptional circumstances. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote: The second category is named error and the tags listed can not be overridden. Those are tags corresponding to packaging errors serious enough to mark a package unfit for the archive and should never happen. In fact, most of the tags listed do not appear in our archive currently, the few packages listed below should be easily fixable with their next upload. We will provide a static url for the list of tags soon, for now you can look at them using [1]. There are multiple files in [2] showing you the packages affected, together with the tags they hit. [1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags [2] http://ftp-master.debian.org/~joerg/lintian/ Since I'm not familiar with most of these lintian errors by name, I've run the list of fatal errors through lintian-info with the following script: $ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \ | sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info I'd recommend that others do likewise, to get an appropriately large set of eyeballs on this change. Some problems I find with this list: E: ftp-master: wrong-file-owner-uid-or-gid N: N: The user or group ID of the owner of the file is invalid. The owner N: user and group IDs must be in the set of globally allocated IDs, N: because other IDs are dynamically allocated and might be used for N: varying purposes on different systems, or are reserved. The set of the N: allowed, globally allocated IDs consists of the ranges 0-99, N: 64000-64999 and 65534. N: N: Refer to Debian Policy Manual section 9.2 (Users and groups) for N: details. N: N: Severity: serious, Certainty: certain N: Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) So false-positives are possible with this lintian check, and it should be overrideable. E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate N: N: There is Upstream Author(s) in your copyright file. This was most N: likely a remnant from the dh_make template. N: N: There's either one upstream author, in which case you should remove N: the (s), or there are several upstream authors, in which case you N: should remove the ( and ). N: N: o/~ join us now and carefully edit debian/copyright files! o/~ N: N: Severity: normal, Certainty: certain N: This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. E: ftp-master: section-is-dh_make-template N: N: The Section: field in this package's control file is set to unknown. N: This is not a valid section, and usually means a dh_make template N: control file was used and never modified to set the correct section. N: N: Refer to Debian Policy Manual section 2.4 (Sections) for details. N: N: Severity: important, Certainty: certain N: Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. (BTW, this tag appears twice in the list.) E: ftp-master: library-in-debug-or-profile-should-not-be-stripped N: N: Libraries in .../lib/debug or in .../lib/profile usually should not be N: stripped. N: N: Severity: important, Certainty: certain N: This is obviously true for debug, and it makes sense to reject such packages because they're shipping broken debug files; is it certain for profile as well? E: ftp-master: binary-file-compressed-with-upx N: N: Debian does not allow binaries to be compressed by UPX. N: N: Severity: important, Certainty: certain Where is this documented? There's no mention of UPX in Debian Policy, and the only mention in the lintian changelog is a 2001 bug about adding support for /reading/ UPX executables. E: ftp-master: copyright-file-is-symlink N: N: The copyright file /usr/share/doc/pkg/copyright must not be a N: symbolic link. N: N: Refer to Debian Policy Manual section 12.5 (Copyright information) for N: details. N: N: Severity: serious, Certainty: certain N: This looks to me like a bug in Policy. Why do we allow /usr/share/doc/$pkg to be a symlink, but disallow /usr/share/doc/$pkg/copyright as a symlink if it fulfills the same constraints? Will
Re: Lintian based autorejects
getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Wow, time goes so fast, it is already the season for attempting to delay the release! -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
* Steve Langasek vor...@debian.org [091101 11:23]: Some problems I find with this list: I think some of those complaints show a general disagreement about what aims Debian has. Are we here to gain for quality or is allowing the maximum amount of (free) software the primary goal? E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate [...] This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. I think a suggestion that a bug filed about this should be normal and rejecting a package targeted at unstable or experimental with this can be fully compatible. Already having a problem with that in the archive is no problem (and there is no reason to stall testing migration because of it). But why should we allow a new version of this package uploaded? Even in case of an NMU its no effort at all to fix it. E: ftp-master: section-is-dh_make-template [...] Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. Again, even if it has no big impact, why should we allow it? It's not hard to find (lintian will tell it), and not at all hard to fix. E: ftp-master: executable-in-usr-share-doc [...] Clearly a bug, but just as clearly not anything that breaks the package to the point of making it unsuitable for the archive. Please drop. Again, what is the advantage of dropping it? As files in /usr/share/doc should not be needed for the package to function (otherwise it is an even more serious bug), the biggest possible cost for the maintainer to fix this is a single rebuild. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 12:05:39PM +0100, Bernhard R. Link wrote:
* Steve Langasek vor...@debian.org [091101 11:23]:
Some problems I find with this list:
I think some of those complaints show a general disagreement about
what aims Debian has. Are we here to gain for quality or is allowing
the maximum amount of (free) software the primary goal?
E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate
[...]
This one has been mentioned previously in the thread. Yes, it's a blemish
in the package to list Upstream Author(s), but the lintian maintainers
have correctly marked this as being of normal severity. We should not be
blocking packages from the archive for such low-severity issues; please drop
this check.
I think a suggestion that a bug filed about this should be normal and
rejecting a package targeted at unstable or experimental with this can
be fully compatible.
Already having a problem with that in the archive is no problem (and
there is no reason to stall testing migration because of it). But why
should we allow a new version of this package uploaded? Even in case of
an NMU its no effort at all to fix it.
The check is as follows:
if (m,Upstream Author\(s\),) {
tag copyright-lists-upstream-authors-with-dh_make-boilerplate;
}
This can mean two things:
1. The list of upstream authors is the dh_make boilerplate, i.e.
useless.
2. The string which introduces the list of upstream authors is the same
as the dh_make boilerplate.
As for 1, I think we agree that this is a bug and probably packages
should get rejected if there is no list of upstream authors.
However, I think this is a non-sequitur; just because the maintainer did
not change the string Upstream author(s) by removing the paranthesis
(or, worse, wrote it themselves from scratcH) implies in any way that no
list of upstream authors is present.
Rather, lintian should check whether a proper list of upstream authors
is present (dunno, maybe there is even a seperate check for that),
possibly by checking for the actual dh_make boilerplate, namely put
author's name and email here. I have filed #553469 to this end.
As for 2, I guess this could be considered a stylistic problem, but no
way does it warrant rejecting the package from the archive.
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Hi Manoj, On Sat, Oct 31, 2009 at 01:03:00PM -0500, Manoj Srivastava wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Please respect the tradition and discuss mass-filing of bugs on debian-devel. thanks, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Michael Banck wrote: Hi Manoj, On Sat, Oct 31, 2009 at 01:03:00PM -0500, Manoj Srivastava wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Please respect the tradition and discuss mass-filing of bugs on debian-devel. +1 It seems that many of the bugs have a chance of false positives or should not be RC. Besides if policy is not meant as normative as you regulary claim, then these are very probably bugs in policy. As there are for some categories of bugs you files many packages not conforming. So either policy is wrong there or policy is normative which would mean that there are a lof of other bugs in policy that noone cares about fixing (or even filing). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Steve Langasek wrote: On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote: The second category is named error and the tags listed can not be overridden. Those are tags corresponding to packaging errors serious enough to mark a package unfit for the archive and should never happen. In fact, most of the tags listed do not appear in our archive currently, the few packages listed below should be easily fixable with their next upload. We will provide a static url for the list of tags soon, for now you can look at them using [1]. There are multiple files in [2] showing you the packages affected, together with the tags they hit. [1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags [2] http://ftp-master.debian.org/~joerg/lintian/ Since I'm not familiar with most of these lintian errors by name, I've run the list of fatal errors through lintian-info with the following script: $ wget -O - -q http://ftp-master.debian.org/~joerg/lintian/lintian.tags \ | sed -e'1,/error:$/d; s/^[[:space:]]\+-/E: ftp-master:/' | lintian-info I'd recommend that others do likewise, to get an appropriately large set of eyeballs on this change. Some problems I find with this list: E: ftp-master: wrong-file-owner-uid-or-gid N: N: The user or group ID of the owner of the file is invalid. The owner N: user and group IDs must be in the set of globally allocated IDs, N: because other IDs are dynamically allocated and might be used for N: varying purposes on different systems, or are reserved. The set of the N: allowed, globally allocated IDs consists of the ranges 0-99, N: 64000-64999 and 65534. Hmm, why is 100-999 not mentioned here or does this lintian check only check files shipped by the package as opposed to created in the postinst? N: Refer to Debian Policy Manual section 9.2 (Users and groups) for N: details. N: N: Severity: serious, Certainty: certain N: Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) If the check is only about files shipped by the package, I see no reason how this objection can be anything more than theoretical. If it's also about files created in the postinst: Steve: Can you give an example of a dynamically allocated non system user needed by a package? Dynamically allocated system users are covered in the range 100-999. E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. It would indeed be good to have consensus first on the severity and certainty of a lintian check before auto rejecting on it IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 01:17:43AM +, Chris Lamb wrote:
Can you please consider changing the above naming?
FWIW the actual reject messages are very clear and do not use these
terms (which I've changed in Git anyway, pending merge). Thanks.
Thanks a lot for your change!
BTW, in spite of what the messages were saying, I was more fearing about
the proposed terminology settling down in our lingo.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
[ Adding -qa to Cc ]
On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
For future handling: If we are adding tags to the list that will hit
more than a few packages we will send a notice to the d-d-a list.
I don't think it's appropriate for the ftp team to add any other checks
without notifying the project, regardless of how many packages are currently
affected. Please make sure you notify the project of /any/ additional rules
you apply at archive accept time.
ACK on this.
While I heartly welcome this addition, I see the centralization of the
tag decision process as potentially dangerous; not for power reasons,
but rather for the bad feelings (and related flamefests!) such changes
can leave behind and for the potential bottleneck risks (nowadays FTP
master is luckily and finally more stuffed than in the past, but
tomorrow who knows?).
So, I revamp a proposal I made in a corner of this thread:
Let the QA team decide upon the non overridable lintian errors.
Rationale: the QA mailing list is considered to be a rather good venue
to discuss and reach consensus, also it is one of the places where
lintian maintainers discuss various issues, and (trivially) QA is the
supposed place where to enforce project-wide QA.
(Full disclosure: yes, I'm currently an active QA member.)
Of course this change proposal is not meant to force FTP masters to
implement support for that. If they agree on such change, it would be
more than reasonable for them to ask for a specific patch implementing
that technically.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On Sun, Nov 01 2009, Michael Banck wrote: Hi Manoj, On Sat, Oct 31, 2009 at 01:03:00PM -0500, Manoj Srivastava wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Please respect the tradition and discuss mass-filing of bugs on debian-devel. This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. manoj -- 186,000 Miles per Second. It's not just a good idea. IT'S THE LAW. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Luk Claes wrote: Michael Banck wrote: Hi Manoj, On Sat, Oct 31, 2009 at 01:03:00PM -0500, Manoj Srivastava wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Please respect the tradition and discuss mass-filing of bugs on debian-devel. +1 It seems that many of the bugs have a chance of false positives or should not be RC. Which is why I checked. Out of the 97 candidates of the copyright being a dh template, only 3 bugs were filed: the ones not a false positive. Besides if policy is not meant as normative as you regulary claim, Rubbish. Policy is normative. Shit does not go into policy to beat people on the head with, but anything in policy is stuff you should follow. then these are very probably bugs in policy. As there are for some categories of bugs you files many packages not conforming. So either policy is wrong there or policy is normative which would mean that there are a lof of other bugs in policy that noone cares about fixing (or even filing). Which I plan on also filing bugs on, since policy is indeed normative. Get your act together, people. manoj -- Never forget what a man says to you when he is angry. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Charles Plessy wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian Wow, time goes so fast, it is already the season for attempting to delay the release! People ignoring bugs wilfully are possibly to blame, don't you think? manoj -- The man who has never been flogged has never been taught. Menander Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Manoj Srivastava sriva...@debian.org (01/11/2009): This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. Mraw, KiBi. signature.asc Description: Digital signature
Re: Lintian based autorejects
Cyril Brulebois wrote: Manoj Srivastava sriva...@debian.org (01/11/2009): This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Cyril Brulebois k...@debian.org (01/11/2009): Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. Make it DevRef (thanks, Kumar). Mraw, KiBi. signature.asc Description: Digital signature
Re: Lintian based autorejects
On Sun, Nov 01 2009, Cyril Brulebois wrote: Manoj Srivastava sriva...@debian.org (01/11/2009): This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. There is no policy 7.1.1: , | 7.Declaring relationships between packages | 7.1. Syntax of relationship fields | 7.2. Binary Dependencies - `Depends', `Recommends', `Suggests', |`Enhances', `Pre-Depends' ` If you mean developers reference, it is chock full of things that are style issues, or just plain wrong, in my opinion. This bit about why filing bugs on policy violations that lintian has been warning the maintainer about for ages is one of them. manoj -- Never give in. Never give in. Never. Never. Never. Winston Churchill Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Luk Claes wrote: Cyril Brulebois wrote: Manoj Srivastava sriva...@debian.org (01/11/2009): This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. Ah. Attacks based on my peronality, without actually checking to see what the facts are. There is no policy 7.1.1 that I have violated. manoj -- Finagle's Seventh Law: The perversity of the universe tends toward a maximum. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Hi Manoj, On Sun, Nov 01, 2009 at 10:12:07AM -0600, Manoj Srivastava wrote: On Sun, Nov 01 2009, Cyril Brulebois wrote: Manoj Srivastava sriva...@debian.org (01/11/2009): This was not a mass filing as I reaed it. Each bug was filed after being checked individually, and was filed one by one, manually. This was not a massive script which could have massive numbers of false positives, and thus these are just bugs filed about violations of Debian policy. Then you probably should read Policy 7.1.1. Individual checks or non-automation doesn't make it less massive. There is no policy 7.1.1: Please read the full thread before answering; the confusion was explained in the next mail. Thanks, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Steve Langasek vor...@debian.org writes: Some problems I find with this list: E: ftp-master: wrong-file-owner-uid-or-gid N: N: The user or group ID of the owner of the file is invalid. The owner N: user and group IDs must be in the set of globally allocated IDs, N: because other IDs are dynamically allocated and might be used for N: varying purposes on different systems, or are reserved. The set of the N: allowed, globally allocated IDs consists of the ranges 0-99, N: 64000-64999 and 65534. N: N: Refer to Debian Policy Manual section 9.2 (Users and groups) for N: details. N: N: Severity: serious, Certainty: certain Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) I wasn't aware of this. Do you know of a package that does this? And can we confirm that dpkg does handle this correctly (in other words, that the UID is ignored if the package is unpacked when the symbolic owner or group already exists on the system with a different UID)? E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate N: N: There is Upstream Author(s) in your copyright file. This was most N: likely a remnant from the dh_make template. N: N: There's either one upstream author, in which case you should remove N: the (s), or there are several upstream authors, in which case you N: should remove the ( and ). N: N: o/~ join us now and carefully edit debian/copyright files! o/~ N: N: Severity: normal, Certainty: certain N: This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. Lintian will almost certainly change here to use the other boilerplate of dh-make as opposed to keying off of Author(s). Once that's done, I think it's a fairly reliable indicator that the upstream author section of the dh-make boilerplate hasn't been edited. Personally, I'm happy to reject packages on that basis; it seems like the least that we could ask for maintainers to handle. Policy does require that debian/copyright be filled out, which is what this is trying to check. E: ftp-master: section-is-dh_make-template N: N: The Section: field in this package's control file is set to unknown. N: This is not a valid section, and usually means a dh_make template N: control file was used and never modified to set the correct section. N: N: Refer to Debian Policy Manual section 2.4 (Sections) for details. N: N: Severity: important, Certainty: certain Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. Seems to me like there's no point in asking the ftpmasters to come up with the source package section name because the package author didn't notice and set one before the first upload. Although I do agree that if we're going to make this a mandatory requirement for packages, Policy needs to be modified accordingly. E: ftp-master: binary-file-compressed-with-upx N: N: Debian does not allow binaries to be compressed by UPX. N: N: Severity: important, Certainty: certain Where is this documented? There's no mention of UPX in Debian Policy, and the only mention in the lintian changelog is a 2001 bug about adding support for /reading/ UPX executables. I suspect that this tag has never triggered, at least in the last few years. I've never devised a test case for it, and I've never seen it appear in the archive. E: ftp-master: copyright-file-is-symlink N: N: The copyright file /usr/share/doc/pkg/copyright must not be a N: symbolic link. N: N: Refer to Debian Policy Manual section 12.5 (Copyright information) for N: details. N: N: Severity: serious, Certainty: certain This looks to me like a bug in Policy. Why do we allow /usr/share/doc/$pkg to be a symlink, but disallow /usr/share/doc/$pkg/copyright as a symlink if it fulfills the same constraints? Will follow up on this separately via debian-policy. This should be discussed on debian-policy, yes. I'm personally rather annoyed that Ubuntu changed this rule for Ubuntu packages without, at least that I can recall, any consultation with Debian, but I think it's probably a reasonable change. E:
Re: Lintian based autorejects
Luk Claes l...@debian.org writes: As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. On behalf of the other four Policy maintainers who aren't Manoj and who so far as I know you don't have personal conflicts with, let me just say gee, thanks. This is how we can ensure that Policy continues not to be the document that it should be and people have to keep reading multiple documents to figure out what they're required to do. I have a limited amount of time to spend on Debian as a whole, which is divided between Lintian, Policy, and my own packages. Reading things like the above is extremely demoralizing and both tends to reduce that overall time committment and the amount of time I'm willing to invest in Policy in particular. If people are going to undercut or ignore that work, what's the point of me trying to fight upstream? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Luk Claes l...@debian.org writes: As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. Even if that were true, it's foolish to think this is a trait specific to one person. Everyone does this to some degree, and smearing one person rather than focussing on the facts is poor form. Instead, we should point out factual errors where they occur, and be willing to have the same done in return. Further to that, I don't know of any evidence that it's true in this case. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent […] Please. Your decision of what (and whom) to spend your time on is your own, but don't point to someone else as a pre-condition to your action. I hope you can address the facts of the matter and collaborate to improve Policy and Debian in general. -- \ “Ours is a world where people don't know what they want and are | `\ willing to go through hell to get it.” —Donald Robert Perry | _o__) Marquis | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 01:34:37PM -0800, Russ Allbery wrote: Luk Claes l...@debian.org writes: As before Manoj seems to interpret things and word things so they fit the way he can use them at the moment he needs them. As long as that continues I'm not going to even try to get the Debian Policy and RC bug policy consistent and the Debian Policy will remain not useful for anything release related as it will be incomplete and sometimes conflicting with actual practice. On behalf of the other four Policy maintainers who aren't Manoj and who so far as I know you don't have personal conflicts with, let me just say gee, thanks. This is how we can ensure that Policy continues not to be the document that it should be and people have to keep reading multiple documents to figure out what they're required to do. I think the ftp team and Manoj are in practice already achieving this, by making the archive block packages over issues that have never been violations of Policy must requirements and filing serious bugs for the same. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
Steve Langasek vor...@debian.org writes: On Sun, Nov 01, 2009 at 01:34:37PM -0800, Russ Allbery wrote: On behalf of the other four Policy maintainers who aren't Manoj and who so far as I know you don't have personal conflicts with, let me just say gee, thanks. This is how we can ensure that Policy continues not to be the document that it should be and people have to keep reading multiple documents to figure out what they're required to do. I think the ftp team and Manoj are in practice already achieving this, by making the archive block packages over issues that have never been violations of Policy must requirements and filing serious bugs for the same. All Manoj is doing is filing bugs. Anyone can do that. I don't see any reason why that would make anything harder in the long run. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. It's going to take changes to Lintian as well as Policy. I think it's a very positive step forward for the archive as a whole to start doing auto-rejects for some major Lintian tags, so I'm happy to help do the work there, as much as I have time to do so. (I'm still somewhat on vacation, although back to having regular access.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Hi, On Sonntag, 1. November 2009, Russ Allbery wrote: I think it's a very positive step forward for the archive as a whole to start doing auto-rejects for some major Lintian tags, I only agree partially. IMO auto-rejects for _introducing_ certain lintian tags (in sid/exp) is right as it is also for _keeping_ certian lintian tags - but those (lists of tags) should not neccessarily be the same (lists). Doing a munin upload following FHS for /var/www doesnt help, but rather harms, if the upgrade path is sloopy. And yet, some FHS violations just seem to be treated as important (#523920), while others are more than serious (not being able to upload with some FHS violations, which IMO have less consequences...) /var/www is a quite cosmetic issue while #523920 actually harms functionality... bla, Holger signature.asc Description: This is a digitally signed message part.
Re: Lintian based autorejects
Le Sun, Nov 01, 2009 at 08:38:56AM -0600, Manoj Srivastava a écrit : People ignoring bugs wilfully are possibly to blame, don't you think? So blame them. But as for reporting a large number of RC bugs, it has been shown in the previous release cycles that putting this in the frame of release goals was a good way to structure this work. To point at other's errors is not the most efficient way to contribute to our project, what is needed is manpower to implement the solution. Said differently in the so kind dialect of debian-devel: will you send patches? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 01:31:08PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: Some problems I find with this list: E: ftp-master: wrong-file-owner-uid-or-gid Policy 9.2 does /not/ prohibit shipping files with owners outside these ranges; it prohibits relying on user or group IDs outside these ranges being static, but there doesn't appear to be anything in Policy that prohibits creating the user in the package preinst and then unpacking the package such that ownership is applied by /name/. (Unless I'm mistaken, this is precisely what dpkg does.) I wasn't aware of this. Do you know of a package that does this? And can we confirm that dpkg does handle this correctly (in other words, that the UID is ignored if the package is unpacked when the symbolic owner or group already exists on the system with a different UID)? I've put together a hand-rolled test package that demonstrates this: http://people.debian.org/~vorlon/test-package_1_all.deb lintian reports the 'wrong-file-owner-uid-or-gid' error for this package, but you'll see that unpacking it results in a file /usr/share/doc/test-package/dynamically-owned owned by 'dynamic-test' regardless of which UID dynamic-test ends up with. To be honest, the last package I saw making use of such behavior was qmail-src, which is hardly an exemplary package; to land a package with these characteristics in the archive, you would effectively need to both build-depend on and pre-depend on another package which creates the user you need. (And in the case of qmail-src, the packages doing this were never in the archive - they were built on the end-user's system.) Nevertheless, if we're going to prohibit this behavior, that change should be ratified via the consensus-based Policy process. E: ftp-master: copyright-lists-upstream-authors-with-dh_make-boilerplate This one has been mentioned previously in the thread. Yes, it's a blemish in the package to list Upstream Author(s), but the lintian maintainers have correctly marked this as being of normal severity. We should not be blocking packages from the archive for such low-severity issues; please drop this check. Lintian will almost certainly change here to use the other boilerplate of dh-make as opposed to keying off of Author(s). Once that's done, I think it's a fairly reliable indicator that the upstream author section of the dh-make boilerplate hasn't been edited. Personally, I'm happy to reject packages on that basis; it seems like the least that we could ask for maintainers to handle. Policy does require that debian/copyright be filled out, which is what this is trying to check. We already have more correct checks for this, such as copyright-without-copyright-notice. Upstream Authors isn't something that's required to be listed anyway; either the authors are the same as the copyright holder and it's redundant with the copyright notice, or they're not the same and listing the authors is a nicety rather than a legal requirement. So while I'm personally annoyed any time I see this boilerplate, I still don't think we should be treating as fatal errors bugs whose real impact is minimal. E: ftp-master: section-is-dh_make-template Sections in source packages have minimal impact; the section that matters is the one specified in the archive override. There's no reason that the invalid default value given by dh_make should result in a package being rejected, when arbitrary other values for the field would not. Please drop this check. Seems to me like there's no point in asking the ftpmasters to come up with the source package section name because the package author didn't notice and set one before the first upload. Although I do agree that if we're going to make this a mandatory requirement for packages, Policy needs to be modified accordingly. Don't the ftpmasters make their own independent judgement on the section field anyway? I don't see how it helps to require the Section field be changed to /some/ other value when there's no guarantee that the new value is valid or correct. It's just one more thing to cause a round-trip for the maintainer. (N.B.: this check would fail even in the case of a package with a pre-existing section override in the archive. What's the sense of that? Let the maintainer get the nag mail after the fact telling them to reconcile the section, instead.) E: ftp-master: binary-file-compressed-with-upx N: N: Debian does not allow binaries to be compressed by UPX. N: N: Severity: important, Certainty: certain Where is this documented? There's no mention of UPX in Debian Policy, and the only mention in the lintian changelog is a 2001 bug about adding support for /reading/ UPX executables. I suspect that this tag has never triggered, at least in the last few years. I've never devised a test case for it, and I've never seen it appear in the archive.
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 02:31:19PM -0800, Russ Allbery wrote: All Manoj is doing is filing bugs. Anyone can do that. I don't see any reason why that would make anything harder in the long run. I have seen him assert in a bug on one package that I'm subscribed to that the package has been deemed too buggy to be in Debian, and that this justifies a serious severity on the bug - effectively affirming that the ftp team has the right to arbitrarily overrule Policy. I think that's a problem. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. The right process is: discuss; reach a consensus; amend Policy; enforce Policy. The wrong process is: the ftp team declares that certain bugs are blockers for inclusion in the archive, and Policy is left to scramble to keep up with documenting this. The ftp team are stewards of the archive, not autocrats. It's going to take changes to Lintian as well as Policy. I think it's a very positive step forward for the archive as a whole to start doing auto-rejects for some major Lintian tags, so I'm happy to help do the work there, as much as I have time to do so. I agree with this principle. What I object to is the arbitrary and non-consensual definition of major that's currently being used. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
On Mon, Nov 02, 2009 at 12:50:19AM +0200, Holger Levsen wrote: And yet, some FHS violations just seem to be treated as important (#523920), while others are more than serious (not being able to upload with some FHS violations, which IMO have less consequences...) Bug #523920 is not an FHS violation. The FHS requires that applications must be able to recover from manual deletion of *files* located under /var/cache; it says nothing about directories. (And deletion of contents under /var/lib -- game over, man.) /var/www is a quite cosmetic issue No, it's not. It interferes with admins' ability to use /var/www as their own webroot unmolested by packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 08:38:56AM -0600, Manoj Srivastava wrote: Wow, time goes so fast, it is already the season for attempting to delay the release! People ignoring bugs wilfully are possibly to blame, don't you think? And that justifies forcing these people to move your pet cosmetic issues to the top of their todo list? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote: On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote: For future handling: If we are adding tags to the list that will hit more than a few packages we will send a notice to the d-d-a list. I don't think it's appropriate for the ftp team to add any other checks without notifying the project, regardless of how many packages are currently affected. Please make sure you notify the project of /any/ additional rules you apply at archive accept time. ACK on this. While I heartly welcome this addition, I see the centralization of the tag decision process as potentially dangerous; not for power reasons, but rather for the bad feelings (and related flamefests!) such changes can leave behind and for the potential bottleneck risks (nowadays FTP master is luckily and finally more stuffed than in the past, but tomorrow who knows?). So, I revamp a proposal I made in a corner of this thread: Let the QA team decide upon the non overridable lintian errors. My only concern is that the ftp archive checks not be used to force changes in Policy. If the set of tags being drawn from is limited to those that are recognized as violations of Policy must requirements, then I have no opinion on who should decide which tags are blockers and which ones are not. If the candidate tags are *not* limited to that set, then I think we have a governance problem regardless of who's driving. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
Steve Langasek vor...@debian.org writes: On Sun, Nov 01, 2009 at 02:31:19PM -0800, Russ Allbery wrote: All Manoj is doing is filing bugs. Anyone can do that. I don't see any reason why that would make anything harder in the long run. I have seen him assert in a bug on one package that I'm subscribed to that the package has been deemed too buggy to be in Debian, and that this justifies a serious severity on the bug - effectively affirming that the ftp team has the right to arbitrarily overrule Policy. I think that's a problem. We have arguments over bug severity all the time, and therefore have an established mechanism for deciding who gets to declare things serious. I'm not sure why this is any different than the bug severity arguments we have regularly. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. The right process is: discuss; reach a consensus; amend Policy; enforce Policy. The wrong process is: the ftp team declares that certain bugs are blockers for inclusion in the archive, and Policy is left to scramble to keep up with documenting this. Yeah, I know how you feel about this. I'm not unsympathetic, but I personally don't mind the ftp team being somewhat more proactive than that. A lot of the bugs that they've marked as rejects are pretty obvious and easy-to-fix bugs, and I'm not sure why the project as a whole should spend time filing bugs about them when the Lintian checks in question have an essentially 0% false positive rate and the fix is fairly obvious. Even if it's not something that's going to break the package, why not do it right when it's fairly easy to do so? One can essentially always have an argument about anything we do in Debian that it should have been done a different way, in a different order, with different communication, and so forth. I'm not saying those arguments are wrong, just that I guess I feel like we'll get to a reasonable outcome and I'm not feeling too worried about it. There are some tags in the first set that probably shouldn't stay in there because my description above is not correct for them. Being iterative about this isn't a bad thing. I'd feel more comfortable saying that everything should go through the Policy process if the Policy process were working in a timely manner. It's not. I'm not sure how to fix that other than clone Debian Developers. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 03:09:56PM +0100, Luk Claes wrote: E: ftp-master: wrong-file-owner-uid-or-gid N: N: The user or group ID of the owner of the file is invalid. The owner N: user and group IDs must be in the set of globally allocated IDs, N: because other IDs are dynamically allocated and might be used for N: varying purposes on different systems, or are reserved. The set of the N: allowed, globally allocated IDs consists of the ranges 0-99, N: 64000-64999 and 65534. Hmm, why is 100-999 not mentioned here or does this lintian check only check files shipped by the package as opposed to created in the postinst? Because those IDs are dynamically allocated, so files shipped in the package belonging to those IDs are not guaranteed to be unpacked correctly - *unless* the owning user/group is created before unpack, using either a preinst or a pre-depends. If the check is only about files shipped by the package, I see no reason how this objection can be anything more than theoretical. It is about files shipped in the package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Archive section in debian/control (was Re: Lintian based autorejects)
On Sun, 2009-11-01 at 15:55 -0800, Steve Langasek wrote: Seems to me like there's no point in asking the ftpmasters to come up with the source package section name because the package author didn't notice and set one before the first upload. Although I do agree that if we're going to make this a mandatory requirement for packages, Policy needs to be modified accordingly. Don't the ftpmasters make their own independent judgement on the section field anyway? I don't see how it helps to require the Section field be changed to /some/ other value when there's no guarantee that the new value is valid or correct. It's just one more thing to cause a round-trip for the maintainer. (N.B.: this check would fail even in the case of a package with a pre-existing section override in the archive. What's the sense of that? Let the maintainer get the nag mail after the fact telling them to reconcile the section, instead.) What's the point of having the maintainer specify it in the first place? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Le Sun, Nov 01, 2009 at 04:17:15PM -0800, Russ Allbery a écrit : I'm not unsympathetic, but I personally don't mind the ftp team being somewhat more proactive than that. A lot of the bugs that they've marked as rejects are pretty obvious and easy-to-fix bugs, and I'm not sure why the project as a whole should spend time filing bugs about them when the Lintian checks in question have an essentially 0% false positive rate and the fix is fairly obvious. Even if it's not something that's going to break the package, why not do it right when it's fairly easy to do so? Dear Russ and everybody, I had a very brief look at the DD-list for the packages with unacceptable Lintian tags, and my gut feeling is that it contains a lot of unmaintained packages (maybe an UDD expert can confirm). Therefore, rejecting uploads is no incentive for them to be fixed. With this in mind, I think that Stefano's proposition to implicate the QA team in the management of which tag gets in the blacklist makes a lot of sense, as it will help the people who will do the hard work of orphaning, MIA checking, and bug fixing to prioritise and orgainse their efforts. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Steve Langasek wrote: On Sun, Nov 01, 2009 at 02:31:19PM -0800, Russ Allbery wrote: All Manoj is doing is filing bugs. Anyone can do that. I don't see any reason why that would make anything harder in the long run. I have seen him assert in a bug on one package that I'm subscribed to that the package has been deemed too buggy to be in Debian, and that this justifies a serious severity on the bug - effectively affirming that the ftp team has the right to arbitrarily overrule Policy. I think that's a problem. Well, just like the release team apparently has the right to arbitrarily overrule policy and decide when serious bugs are not serious -- as opposed to not RC -- yup. I do think that the ftp team decides what gets into the archive. They do this however they choose -- and I respect that decision. Just like the release team decides what gets ihnto the release. By whatever means they chose. Just like the release team decides on fiat what is RC policy, the ftp team decides what error make the packages too buggy for Debian. And poor mortals like me just kowtow, accept the rule-by-fiat, and try to conform. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. By the same token, the release team should not be accepting packages intot he release that ciolate the MUST requirements, neh? Or is the release team more equal than the ftp team? The right process is: discuss; reach a consensus; amend Policy; enforce Policy. Except when the release team decides to throw the policy to the wind and accept packages that wilfully violate policy MUST directives. Sounds like a double standard to me. The wrong process is: the ftp team declares that certain bugs are blockers for inclusion in the archive, and Policy is left to scramble to keep up with documenting this. And when the release team decides that stuff is not a vblocker, and policy is left scrambling as to what is a serious bug and what is not. The ftp team are stewards of the archive, not autocrats. The release team is a steward _and_ autocrats? Or how is the rc policy decided? It's going to take changes to Lintian as well as Policy. I think it's a very positive step forward for the archive as a whole to start doing auto-rejects for some major Lintian tags, so I'm happy to help do the work there, as much as I have time to do so. I agree with this principle. What I object to is the arbitrary and non-consensual definition of major that's currently being used. Seems like the same process the release team uses, in my humble opinion. All delegates feel like they are god, when it comes to their part of the process. manoj -- I think that's easier to read. Pardon me. Less difficult to read. Larry Wall in 199710120226.taa06...@wall.org Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 12:05:39PM +0100, Bernhard R. Link wrote: * Steve Langasek vor...@debian.org [091101 11:23]: Some problems I find with this list: I think some of those complaints show a general disagreement about what aims Debian has. Are we here to gain for quality or is allowing the maximum amount of (free) software the primary goal? There's an expression: you get what you test for. When you reject packages for failing specific quality checks, this does not ensure that you end up with packages of a higher quality overall, it only ensures that you end up with packages that pass those specific tests. And when the tests you've chosen to enforce are for low-impact issues, as is the case for most of those that I've objected to, then treating these as fatal when we know there are other, *higher* impact bugs that we can't or don't test for results in a distorted focus on passing the test instead of on making the package high-quality throughout. I would much rather see maintainers focus on fixing policy-compliant-but-broken-by-design config file handling in their packages than worrying about whether their package has an extra build-dependency with no practical effect. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
Steve Langasek wrote: And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. The right process is: discuss; reach a consensus; amend Policy; enforce Policy. The wrong process is: the ftp team declares that certain bugs are blockers for inclusion in the archive, and Policy is left to scramble to keep up with documenting this. The ftp team are stewards of the archive, not autocrats. Well said. With some obvious exceptions (BYHAND and maintainer disputes come to mind), it's the first time that ftp-masters take accept/reject decisions on regular package uploads and not just NEW packages. lintian already categorizes the bugs into “errors” and “warnings”. I'd personally prefer it if the ftp-master team didn't choose to hand-pick lintian tags themselves but trusted lintian and its maintainers. Possibly also by filling bugs to lintian or policy as appropriate. I'd also prefer it if the QA team was involved somehow in all these, since, well, this is about “quality assurance”, isn't it? While I also agree in principle with lintian-based autorejects and respect the work that has been done for this, I don't think that it fits the ftp-master job description to take such a decision. It may be an acceptable change in the role's power but it should at least be clear and communicated as such. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Charles Plessy wrote: Le Sun, Nov 01, 2009 at 08:38:56AM -0600, Manoj Srivastava a écrit : People ignoring bugs wilfully are possibly to blame, don't you think? So blame them. But as for reporting a large number of RC bugs, it has If there are a large number of RC bugs around, not reporting them does little to improve the quality of implementation. I see no benefit it hiding our problems. If you want to make it a release goal to make Squeeze free of all MUST directive violations of policy, please do not assume anyone is stopping you. manoj -- Ain't no right way to do a wrong thing. The Mad Dogtender Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Steve Langasek wrote: On Sun, Nov 01, 2009 at 08:38:56AM -0600, Manoj Srivastava wrote: Wow, time goes so fast, it is already the season for attempting to delay the release! People ignoring bugs wilfully are possibly to blame, don't you think? And that justifies forcing these people to move your pet cosmetic issues to the top of their todo list? Not my pet cosmetic issue. This is a decision taken by folks in charge of the archive as to what belongs in the archive. No more than the release teanm decides, mostly all by itself, as to what does or does not belong in a release, adding or not adding overrides to bugs, reducing violations of must directives to non-serious status all by themselves (not going through the policy change process at all). If one team can muck with policy related bug severities, and I have to just suck it up, I gave another important team the same benefit. manoj -- Revenge is a meal best served cold. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 07:54:52PM -0600, Manoj Srivastava wrote: Well, just like the release team apparently has the right to arbitrarily overrule policy and decide when serious bugs are not serious -- as opposed to not RC -- yup. I do think that the ftp team decides what gets into the archive. They do this however they choose -- and I respect that decision. Just like the release team decides what gets ihnto the release. By whatever means they chose. Where the release team policy on RC bugs has diverged from Policy, it has been to *relax* enforcement of Policy requirements on packages already in the archive, and not remove packages from testing for these bugs. The release team does not obligate anyone to *not* fix such bugs in their packages; it does not *prohibit* developers from doing NMUs to fix those bugs. It's within the power of any developer to decide that a bug is important enough to them that they'll fix it themselves before release, you don't need the release team's blessing to do so - unlike trying to get packages past the ftp team's new rules and into the archive. This is a difference between imposing new rules, and not forcing maintainers to comply with rules. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. By the same token, the release team should not be accepting packages intot he release that ciolate the MUST requirements, neh? Or is the release team more equal than the ftp team? Only you would think that this is the same token. All delegates feel like they are god, when it comes to their part of the process. Speak for yourself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Archive section in debian/control (was Re: Lintian based autorejects)
On Sun, Nov 01, 2009 at 10:12:11PM -0300, Felipe Sateler wrote: (N.B.: this check would fail even in the case of a package with a pre-existing section override in the archive. What's the sense of that? Let the maintainer get the nag mail after the fact telling them to reconcile the section, instead.) What's the point of having the maintainer specify it in the first place? - it provides a hint to the ftp team about the section it might belong in - it gives us a way to see when the ftp team and the maintainer disagree about the correct section (reminder mails to the maintainer on override mismatch) - it gives users useful information when inspecting the .deb manually - it gives sensible default values for the Packages file when importing into some package archive other than the official Debian archive All are valuable; but none are reasons to reject packages, IMHO. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Lintian based autorejects
Manoj Srivastava sriva...@debian.org writes: On Sun, Nov 01 2009, Steve Langasek wrote: And that justifies forcing these people to move your pet cosmetic issues to the top of their todo list? Not my pet cosmetic issue. This is a decision taken by folks in charge of the archive as to what belongs in the archive. […] That's a salient point here: Manoj is filing bugs for issues the FTP team has declared to be bugs. It's rather disingenuous to claim now that they are one person's “pet cosmetic issues”. If one team can muck with policy related bug severities, and I have to just suck it up, I gave another important team the same benefit. This, though, is a distraction. I think there is something to what you're saying about a double standard, but it's not relevant in this case. Just because one has criticisms of team FOO's behaviour does not mean it's relevant when discussing team BAR's behaviour. If what you're doing has merit (and in this case I personally think it does), then discuss its merits instead of the flaws you see in others. -- \ “We reserve the right to serve refuse to anyone.” —restaurant, | `\ Japan | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Charles Plessy wrote: Le Sun, Nov 01, 2009 at 04:17:15PM -0800, Russ Allbery a écrit : I'm not unsympathetic, but I personally don't mind the ftp team being somewhat more proactive than that. A lot of the bugs that they've marked as rejects are pretty obvious and easy-to-fix bugs, and I'm not sure why the project as a whole should spend time filing bugs about them when the Lintian checks in question have an essentially 0% false positive rate and the fix is fairly obvious. Even if it's not something that's going to break the package, why not do it right when it's fairly easy to do so? Dear Russ and everybody, I had a very brief look at the DD-list for the packages with unacceptable Lintian tags, and my gut feeling is that it contains a lot of unmaintained packages (maybe an UDD expert can confirm). Therefore, rejecting uploads is no incentive for them to be fixed. If they are unmaintained, nothing we do can make the maintaier fix things. At least filing bugs makes the problems visible, and we ensure that the next drive-by upload will actually fix these policy violations. With this in mind, I think that Stefano's proposition to implicate the QA team in the management of which tag gets in the blacklist makes a lot of sense, as it will help the people who will do the hard work of orphaning, MIA checking, and bug fixing to prioritise and orgainse their efforts. Why can't the presence of appropriate bugs help these folks do the same thing? manoj -- You boys lookin' for trouble? Sure. Whaddya got? -- Marlon Brando, The Wild Ones Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Steve Langasek wrote: On Sun, Nov 01, 2009 at 07:54:52PM -0600, Manoj Srivastava wrote: Well, just like the release team apparently has the right to arbitrarily overrule policy and decide when serious bugs are not serious -- as opposed to not RC -- yup. I do think that the ftp team decides what gets into the archive. They do this however they choose -- and I respect that decision. Just like the release team decides what gets ihnto the release. By whatever means they chose. Where the release team policy on RC bugs has diverged from Policy, it has been to *relax* enforcement of Policy requirements on packages already in the archive, and not remove packages from testing for these bugs. The Which arguably makes the release buggier. I am not sure that is a good thing. But then, I am not in charge of releases, so what I think carries no weight, neh? release team does not obligate anyone to *not* fix such bugs in their packages; it does not *prohibit* developers from doing NMUs to fix those bugs. It's within the power of any developer to decide that a bug is important enough to them that they'll fix it themselves before release, you don't need the release team's blessing to do so - unlike trying to get packages past the ftp team's new rules and into the archive. What you have been objecting to in my bug filing is that I let the ftp-masters decide what severity the bugs are at, just like let the release team decide when the bugs are not serious (as opposed to doing squeeze-ignore's). If you think one is wrong, the other is as well. If the teams in chage of the release/archive do not change the bug severities, I'll be happy to only file bugs at the severity levels as set in policy and on bugs.debian.org. This is a difference between imposing new rules, and not forcing maintainers to comply with rules. We knew this decision by the ftp team was coming for a while, and will require checking against our other documents and probably changes to the severity of various rules. And I objected before when this was first proposed that the ftp team should not be auto-rejecting from the archive for any issues that are not violations of Policy must requirements. By the same token, the release team should not be accepting packages intot he release that ciolate the MUST requirements, neh? Or is the release team more equal than the ftp team? Only you would think that this is the same token. Both cases reset severities from the defaults for bugs related to policy violations. manoj -- Cunning and deceit will every time serve a man better than force. Niccolo Machiavelli Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Faidon Liambotis parav...@debian.org writes: lintian already categorizes the bugs into “errors” and “warnings”. I'd personally prefer it if the ftp-master team didn't choose to hand-pick lintian tags themselves but trusted lintian and its maintainers. Possibly also by filling bugs to lintian or policy as appropriate. The Lintian maintainers (at least me) explicitly asked the ftp team to not do that. I know I don't want to have that responsibility; I want someone else to look at what Lintian is doing and make an independent decision. This way, two groups need to have reviewed the check and agree that it's worth issuing independently. Also, note that the ftp team are at least project delegates, whereas the Lintian maintainers are just package maintainers. If we have a governance problem with the ftp team making this decision, it would be even worse if the Lintian maintainers were making this decision. I'd also prefer it if the QA team was involved somehow in all these, since, well, this is about “quality assurance”, isn't it? I'm a little surprised to see the QA team brought up in this context since I haven't really seen that much overlap between the sort of checks that Lintian is doing and the sort of checks that the QA team has been working on except at a very high level. But I'd absolutely love to have them involved if they're interested. While I also agree in principle with lintian-based autorejects and respect the work that has been done for this, I don't think that it fits the ftp-master job description to take such a decision. I do think that they sought consensus on the idea, and while there were objections in the previous discussion as well, my impression was that the general feeling of the project was in favor. However, I personally am in favor and therefore may be a biased judge of consensus. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01 2009, Ben Finney wrote: Manoj Srivastava sriva...@debian.org writes: On Sun, Nov 01 2009, Steve Langasek wrote: And that justifies forcing these people to move your pet cosmetic issues to the top of their todo list? Not my pet cosmetic issue. This is a decision taken by folks in charge of the archive as to what belongs in the archive. […] That's a salient point here: Manoj is filing bugs for issues the FTP team has declared to be bugs. It's rather disingenuous to claim now that they are one person's “pet cosmetic issues”. They are all violations of should and higher debian policy directives. They are bugs, no question of that. I just let the ftp master's decision allow me to file them as serious (too buggy to be accepted in the archive), and I was pretty up front about mentioning that in the bug report. If what you're doing has merit (and in this case I personally think it does), then discuss its merits instead of the flaws you see in others. The facts on the ground are that currently, packages with these bugs can't get into the archive. Personally, think the ftp masters are as much in charge of the archive, as, say, the release team is in charge of the release, and thus they have a say as to what gets in. Steve does not agree, but that does not change that *today*, these packages are too buggy to get in. Now, once we go through the GR dance, the situation might change. At that point, these bugs can be downgraded back to important. But they remain valid bugs, and I am not going to not file valid bugs against packages or ask permission, pretty please, so I might file a bug to say that a package is buggy. manoj who spent over 30 hours checking for and filing 219 bugs against packages which violate policy, and is getting somewhat irritated by all the kvetching -- Well thaaat's okay. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Manoj Srivastava sriva...@debian.org writes: who spent over 30 hours checking for and filing 219 bugs against packages which violate policy, and is getting somewhat irritated by all the kvetching Thank you for doing this. I've looked at doing it from time to time based on Lintian results and always shied away from the work, but I think it's valuable work and bugs that should be filed. Regardless of what severity they end up at, they're bugs, and I think we're better off for having them recorded. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 07:29:23PM -0800, Russ Allbery wrote: Also, note that the ftp team are at least project delegates, whereas the Lintian maintainers are just package maintainers. If we have a governance problem with the ftp team making this decision, it would be even worse if the Lintian maintainers were making this decision. No, in fact the opposite is true. Any function that is correctable by any member of the developer body is inherently better than one that is under the control of a small group that has been given superpowers, legitimately or not, by virtue of the fact that it is correctable by any member of the developer body. Of course we will never come to accept that idea as a group, and people will foam at the mouth about the Constitution and the DPL, and other people will foam at the mouth about the same old power issues that come up over and over again cyclically with different faces, and one day I will learn to keep my mouth shut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Hi, On Dienstag, 27. Oktober 2009, Simon McVittie wrote: On Tue, 27 Oct 2009 at 15:06:07 +0100, Joerg Jaspert wrote: The second category is named error and the tags listed can not be overridden. I don't think it's appropriate to make, for instance, dir-or-file-in-var-www instantly fatal without following the usual mass-bug-filing procedure. If you'd like mass bugs to be filed based on these lintian tags but don't have time, let me know if I can help (I can't promise to deal with all of them). I'm not arguing that dir-or-file-in-var-www is not a bug - it is - but it's a technical problem that needs a transition (moving files around, reconfiguration, probably a migration path in many cases), rather than just some incorrect boilerplate in debian/copyright that can easily be fixed before uploading. Thankfully, we have a procedure to deal with buggy packages, i.e. a bug tracking system :-) together with processes for NMU or removal of packages that are too buggy. +1 from me for these two paragraphs. Currently I have no idea how to fix any issues with munin in unstable (as I dont have a migration plan/path for /var/www/munin which I like/consider sensible) and the idea to upload munin 1.4 (which is scheduled for release in November/December this year) to experimental is stalled atm too, for the same reason. Which IMO is pretty sad. I'm in favour of auto-rejecting packages with very serious packaging problems, but auto-rejecting makes bugs worse than RC, so IMO it's necessary to be more conservative about existing packages +1 again. - if your package has an RC bug open, you can still upload it to fix other (possibly RC) bugs, but if your package is being auto-rejected, you have no choice but to fix the auto-reject before the next (successful) upload. I realise this is somewhat deliberate, to give maintainers a strong incentive to fix their packages. However, it seems disproportionate: we don't enforce that for RC bugs, even those with severity 'critical', so this is effectively creating a class of bugs more severe than 'critical'. It seems unwise to do that without the relevant bugs at least being tracked as RC first! Some examples of tags I consider reasonable to auto-reject, because they should be easy to fix (but many of them should be bug reports anyway): - binary-file-compressed-with-upx - copyright-lists-upstream-authors-with-dh_make-boilerplate - missing-dependency-on-perlapi - section-is-dh_make-template Some examples of tags where I do not consider this reasonable until bugs have been filed: - statically-linked-binary - mknod-in-maintainer-script - debian-rules-not-a-makefile - dir-or-file-in-var-www Again, +1. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Lintian based autorejects
On Sat, Oct 31 2009, Holger Levsen wrote: Some examples of tags where I do not consider this reasonable until bugs have been filed: - statically-linked-binary - mknod-in-maintainer-script - debian-rules-not-a-makefile - dir-or-file-in-var-www Again, +1. Well, at this rate, all such bugs whill have been filed in a week or so. manoj getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian -- 'Tis true, 'tis pity, and pity 'tis 'tis true. Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
In article 87hbtfxwyz@anzu.internal.golden-gryphon.com you wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian I think packages which had no bug reports before are clearly not too buggy to be in Debian. Gruss Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Bernd Eckenfels bernd...@eckenfels.net writes: you wrote: getting around to filing bugs on policy MUST violations and others that make the package too buggy to be in Debian I think packages which had no bug reports before are clearly not too buggy to be in Debian. No bug reports could just be a sign that no one uses the package, or that the latent problem that the Policy rule is designed to protect against has not yet happened with that particular package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Stefano Zacchiroli wrote: Can you please consider changing the above naming? FWIW the actual reject messages are very clear and do not use these terms (which I've changed in Git anyway, pending merge). Thanks. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org `- signature.asc Description: PGP signature
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
As there are certain lintian tags that should only appear in very rare
cases we have created two categories. The first is named warning, tags
snip
The second category is named error and the tags listed can not be
overridden. Those are tags corresponding to packaging errors serious
On a second read of the proposal, it occurred to me (and a handful of
other DDs in private communications agreed) that the above naming choice
of warning and error can be a bit unfortunate. In fact, lintian
already has its own notion of warning/error and having the naming
overloaded by dak messages that are based on lintian outcome can be
quite confusing.
Can you please consider changing the above naming?
The first alternative naming that comes to my mind is non-fatal errors
vs fatal errors. It is not particularly exciting as a choice, but I
believe it would be better than warning/error.
Thanks in advance,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 05:51:12PM -0700, Ryan Niebur wrote: I prefer Author(s). Less text to update when a new author is added. It does no harm and affects nothing in the end result. I'm curious as to why you think Author(s) is a bad thing? It's the sort of thing you get in automatically generated text where the programmer hasn't bothered to figure out if something is a plural or not. Like I say, I don't think it's serious in itself but it seems wishlist. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Wed, Oct 28, 2009 at 09:37:53AM +0100, Jan Hauke Rahm wrote: On Tue, Oct 27, 2009 at 07:42:21PM -0700, Russ Allbery wrote: Please note that the intention of the Lintian tag is not to complain about people using Author(s), but to catch people who have used dh-make and then never completed the relevant section of the resulting debian/copyright file, which I think we would all agree is an obvious RC bug. Yes, so can't we introduce a bogus line in dh-make's default copyright file? Something like a trap for lintian? If this is really about catching packages where the maintainer forgot to even think about debian/copyright, this would work perfectly and probably without false positives. dh_make already inserts put author's name and email here, I had guessed that lintian would check for that and error out otherwise, but if this is not yet the case, maybe it can be added. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
