Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
[opensuse-buildservice] challenges in testing changes to rpmlint
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Tue, 14 Feb 2012 00:09:10 +0000
  • Message-id: <20120214000910.GB10523@southern.linksys.moosehall>
Adam Spiers (aspiers@xxxxxxxx) wrote:
Archie Cobbs (archie.cobbs@xxxxxxxxx) wrote:
(dreaming) Why not let each project be a simple git repo, with a
branch for each repository, defaulting to 'master' if no such branch
were defined?

Right, that was also my first reaction too the first time I found
myself in a twisty maze of OBS repositories, all alike.

Speaking of twisty mazes, here's a scenario I just found myself :-(

I'm working on improving some of the OBS source services, during which
I noticed that 'obsrun' is a standard user/group used by the OBS
backend. However, when building from .spec files which reference this
in the %files section, rpmlint complains:

obs-service-tar_scm.noarch: W: non-standard-uid
/var/cache/obs/tar_scm/repourl obsrun
A file in this package is owned by an unregistered user id. To register the
user, please branch the devel:openSUSE:Factory:rpmlint rpmlint package, add
the user to the "config" file and send a submitrequest.

So, wanting to be a good citizen, I branched and made the change.
Before sending the submitrequest, I wanted to test it, so I did an
'osc build' locally, installed the resulting rpm, and then rebuilt
obs-service-tar_scm, hoping to see the warning disappear.
Unfortunately it was a lot harder than that!

TL;DR summary
-------------

- rpmlint-mini.spec pulls in files from /usr on the build host;
isn't that evil and wrong?
- Why does rpmlint-mini include its own Python?
- Why does rpmlint-mini even exist - isn't rpmlint good enough?
- If submitrequests for rpmlint are to be encouraged, IMHO this
all needs to be made a lot more obvious.

The full saga
-------------

I'm not entirely sure what the moral of this story is, but I'm
including it here in case it's of use to anyone in the future ...

First I found out that osc build doesn't use the rpmlint rpm at
build-time; it uses rpmlint-mini, and rpmlint-Factory (even if not
building for Factory, I think). The latter seems to be just a small
layer of additional rpmlint configuration though.

OK, so I needed to get my change into rpmlint-mini somehow. Looking
in its .spec file, I saw the %install section has some very strange
lines - in particular:

install -m 644 -D /usr/share/rpmlint/config
$RPM_BUILD_ROOT/opt/testing/share/rpmlint/config

So the contents of the rpmlint-mini rpm you are building will depend
directly on whichever rpmlint config you happened to have installed on
the build machine at build-time! I thought that there was a golden
rule about .spec files only referring to sources in the SOURCES/
directory, otherwise the generated .src.rpm will not contain all the
sources required to be able to consistently reproduce the same binary
.rpm. Did I get that wrong, or is there a good reason why
rpmlint-mini should be an exception to this rule?

Anyway, I figured that if I rebuilt rpmlint-mini on the same machine
which had my patched rpmlint installed, it would inherit the same
patched config via the install line above. However, rpmlint-mini
also contains:

%define _use_internal_dependency_generator 0
%define __find_requires %my_requires

The point of this seems to be to ensure that all packages found by the
built-in %{__find_provides} are filtered out of the resulting
'requires' list. I'm guessing that this is something to do with the
way that rpmlint-mini contains its own copy of Python (why?!), but the
end result is that my freshly built rpmlint-mini includes the
following dependencies:

...
auto: libc.so.6()(64bit)
auto: libc.so.6(GLIBC_2.11)(64bit)
auto: libc.so.6(GLIBC_2.14)(64bit)
auto: libc.so.6(GLIBC_2.15)(64bit)
...

In particular, the dependency on glibc 2.15 presumably comes from the
rpm being built inside an openSUSE Factory buildroot. So that means I
can only install it inside the buildroot, not on the 12.1 host:

sudo rpm -Uhv
/var/tmp/build-root/openSUSE_Factory/x86_64/home/abuild/rpmbuild/RPMS/x86_64/rpmlint-mini-1.3-0.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.15)(64bit) is needed by rpmlint-mini-1.3-0.x86_64

But that's OK, because it's the buildroot which needs it anyway.
Unfortunately installing it in the buildroot doesn't work either,
because /usr/lib/build/init_buildsystem happily replaces it with the
unpatched version every time:

processing specfile
/home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec
...
running changelog2spec --target rpm --file
/home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec
init_buildsystem --cachedir /var/cache/build --rpmlist /tmp/rpmlist.Zl1T5W
/home/adam/SUSE/OBS/home/aspiers/branches/devel/openSUSE/Factory/rpmlint/rpmlint-mini/rpmlint-mini.spec
...
reordering...cycle: gio-branding-upstream -> libgio-2_0-0
breaking dependency libgio-2_0-0 -> gio-branding-upstream
cycle: libcrack2 -> cracklib
breaking dependency libcrack2 -> cracklib
done
deleting unwanted rpmlint-1.3-0
installing rpmlint-1.3-109.1

Next I tried injecting the patched rpmlint rpm into
/var/tmp/osbuild-packagecache, but that didn't work either. After
wading through /usr/lib/build/{build,init_buildsystem}, I finally
found that the list of rpms to install in the buildroot is actually
generated and passed into build by osc, and there's a nice
--prefer-pkgs=DIR option to osc build which enabled me to ensure that
my patched rpmlint was installed in the buildroot whilst rpmlint-mini
was built. Then I could finally copy the patched rpmlint-mini back to
the preferred package directory and rebuild my source service to
ensure that the non-standard-[ug]id warnings no longer appeared.
They didn't - hooray! So here's the request:

https://build.opensuse.org/request/show/104823
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >