[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NEW handling ...



On Thu, Mar 17, 2005 at 10:44:26PM +0100, David Schmitt wrote:
> On Thursday 17 March 2005 22:09, Joerg Jaspert wrote:
> > On 10231 March 1977, David Schmitt wrote:
> > >> > Collecting tidbits of
> > >> > information concerning the various packages rotting in NEW and making
> > >> > that information public.
> > >>
> > >> A list of packages-in-NEW is available on the Web, including binary
> > >> package names, bugs closed, et al.
> > >> Nothing more can be done by the average bored DD, since they cannot
> > >> access these packages, hence not do most of the necessary checks.
> > >
> > > Isn't there a mirror of NEW on merkel?
> >
> > Yes, but you cant read anything else than .changes files in NEW.
> 
> I think it was Anthony who mentioned a script he uses for testing the NEW 

Fernanda.  It prints:

* Contents of .changes (if fed a .changes file);
* Contents of .deb/control (nicely coloured, I might add);
* lintian and linda check results;
* Contents of .deb
* .deb/copyright
* ls -l .deb

I can't think of anything there that obviously violates the crypto-in-main
policy, but I'm not 100% familiar with what's required.  The modification
necessary should be fairly simple: Add a fernanda run to
jennifer::acknowledge_new() (starts at line 1078), and dump the results to a
file.  You'd also have to modify fernanda to check whether sys.stdout is a
TTY, and not invoke less if it isn't, since at the moment it automatically
pipes it's output through less.  The colour codes might also be an issue, so
fernanda may need extra help not to screw that up.

> packages. It'd probably be good-enough[tm] for a first iteration to link 
> output of that script to ftp-master.d.o/new.html or mail it to 
> debian-ftp-master@ldo or something like that.

I'd be inclined to put it in queue/new/<package>.fernanda or something like
that, which could then be linked to from wherever.

> > > kernel-patch-2.4-{blooper,pom} (1 year):
> > > * Fixes for minor annoying kernel bugs
> > > * Netfilter patch-o-matic patches to base level, IPSEC policy match
> > > Both should be superceded by debian-kernel. Could be REJECTed.
> >
> > Should/Could?
> 
> Conservative formula; I have no idea what patches are included. Maintainer 
> should step forward to explain[1].

> [1] Or receive deserved rotting in NEW.

I wonder if we could change Debian's attitude to NEW rejection like has
happened with NMUs -- that having your package rejected isn't the end of the
world, it's just something that happens.  So ftpmasters could reject with
less fear of being taken to the cleaners by random pissed-off maintainers on
d-devel.

- Matt

Attachment: signature.asc
Description: Digital signature


Reply to: