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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpN66KPK_Tra.pgp
Description: PGP signature