Re: NEW processing

[Tzafrir Cohen]

On Wed, Dec 03, 2008 at 08:48:20PM -0600, Raphael Geissert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Michael Tautschnig wrote:
> [...]
> > 
> > Still, I don't think we need to bring in that unknown $user, I think this
> > thread is more about some impatient DDs sitting and waiting for their 
> > package
> > to enter the archive. 
> 
> 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.

How do you track that down?
http://wnpp.debian.net/?type[]=ITP&project=&description=&owner[]=yes&owner[]=no&col[]=dust&col[]=type&col[]=description&col[]=installs&col[]=owner&col[]=reporter&sort=project

No quick way to get that information from here.
Picking three random ITPs:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351594 (ITP: chocolate-doom)
Bug reports points to http://debian.halfcoded.net/ . Packages are still 
there. Last modified: Dec 2007.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455759 (ITP: crystal)
Points to debian-mentors, but only at the end of the report.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457230 (ITP: glest-indians)
No information about a package.

-- 
Tzafrir Cohen | [EMAIL PROTECTED] | VIM is
http://tzafrir.org.il || a Mutt's
[EMAIL PROTECTED] ||  best
ICQ# 16849754 || friend


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Holger Levsen]

Hi,

On Wednesday 03 December 2008 23:46, Steve Langasek wrote:
> > Some archs have already problems keeping up
> [citation needed]

:-)

http://buildd.debian.org/stats/graph-quarter-big.png


regards,
Holger


pgpLRSr6TXE24.pgp
Description: PGP signature

Re: NEW processing

[Sune Vuorela]

On 2008-12-03, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Sune Vuorela <[EMAIL PROTECTED]> writes:
>
>> And from my maintainer point of view, lintian becomes more and more
>> irrelevant, as it warns about more and more stupidities, so the real
>> issues is being hidden in the amount of crap outputted.
>
> 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.  :)

Latest, the warning about quilt patches without any description. Sure it
is nice to have a description, but I don't need lintian to tell it.

and in other words, the latest package I uploaded:

$ lintian kdebase_3.5.9.dfsg.1-6_i386.changes  | wc --lines && lintian
kdebase_3.5.9.dfsg.1-6_i386.changes | tail -1
142
N: 58 tags overridden (32 errors, 26 warnings)

You are most welcome to join in and help fixing issues and especially
writing manpages.
and then, there is the ~1500 open bug reports.


Please stop making the lives for the developers harder. Especially the
idea about automatically rejecting based on lintian.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Steve Langasek]

On Wed, Dec 03, 2008 at 10:15:50PM +0100, Joerg Jaspert wrote:

> Packages that only add new binary components are already sorted above
> packages that have completly new source, to decrease their time in the
> queue, as their checks are much faster done than a complete source
> review. But even those have a little review from us, enough people
> manage to even get those done wrong. Love empty packages? soname changes
> like to do that to people, for example.

And checks for critical bugs, such as empty packages, are a good thing to
have in place.  I'm glad this is done as part of binary NEW processing.

The problem is when packages are rejected for things that aren't critical
bugs - even, in some cases, for bugs that don't follow from Policy or the
DFSG.  The ftp team should not presume in such cases that it's their place
to block these packages from the archive.

> Note that we currently are working on integrating lintian into dak in a
> way that lets us autoreject on selected lintian tags. That will help NEW
> a little too, even if NEW is the smallest driving force for this change.

Applying the same quality standards to NEW and non-NEW uploads is good.

By what process will the selection of lintian tags be submitted to the
project for review and approval prior to implementation as a hard reject? 
What is the plan for tracking bugfixes to the lintian checks themselves on
an ongoing basis?

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Kalle Kivimaa]

Amaya <[EMAIL PROTECTED]> writes:
> Wrong! The overrriden ones should be a lot of fun to look at.

Well, the override file is there for a purpose - it's entirely
possible that lintian gives a false positive or the package in
question has a valid exception for the error. In any case the lintian
override file will get very close scrutiny by the ftpmaster doing the
NEW check.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Steve Langasek]

On Thu, Dec 04, 2008 at 09:25:43AM +0100, Holger Levsen wrote:

> On Wednesday 03 December 2008 23:46, Steve Langasek wrote:
> > > Some archs have already problems keeping up
> > [citation needed]

> :-)

> http://buildd.debian.org/stats/graph-quarter-big.png

First, that graph isn't a measure of how the buildds are keeping up.  It
measures what percentage of packages are built on each architecture, which
basically means it's a measure of how well-ported Debian is to those archs
(and/or how well the P-a-s entries are being maintained for those archs).

Second, there isn't actually anything on that graph (or on the graph that
/does/ give a better measure how well the buildds are keeping up,
http://buildd.debian.org/stats/graph2-quarter-big.png) to indicate the archs
are having problems.  There are actually "warning" lines configured for
those graphs, as you can see from
; and all archs have been far
enough above the thresholds for the past quarter that the lines themselves
are cut off below the bottom of the graph.  

So I don't think we have archs that are struggling to keep up right now,
except during exceptional periods when they have zero buildds on-line.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Stefano Zacchiroli]

On Thu, Dec 04, 2008 at 02:01:49AM +0100, Amaya wrote:
> > > could be very much automatic, just as Zach pointed out. An automatic
> > /me loves the Spanish pronunciation of my (nick)name :-)
> 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 :)

I then propose to put all the blame on büḃúllè, ... deal? :-)
(beside that, it was just a pun)

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],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: NEW processing

[Steve Langasek]

On Wed, Dec 03, 2008 at 05:03:49PM -0800, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

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

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

Right - sorry for the imprecision.

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

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

I know this is the current lintian policy on E vs. W, but that this wasn't
the case historically.  Is this the case for lintian 1.24?  I believe that's
the version in use on ftp-master currently.  (It also appears to be the
version that will be shipping with lenny?)

And even under the new classification, "possibly important" bugs are still a
far cry from things that should be treated as reasons for rejects, 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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Manoj Srivastava]

On Thu, Dec 04 2008, Steve Langasek wrote:

> Which is why the ftp team should not be taking it upon themselves to
> overrule other developers' assessments of which bugs are critical to
> fix unless those overrulings are grounded in a clear consensus.
>
> If you have doubts about the quality of your own packages, feel free
> to get more experienced developers to review them for you before you
> upload.  But don't put up obstacles to other developers getting work
> done by giving some other set of developers veto power based on
> external criteria that the project has never agreed to.

Why are these paragraphs only relevant to the ftp team and
 the archive, and not the release team and the, umm, release?

manoj
-- 
But what can you do with it?  -- ubiquitous cry from Linux-user
partner. (Submitted by Andy Pearce, [EMAIL PROTECTED])
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Neil Williams]

On Wed, 3 Dec 2008 16:51:34 -0800
Steve Langasek <[EMAIL PROTECTED]> wrote:

> > I completely disagree. It's a welcome benefit if packages of
> > inferior quality are prevented from entering the archive in the
> > first place imo. If you want to test packages not yet ready for
> > debian
> 
> 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.

Absolutely true - though lintian does an excellent job, it does not
claim to be the final arbiter of quality, merely a tool to assist in
raising the quality of packages. For a start, lintian always tests the
source package in isolation.

One problem in reviewing packages on debian-mentors is that
"lintian-clean" almost becomes the be all and end all of the quality
assessment - maintainers don't expect to have to fix anything that
lintian does not pick up.

Package quality has to be about a whole lot more than just
lintian-clean.

Simplest example - lintian cannot test if the program actually does
anything. A patch that inadvertently causes the program to crash or
just skip large parts of the codebase will not be picked up. Other
examples include pbuilder tests or any test that has to test the new
package against existing packages.

lintian would need a whole new class of checks where a consensus has
been reached that these errors (and these alone) are rigorously
indicative of poor package quality and that any incidence of these
warrants an automatic REJECT. To implement this, it would probably be
better if tools that actually run lintian as part of the build (debuild,
pdebuild some of the VCS-buildpackage tools) would check the lintian
result for these errors and actually fail the build if they occur
(Emdebian does this already). Lintian would also need to disallow
overrides for such errors.

I'm not at all sure how many checks would gain this level of certainty.

Some that might qualify (only a cursory glance, a full review would
probably pick others):

arch-dependent-file-in-usr-share{2 packages}
binary-in-etc   
file-in-etc-not-marked-as-conffile  {7 packages}
package-contains-ancient-file   
file-directly-in-usr-share  
file-in-usr-local   {1 package}
dir-in-usr-local
executable-is-not-world-readable{2 packages}
special-file{1 package}
symlink-has-double-slash
file-directly-in-usr-share-doc

http://lintian.debian.org/tags/

Hmmm, maybe not.

Before we implement such a REJECT policy, it's probably a good idea to:

a) RELEASE LENNY
b) get a consensus on which lintian errors are always unacceptable in
all packages
c) fix packages that already contain such errors (with NMU's if
necessary)
d) fix as many other lintian errors as possible throughout the archive.
(Quite a lot of lintian errors - some that I would consider quite
serious - affect several hundred packages.)

If we are going to make "lintian quality" such a banner for NEW,
shouldn't we imrpove the packages we already have in the archive first?
(after releasing Lenny, of course).

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpz4C8qVs9Vv.pgp
Description: PGP signature

Re: NEW processing

[Stefano Zacchiroli]

On Wed, Dec 03, 2008 at 04:22:05PM -0800, Steve Langasek wrote:
> I submit that lintian warnings are entirely out of scope for the
> task the project has entrusted to the ftp team, and that mentioning

And indeed, the proposal [1] (or at least my proposal) is to let dak
automatically reject on lintian basis, with no need for ftp-masters to
fiddle with that.

  [1] http://lists.debian.org/debian-devel/2008/12/msg00184.html

That to me would look like not as an additional job that the project
asked ftp-masters to do, but rather as a (sane) extra QA step. It it
were detectable, I'd love to reject also automatically packages which
were not built with cowbuilder/pbuilder/..., which were not installed
by the uploader before uploading, and so on and so forth.

That has nothing to do with power (or with personal battles against
ftp-masters, FWIW), just plain QA.

And if you argue that lintian can be sometimes dumb in checking, I for
sure concur, it is just a program after all. To "fight" that, we give
uploaders the power of overrides and to "someone" the power of tuning
lintian parameters.

To me, the most natural choice of someone looks like ftp-masters, just
because they do maintainer dak. If people are uneasy about that other
choices can be:

- the lintian maintainers
- the QA team
- the policy editors
- the CTTE
- ... add yours ...

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],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: NEW processing

[Neil Williams]

On Thu, 4 Dec 2008 00:44:03 +0100
Amaya <[EMAIL PROTECTED]> wrote:

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

$ sudo pbuilder create
$ sudo pbuilder login

?

Is this a disc-space issue, or something I'm missing about chroots as
testing targets?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp6AWEfS7BLT.pgp
Description: PGP signature

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

[Steve Langasek]

On Wed, Dec 03, 2008 at 01:04:14PM +, Noah Slater wrote:
> On Wed, Dec 03, 2008 at 01:50:22PM +0100, Stefano Zacchiroli wrote:
> > On Wed, Dec 03, 2008 at 12:26:03PM +, Noah Slater wrote:
> > > How should we go about collecting to the contributers? Should I post
> > > a note to the wiki (alerting the subscribers) about this, and if so,
> > > where to direct people for collaboration?

> > It is up to you. From a management point of view, I don't think you should
> > look for many people as the drivers. We already have two people in this 
> > thread
> > which volunteered for that (you are one of the two). I suggest you start
> > together to shape the first draft and see how to make the work fit in the 
> > DEP
> > process (remember that Sam proposed the copyright stuff before we had DEPs).

> Okay, sure. Well, it has already been requested that this be delayed
> until after Lenny and I think that sounds like a good idea. Once we have
> that out of the way I will being to push this forward as a DEP.

Hrm, who requested this (and where)?  This seems like a perfectly reasonable
thing to work on in parallel to the release, 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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Manoj Srivastava]

On Wed, Dec 03 2008, Noah Slater wrote:

> On Wed, Dec 03, 2008 at 10:52:39AM -0800, Steve Langasek wrote:

>> Why do you need a separate mailing list for a single proposal?  Please
>> discuss this on debian-devel or debian-project, which are already perfectly
>> adequate lists for this.
>
> We have struggled enough with the proposal as it is. My fear is that
> discussing it on debian-devel will open it up to "fire-and-forget"
> criticism that lacks context of previous discussions, is poorly
> thought out, results in spiralling threads and contributes little to
> the effort. If there was some dedicated forum for discussing this,
> even if this was simply a DEP mailing list, I think it would encourage
> thoughtful and committed contributions from all involved.

Then you'll just have to go through another round of discussion
 and debate  before this proposal could be implemented, I
 think. Something as intrusive as this proposal can't be just discussed
 in special purpose mailing lists.

manoj
-- 
Let's just be friends and make no special effort to ever see each other
again.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Possibly excessive lintian warnings (was: NEW processing)

[Russ Allbery]

Sune Vuorela <[EMAIL PROTECTED]> writes:

> Latest, the warning about quilt patches without any description. Sure it
> is nice to have a description, but I don't need lintian to tell it.

This is severity: minor, certainty: certain, which currently *barely*
makes the W threshold.  I think a very good argument could be made that
this is actually severity: wishlist, which would downgrade it to an I.
I'm copying debian-lint-maint to see what the other Lintian maintainers
think.

I do think the warning is correct for a lint program, and it sounds like
you do agree that this is something that should be improved about the
package.  The prioritization just may be off.

> and in other words, the latest package I uploaded:
>
> $ lintian kdebase_3.5.9.dfsg.1-6_i386.changes  | wc --lines && lintian
> kdebase_3.5.9.dfsg.1-6_i386.changes | tail -1
> 142
> N: 58 tags overridden (32 errors, 26 warnings)

http://lintian.debian.org/full/[EMAIL PROTECTED]

Much of this is just more of the desktop file fiasco, since KDE doesn't
follow what's supposedly a shared standard.  I've complained about that at
some length before and don't know what people are supposed to do with
desktop files.  If anyone from the KDE team is willing to propose patches
or even concrete actionable changes to how Lintian checks desktop files so
that KDE's desktop files don't produce tons of noise, I'd love to hear
them.

You don't have man pages for many of your programs, as you've noted, which
is pile of warnings.

You install libraries into /usr/lib in a bunch of packages without shlibs
entries and don't call ldconfig in postinst.  Hm, and you override that in
a few places.  In general, just looking at the Lintian report, I don't
understand what you're doing with shared libraries and why it's correct.
Lintian thinks it's wrong, and I understand why Lintian thinks it's wrong,
but I must be missing something (which Lintian is also missing).

You're apparently not using detached symbols for your debugging libraries,
which is another small pile of warnings.

By and large, apart from the desktop mess and whatever is going on with
shared libraries that I don't understand, the Lintian report looks like a
lot of work that should ideally be done on the packages.  I'm not really
seeing stuff that's obviously wrong, although I only looked at it
cursorily.

> You are most welcome to join in and help fixing issues and especially
> writing manpages.  and then, there is the ~1500 open bug reports.

You have a huge and difficult-to-package piece of software and inadequate
resources to do all the work on it that should ideally be done.  I get
that, and I'm not criticizing what you're doing.  But I don't think that
Lintian should stay silent about issues just because there isn't enough
time to correct them.  It shouldn't complain about things that aren't
actually issues, but it should complain about the things that need to be
fixed, even if they can't be fixed right away.  That's what it's for.

Not having a man page for a binary is a Policy violation.  If Lintian
doesn't complain about Policy violations, it's hard to understand what the
point of it would be.  There's a reason why that's a warning and not an
error, though.  :)

> Please stop making the lives for the developers harder. Especially the
> idea about automatically rejecting based on lintian.

The only thing that's been seriously discussed with an eye to
implementation, so far as I know, is to automatically reject on the basis
of a hand-selected and very limited subset of Lintian tags, which would
probably not affect anything that you're doing and which would certainly
not automatically block packages with proper overrides.  I don't think
this is going to hurt you as much as you think it would.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Lucas Nussbaum]

On 04/12/08 at 09:25 +0100, Holger Levsen wrote:
> Hi,
> 
> On Wednesday 03 December 2008 23:46, Steve Langasek wrote:
> > > Some archs have already problems keeping up
> > [citation needed]
> 
> :-)
> 
> http://buildd.debian.org/stats/graph-quarter-big.png

That proves that buildds have problems building all packages that they
should build, not that they have a problem keeping up with the load they
receive.

If you add 10 times more buildds, this graph is unlikely to change much.

I've been graphing the number of NeedsBuild packages per arch. Results
are here:
http://blop.info/pub/needsbuild-day.png
http://blop.info/pub/needsbuild-week.png
http://blop.info/pub/needsbuild-month.png
http://blop.info/pub/needsbuild-year.png

As you can see, there are short times where the buildds for one arch
have problem keeping up with the load, but that's often caused by :
- one of the buildds being temporarily unavailable
- one of the buildds building a very big package

What we lack is more redundancy, but that's not new.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> By what process will the selection of lintian tags be submitted to the
> project for review and approval prior to implementation as a hard
> reject?

I think that's a pretty good question.  I don't think we need a very
formal process, but as a Lintian maintainer, I'd kind of like people to
sanity check them before we start doing that just so that we don't get
flooded with complaints if we missed something obvious.

Thankfully, it's pretty easy to check in advance whether enabling hard
rejects would affect much of the archive.  There are a bunch of E tags
Lintian produces which occur nowhere in the archive because they're so
serious that they'd be immedate RC bugs if they made it in and we've
cleaned them out.  That would be the place to start.  Lintian can do
things like catch empty packages or packages missing copyright files
without having to write new custom code to do so.

> What is the plan for tracking bugfixes to the lintian checks themselves
> on an ongoing basis?

Joerg usually backports Lintian shortly after each new release.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: qmail and related packages in NEW

[Gerrit Pape]

On Tue, Dec 02, 2008 at 11:29:13AM +0100, Bjørn Mork wrote:
> Gerrit Pape <[EMAIL PROTECTED]> writes:
> > Hi, I'm quite surprised how the inclusion of qmail and related packages
> > into sid is handled, or rather not handled, by the ftpmasters.
> 
> I downloaded the netqmail source from http://dbn.smarden.org/sid/ and
> looked briefly at it, to see if most of the well-known (some of the for
> 10+ years!) bugs have been fixed.  Unfortunately, it doesn't seem so.
> The Debian packaging included surprisingly few patches, and the fixes
> I tested still applies to the Debian package. e.g:
> 
>  [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < 
> ../patch-qmail-1.03-rfc2821.diff
>  patching file qmail-remote.c
>  [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < 
> ../patch-qmail-1.03-rfc1652.diff 
>  patching file ./qmail-smtpd.c
>  Hunk #1 succeeded at 229 with fuzz 1.

> To avoid having packages starting their Debian life with a long list of
> serious and grave bugs, may I suggest that you take a look at
> http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [1]
> and either include the patches or use the suggested workarounds?

Sure, the two patches you mention might be considered for Debian.

However, I wonder how two issues can be called a 'long list', and how
these can be judged as severity grave or serious.

Right now, upstream doesn't completely agree with Andree's list of bugs.
Do you know how many people add accept_8bitmime to the default exim
configuration, and for what reason?  Do you know why any highest
priority MX with the closest distance to the mail store should issue
temporary errors on incoming connections permanently, and whether this
is okay with the standards?

I've yet to be pointed to a grave or serious bug in the packages pending
in NEW, otherwise I see no reason why they shouldn't be processed and
pass NEW.  I completely agree with this well written post

 http://lists.debian.org/debian-devel/2008/12/msg00207.html

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Adam D. Barratt]

On Thu, 04 Dec 2008 01:00:17 -0800, Russ Allbery wrote:

Sune Vuorela <[EMAIL PROTECTED]> writes:


Latest, the warning about quilt patches without any description.
Sure it is nice to have a description, but I don't need lintian to
tell it.


This is severity: minor, certainty: certain, which currently *barely*
makes the W threshold.  I think a very good argument could be made
that this is actually severity: wishlist, which would downgrade it to
an I. I'm copying debian-lint-maint to see what the other Lintian
maintainers think.


As I mentioned to Sune on IRC last night, the quilt tag's severity was 
copied from the equivalent dpatch tag (which was originally implemented as a 
warning and then moved to minor/certain during the transition).


I've no problem with downgrading the severity, although we should make a 
corresponding change to the dpatch tag at the same time, unless there's some 
reason it's particularly worse for a dpatch to be missing a description.


Adam 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Steve Langasek]

On Thu, Dec 04, 2008 at 01:03:19AM -0800, Russ Allbery wrote:
> Thankfully, it's pretty easy to check in advance whether enabling hard
> rejects would affect much of the archive.  There are a bunch of E tags
> Lintian produces which occur nowhere in the archive because they're so
> serious that they'd be immedate RC bugs if they made it in and we've
> cleaned them out.  That would be the place to start.

I agree that's a good place to start.  There should still be some sort of
public review, though - just because nothing in the archive currently
suffers from the bug shouldn't automatically make it a hard requirement.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Adam D. Barratt]

On Wed, 03 Dec 2008 20:28:59 -0600, Raphael Geissert wrote:

From the lintian hacker desk:


$ lintian -I --exp-output format=letterqualifier

[...]

Other *experimental* output formats are 'xml' and 'colons' (currently
b0rken). 


