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

Re: MBF Re: Bug#621277: ggz-grubby: Getting rid of unneeded *.la / emptying dependency_libs

On Thu, 7 Apr 2011 19:13:43 +0200
Andreas Metzler <ametzler@downhill.at.eu.org> wrote:

> On 2011-04-06 codehelp@debian.org wrote:
> > Package: ggz-grubby
> > Severity: normal
> > User: codehelp@debian.org
> > Usertags: la-file-removal
> > To finish an old release goal from Squeeze, to comply with Policy
> > 10.2 and to ease the introduction of MultiArch, I'm filing bugs
> > against packages which contain .la files which can be either removed
> > or stripped of the dependency_libs variable.
> [...]
> Hello,
> Please stop this mass bug filing. 

It'll pause whilst I add a few more checks to the process.

> a) There were duplicate bugs filed.

It would have been helpful to list some of those. I've found one out of
the bugs submitted against the packages you mention.

> b) Bugs were filed for issues recently solved.

I do try and avoid that by constantly updating the source data prior to
each phase, but as you describe, some lag is inevitable.

> c) The bugs reports are unversioned.
> I can completely understand that a and b can occassionally happen due
> to timing issues. However imnsho a MBF with unversioned bug-reports is
> not acceptable.

I've been updating the process at this end and I'll be able to add the
version information for the next runs. However, the original data does
not include a version so the only version number available is what can
be retrieved from either an apt-cache on sid or rmadison. That
therefore suffers from the same timing problems as the other issues
you've described.

Some duplicates come from the Ubuntu changes and those have usertags,
so I'll add that check to the processing. I missed that, so apologies
on that score.

That led to #621246 being missed and #620742 being added.

> cu and- closing three invalid reports in ggz-* -dreas

The three bugs I reported against ggz* yesterday were #621246, #621277
and #621339. The other two are not duplicates but have had recent
uploads which might not have got into the source data. Certainly for
#621246, the upload which is currently 1 day old in sid has the dependency_libs emptied. I don't think there's any way that the process can reliably catch uploads that new but thanks for fixing that package.

I'll add the version available on the mirrors at the time of processing,
albeit that the version may not be the very latest version uploaded.


Neil Williams

Attachment: pgpQ2P4y6rAkW.pgp
Description: PGP signature

Reply to: