Core i386 rawhide rebuild in mock status 2006-06-04

[Paul Howarth]

On Wed, 2006-06-07 at 06:43 +1200, Michael J Knox wrote:
> Paul Howarth wrote:
> > Michael J. Knox wrote:
> >> OK, finally got some time to finsh bug reporting the below.
> >>
> >> The list is now complete (well.. 99% sure it is) with the exception of 
> >> these:
> >>
> >> duplicates present emacs
> >> duplicates present ethereal
> >> duplicates present rgmanager
> >>
> >> The new of each of these built ok.
> >>
> >> libwpd failed because it was not able to download some of the 
> >> requirements. I am now building this locally to test this myself.
> >>
> >> Michael
> > 
> > Now that all of the packages have bugs assigned to them, is there any 
> > convenient way of spotting which ones are just bug reports and which 
> > ones have suggested fixes included, short of actually looking at all of 
> > the reports that are in the "NEW" state? I'd been plodding through the 
> > list making reports with suggested fixes based on the list of packages 
> > without a bug filed, but that list is now going to be empty.
> > 
> > Time to move on to Extras unless somebody can come up with something 
> > clever.
> > 
> 
> Well... To see which are build requires bugs in core, you can look at this:
> 
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=191529
> 
> Or if you want extras, you can look at:
> 
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=193444
> 
> As you can see, extras has a long way to go to catch up.
> 
> http://fedoraproject.org/wiki/QA/FixBuildRequires has links to template 
> bug reports too.

I know about those. The problem is, the bug dependency tree shows which
packages there are issues with, but not which packages already have
suggested fixes. It's pointless me trying to fix a package that someone
has already done some work on and made a suggestion for a fix.
Previously I could look down the list of packages with no bug reported
in Matt's reports and and I'd know that nobody had looked at those yet.
Now I need to look at the bugzilla entries for each package, which takes
far longer.

> The list of bugs to file may well be empty now, but there are still the 
> follow ups and closing of bugs the are fixed and now build inside mock.

Indeed, but the package maintainers that have received the bug reports
are now in the best place to do that, rather than community members like
me who need to search through bugzilla to find issues that need fixing.
I'll concentrate on Extras for now, as it's easier to see what needs
attention.

Paul.