It's fixed in HEAD (well, it now works for me).

Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Sune Vuorela]

On 2008-12-04, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Sune Vuorela <[EMAIL PROTECTED]> writes:
>
>> Latest, the warning about quilt patches without any description. Sure it
>> is nice to have a description, but I don't need lintian to tell it.
>
> I do think the warning is correct for a lint program, and it sounds like
> you do agree that this is something that should be improved about the
> package.  The prioritization just may be off.

Yes. downgrading to I is a good solution.

And other warnings that could be changed:
dbg-package-missing-depends - if there 1 dbg package and multiple
arch depending packages beside that.

> Much of this is just more of the desktop file fiasco, since KDE doesn't
> follow what's supposedly a shared standard.  I've complained about that at
> some length before and don't know what people are supposed to do with
> desktop files.  If anyone from the KDE team is willing to propose patches
> or even concrete actionable changes to how Lintian checks desktop files so
> that KDE's desktop files don't produce tons of noise, I'd love to hear
> them.

A good solution is to get lenny out of the door so that we can ditch
kde3 and go on with kde4.  KDE4 do follow the specs. Kde3 originates
from before it was a shared standard (one of the few fdo standards that
is actually a *shared* standard and not a rubber stamp on gnome
standards, but that's a entirely different issue)

> You're apparently not using detached symbols for your debugging libraries,
> which is another small pile of warnings.

we are, but apparantly dh_strip has issues under some conditions with
some of the files.

> You have a huge and difficult-to-package piece of software and inadequate
> resources to do all the work on it that should ideally be done.  I get

This is why I need automatic tools that *helps* me and not tools that
gets in the way.

> Not having a man page for a binary is a Policy violation.  If Lintian
> doesn't complain about Policy violations, it's hard to understand what the
> point of it would be.  There's a reason why that's a warning and not an
> error, though.  :)

It is also one of the reasons why we aren't overriding that.

>> Please stop making the lives for the developers harder. Especially the
>> idea about automatically rejecting based on lintian.
>
> The only thing that's been seriously discussed with an eye to
> implementation, so far as I know, is to automatically reject on the basis
> of a hand-selected and very limited subset of Lintian tags, which would
> probably not affect anything that you're doing and which would certainly
> not automatically block packages with proper overrides.  I don't think
> this is going to hurt you as much as you think it would.

Some people in this thread are suggesting automatic rejecting based on any E: 
tag.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: qmail and related packages in NEW

[Kalle Kivimaa]

Gerrit Pape <[EMAIL PROTECTED]> writes:
> I've yet to be pointed to a grave or serious bug in the packages pending
> in NEW, otherwise I see no reason why they shouldn't be processed and
> pass NEW.  I completely agree with this well written post

Does the package in NEW fix the well known backscatter spam issue? I
tried searching for the fix in the package but unfortunately failed.

If it doesn't, then IMO, at this day and age, a MTA sending
backscatter spam doesn't belong to Debian.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Invitation to connect on LinkedIn

[chennai pc]

LinkedIn


chennai pc requested to add you as a connection on LinkedIn:
--

Paul,

Hi,

  I am manager of www.chennaipc.com - Computer Laptop Directory in Chennai.Also 
we own www.manyforyou.com - All information Linking portal.I Would like to add 
in my business network.

Thanks
Balaji
www.sjbsindia.com 
www.chennaipc.com
www.manyforyou.com
www.sjbsjobs.com

View invitation from chennai pc
http://www.linkedin.com/e/uwTRS9NuUj0vo8kjIcGBPqZTCi3vo8VBXfNSMrhwsPJn/blk/877691833_2/cBYPcPwNejoTdPwLqnpPbOYWrSlI/svi/
 
--

DID YOU KNOW that LinkedIn can find the answers to your most difficult 
questions? Post those vexing questions on LinkedIn Answers to tap into the 
knowledge of the world's foremost business experts: 
http://www.linkedin.com/e/ask/inv-23/

 
--
(c) 2008, LinkedIn Corporation

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

[Steve Langasek]

On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote:

>   * The 'keyfiles' option is now obsolete.  Instead the authentication
> module will automatically locate all files matching the pattern 'id_*'
> (the idea for this came from a patch from Javier Serrano Polo).

That doesn't sound like a good idea to me.  What if a user has extra ssh
keys lying around that multiple people have the passphrase to, which prior
to this change would have been perfectly safe?

Also, why is the pattern id_*?  ssh also recognizes 'identity' by default. 
Shouldn't this really use the same pattern as ssh itself, i.e.,
(identity|id_dsa|id_rsa)?

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: qmail and related packages in NEW

[Florian Weimer]

* Gerrit Pape:

> Right now, upstream doesn't completely agree with Andree's list of
> bugs.

Out of curiosity, does netqmail fix at least the delayed bounce
problem?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Charles Plessy]

Le Wed, Dec 03, 2008 at 08:40:12PM -0600, Raphael Geissert a écrit :
> 
> 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.

Hi Raphael,

I think that the workflow on -mentors does not discourage enough maintainers
from working alone. Co-maintainance, work in a packaging team and use of VCS
should be more often proposed after ITPs are filed (and of course, ITPs should
be filed earlier).

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packaging IKVM: inclusion of 3rd-party sources

[David Paleino]

Hello,
as part of the Debian Mono Team, I'm trying to get ikvm [1] into an usable
state.
I've contacted the upstream author, since the build process is *nasty*, at
least: it *requires* GNU Classpath's and OpenJDK's sources (upstream specified
that a *full* *build* of OpenJDK is required, because of some generated files),
and including them inside debian/ is not a great idea to me because:

1) *enormous* diff.gz;
2) security headaches -- code duplication is never nice;
3) hard maintainability.

Upstream noted that he does provide pre-generated .zips with all the needed
files to build IKVM. I suppose that this makes ikvm non-free (pre-built
binaries), but the binaries are effectively coming from software in main (GNU
Classpath and OpenJDK).

How should I behave here?

  1) Should I include the sources in debian/ and do all the needed steps to get
  a full compile? (notice that if we follow this, each IKVM build will include
  an OpenJDK build...)

  2) Or should I make two separate (source) packages, "ikvm" and
  "ikvm-build-deps", with the former Build-Depends on the latter? Also, would
  this be acceptable? (probably ikvm-build-deps would go into non-free, and
  ikvm into contrib?)

Any suggestion is very welcome.

Regards,
David Paleino

[1] that is, the JVM ported on Mono

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: NEW processing

[Romain Beauxis]

Le Wednesday 03 December 2008 22:15:50 Joerg Jaspert, vous avez écrit :
> Packages that only add new binary components are already sorted above
> packages that have completly new source, to decrease their time in the
> queue, as their checks are much faster done than a complete source
> review. But even those have a little review from us, enough people
> manage to even get those done wrong. Love empty packages? soname changes
> like to do that to people, for example.

Thanks for this answer.

I would like to see these particular uploads be accepted faster. Could it be 
possible to make them more automatic when lintian checks are implemented in 
dak ? I guess that archive consistency and empty package, if they are the 
main issues, could be catched more automatically...


Romain


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging IKVM: inclusion of 3rd-party sources

[Cyril Brulebois]

David Paleino <[EMAIL PROTECTED]> (04/12/2008):
> How should I behave here?
> 
>   1) Should I include the sources in debian/ and do all the needed
>   steps to get a full compile? (notice that if we follow this, each
>   IKVM build will include an OpenJDK build...)
> 
>   2) Or should I make two separate (source) packages, "ikvm" and
>   "ikvm-build-deps", with the former Build-Depends on the latter?
>   Also, would this be acceptable? (probably ikvm-build-deps would go
>   into non-free, and ikvm into contrib?)
> 
> Any suggestion is very welcome.

3) Run away.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the buildd.debian.org world

[Michael Banck]

Hi,

On Mon, Nov 24, 2008 at 07:26:06PM +0100, Adeodato Simó wrote:
> Recent work from Steve McIntyre (current DPL) in coordination with Ryan
> Murray (wanna-build maintainer and buildd admin for several architectures) 
> has led to the injection of new blood in the buildd.debian.org world. We

Will the experimental autobuilders get integrated into
buildd.debian.org, where they (IMO) belong, especially with the current
situation where experimental has replaced unstable to some extent?


cheers,

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging IKVM: inclusion of 3rd-party sources

[Paul Wise]

On Thu, Dec 4, 2008 at 8:01 PM, Cyril Brulebois <[EMAIL PROTECTED]> wrote:
> David Paleino <[EMAIL PROTECTED]> (04/12/2008):
>> Any suggestion is very welcome.
>
> 3) Run away.

4) Prepare asbestos suit. Then build-depend on openjdk-6-source and
notify the release team about the need to binNMU every time openjdk
gets updated. Notify the security team of this requirement so that
they can fix ikvm when/if OpenJDK requires a DSA/DTSA.

5) Some kinda mono -> Java runtime bridge instead of converting the
code at build time?

6 ) see #3

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Vincent Zweije]

On Thu, Dec 04, 2008 at 02:03:52AM -0800, Steve Langasek wrote:

||  On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote:
||
||  >   * The 'keyfiles' option is now obsolete.  Instead the authentication
||  > module will automatically locate all files matching the pattern 'id_*'
||  > (the idea for this came from a patch from Javier Serrano Polo).
||
||  That doesn't sound like a good idea to me.  What if a user has extra ssh
||  keys lying around that multiple people have the passphrase to, which prior
||  to this change would have been perfectly safe?
||
||  Also, why is the pattern id_*?  ssh also recognizes 'identity' by default.
||  Shouldn't this really use the same pattern as ssh itself, i.e.,
||  (identity|id_dsa|id_rsa)?

In addition I, and probably some others, have the habit of disabling
files by adding a .OFF extension to it.

This practice is based on the (in my view) reasonable assumption that
programs should not be scanning directories for files to use unless
those directories are specially intended for that purpose.

It probably would be fine if there were a (documented) ~/.ssh/id.d/
directory containing keys to be used (and nothing else).

Ciao.Vincent.
-- 
Vincent Zweije <[EMAIL PROTECTED]>| "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature

Re: NEW processing

[Bernhard R. Link]

* Lucas Nussbaum <[EMAIL PROTECTED]> [081203 18:19]:
> > I completely disagree. It's a welcome benefit if packages of inferior
> > quality are prevented from entering the archive in the first place imo.
>
> We currently have a long reviewing process before packages get into the
> archive. But once they are in, maintainers are free to do whatever they
> want with their packages, without any review happening.
>
> I'm not advocating that we just stop doing reviews. But IMHO, NEW
> processing should be about the legal problems, not about the random
> lintian warning/errors, and the various other packaging malpractices.
> What we should do instead is encourage reviews (either on mentors, or
> inside teams), because that's also a much more scalable solution.

I think package general reviews are a good idea. But checking packages
upon entering is still the best point. Removing packages that users
already user is not something most people take lightly. Rejecting
packages not having some minimal quality to begin with is easy, though.

> Of course, if ftpmasters come across random problems in the package
> while reviewing legal stuff and mention that to the maintainer, it's
> great. But having other things checked by ftpmasters just reduces their
> bandwidth and causes longer queues.

I think splitting that in two teams and having packages only leave NEW
when both ftp-masters have agreed on the legal aspects and an other
group of people have checked for other problems will not improve the
time packages are in NEW in my eyes.

And suggesting that things are not checked first time will only make
things having less quality. In my eyes there are rather too few checks.
Having things like packages with unneedingly repackaged upstream sources
and things like that entering which are not possible to undo even by
some later maintainer before the next upstream version and things like
that do not benefit the project at all...

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Jens Peter Secher]

2008/12/4 Vincent Zweije <[EMAIL PROTECTED]>:
> On Thu, Dec 04, 2008 at 02:03:52AM -0800, Steve Langasek wrote:
>
> ||  On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote:
> ||
> ||  >   * The 'keyfiles' option is now obsolete.  Instead the authentication
> ||  > module will automatically locate all files matching the pattern 
> 'id_*'
> ||  > (the idea for this came from a patch from Javier Serrano Polo).
> ||
> ||  That doesn't sound like a good idea to me.  What if a user has extra ssh
> ||  keys lying around that multiple people have the passphrase to, which prior
> ||  to this change would have been perfectly safe?
> ||
> ||  Also, why is the pattern id_*?  ssh also recognizes 'identity' by default.
> ||  Shouldn't this really use the same pattern as ssh itself, i.e.,
> ||  (identity|id_dsa|id_rsa)?
>
> In addition I, and probably some others, have the habit of disabling
> files by adding a .OFF extension to it.
>
> This practice is based on the (in my view) reasonable assumption that
> programs should not be scanning directories for files to use unless
> those directories are specially intended for that purpose.
>
> It probably would be fine if there were a (documented) ~/.ssh/id.d/
> directory containing keys to be used (and nothing else).
>

That is a very good idea.  But the id.d directory should probably
contain soft links to the actual keys to not interfere with the
standard location.  Are the other packages which does something
similar?

If there are no objections, I will implement such a behaviour.

Cheers,
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Upcoming events in Japan

[Junichi Uekawa]

Hi,


This is a short note to tell you all about what kind of events are
happening in Japan.

Upcoming events before the end of this year:

1. Kansai Debian Meeting

14 Dec 2008 in Osaka
http://wiki.debian.org/KansaiDebianMeeting

2. Tokyo Area Debian Meeting

20 Dec 2008 in Ogikubo
http://tokyodebian.alioth.debian.org/2008-12.html


I hope I haven't missed anything.

regards,
junichi
-- 
[EMAIL PROTECTED],debian.org}


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Jens Peter Secher]

2008/12/4 Luca Niccoli <[EMAIL PROTECTED]>:
> 2008/12/3 Jens Peter Secher <[EMAIL PROTECTED]>:
>
>> Because of the security implications of changing a PAM module, I would
>> welcome some peer reviewing of the changes I have made.  The new package
>> has been uploaded to experimental, and the NEWS.Debian is as follows.
>> Also, I would like comments in general about the whether there are
>> better ways to solve the problems.
>
> As a user, I see a regression: I have @include (pam)-ssh-auth before
> @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

To do that you will need to change /etc/pam.d/ssh-auth to

  auth sufficient pam_ssh.so

such that the SSH passphrase is always asked, and, if it unlocks any
of the SSH keys, it will be sufficient to login.

