gmane.linux.debian.devel.general

Re: NEW processing

Raphael Geissert — 2008-12-04T02:48:20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Tautschnig wrote: [...] What about encouraging those impatient folks (please don't be just exclusive to DDs) to track down (at times from mentors.d.n) the source package and review it themselves. Any finding should be notified to the maintainer and CCed to ftpmasters so that they can REJECT the package if deserved, helping out instead of just pestering. Cheers, Raphael Geissert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkk3RPUACgkQYy49rUbZzlpVoACeLpFsrZE6tj/N1+J3DKKm8N/F QbgAnAyIc8X4yOd7+VdunzXszaKYqENe =/R5Z -----END PGP SIGNATURE-----

Re: NEW processing

Raphael Geissert — 2008-12-04T02:40:12

[...] Except when they get their package back in NEW for some reason. [...] The problem is that many people asking for reviews in -mentors as soon as some issues are found on their packages they just forget about them; making the whole process just a waste of time. I of course do not want to say that reviewing packages in -mentors is always useless, but here again we need to deal with yet another social problem which is the lack of willingness by some people to work on their package to get it in shape. Cheers, Raphael Geissert

Re: NEW processing

Raphael Geissert — 2008-12-04T02:28:59

No need to make it exclusive to new packages. $ lintian -I --exp-output format=letterqualifier sysvinit_2.86.ds1-61_i386.deb I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/initscript.5.gz:28 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/initscript.5.gz:35 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/initscript.5.gz:36 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/inittab.5.gz:218 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/inittab.5.gz:226 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man5/inittab.5.gz:227 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man8/init.8.gz:169 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man8/runlevel.8.gz:26 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man8/shutdown.8.gz:61 I[W!]: sysvinit: hyphen-used-as-minus-sign usr/share/man/man8/shutdown.8.gz:62 I[W!]: sysvinit: no-md5sums-control-file E[I!]: sysvinit: depends-on-essential-package-without-using-

Re: volunteers wanted for driving/finalizing a DEP ondebian/copyright format

Noah Slater — 2008-12-04T02:24:52

Heh heh. Sure thing, Charles.

Re: NEW processing

Russ Allbery — 2008-12-04T01:03:49

Minor correction: lintian warnings are those points that the Lintian maintainers are either not confident are indicative of bugs or indicate bugs that are not severity important or higher. There should be no minor-severity bugs that result in lintian errors. If there are, that's a bug in Lintian. Please report it. The lowest threshold that produces an E tag is severity: important, likelihood: possible. The severity classifications are new, based on a GSoC project by Jordà Polo (who did an excellent job), and have only been checked over comprehensively a few times. There may be misclassifications remaining, which we'd be happy to fix.

Re: NEW processing

Amaya — 2008-12-04T01:01:49

Nah, blame me, for letting búbúlle pamper me with allowing me to pronounce his nickname as I wish ;) I assure you Spain has nothing to do with this :)

Re: NEW processing

Amaya — 2008-12-04T00:59:57

Re: NEW processing

Steve Langasek — 2008-12-04T00:51:34

The fallacy here is to assume that lintian cleanliness is strongly correlated with high package quality. It isn't. There are certain lintian *errors* that are almost certain indicators of *poor* package quality, but this is not proof of the converse.

Re: volunteers wanted for driving/finalizing a DEP ondebian/copyright format

Charles Plessy — 2008-12-04T00:50:15

Le Wed, Dec 03, 2008 at 08:52:17PM +0000, Noah Slater a écrit : Hi Noah, I think that you will unfortunately go through this if you want to reach the users of the format (me for instance). But you have two tools for your success: - The wiki, in which you can record objections and counter-arguments. - The delete button of your mail browser. Rendez-vous after Lenny release on -devel :)

Re: NEW processing and lintian warnings.

Charles Plessy — 2008-12-04T00:37:45

Le Wed, Dec 03, 2008 at 12:41:50PM -0800, Michael Tautschnig a écrit : Hi everybody After reading the thread this morning, I really feel that there is a consensus that packages with "lintian errors" have to be rejected, ideally in an automagic manner. This is probably a good idea, with the caveat that it will make lintian and NEW interdependent in the same way that the "serious" bug severity has been phagocyted by policy bugs: expect complaints about the classification of lintian output based on the fact that it makes packages rejected. Nevertheless, for complete cleaning of "lintian warnings", I really think that the Project is going the wrong way. We start to micromanage Upstream code and accumulate patches that are definitely minor improvements, like adding whatis entries to manpages. We really should leverage Upstream's workforce and report the problems there instead of fixing them locally at the expense of our limited time. With this, "lintian warnings" become not only useful to Debian but also to t

Re: For those who care about pam-ssh: RFC

Luca Niccoli — 2008-12-04T00:33:30

2008/12/3 Jens Peter Secher gmail.com>: As a user, I see a regression: I have < at >include (pam)-ssh-auth before < at >include common-auth in my confguration, and I use two different passwords for my local account and my ssh key; this way if I know I'll be networking I take the bother to type the long-and-very-secure password to unlock my key and get acces to the computer, otherwise I just hit enter and I'm asked for the simpler local password (I don't think there's really a point in a strong password if someone has physical access to the computer). This doesn't work anymore out-of-the-box. Of course switching back to the old behaviour is not a big deal, so I'm not complaining, just wondering if this change makes the package better fitted to what the user is expecting from it. Maybe I'm the odd one, I don't know; let me just point that with the new way the unlock of the key is not what grants you the access to the machine (which is what I would think ssh-auth do), IFUC. I also noted is that pam-s

Re: NEW processing

Steve Langasek — 2008-12-04T00:22:05

I submit that lintian warnings are entirely out of scope for the task the project has entrusted to the ftp team, and that mentioning this at all as a factor in making the NEW queue "painless" indicates there's a problem with the process as implemented. - lintian *warnings* are those points that even the lintian maintainers are not confident are always indicative of bugs. There's really no reason for the ftp team to look at these as a condition for NEW acceptance. - Even with lintian errors, there are many that are definitely bugs but which should not be grounds for a reject from the archive because they're *minor* bugs, and the ftp team should not be in the business of enforcing lintian cleanness as a condition of acceptance into the archive because this is (and always will be) a false measure of package quality.[1] - To the extent that bugginess tests are enforced by the ftp team, they should be *symmetric*. If a bug wouldn't be grounds for kicking the package out of the archive, it al

Re: NEW processing

Stefano Zacchiroli — 2008-12-03T23:46:52

/me loves the Spanish pronunciation of my (nick)name :-) Besos.

Re: NEW processing

Amaya — 2008-12-03T23:45:42

Wrong! The overrriden ones should be a lot of fun to look at.

Re: NEW processing

Amaya — 2008-12-03T23:44:03

I think that understand what the FTP masters do, how they do it, and the already documented errors that they look for would make us, as maintainers, be a lot more aware of what can go wrong with our NEW packages. That's why I believe that helpful input, in the line of Kalle Kivimaa, is crucial in order to make their jobs easyer. Maybe providing some sort of updated unstable to test our packages on, in case we don't trust that our system has not become too tainted due to intensive testing, would help. I know some of us do not have the resources to easily build cleaner testing targets.

Re: NEW processing

Amaya — 2008-12-03T23:29:30

This imput seems to me the most useful contribution to this thread, Zach came up with a very good idea inmediately. I think tests are important in our strive for quality, and I think they could be very much automatic, just as Zach pointed out. An automatic lintian reject if "E:" saves time for mainainers, ftp-masters and because of this everyone wins (users also are available to test packages much sooner). If we could get every ftp-team involved members in producing this kind of useful feedback, we could come up with other good ideas as on how to autmatize these check saving the ftp-team the fustration of reiteration of simple tasks, so that their job also becomes more interesting and thus, more motivating. I feel this works the same way as "antispam software helps in mailing list moderation tasks", if you know what I mean. Keep up this good thread, and think really hard about what of these tasks are easy to automate, given that get get more input from the ftp-team.

Re: NEW processing

Lucas Nussbaum — 2008-12-03T22:49:48

We have had problems with arches keeping up for years. Rather simple changes in the scheduling[*] of the builds could improve the situation. Also, we have an architecture qualification page, where it's clear that several arches don't provide buildd redundancy. The fact that we are not addressing those problems shows that the problems aren't that severe, since we prefer to deal with them again and again. [*] Possible improvements: - give higher priority to packages that could go to testing if the builds were there - give lower priority on slow arches to packages that haven't been built yet on fast arches. If a fast arch has already built the package, a slow arch is less likely to lose time trying to build a package.

Re: NEW processing

Russ Allbery — 2008-12-03T22:52:58

If you think Lintian is warning about something that it shouldn't warn about, please report a bug. In some cases, it may be that we think that you are not maintaining your package the way that we think you should based on our understanding of the general Debian consensus, but a lot of the time we just didn't realize. So you should at least make us *say* that if that's really the case. You might be surprised by us agreeing with you. :) Also, please be aware of the tuning options on Lintian's output that were added in 2.0. You now have quite a bit more control over what you see from Lintian and can do things like exclude tags that Lintian knows are guesses about problems rather than problems it's fairly certain are there. Tags are also now classified internally using bug severities, so you can tell Lintian things like "only show me tags that are important severity or higher."

Re: NEW processing

Russ Allbery — 2008-12-03T22:49:50

We've been working towards this. Lintian now supports taking a specific list of tags that it should look for and only reporting those tags specifically so that ftp-master can create a restricted set of errors that they really care about and enforce those without picking up whatever we thought was a good idea to put into Lintian. The intention is for that set to be very conservative and to be subject to additional sanity checking outside of just the Lintian maintenance team, and to only pick up new tags after they've been around for a while and proven to not have significant false-positive problems.

Re: NEW processing

Steve Langasek — 2008-12-03T22:46:12

[citation needed]

Re: NEW processing

Holger Levsen — 2008-12-03T22:42:29

Hi Daniel, On Wednesday 03 December 2008 20:01, Daniel Baumann wrote: No. What I wanted to say I said / tried to say in the parts you didnt quote: someone commented new processing is slow. I replied that its done by volunteers and that the ftpteam is looking for new members. regards, Holger