On 03/21/2013 12:09 PM, Adam Spiers wrote:
[setting Cc and Reply-To to the opensuse-buildservice
Sascha Peilicke (speilicke(a)suse.com) wrote:
On 03/21/2013 09:50 AM, Togan Muftuoglu wrote:
On 03/21/2013 09:10 AM, Sascha Peilicke wrote:
> The reason is I had a declination with a
comment why I have not
> explained use of %ghost macro in a spec file, but a person who would
> have reviewed the rpm buildlogs for the package would realize the fact
> that rpmlint gives the following error.
Who seriously looks at buildlogs when reviewing requests?
I do and I would expect those who review requests do as well other wise
why bother in the first place to generate a build log and rpmlint log.
If the package doesnot build it is recommended to have a look at the
build log. Well I would assume if it builds fine one still should look
the logs and especially the rpmlint log
Well, we review packages building for multiple architectures and a
plethora of distros. Of course I mostly care about openSUSE:Factory
(i586,x86_64) but still. And yes, I look at the rpmlint log for that
target too. And no, I don't look at any build-log. On a calm day, I
review ~50 packages
8-O Wow, I had no idea any one person did that much work!
AFAICS, the rpmlint results are only available in two places:
- the build log
- the Rpmlint Results tab on each package's Overview page
Right? And neither of these are formatted in a very nice way.
Somewhat true yes. The Results tab at least is colored. Back then I
didn't find the screen space to put it next to something, so the
grouping with "Build Results" is good enough IMO. Another good thing is
that currently both have the same output (the webui simply copies it
actually) to what "osc build" spits out. So it's easier to match back.
I simply don't have the time and it makes no
sense either. Packages that don't build are declined by
'factory-auto' already, packages that build are good enough. I doubt
people would appreciate if we start commenting the fuzzy mess that
build-logs are ;-)
Since I am not currently a regular reviewer, feel free to tell me if
I'm talking rubbish, but it seems to me that there are some
low-hanging fruit changes we could make here to make life much easier
for reviewers, e.g.:
- Change the Rpmlint Results tab to group warnings/errors by
filter type, and just show the number of occurrences in each
group. Then you can mouseover or click to see more details.
Could work, but in general I tried to reduce the number of clicks as
much as possible since review time matters. Currently, it's one click to
reach the rpmlint tab and maybe another to pick the distro you're
@Henne: Maybe the distinction between distros can be released a bit,
usually openSUSE:* are all the same to openSUSE:Factory. Only SLE_11_*
rpmlint warnings differ, but they're maybe that outdated that we don't
want to show them. Long story short, only showing Factory rpmlint issues
should be enough for every request (even those not targeted at
However, having collapsed boxes means more clicks and wouldn't like that
- Add a way to view an rpmlint results summary via osc (is there an
API call for this, or do you just have to grep the build log
- Automatically color the build log according to patterns.
Very useful and easily done via CodeMirror2.
- Automatically split the build log into the different phases, e.g.
- booting the VM
- init_buildsystem etc.
- /usr/lib/rpm/brp-* hooks
- autoreqprov calculation
- post-build checks (01-check-debuginfo ... 99-check-remove-rpms)
- post-build tasks (e.g. "creating baselibs", "comparing built
packages with former built")
- VM power down
and make each section expandable in the webUI with all sections
starting collapsed and colour-coded red/green according to whether
the section's contents matched any known failure patterns.
(Actually I already have some code which might help implement this
I like the idea and that may reduce the scrolling needed. Collapsing
sections here is that you usually search for something specific.
Maybe an idea for the next hack week? If that makes sense to people
then I can submit the idea as a proposal.
Sure, please do that. I already have a number of topics for Hackweek I
want to work on, but that doesn't look to difficult.
@Henne: How about you?
With kind regards,
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org