> (I don't
> think there's really a point in a strong password if someone has
> physical access to the computer).

Hmm, if noone else has access to the computer (including remote
access) then the passphrase on the SSH keys do not need to be more
secure than the login password.  On the other hand, if there is remote
access to the computer, then a weak password will enable an evil
hacker to get into you account, copy your SSH key and brute-force
attack the key elsewhere.  So I do not really see your point.


Cheers,
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Clint Adams]

On Wed, Dec 03, 2008 at 10:09:37AM -0800, Don Armstrong wrote:
> It shouldn't need to be more than this, because packages shouldn't be
> uploaded with problems that can be trivially identified at NEW
> processing time.

Agreed.

> However, considering some of the rejects which have
> recently been discussed here, that appears not to be the case.

That seems irrelevant.

> This is the minimum required check, I think; if ftpmasters want to
> check more things and/or find more issues as they're doing this check,
> more power to them.

No, not more power to them.  Conflating unnecessary tasks with privileged
roles is a bad idea.

If the project needed to moderate all BTS mails to ensure that nothing
insulting was said about the King, it wouldn't be rational to let the
BTS moderation team task themselves with ensuring that the message tone
was polite enough, that any submissions with spelling errors were
hard-rejected, and so on.  This would clearly improve the quality of
the information in the BTS.  Having the stewards of the archive do
QA work in a bottleneck is even more ludicrous because, unlike a bug
report, which is practically eternal, bugs in packages can actually be
fixed by subsequent uploads.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Dropping multisync-0.8x for lenny

[Michael Banck]

Hi,

recently a user made me aware that multisync_0.82-8.1 is still shipping
in lenny currently. 

The 0.8x series of multisync has been abandoned upstream for several
years now, and I think the opensync-0.22 packages together with
kitchensync should give at least the same user experience for lenny.
However, looking at popcon, it looks like multisync-0.8x is still quite
popular AFAICT, and it might work better for some users on older
devices, so I am a bit hesitant to get it removed.

Personally, I do not want to maintain (well, reply to bug reports mostly
I guess) multisync-0.8x for lenny, so I think removing it from
testing/unstable is a sensible approach even though we cannot provide a
migration path to kitchensync/opensync. Users will still be able to use
it when upgrading to lenny, but new users should rather turn to
kitchensync (even though the opensync-0.22 packages are not perfect
either, e.g. Windows Mobile syncing will not work very well with lenny
on kitchensync due to #484130).

If somebody is really fond of multisync-0.8x and wants to
retain/maintain it for lenny, please let me know; otherwise, I'll ask
for its removal from testing/unstable soonish.


cheers,

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Luca Niccoli]

2008/12/4 Jens Peter Secher <[EMAIL PROTECTED]>:

> To do that you will need to change /etc/pam.d/ssh-auth to
>
>  auth sufficient pam_ssh.so

I know, that's why I'm not complaining =)
May writing it in the README.Debian could be a good idea.

> Hmm, if noone else has access to the computer (including remote
> access) then the passphrase on the SSH keys do not need to be more
> secure than the login password.  On the other hand, if there is remote
> access to the computer, then a weak password will enable an evil
> hacker to get into you account, copy your SSH key and brute-force
> attack the key elsewhere.  So I do not really see your point.

If someone has physical access to my computer, the only security is
encryption. No sense for a strong login password, he could boot with
an other OS or take out the HD and directly read the key (both options
will take far less time then brute-forcing an even weak password by
typing tries by hand).
Brute forcing a strong encryption password would take a lot of time
instead (I guess), which at least keeps safe computers not accessible
to anyone else (I'm thinking about a laptop and a home server, if I
get stolen of the laptop I can delete the public key on the server).
Please correct me if I'm completely mistaken...
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Jens Peter Secher]

2008/12/4 Luca Niccoli <[EMAIL PROTECTED]>:
> 2008/12/4 Jens Peter Secher <[EMAIL PROTECTED]>:
>
>> To do that you will need to change /etc/pam.d/ssh-auth to
>>
>>  auth sufficient pam_ssh.so
>
> I know, that's why I'm not complaining =)
> May writing it in the README.Debian could be a good idea.
>

OK, will do.

Cheers,
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Joerg Jaspert]

>> The only thing that's been seriously discussed with an eye to
>> implementation, so far as I know, is to automatically reject on the basis
>> of a hand-selected and very limited subset of Lintian tags, which would
>> probably not affect anything that you're doing and which would certainly
>> not automatically block packages with proper overrides.  I don't think
>> this is going to hurt you as much as you think it would.
> Some people in this thread are suggesting automatic rejecting based on any E: 
> tag.

Those people won't be the ones who implement it.

Those who will implement it will, of course, make sure to crawl through
lintian.debian.org making sure to only reject on tags that hit the most
packages possible as they don't have any better things to do than
pointlessly rejecting packages just for fun.

One of the sentences is a joke.

-- 
bye, Joerg
Some NM:
>  3. How do you manage new upstream releases?
yes i manage them.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Joerg Jaspert]

>> By what process will the selection of lintian tags be submitted to the
>> project for review and approval prior to implementation as a hard
>> reject?

> I think that's a pretty good question.  I don't think we need a very
> formal process, but as a Lintian maintainer, I'd kind of like people to
> sanity check them before we start doing that just so that we don't get
> flooded with complaints if we missed something obvious.

I have a list of tags. In Extremadura I had other ftpteam members and a
lintian maintainer look at it. Whenever this gets implemented this list will
be made public and then have a place on ftp-master.d.o webpage
somewhere. And everyone can comment on it.

-- 
bye, Joerg
Ich will ein anderes Telefon, das hier klingelt immer!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Miriam Ruiz]

2008/12/4 Joerg Jaspert <[EMAIL PROTECTED]>:

> I have a list of tags. In Extremadura I had other ftpteam members and a
> lintian maintainer look at it. Whenever this gets implemented this list will
> be made public and then have a place on ftp-master.d.o webpage
> somewhere. And everyone can comment on it.

So it was already decided that it was going to be implemented in
Extremadura meeting?

Greetings,
Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Kurt Roeckx]

On Thu, Dec 04, 2008 at 09:50:04AM +0100, Lucas Nussbaum wrote:
> As you can see, there are short times where the buildds for one arch
> have problem keeping up with the load, but that's often caused by :
> - one of the buildds being temporarily unavailable
> - one of the buildds building a very big package

- one of the buildd maintainers temporarily unavailable


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Joerg Jaspert]

>> I have a list of tags. In Extremadura I had other ftpteam members and a
>> lintian maintainer look at it. Whenever this gets implemented this list will
>> be made public and then have a place on ftp-master.d.o webpage
>> somewhere. And everyone can comment on it.
> So it was already decided that it was going to be implemented in
> Extremadura meeting?

We already talked about it in Mar del Plata, and there lintian already
got a feature we want for it.

-- 
bye, Joerg
> What would you do if you wanted to retire from the project?
This is far easier than to get in! ;)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Raphael Geissert]

Sune Vuorela wrote:
[...]
> 
> And other warnings that could be changed:
> dbg-package-missing-depends - if there 1 dbg package and multiple
> arch depending packages beside that.
>

Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends field
(say ${dbg:Depends}).

Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Russ Allbery]

"Adam D. Barratt" <[EMAIL PROTECTED]> writes:

> As I mentioned to Sune on IRC last night, the quilt tag's severity was
> copied from the equivalent dpatch tag (which was originally implemented
> as a warning and then moved to minor/certain during the transition).
>
> I've no problem with downgrading the severity, although we should make a
> corresponding change to the dpatch tag at the same time, unless there's
> some reason it's particularly worse for a dpatch to be missing a
> description.

I think they're equivalent cases.  Personally, I vote for downgrading them
both.  Unless there are any objections, I'll do that in a bit.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Sune Vuorela]

On 2008-12-04, Raphael Geissert <[EMAIL PROTECTED]> wrote:
> Will try to work on a dh-like command (or maybe a patch against dh_strip,
> depends on what Joey prefers) that will basically scan
> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
> matching the subgrouped expression, to automagically generate the Depends 
> field
> (say ${dbg:Depends}).
>
> Once that's done it would be just a matter of adjusting a couple of lines in
> debian/control and you are done with dealing with -dbg packages.

No. it actually wouldn't work.

In kde, for example kdepim, contains applications like
 - korganizer
 - kaddressbook
 - kmail
 - kpilot

With a -dbg package depending on all apps, the user will have to install
all apps just for getting a backtrace for one application.

That is not desired.
Bloating the archive with seperated -dbg packages is ttbomk not desired
as well.

The current approach is currently the least bad, and lintian should not
complain.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Adam D. Barratt]

On Thu, 2008-12-04 at 12:51 -0800, Russ Allbery wrote:
> "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> 
> > As I mentioned to Sune on IRC last night, the quilt tag's severity was
> > copied from the equivalent dpatch tag (which was originally implemented
> > as a warning and then moved to minor/certain during the transition).
> >
> > I've no problem with downgrading the severity, although we should make a
> > corresponding change to the dpatch tag at the same time, unless there's
> > some reason it's particularly worse for a dpatch to be missing a
> > description.
> 
> I think they're equivalent cases.  Personally, I vote for downgrading them
> both.

I agree...

> Unless there are any objections, I'll do that in a bit.

... and did that an hour ago. Apologies for not waiting a little longer
for objections / consensus.

Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Raphael Geissert]

Neil Williams wrote:

> d) fix as many other lintian errors as possible throughout the archive.
> (Quite a lot of lintian errors - some that I would consider quite
> serious - affect several hundred packages.)

Actually, that's on my list of proposed QA RGs for squeeze, and am willing to
work on it (together with the no bashisms one [not just whatever dash doesn't
support], and others). But lets talk about that when the cal for proposals is
made.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Russ Allbery]

"Adam D. Barratt" <[EMAIL PROTECTED]> writes:

> ... and did that an hour ago. Apologies for not waiting a little longer
> for objections / consensus.

Oh, no, it's no problem.  I was being too conservative.  Thank you!

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Russ Allbery]

Sune Vuorela <[EMAIL PROTECTED]> writes:

> No. it actually wouldn't work.
>
> In kde, for example kdepim, contains applications like
>  - korganizer
>  - kaddressbook
>  - kmail
>  - kpilot
>
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.

That's why the recommendation (which Lintian currently doesn't talk about;
will fix that) is that the debug package depend on the all of the
corresponding packages as alternatives.  (korganizer | kaddressbook
| kmail ...)  That way, you still get the checking that the version of the
debug package matches the version of the package for which it has debug
symbols, without the problem you cite.  This is what I've done for other
packages and it seems to work reasonably well.

(Lintian may still be confused due to the lack of similarity between the
package name and the debug package name, but we may be able to fix that.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Raphael Geissert]

Hi Charles,

Charles Plessy wrote:

> Le Wed, Dec 03, 2008 at 08:40:12PM -0600, Raphael Geissert a écrit :
>> 
>> 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.
> 
> Hi Raphael,
> 
> I think that the workflow on -mentors does not discourage enough maintainers
> from working alone. Co-maintainance, work in a packaging team and use of VCS
> should be more often proposed after ITPs are filed (and of course, ITPs should
> be filed earlier).

Yes, I've seen some of those as well; those make me happy, actually. It is
always nice to work with someone who is willing to keep working to get it the
best way as possible. I love that.

That reminds me that another problem (probably the original source of these
issues) is that the documentation is not explicit enough or doesn't say all it
needs to/should say.

And before anyone tells me to stop complaining instead of working on it: I will,
I just have too many items on my todo list that should be done before.


> 
> Have a nice day,
> 

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Wed, Dec 03, 2008 at 05:03:49PM -0800, Russ Allbery wrote:

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

> I know this is the current lintian policy on E vs. W, but that this
> wasn't the case historically.  Is this the case for lintian 1.24?  I
> believe that's the version in use on ftp-master currently.  (It also
> appears to be the version that will be shipping with lenny?)

It's been the rough goal for a while, although we've become much clearer
about it recently.  I think 1.24 should generally be okay, although of
course bugs have been fixed since then.

> And even under the new classification, "possibly important" bugs are
> still a far cry from things that should be treated as reasons for
> rejects, IMHO.

Sure, which is why ftp-master is only going to use a specific list of
tags.  Joerg came to us and asked for the facility for exactly that
reason

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Raphael Geissert]

Sune Vuorela wrote:

> On 2008-12-04, Raphael Geissert <[EMAIL PROTECTED]> wrote:
>> Will try to work on a dh-like command (or maybe a patch against dh_strip,
>> depends on what Joey prefers) that will basically scan
>> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
>> matching the subgrouped expression, to automagically generate the Depends
>> field (say ${dbg:Depends}).

Using ORed depends, I forgot to say.

>>
>> Once that's done it would be just a matter of adjusting a couple of lines in
>> debian/control and you are done with dealing with -dbg packages.
> 
> No. it actually wouldn't work.
> 
> In kde, for example kdepim, contains applications like
>  - korganizer
>  - kaddressbook
>  - kmail
>  - kpilot
> 
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.
> 
> That is not desired.
> Bloating the archive with seperated -dbg packages is ttbomk not desired
> as well.

Of course.

> 
> The current approach is currently the least bad, and lintian should not
> complain.

I don't agree, -dbg packages all by themselves are completely useless, they MUST
depend on something that will actually make them meaningful. Otherwise they
should not be built/shipped.

> 
> /Sune

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Promoting free PDF readers (was Re: Popular packages in Ubuntu that is missing in Debian/main)

[Luca Capello]

Hi there!

On Mon, 01 Dec 2008 11:12:55 +0100, Johannes Wiedersich wrote:
> Gunnar Wolf wrote:
>> But anyway, and knowing this is not an Ubuntu list... Does anybody
>> know why on Earth is Acroread popular? Why isn't a PDF regularly
>> handled in a saner way with Evince (or kde-based lookalike) in some
>> distributions?
>
> Zillions of websites promote acroread via links and thumbnails. I've yet
> failed to find a site with a pdf and that 'download envince|kpdf|okular
> for free' button. Don't forget that many people use an inferior OS just
> out of convenience/marketing/whatever.

FYI, the FSFE has started such initiative:

  http://wiki.fsfe.org/Free-PDF-Readers-Campaign

