[rosa-devel] Updates Builder - Visualization of Update Results
denis.silakov at rosalab.ru
Wed Dec 18 20:51:15 MSK 2013
On 18.12.2013 19:29, Jeff Johnson wrote:
> On Dec 18, 2013, at 3:47 AM, Denis Silakov wrote:
>> Hi all,
>> as some of you likely know, we have an Updates Builder service that
>> detects new upstream releases for some packages and tries to build
>> these new versions in ABF for ROSA and OMV.
>> Now we have pages with statistics concerning Updates Builder work:
>> OMV: http://upstream-tracker.org/updates_builder_reports/omv_results.html
> The percentage of successful builds is less than impressive.
22 packages from 186 for ROSA - more than 10%, not so bad for completely
automated tools. Note that this statistics reflects only December.
Actually for ~7 months Updates Builder performed several hundreds of
successful updates (the success rate was especially high in the
beginning, when we had a lot of outdated packages).
For OMV results are less impressive for one more reason not mentioned
below - new upstream versions often require new dependencies which are
not even present in repositories (this is especially true for R and perl
packages many of which were not updated in our repositories for a couple
It's not hard to add these deps (this can be done in semi-automated
way), but I simply don't have enough permissions in cooker to attache
packages to repositories. After some of my requests to cooker ML to
attach packages to repos were left without answers, I gave up.
Note also that we do have scripts that analyze results of Updates
Builder and try to fix trivial issues. They can be found in ABF:
To be sure, this set can be extended. Some comments on particular cases
suggested by you are below.
> Theses rather simple failures appear to be missing:
> 1) hunk FAILED
> + /usr/bin/patch --fuzz=0 -s -U -p1 -b --suffix .alsa-by-default
> 2 out of 2 hunks FAILED -- saving rejects to file lib-src/portaudio-v19/src/os/unix/pa_unix_hostapis.c.rej
> + exit 1
> If you disable --fuzz=0, many patches will start to apply.
My estimations are not so optimistic. During the last several months I
have updated dozens of packages with patches and in most cases you
should remake the patch. But yes, --fuzz=0 can help in some cases.
> 2) cd: .* No such file or directory
> + cd jack-126.96.36.199
> /var/tmp/rpm-tmp.65054: line 27: cd: jack-188.8.131.52: No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.65054 (%build)
> Bad exit status from /var/tmp/rpm-tmp.65054 (%build)
> Child returncode was: 1
> The version being used by %setup in the *.spec disagrees with the
> tarball unpacking.
> It isn't impossibly hard to create a single deterministic subdir name
> for all %setup unpackings.
> This could even be done by ABF for the overwhelming majority class of
> single-subdirectory builds.
Yes, that's a good idea.
> 3) File not found
> RPM build errors:
> File not found by glob: /builddir/build/BUILDROOT/hdf5-1.8.11-1-rosa2012.1.i586-buildroot/usr/lib/libhdf5.so.7*
> File not found by glob: /builddir/build/BUILDROOT/hdf5-1.8.11-1-rosa2012.1.i586-buildroot/usr/lib/libhdf5_cpp.so.7*
> These errors could (and likely should) be reported and fixed in %files
Some file patterns are already analyzed and fixed by analyze.log script
mentioned above. However, this particular case is more tricky, hdf5 (as
well as many other packages that follow library policy) has defines like
So the correct way is to fix 'major' definition, not the %files directly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rosa-devel