Re: Lintian based autorejects

[Frans Pop-3]

On Tuesday 27 October 2009, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be

Looks like it's named "nowayout".

> overridden. Those are tags corresponding to packaging errors serious
> enough to mark a package unfit for the archive and should never happen.

Please move "no-standards-version-field" to "wayout".

Because udebs don't follow loads of policy requirements (which is allowed
because of their nature), and because that makes blindly updating the
standards version with policy updates a rather meaningless job, the D-I
team has removed the standards version fields from most source packages
that produce only udebs; they include a lintian override for that.

So having that tag in nowayout would mean that uploads of udebs will start
failing massively.

Thanks,
FJP

[Simon McVittie-7]

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.

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 - 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

Regards,
    Simon

[Mike Hommey]

On Tue, Oct 27, 2009 at 02:57:35PM +0000, Simon McVittie wrote:

> <snip>
> 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

I tend to agree with you here, though I would suggest keeping all tags
as strong rejects for NEW packages, and by NEW, here, I mean *totally* new
packages, not those existing source packages that add a new binary
package.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert]

On 11916 March 1977, Frans Pop wrote:

> Looks like it's named "nowayout".

Thats just because I didnt copy the very latest version of it over to
ries. Done now.

>> overridden. Those are tags corresponding to packaging errors serious
>> enough to mark a package unfit for the archive and should never happen.
> Please move "no-standards-version-field" to "wayout".

> Because udebs don't follow loads of policy requirements (which is allowed
> because of their nature), and because that makes blindly updating the
> standards version with policy updates a rather meaningless job, the D-I
> team has removed the standards version fields from most source packages
> that produce only udebs; they include a lintian override for that.

> So having that tag in nowayout would mean that uploads of udebs will start
> failing massively.

Frank, as our lintian interface :), said that lintian should detect it
runs on/with udebs and then disable checks that make no sense for udebs.
So if lintian warns for such packages as udebs about things udebs dont
actually have to follow, that should probably adapted there, though we
can easily move tags if its not possible to detect in lintian.

Now, in this case there is no need to move it, as looking at
http://lintian.debian.org/tags/no-standards-version-field.html shows
that we do not see any of the D-I packages, so I assume lintian is
detecting it properly nd we do not need to move it.

Should an upload fail because of this and/or lintian behaving funnily we
can still look at it then, but I assume it wont.

--
bye, Joerg
You're in good shape for being a Debian, with a SAP background
... anything has to look good from there...


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

On Tuesday 27 October 2009, Joerg Jaspert wrote:
> Now, in this case there is no need to move it, as looking at
> http://lintian.debian.org/tags/no-standards-version-field.html shows
> that we do not see any of the D-I packages, so I assume lintian is
> detecting it properly and we do not need to move it.

Ah, it seems a test for this was indeed added in Lintian in the not too
distant past. That also explains why [1] shows "unused override" for many
of our packages for that tag.

Note that both live-installer and userdevfs are listed on the page and
*are* D-I packages.

live-installer also has a deb, and thus _should_ have a standards version.
I'll file a BR.

userdevfs only has a udeb, so that looks like a bug somewhere.
Ah, I see the reason. Current version in the archive uses XB-Package-Type
instead of XC-Package-Type. But that has already been corrected in SVN, so
should get resolved with the next upload.

Thanks for the reply Joerg. Guess I'll also drop all the no longer needed
overrides for our packages.

Cheers,
FJP

[1] http://lintian.debian.org/full/debian-boot@...


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Tue, Oct 27 2009, Simon McVittie wrote:

> 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

        I disagree about this one. This is a violation of a must rule in
 policy, and there is no reason to not fix it (since a mekfile can call
 anything you need it to). Seems like the violators are mostly vdr
 related (and leave, which was last checked against ancient policy
 version 3.6.0).

        If you want bugs filed, OK, sure. Need to do something when
 bored with job interview prep.

>     - dir-or-file-in-var-www

        manoj
--
If it wasn't so warm out today, it would be cooler.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernhard R. Link-2]

* Joerg Jaspert <joerg@...> [091027 15:06]:
> 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.

Are there any plans to extend this on binary-only uploads?
"package-contains-info-dir" is an example for something that depends on
the build environment so that it might only show up on some architectures
but not in the packages uploaded with the source (as usually the maintainer
will be told my lintian if building in such a way that it happens and thus
fixed it in that case).

Hochachtungsvoll,
        Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
        Niklaus Wirth


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Geissert-4]

Hi Joerg, ftp people,

2009/10/27 Joerg Jaspert <joerg@...>:
> Heyho,
>
> 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.

\o/! many thanks for that, it is much appreciated that we finally have
an automated filter.

>
> Those automated rejects will only be done on sourceful uploads to
> unstable and experimental.

Great, thanks; I was afraid this could interfere with uploads to stable.
[...]
> If you think we should add tags or categorize them differently, feel
> free to mail us at ftpmaster@....
>

Yes, please add wrong-file-owner-uid-or-gid to the list of "errors"
(although this one makes sense to be applied on a per-binary basis).
And why not FSSTND-dir-in-usr?
package-contains-info-dir-file detects some cases where it would
currently prevent the package from being installed, so its addition to
the warnings list would be great.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Tue, Oct 27, 2009 at 06:06:12PM +0100, Bernhard R. Link wrote:
> * Joerg Jaspert <joerg@...> [091027 15:06]:
> > Those automated rejects will only be done on sourceful uploads to
> > unstable and experimental.
> Are there any plans to extend this on binary-only uploads?

First there needs to be proper handling of REJECT of binary-only
uploads. Currently the mails (if it all) go to the buildd, not to the
maintainer.

Bastian

--
Captain's Log, star date 21:34.5...


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thijs Kinkhorst-4]

On tiisdei 27 Oktober 2009, 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.

This will be a useful development, but I question the choice of which tags to
reject. Indeed "worst policy violations" or prevention of time wasted seem
like sound goals. But why then reject on the following tag:
- copyright-lists-upstream-authors-with-dh_make-boilerplate?

Basically this tag is triggered if you write "Author(s):" instead
of "Authors:" in debian/copyright. If I would encounter that somewhere I
doubt I would file even a minor bug against the package, let alone consider
it one of the "worst policy violations". Or whose time is wasted with someone
writing "Author(s)"? Rejecting uploads for that, basically a graver action
than calling something RC, seems disproportional to me.


Thijs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 27/10/09 at 14:57 +0000, Simon McVittie wrote:

> 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

I fully agree. Auto-rejecting should be limited to errors we absolutely
do not want in our archive. For everything else, RC bugs should be used
instead.

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.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert]

>> Those automated rejects will only be done on sourceful uploads to
>> unstable and experimental.
> Are there any plans to extend this on binary-only uploads?

No. Not much helpful to reject buildd packages.

--
bye, Joerg
Von einem Besucher auf dem LT:

Die 3 Microsoft-Leute auf Ihrem Stand müssen sich vorkommen wie 3
Mönche im Puff.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Cyril Brulebois-4]

Joerg Jaspert <joerg@...> (27/10/2009):
> No. Not much helpful to reject buildd packages.

Like the ones totally broken due to “toolchain” issues? The
dbus/debhelper joke comes to mind: The sourceful upload was
OK. Due to bad timing, the autobuilt packages were not.

Mraw,
KiBi.

[Manoj Srivastava]

On Tue, Oct 27 2009, 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.

        Sounds like a plan. I'm starting to file serious bugs on these
 packages. If you do so, please set the user and tag as:

User: lintian-maint@...
Usertags: <actual lintian tag here>

        About time we took a stand against junk packages.

        manoj
--
"Help save the world!"  -- Larry Wall in README
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ryan Niebur-3]

On Tue, Oct 27, 2009 at 09:15:58PM +0100, Thijs Kinkhorst wrote:

> On tiisdei 27 Oktober 2009, 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.
>
> This will be a useful development, but I question the choice of which tags to
> reject. Indeed "worst policy violations" or prevention of time wasted seem
> like sound goals. But why then reject on the following tag:
> - copyright-lists-upstream-authors-with-dh_make-boilerplate?
>
> Basically this tag is triggered if you write "Author(s):" instead
> of "Authors:" in debian/copyright. If I would encounter that somewhere I
> doubt I would file even a minor bug against the package, let alone consider
> it one of the "worst policy violations". Or whose time is wasted with someone
> writing "Author(s)"? Rejecting uploads for that, basically a graver action
> than calling something RC, seems disproportional to me.
>

*agree*
I completely disagree with this lintian warning and prefer to use
"Author(s)".

--
_________________________
Ryan Niebur
ryanryan52@...

[Mark brown-22]

On Tue, Oct 27, 2009 at 03:59:52PM -0700, Ryan Niebur wrote:

> I completely disagree with this lintian warning and prefer to use
> "Author(s)".

I do agree that rejecting on this is probably excessive but I'm curious
as to why you think it's incorrect?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bernd Eckenfels-11]

In article <8763a0fq30.fsf@...> you wrote:
>        About time we took a stand against junk packages.

Not helpfull to attack people. You will just lose a lot developers when they
feel second class.

Gruss
Bernd


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Barry deFreese-2]

Lucas Nussbaum wrote:
> On 27/10/09 at 14:57 +0000, Simon McVittie 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.

I like that plan!

Barry deFreese


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen Gran]

This one time, at band camp, Cyril Brulebois said:
> Joerg Jaspert <joerg@...> (27/10/2009):
> > No. Not much helpful to reject buildd packages.
>
> Like the ones totally broken due to “toolchain” issues? The
> dbus/debhelper joke comes to mind: The sourceful upload was
> OK. Due to bad timing, the autobuilt packages were not.

What that has to do with lintian based auto-rejects, I'm not really
sure, but thanks.

Mryawn.
--
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@... |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[Ben Finney-5]

Bernd Eckenfels <bernd-09@...> writes:

> In article <8763a0fq30.fsf@...> you wrote:
> >        About time we took a stand against junk packages.
>
> Not helpfull to attack people. You will just lose a lot developers
> when they feel second class.

Non sequitur. Manoj's advice has nothing to do with attacking *people*.

People are distinct from the packages they maintain. We need to be free
to mercilessly point out flaws in packages, without any connotation of
attacking the package maintainer. The maintainer has responsibility for
those flaws, but that in no way implies a flaw in the person, unless
they can't get over themselves to argue objectively or fix the problem.

If we can't practice egoless package maintenance, we're getting in the
way of improving the quality of the Debian operating system.

--
 \       “Never use a long word when there's a commensurate diminutive |
  `\                                    available.” —Stan Kelly-Bootle |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...