The discussion started in July 2008 on the FSFE discussion mailing list,
but unfortunately the archive is available to subscribers only:

  https://lists.fsfe.org/mailman/listinfo/discussion

Recently, a dedicated mailing list was setup:

  http://lists.fsfe.org/mailman/listinfo/pdfreaders

Thx, bye,
Gismo / Luca


pgpSn8Shm1pk9.pgp
Description: PGP signature

Re: NEW processing

[Faidon Liambotis]

Thomas Viehmann wrote:
> The particular pass through NEW that has been used to demonstrate the
> deficiency of NEW processing was necessitated by the rename
> iceweasel-l10n-hi to iceweasel-l10n-hi-in introduced in the previous
> upload (and processed in 3-4 days or so). This rename took place after
> uninstallability of iceweasel-l10n-all had been pointed out to the
> maintainer after he asked for an unblock on release. In essence, this
> whole trip through NEW would not have happened if the maintainer would
> actually routinely install his packages before uploading. I am all in
> favor of fast-tracking urgent stuff, but the deal should involve the
> maintainer making extra-sure to get things right, too.
Because we all know that uninstabillity problems can only occur when you
change the package name...

Or undistributable/illegal stuff. Or lintian errors.
In that sense, you should perform quality checks and moderate _every_
upload as well.

I'm all for doing legal checks and semi-automated quality/sanity checks
on the *first* upload.
But what's the point on doing it on binary package renames?
Crap can be introduced into the archive just as easily without it /ever/
processing NEW.

If the source package existed in the archive before it shouldn't pass
through NEW!

Quality assurance of existing packages is a job for the QA team.
The two teams should definitely cooperate, share common patterns and
possibly scripts.
In that way, all packages can be automatically or semi-automatically
checked, even those that don't ever change their package names.

Am I the only one that finds all of the above obvious?

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Sune Vuorela]

On 2008-12-04, Raphael Geissert <[EMAIL PROTECTED]> wrote:
> Using ORed depends, I forgot to say.

How would OR'ed depends work?

let us look at a example:

package: kdepim-dbg
depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
version: 4.1.3-1

now, I install korganizer 4.1.3-1 and kdepim-dbg.
later, 4.1.3-2 gets uploadde and I install kaddressbook.
korganizer still fulfills the kdepim-dbg version.
thus, the user is not anywhere better satisfied than before.

The only thing that would work would be if dpkg and apt supported 
Conflicts: korganizer (!= $binary:Version), but that is as far as I can
read in policy not valid, so I also don't expect the tools to support
it.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings

[Russ Allbery]

Sune Vuorela <[EMAIL PROTECTED]> writes:

> How would OR'ed depends work?
>
> let us look at a example:
>
> package: kdepim-dbg
> depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
> version: 4.1.3-1
>
> now, I install korganizer 4.1.3-1 and kdepim-dbg.
> later, 4.1.3-2 gets uploadde and I install kaddressbook.
> korganizer still fulfills the kdepim-dbg version.
> thus, the user is not anywhere better satisfied than before.
>
> The only thing that would work would be if dpkg and apt supported 
> Conflicts: korganizer (!= $binary:Version), but that is as far as I can
> read in policy not valid, so I also don't expect the tools to support
> it.

Your case is somewhat unusual in that you're providing debugging symbols
for a bunch of packages that are otherwise fairly unrelated and can be
installed with a mix of version numbers.  Most of the time, this is not
the case.  In your case, this is only marginally useful; it does ensure
that the user has at least one relevant package installed, but no more
than that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Raphael Geissert]

Faidon Liambotis wrote:

> Quality assurance of existing packages is a job for the QA team.

And since everybody makes part of the QA team what you are really saying
is: "Quality assurance of existing packages is a job for me".

ftp-masters are doing a great, often thankless, job. Instead of just saying what
they should or should not do why don't you volunteer and actually do something
about it? (e.g. the QA check part).

Cheers,
Raphael Geisser



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NEW processing

[Raphael Geissert]

Tzafrir Cohen wrote:

> On Wed, Dec 03, 2008 at 08:48:20PM -0600, Raphael Geissert 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.
> 
> How do you track that down?
[...]

Check the ITP? mentors.d.n? contact the maintainer? contact ftp-master?

That's exactly why I said "track down".

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Paul Wise]

The best solution would just be to drop most -dbg packages, drop
maintainer-uploaded binary packages (using the buildd built packages
instead), install the dh_strip from debug.d.n on all the buildds and
get people to use -dbgsym packages from debug.d.n.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Possibly excessive lintian warnings (was: NEW processing)

[Raphael Geissert]

Paul Wise wrote:

> The best solution would just be to drop most -dbg packages, drop
> maintainer-uploaded binary packages (using the buildd built packages
> instead), install the dh_strip from debug.d.n on all the buildds and
> get people to use -dbgsym packages from debug.d.n.
> 

a) That doesn't solve the dependencies problem.

b) There are lots of packages missing at debug.d.n, and they only keep one
package version. It isn't a drop-in replacement.

c) What's the point on using a separate server when we have mirrors?

d) We don't need debug symbols for every package out there.

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Work-needing packages report for Dec 5, 2008

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 482 (new: 3)
Total number of packages offered up for adoption: 114 (new: 0)
Total number of packages requested help for: 46 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libaudio-flac-decoder-perl (#507386), orphaned 4 days ago
 Description: Perl module providing an object-oriented FLAC decoder
 Installations reported by Popcon: 85

   libdata-compare-perl (#507388), orphaned 4 days ago
 Description: perl module to compare perl data structures recursively
 Reverse Depends: libtest-simpleunit-perl
 Installations reported by Popcon: 139

   libscalar-properties-perl (#507389), orphaned 4 days ago
 Description: perl module to add run-time properties on scalar
   variables
 Installations reported by Popcon: 48

479 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 114 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#470795), requested 266 days ago
 Description: Co-maintainer wanted
 Reverse Depends: achims-guestbook ampache apache2 apache2-dbg
   apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork
   apache2-mpm-worker apache2-prefork-dev apache2-suexec (151 more
   omitted)
 Installations reported by Popcon: 40520

   ara (#450876), requested 389 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 124

   athcool (#278442), requested 1500 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 231

   bash-completion (#472468), requested 255 days ago
 Description: programmable completion for the bash shell
 Installations reported by Popcon: 19259

   cvs (#354176), requested 1015 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 4

   dctrl-tools (#448284), requested 404 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate feta
   haskell-devscripts hg-buildpackage ia32-archive ia32-libs-tools
   mlmmj sbuild (1 more omitted)
 Installations reported by Popcon: 9400

   dpkg (#282283), requested 1475 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb cacao-oj6-dbg cacao-oj6-jdk
   (118 more omitted)
 Installations reported by Popcon: 79592

   drscheme (#402589), requested 724 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 345

   elvis (#432298), requested 514 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 374

   fglrx-driver (#454993), requested 362 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2163

   flightgear (#487388), requested 166 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 967

   gentoo (#422498), requested 578 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 256

   gnat-4.3 (#475374), requested 238 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven13 (45 more
   omitted)
 Installations reported by Popcon: 605

   gnat-gps (#496905), requested 98 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 123

   grub (#248397), requested 1669 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: brdesktop-artwork-grub dfsbuild grub-choose-default
   grub-doc replicator