On 03/21/2013 12:09 PM, Adam Spiers wrote:
[setting Cc and Reply-To to the opensuse-buildservice list]
Sascha Peilicke (speilicke@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 interested in. @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 openSUSE:Factory). However, having collapsed boxes means more clicks and wouldn't like that there.
- 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 client-side?)
- 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. - %prep - %build - %install - /usr/lib/rpm/brp-* hooks - autoreqprov calculation - %clean - post-build checks (01-check-debuginfo ... 99-check-remove-rpms) - rpmlint - 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 last idea.)
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, Sascha Peilicke 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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org