From sergio at sergiomb.no-ip.org Sat Dec 1 22:10:00 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 01 Dec 2007 22:10:00 +0000 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> <20071126141948.498d39a9@redhat.com> <20071126151915.4c7a28ca@redhat.com> Message-ID: <1196547000.28891.4.camel@localhost.localdomain> On Mon, 2007-11-26 at 17:59 -0700, William F. Acker WB2FLW +1-303-722-7209 wrote: > > > http://koji.fedoraproject.org/packages/pungi/1.1.10/1.fc8/data/signed/30c9ecf8/noarch/pungi-1.1.10-1.fc8.noarch.rpm I had a problem when makes repoview .. after that I try pungi with this option -BPI which fails on makedirs every time. This patch correct this , and is safe to use it, please apply it. -------------- next part -------------- A non-text attachment was scrubbed... Name: pungi.py.diff Type: text/x-patch Size: 1474 bytes Desc: not available URL: From jkeating at redhat.com Sun Dec 2 01:56:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 1 Dec 2007 20:56:22 -0500 Subject: Unable to create a distro on multiple disks with Pungi. In-Reply-To: <1196547000.28891.4.camel@localhost.localdomain> References: <20071123094716.5b87066e@redhat.com> <20071123200557.17f67504@redhat.com> <20071126141948.498d39a9@redhat.com> <20071126151915.4c7a28ca@redhat.com> <1196547000.28891.4.camel@localhost.localdomain> Message-ID: <20071201205622.0640ef13@redhat.com> On Sat, 01 Dec 2007 22:10:00 +0000 Sergio Monteiro Basto wrote: > I had a problem when makes repoview .. > after that I try pungi with this option -BPI > which fails on makedirs every time. > This patch correct this , and is safe to use it, please apply it. I'm currently working on a better method of detecting a re-run to an existing destdir. It will obsolete the attached patch. Thanks though! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Dec 3 15:28:43 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 03 Dec 2007 09:28:43 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? Message-ID: With recent versions of mock, (ie, mock-0.8 series), I've noticed change in behavior, seemingly the mockbuild user doesn't include stuff from /etc/profile.d/* (my guess is that it's no longer being treated as a login shell). I mention this because bunch of kde-related packages that once built fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE aren't getting set properly). Can anyone confirm/deny this? -- Rex From paul at city-fan.org Mon Dec 3 16:49:41 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 03 Dec 2007 16:49:41 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071130193556.GC4039@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> Message-ID: <475433A5.6050709@city-fan.org> Michael E Brown wrote: > On Fri, Nov 30, 2007 at 04:17:52PM +0000, Paul Howarth wrote: >> Michael E Brown wrote: >>> I need a little bit of help understanding what the >>> 'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and >>> pushed out mock-0.8 without this. I have rebuilt most of rawhide with >>> this new mock version and have not seen anything that I directly can say >>> was a failure due to this being missing, so I am sort of not seeing the >>> point. >>> >>> I have searched around as much as I can to try to understand why >>> this was put into place. From what I can understand, it was only put in >>> in the FC2 timeframe to fix some problems with the selinux policy on the >>> host machine. These *appear* to have been fixed in the host selinux >>> policy, so again, i dont see a reason to keep this around. >>> >>> Jesse mentioned on IRC, though, that this might be needed, so I pose >>> this question. I've a local branch set up with the 0.8.x code and the >>> LD_PRELOAD put back in. So, I can quickly spin a new release with this >>> back in if it is actually needed. So far, I havent convinced myself it >>> is needed, though... >>> >>> Could somebody please enlighten me? >> I suspect it was there to convince rpm that selinux was disabled and >> hence prevent it from trying to set the contexts of installed files. If >> rpm doesn't set the context, the files are installed as mock_var_lib_t >> (assuming my policy module from the wiki is loaded), and this is a >> "neutral" type that doesn't cause any problems. However, if rpm sets the >> contexts of files it installs, it'll set things like /sbin/ldconfig to >> ldconfig_exec_t, and there is now a transition defined in policy from >> unconfined_t to ldconfig_exec_t. The result of this is that some >> processes such as ldconfig get run "confined" in the chroot and fail as >> a result because not *all* file contexts are set up as they would be on >> the host system, which is what the policy is set up for. >> >> I've not quite figured out all te ins and outs of it but a tell-tale >> sign of there being a problem is to look (ls -lZ) at the root >> directories of your chroots and see if they look like this: >> >> /var/lib/mock/fedora-2-i386-core/root: >> drwxr-xr-x root root system_u:object_r:bin_t:s0 bin >> drwxr-xr-x root root system_u:object_r:boot_t:s0 boot >> drwx------ root mock system_u:object_r:mock_var_lib_t:s0 builddir >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev >> drwxr-xr-x root root system_u:object_r:etc_t:s0 etc >> drwxr-xr-x root root system_u:object_r:home_root_t:s0 home >> drwxr-xr-x root root system_u:object_r:root_t:s0 initrd >> drwxr-xr-x root root system_u:object_r:lib_t:s0 lib >> drwxr-xr-x root root system_u:object_r:mnt_t:s0 mnt >> drwxr-xr-x root root system_u:object_r:usr_t:s0 opt >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc >> drwxr-x--- root root system_u:object_r:user_home_dir_t:s0 root >> drwxr-xr-x root root system_u:object_r:bin_t:s0 sbin >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys >> drwxrwxrwt root root system_u:object_r:tmp_t:s0 tmp >> drwxr-xr-x root root system_u:object_r:usr_t:s0 usr >> drwxr-xr-x root root system_u:object_r:var_t:s0 var >> >> rather than this: >> /var/lib/mock/fedora-3-i386-core/root: >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 bin >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 boot >> drwx------ paul mock system_u:object_r:mock_var_lib_t:s0 builddir >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 dev >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 etc >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 home >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 initrd >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 lib >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 media >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 mnt >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 opt >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 proc >> drwxr-x--- root root system_u:object_r:mock_var_lib_t:s0 root >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 sbin >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 selinux >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 srv >> drwxrwsr-x root mock system_u:object_r:mock_var_lib_t:s0 sys >> drwxrwxrwt root root system_u:object_r:mock_var_lib_t:s0 tmp >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 usr >> drwxr-xr-x root root system_u:object_r:mock_var_lib_t:s0 var >> >> (it's best to remove any cache or existing root and generate a fresh one) >> >> I'd like to try a version with the LD_PRELOAD back in if possible. > > Well you can look at current fedora mock and run > mock -r fedora-8-x86_64 init > > On my local machine (with selinux enabled), I see that everything is > labelled with "var_lib_t", like this: > > $ ls -lZ > drwxr-xr-x root root user_u:object_r:var_lib_t bin > drwxr-xr-x root root user_u:object_r:var_lib_t boot > drwx------ michael_e_brown mock user_u:object_r:var_lib_t builddir > drwxrwxr-x root root user_u:object_r:var_lib_t dev > ... cut ... If you're not using the policy module, I'd expect you to have problems building packages that run mono and/or java code at build time as described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks The package I came across that exhibited this problem and led me to write the policy module was "lat", a mono-based package. > There is a current git branch with the selinux changes ported at: > > git clone http://linux.dell.com/git/mock.git > git checkout -b selinux origin/selinux I built an RPM from this, and my first try at running it resulted in: Traceback (most recent call last): File "/usr/libexec/mock.py", line 430, in os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so" NameError: name 'LIBDIR' is not defined I added a manual definition of LIBDIR into /usr/libexec/mock.py and tt ran a bit further. I now get the sane file contexts that I was expecting but none of the scriptlets run in the target chroot because the object pointed to by the LD_PRELOAD isn't available in the chroot: /bin/sh: error while loading shared libraries: /usr/lib64/libselinux-mock.so: cannot open shared object file: No such file or directory error: %post(bash-2.05b-38.i386) scriptlet failed, exit status 127 /bin/sh: error while loading shared libraries: /usr/lib64/libselinux-mock.so: cannot open shared object file: No such file or directory error: %post(libselinux-1.11.4-1.mockfix.fc2.i386) scriptlet failed, exit status 127 /bin/sh: error while loading shared libraries: /usr/lib64/libselinux-mock.so: cannot open shared object file: No such file or directory error: %post(info-4.7-4.i386) scriptlet failed, exit status 127 /bin/sh: error while loading shared libraries: /usr/lib64/libselinux-mock.so: cannot open shared object file: No such file or directory error: %post(sed-4.0.8-4.i386) scriptlet failed, exit status 127 /bin/sh: error while loading shared libraries: /usr/lib64/libselinux-mock.so: cannot open shared object file: No such file or directory ... and so on. Don't know what to do about that. Paul. From bugs.michael at gmx.net Mon Dec 3 16:52:01 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 3 Dec 2007 17:52:01 +0100 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: References: Message-ID: <20071203175201.4b7ffacc.bugs.michael@gmx.net> On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote: > With recent versions of mock, (ie, mock-0.8 series), I've noticed change in > behavior, seemingly the mockbuild user doesn't include stuff > >from /etc/profile.d/* (my guess is that it's no longer being treated as a > login shell). > > I mention this because bunch of kde-related packages that once built fine, > no longer do, because /etc/profile.d/qt.sh apparently isn't getting > source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE > aren't getting set properly). > > Can anyone confirm/deny this? It would be a bug if it sourced files from /etc/profile.d/* automatically, because a normal rpmbuild does not do that either -- as often the files get installed only after you have logged in already. We have been doing it manually in %build for a very long time, especially for qt.sh From rdieter at math.unl.edu Mon Dec 3 18:32:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 03 Dec 2007 12:32:39 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote: > >> With recent versions of mock, (ie, mock-0.8 series), I've noticed change >> in behavior, seemingly the mockbuild user doesn't include stuff >> >from /etc/profile.d/* (my guess is that it's no longer being treated as >> >a >> login shell). >> >> I mention this because bunch of kde-related packages that once built >> fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting >> source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE >> aren't getting set properly). >> >> Can anyone confirm/deny this? Or more precisely, is this mock's intended behavior? If so, please reconsider. :) > It would be a bug if it sourced files from /etc/profile.d/* automatically, > because a normal rpmbuild does not do that either -- The user running rpmbuild logged in, and sourced things. mockbuild used to do the same (with 0.7), but now apparently doesn't. > We have been doing > it manually in %build for a very long time, especially for qt.sh This is a hack to cater to the "I just installed pkg X after logging in, why doesn't my local rpmbuild work?" croud. That's all fine and dandy, but I'd much rather not make manual source'ing of profile.d/ items a requirement to make things "just work" in fedora's buildsys either. -- Rex -- Rex From jkeating at redhat.com Mon Dec 3 19:00:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 3 Dec 2007 14:00:40 -0500 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> Message-ID: <20071203140040.0127e440@redhat.com> On Mon, 03 Dec 2007 12:32:39 -0600 Rex Dieter wrote: > This is a hack to cater to the "I just installed pkg X after logging > in, why doesn't my local rpmbuild work?" croud. That's all fine and > dandy, but I'd much rather not make manual source'ing of profile.d/ > items a requirement to make things "just work" in fedora's buildsys > either. And I'd rather not rely on some "shell magic" to make things just work too. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Mon Dec 3 22:39:26 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 16:39:26 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <475433A5.6050709@city-fan.org> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> Message-ID: <20071203223925.GC14186@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote: > Michael E Brown wrote: > If you're not using the policy module, I'd expect you to have problems > building packages that run mono and/or java code at build time as > described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks > > The package I came across that exhibited this problem and led me to > write the policy module was "lat", a mono-based package. > > >There is a current git branch with the selinux changes ported at: > > > > git clone http://linux.dell.com/git/mock.git > > git checkout -b selinux origin/selinux > > I built an RPM from this, and my first try at running it resulted in: > > Traceback (most recent call last): > File "/usr/libexec/mock.py", line 430, in > os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so" > NameError: name 'LIBDIR' is not defined > > I added a manual definition of LIBDIR into /usr/libexec/mock.py and tt > ran a bit further. I now get the sane file contexts that I was expecting > but none of the scriptlets run in the target chroot because the object > pointed to by the LD_PRELOAD isn't available in the chroot: > > /bin/sh: error while loading shared libraries: > /usr/lib64/libselinux-mock.so: cannot open shared object file: No such > file or directory > > ... and so on. > > Don't know what to do about that. The selinux stuff was only lightly tested. Looks like it still needs work. Looks like I missed something when I rebased to HEAD. I'll take another look at it, and also check out lat. -- Michael From Michael_E_Brown at dell.com Mon Dec 3 22:53:48 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 16:53:48 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> Message-ID: <20071203225348.GD14186@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 12:32:39PM -0600, Rex Dieter wrote: > Michael Schwendt wrote: > > > On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote: > > > >> With recent versions of mock, (ie, mock-0.8 series), I've noticed change > >> in behavior, seemingly the mockbuild user doesn't include stuff > >> >from /etc/profile.d/* (my guess is that it's no longer being treated as > >> >a > >> login shell). > >> > >> I mention this because bunch of kde-related packages that once built > >> fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting > >> source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE > >> aren't getting set properly). > >> > >> Can anyone confirm/deny this? > > Or more precisely, is this mock's intended behavior? > If so, please reconsider. :) Yes, this is the intended behaviour. The behaviour from 0.7 was a bug as it made builds non-reproduce-able, becuase environment variables from the host leaked into the chroot build. If I run a mock 0.7 build of PKG_X and I have QT installed on my local machine, PKG_X, then the mock build would see QT. If you run a mock 0.7 build of PKG_X and *dont* have QT installed on your box, then PKG_X build silently doesnt see QT. This could lead to silently-differing output RPMs from two otherwise identical builds. The new mock scrubs the environment in the setuid wrapper such that when we exec() rpmbuild it has a clean environment. When we exec() rpmbuild, we do so with a clean environment. If you wish to include dependencies, the proper way to do that is from the specfile. -- Michael From Michael_E_Brown at dell.com Mon Dec 3 23:33:34 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 17:33:34 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071203223925.GC14186@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> Message-ID: <20071203233333.GA20024@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 04:39:26PM -0600, Michael E Brown wrote: > On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote: > > Michael E Brown wrote: > > If you're not using the policy module, I'd expect you to have problems > > building packages that run mono and/or java code at build time as > > described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks Can you explain to me what you mean by "if you're not using the policy module"? I'm sorta-slow when it comes to selinux (as evidenced by this thread...) > > The package I came across that exhibited this problem and led me to > > write the policy module was "lat", a mono-based package. Using unmodified current mock (0.8.12) on Fedora 8 with selinux enforcing, I was able to compile current F8 lat: $ mock -r fedora-8-x86_64 --rebuild --resultdir=./try/out ./try/lat-1.2.3-1.fc8.src.rpm INFO: mock.py version 0.8.12 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean INFO: Start(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) State Changed: init State Changed: lock buildroot INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled root cache State Changed: unpacking cache State Changed: running yum State Changed: setup State Changed: build INFO: Done(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) 9 minutes 42 seconds INFO: Results and/or logs in: ./try/out INFO: Cleaning up build root ('clean_on_success=True') State Changed: lock buildroot State Changed: clean -- Michael From orion at cora.nwra.com Mon Dec 3 23:38:10 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Dec 2007 16:38:10 -0700 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: <20071203225348.GD14186@humbolt.us.dell.com> References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203225348.GD14186@humbolt.us.dell.com> Message-ID: <47549362.1020100@cora.nwra.com> Michael E Brown wrote: > > When we exec() rpmbuild, we do so with a clean environment. If you wish > to include dependencies, the proper way to do that is from the specfile. One could argue though that it should exec rpmbuild within a login shell so that it picks up settings from /etc/profile.d/* within the chroot environment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Michael_E_Brown at dell.com Mon Dec 3 23:55:03 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 3 Dec 2007 17:55:03 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: <47549362.1020100@cora.nwra.com> References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203225348.GD14186@humbolt.us.dell.com> <47549362.1020100@cora.nwra.com> Message-ID: <20071203235502.GB20024@humbolt.us.dell.com> On Mon, Dec 03, 2007 at 04:38:10PM -0700, Orion Poplawski wrote: > Michael E Brown wrote: > > > >When we exec() rpmbuild, we do so with a clean environment. If you wish > >to include dependencies, the proper way to do that is from the specfile. > > One could argue though that it should exec rpmbuild within a login shell > so that it picks up settings from /etc/profile.d/* within the chroot > environment. Indeed. One could argue that. At this point, I would defer to Jesse, who has more experience in this specific area. I was merely trying to point out why the old mock behaviour was a bug (leaking env vars from host=>chroot). The patch to change the rpmbuild to be a login shell would not be a large one, and I am sort of on the fence about it. (Minor input would be that env. vars from /etc/profile.d/ seem like a poor way to do this, there seem to be lots of better ways.) -- Michael From Matt_Domsch at dell.com Tue Dec 4 05:02:11 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 3 Dec 2007 23:02:11 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: <20071203235502.GB20024@humbolt.us.dell.com> References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203225348.GD14186@humbolt.us.dell.com> <47549362.1020100@cora.nwra.com> <20071203235502.GB20024@humbolt.us.dell.com> Message-ID: <20071204050211.GA4865@auslistsprd01.us.dell.com> On Mon, Dec 03, 2007 at 05:55:03PM -0600, Michael E Brown wrote: > On Mon, Dec 03, 2007 at 04:38:10PM -0700, Orion Poplawski wrote: > > Michael E Brown wrote: > > > > > >When we exec() rpmbuild, we do so with a clean environment. If you wish > > >to include dependencies, the proper way to do that is from the specfile. > > > > One could argue though that it should exec rpmbuild within a login shell > > so that it picks up settings from /etc/profile.d/* within the chroot > > environment. > > Indeed. One could argue that. > > At this point, I would defer to Jesse, who has more experience in this > specific area. > > I was merely trying to point out why the old mock behaviour was a bug > (leaking env vars from host=>chroot). > > The patch to change the rpmbuild to be a login shell would not be a > large one, and I am sort of on the fence about it. (Minor input would be > that env. vars from /etc/profile.d/ seem like a poor way to do this, > there seem to be lots of better ways.) What's the benefit to having mock implicitly invoke a login shell, rather than the spec file explicitly including such if it needs it? I much prefer explicit over implicit - so much easier to track down when things don't work as expected when you don't have to "just know" that mock uses a login shell to invoke /etc/profile.d/* because you can see in the spec where /etc/profile.d/qt.sh got sourced. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From paul at city-fan.org Tue Dec 4 12:35:03 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Dec 2007 12:35:03 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071203233333.GA20024@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <20071203233333.GA20024@humbolt.us.dell.com> Message-ID: <47554977.7040004@city-fan.org> Michael E Brown wrote: > On Mon, Dec 03, 2007 at 04:39:26PM -0600, Michael E Brown wrote: >> On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote: >>> Michael E Brown wrote: >>> If you're not using the policy module, I'd expect you to have problems >>> building packages that run mono and/or java code at build time as >>> described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks > > Can you explain to me what you mean by "if you're not using the policy > module"? I'm sorta-slow when it comes to selinux (as evidenced by this > thread...) I'm referring to the SELinux policy module attached to the wiki page: http://fedoraproject.org/wiki/PackageMaintainers/MockTricks There's a description of the problem (at least as it was in FC5) on that page. >>> The package I came across that exhibited this problem and led me to >>> write the policy module was "lat", a mono-based package. > > Using unmodified current mock (0.8.12) on Fedora 8 with selinux > enforcing, I was able to compile current F8 lat: > > $ mock -r fedora-8-x86_64 --rebuild --resultdir=./try/out ./try/lat-1.2.3-1.fc8.src.rpm > INFO: mock.py version 0.8.12 starting... > State Changed: init plugins > State Changed: start > State Changed: lock buildroot > State Changed: clean > INFO: Start(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) > State Changed: init > State Changed: lock buildroot > INFO: enabled yum cache > State Changed: cleaning yum metadata > INFO: enabled root cache > State Changed: unpacking cache > State Changed: running yum > State Changed: setup > State Changed: build > INFO: Done(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) 9 minutes 42 seconds > INFO: Results and/or logs in: ./try/out > INFO: Cleaning up build root ('clean_on_success=True') > State Changed: lock buildroot > State Changed: clean I'm also unable to reproduce the problem at this time, but I believe that that's because of the labelling issue, which is masking the problem. After building lat, try this: # ls -lZ /var/lib/mock/fedora-8-x86_64/root/usr/bin/mono I get: -rwxr-xr-x root root system_u:object_r:mono_exec_t:s0 /var/lib/mock/fedora-8-x86_64/root/usr/bin/mono With the LD_PRELOAD, this would have been var_lib_t or mock_var_lib_t, depending on whether you were using the policy module. I'd expect the build to fail with this file not labelled as mono_exec_t, due to execmod errors. If you get var_lib_t for this file, could you try removing any cache for this root, and also the root itself (/var/lib/mock/fedora-8-x86_64/root) and try again? Paul. From rdieter at math.unl.edu Tue Dec 4 13:55:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Dec 2007 07:55:41 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> Message-ID: Jesse Keating wrote: > On Mon, 03 Dec 2007 12:32:39 -0600 > Rex Dieter wrote: > >> This is a hack to cater to the "I just installed pkg X after logging >> in, why doesn't my local rpmbuild work?" croud. That's all fine and >> dandy, but I'd much rather not make manual source'ing of profile.d/ >> items a requirement to make things "just work" in fedora's buildsys >> either. > > And I'd rather not rely on some "shell magic" to make things just work > too. Sigh, so can someone come up with a better solution to "I want to install pkg foo, where it defines env vars, and pkgs consuming/using pkg foo shouldn't need to know it's implementation details (ie, which file in /etc/profile.d/ needs to source'd)" ? -- Rex From jkeating at redhat.com Tue Dec 4 14:23:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 4 Dec 2007 09:23:47 -0500 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> Message-ID: <20071204092347.170febf5@redhat.com> On Tue, 04 Dec 2007 07:55:41 -0600 Rex Dieter wrote: > Sigh, so can someone come up with a better solution to "I want to > install pkg foo, where it defines env vars, and pkgs consuming/using > pkg foo shouldn't need to know it's implementation details (ie, which > file in /etc/profile.d/ needs to source'd)" ? How do you plan to solve this when installing on a real system? User installs a bunch of -devel packages, tries to do an rpmbuild, fail. What then? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Dec 4 14:50:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Dec 2007 08:50:44 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> <20071204092347.170febf5@redhat.com> Message-ID: Jesse Keating wrote: > On Tue, 04 Dec 2007 07:55:41 -0600 > Rex Dieter wrote: > >> Sigh, so can someone come up with a better solution to "I want to >> install pkg foo, where it defines env vars, and pkgs consuming/using >> pkg foo shouldn't need to know it's implementation details (ie, which >> file in /etc/profile.d/ needs to source'd)" ? > > How do you plan to solve this when installing on a real system? User > installs a bunch of -devel packages, tries to do an rpmbuild, fail. > What then? The easiest (and only) solution I see so far is my initial suggestion: "start a (new) login shell". If that's not acceptable, then we're stuck with the status-quo. -- Rex From mikeb at redhat.com Tue Dec 4 19:13:54 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 04 Dec 2007 14:13:54 -0500 Subject: mock not processing /etc/profile.d/*, not a login shell? In-Reply-To: References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> <20071204092347.170febf5@redhat.com> Message-ID: <1196795634.23743.2.camel@burren.boston.redhat.com> On Tue, 2007-12-04 at 08:50 -0600, Rex Dieter wrote: > Jesse Keating wrote: > > > On Tue, 04 Dec 2007 07:55:41 -0600 > > Rex Dieter wrote: > > > >> Sigh, so can someone come up with a better solution to "I want to > >> install pkg foo, where it defines env vars, and pkgs consuming/using > >> pkg foo shouldn't need to know it's implementation details (ie, which > >> file in /etc/profile.d/ needs to source'd)" ? > > > > How do you plan to solve this when installing on a real system? User > > installs a bunch of -devel packages, tries to do an rpmbuild, fail. > > What then? > > The easiest (and only) solution I see so far is my initial suggestion: > "start a (new) login shell". > > If that's not acceptable, then we're stuck with the status-quo. Why not convert qt to use pkg-config like so many other projects do, rather than stuffing build configuration details into my environment, where I don't care about them 99% of the time? From opensource at till.name Tue Dec 4 20:42:47 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 21:42:47 +0100 Subject: [Patch] Typo in Makefile.common scratch-build-% target Message-ID: <200712042142.48180.opensource@till.name> Hiyas, I noticed that there is a typo in the scratch-build-% target in Makefile.common, which breaks the target. The attached patch fixes this. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-arch-override-typo.patch Type: text/x-makefile Size: 779 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rdieter at math.unl.edu Tue Dec 4 21:40:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Dec 2007 15:40:55 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> <20071204092347.170febf5@redhat.com> <1196795634.23743.2.camel@burren.boston.redhat.com> Message-ID: Mike Bonnet wrote: > Why not convert qt to use pkg-config like so many other projects do, > rather than stuffing build configuration details into my environment, > where I don't care about them 99% of the time? qt itself *does* use pkg-config, many qt-consuming apps don't use pkg-config (yet). -- Rex From paul at city-fan.org Wed Dec 5 12:35:46 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Dec 2007 12:35:46 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071203223925.GC14186@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> Message-ID: <47569B22.6060307@city-fan.org> Michael E Brown wrote: > On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote: >> Michael E Brown wrote: >> If you're not using the policy module, I'd expect you to have problems >> building packages that run mono and/or java code at build time as >> described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks >> >> The package I came across that exhibited this problem and led me to >> write the policy module was "lat", a mono-based package. >> >>> There is a current git branch with the selinux changes ported at: >>> >>> git clone http://linux.dell.com/git/mock.git >>> git checkout -b selinux origin/selinux >> I built an RPM from this, and my first try at running it resulted in: >> >> Traceback (most recent call last): >> File "/usr/libexec/mock.py", line 430, in >> os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so" >> NameError: name 'LIBDIR' is not defined >> >> I added a manual definition of LIBDIR into /usr/libexec/mock.py and tt >> ran a bit further. I now get the sane file contexts that I was expecting >> but none of the scriptlets run in the target chroot because the object >> pointed to by the LD_PRELOAD isn't available in the chroot: >> >> /bin/sh: error while loading shared libraries: >> /usr/lib64/libselinux-mock.so: cannot open shared object file: No such >> file or directory >> >> ... and so on. >> >> Don't know what to do about that. > > The selinux stuff was only lightly tested. Looks like it still needs > work. Looks like I missed something when I rebased to HEAD. The way I *think* it used to work was that mock-helper would set the LD_PRELOAD and then exec() the required program (rpm, yum, whatever). When it came to running yum, it didn't exec() yum directly, it exec()-ed mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD from the environment (the libselinux-mock already being in place from the exec() that called it). The result of this was that child processes of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the fake libselinux without the LD_PRELOAD being visible. The more integrated architecture of mock now may make this sort of hack quite difficult to implement. Paul. From dennis at ausil.us Tue Dec 4 21:01:29 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 4 Dec 2007 15:01:29 -0600 Subject: [Patch] Typo in Makefile.common scratch-build-% target In-Reply-To: <200712042142.48180.opensource@till.name> References: <200712042142.48180.opensource@till.name> Message-ID: <200712041501.29915.dennis@ausil.us> On Tuesday 04 December 2007, Till Maas wrote: > Hiyas, > > I noticed that there is a typo in the scratch-build-% target in > Makefile.common, which breaks the target. The attached patch fixes this. > > Regards, > Till applied thanks From astrand at cendio.se Wed Dec 5 19:09:20 2007 From: astrand at cendio.se (=?UTF-8?Q?Peter_=C3=85strand?=) Date: Wed, 5 Dec 2007 20:09:20 +0100 (CET) Subject: SELinux error message and Anaconda dependencies Message-ID: During installation of our minimal F8 system, we get: /usr/sbin_load_policy: Can't load policy: No such file or directory The installation works anyway, but this looks a little bit ugly. I presume this is because no SELinux policy package has been included? Is it possible to get rid of the message without adding (more) SELinux packages? Speaking of unwanted packages: It's a bit sad that the anaconda-runtime package needs to be included in the generated distribution. If it were not for this package, the distribution could be shrinked substantially. Currently, we are down at 411 packages and something like 800 MB. Ok, but the build time is quite long. If anaconda-runtime wasn't necessary, we could get rid of things like: anaconda (14 MB) anaconda-runtime (4 MB) policycoreutils, checkpolicy (3.5 MB) zenity (3 MB) system-config-firewall, firstboot, system-config-keyboard (3 MB) syslinux (1.5 MB) genisoimage (1.3 MB) ...and so on. But I guess this is not possible? There are some strange dependencies as well. For example, fedora-gnome-theme is required by libgnome, and firstboot is required by system-config-keyboard. Tricky, not what I expected. Regards, --- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Link?ping Phone: +46-13-21 46 00 From jkeating at redhat.com Wed Dec 5 19:13:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Dec 2007 14:13:52 -0500 Subject: SELinux error message and Anaconda dependencies In-Reply-To: References: Message-ID: <20071205141352.2cf0c248@redhat.com> On Wed, 5 Dec 2007 20:09:20 +0100 (CET) Peter ?strand wrote: > ...and so on. But I guess this is not possible? Well, pungi needs to grow the ability to separate the packages needed for composing vs the packages that will be in the compose. Once that's accomplished, then your package manifest can drop anaconda-runtime and a few other things. I just haven't done that work yet, and I'm not planning to for F9. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ob.system at gmail.com Fri Dec 7 20:12:02 2007 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Fri, 7 Dec 2007 15:12:02 -0500 Subject: Koji-1.3 and SVN Message-ID: <6a28481b0712071212t79f1d933h5bca7ba9b9f5b8f4@mail.gmail.com> How should I set my SVN repository for Koji use? thank's Oscar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael_E_Brown at dell.com Fri Dec 7 20:40:44 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 7 Dec 2007 14:40:44 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <47569B22.6060307@city-fan.org> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <47569B22.6060307@city-fan.org> Message-ID: <20071207204043.GC20952@humbolt.us.dell.com> On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote: > The way I *think* it used to work was that mock-helper would set the > LD_PRELOAD and then exec() the required program (rpm, yum, whatever). > When it came to running yum, it didn't exec() yum directly, it exec()-ed > mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD > from the environment (the libselinux-mock already being in place from > the exec() that called it). The result of this was that child processes > of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the > fake libselinux without the LD_PRELOAD being visible. > > The more integrated architecture of mock now may make this sort of hack > quite difficult to implement. s/difficult/easy/g; It should be extremely easy to do this, *if* it is necessary. We just need to set/unset the variable as necessary around all calls to external programs. Like this: os.environ['LD_PRELOAD'] = "..."; or del(os.environ["LD_PRELOAD"]); Luckily, we have *one* entry point to call all external programs, atm, which is mock.util.do(). We just need to decide before each external call if we need to set the variable or not. We also have *one* wrapper for running yum, which then calls down to mock.util.do(). If necessary, we could easily set/unset this variable in that call and insulate all other callers from this knowledge. All-in-all, if we can come up with a test case for why we would still need the preload, I could quite easily add this functionality back. So far, though, I'm not seeing a lot of evidence of what is broken, and I'm the sort that likes to see the broken pieces before I implement the fix. -- Michael From wacker at octothorp.org Fri Dec 7 21:06:07 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Fri, 7 Dec 2007 14:06:07 -0700 (MST) Subject: Spinning our distro with the new yum Message-ID: I know that testing would be best, but I just thought I'd check if anyone has had a chance to build with today's yum. I know that with F7, we had to stick to the original yum in order to get a distro that would install. Although there's no reason to think that any yum update would be fatal, I thought I'd ask. TIA. -- Bill in Denver From kanarip at kanarip.com Fri Dec 7 21:12:49 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 22:12:49 +0100 Subject: Spinning our distro with the new yum In-Reply-To: References: Message-ID: <4759B751.6080603@kanarip.com> William F. Acker WB2FLW +1-303-722-7209 wrote: > I know that testing would be best, but I just thought I'd check if > anyone has had a chance to build with today's yum. I know that with F7, > we had to stick to the original yum in order to get a distro that would > install. Although there's no reason to think that any yum update would > be fatal, I thought I'd ask. > I think this yum update actually fixes more then it breaks. One of those fixes possibly includes the fix for https://bugzilla.redhat.com/show_bug.cgi?id=372011 (endlessly looping yum), but I haven't verified yet. -Jeroen From skvidal at fedoraproject.org Fri Dec 7 21:14:57 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 07 Dec 2007 16:14:57 -0500 Subject: Spinning our distro with the new yum In-Reply-To: References: Message-ID: <1197062097.7714.15.camel@cutter> On Fri, 2007-12-07 at 14:06 -0700, William F. Acker WB2FLW +1-303-722-7209 wrote: > I know that testing would be best, but I just thought I'd check if anyone > has had a chance to build with today's yum. I know that with F7, we had > to stick to the original yum in order to get a distro that would install. > Although there's no reason to think that any yum update would be fatal, I > thought I'd ask. yum 3.2.8 should be pretty good. It's time in updates-testing for f7 and f8 looked good. You want to make sure you get 3.2.8-2 if you're doing livecd spins. Jeremy found a problem there and promptly fixed it. -sv From paul at city-fan.org Sat Dec 8 11:08:02 2007 From: paul at city-fan.org (Paul Howarth) Date: Sat, 8 Dec 2007 11:08:02 +0000 Subject: Pathname-based buildreqs not working? Message-ID: <20071208110802.3c43672a@metropolis.intra.city-fan.org> Yesterday I noticed that mock/yum seem to be having trouble finding pathname-based buildreqs. For example, buildreqs of /usr/include/tcpd.h and /usr/include/pcap.h aren't getting found. I use these to maintain spec compatibility across various releases, where these files can be found in either tcp_wrappers or tcp_wrappers-devel, or libpcap or libpcap-devel packages respectively. I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it hasn't helped. Is this intentional behaviour (not getting/reading the filelists metadata) for speed purposes? Paul. From jos at xos.nl Sat Dec 8 11:29:07 2007 From: jos at xos.nl (Jos Vos) Date: Sat, 8 Dec 2007 12:29:07 +0100 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071208110802.3c43672a@metropolis.intra.city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> Message-ID: <20071208112907.GB17849@jasmine.xos.nl> On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > Yesterday I noticed that mock/yum seem to be having trouble finding > pathname-based buildreqs. I had this problem with RHEL5, mock 0.7.4 and yum 3.0.x, but not with yum 3.2.x. Is this maybe a yum problem? Did you directly query yum to search for these files as a test? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From paul at city-fan.org Sat Dec 8 15:03:22 2007 From: paul at city-fan.org (Paul Howarth) Date: Sat, 8 Dec 2007 15:03:22 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071208112907.GB17849@jasmine.xos.nl> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> Message-ID: <20071208150322.63717924@metropolis.intra.city-fan.org> On Sat, 8 Dec 2007 12:29:07 +0100 Jos Vos wrote: > On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > > > Yesterday I noticed that mock/yum seem to be having trouble finding > > pathname-based buildreqs. > > I had this problem with RHEL5, mock 0.7.4 and yum 3.0.x, but not > with yum 3.2.x. Is this maybe a yum problem? Did you directly > query yum to search for these files as a test? Worked fine: # yum install /usr/include/pcap.h Setting up Install Process Parsing package install arguments Importing additional filelist information filelists.sqlite.bz2 100% |=========================| 70 kB 00:00 filelists.sqlite.bz2 100% |=========================| 94 kB 00:00 filelists.sqlite.bz2 100% |=========================| 1.8 MB 00:13 filelists.sqlite.bz2 100% |=========================| 762 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package libpcap-devel.x86_64 14:0.9.7-3.fc8 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: libpcap-devel x86_64 14:0.9.7-3.fc8 fedora 28 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 28 k Is this ok [y/N]: n Exiting on user Command Complete! # rpm -q yum yum-3.2.7-2.fc8 I noticed though that in the failed mock run, the yum_cache for the target didn't include the filelists metadata... Paul. From Michael_E_Brown at dell.com Mon Dec 10 05:34:14 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Sun, 9 Dec 2007 23:34:14 -0600 Subject: mock 0.9.0 in rawhide, mock 0.8.16 pending updates-testing for F-7, F-8 Message-ID: <20071210053413.GB15457@humbolt.us.dell.com> Mock users: I have built mock 0.8.16 for F7/F8 updates-testing with bodhi push pending. Changes in 0.8.16: -- Fix --without to operate according to rpmbuild specs -- add --trace cmdline parameter to activate function tracing (off by default) -- root logs are now less verbose. -- more friendly for users using automounts If you file a bug report against mock, please enable function tracing (--trace) and attach the root/build logs. I have also built 0.9.0 for rawhide. The 0.9.0 branch is synced with the 0.8 branch, so it has the above changes. Additionally, the /usr/bin/mock setuid wrapper is now completely gone, replaced by userhelper. I have included userhelper pam config that emulates the old mock setuid helper, eg. if user is in group 'mock', it allows access. Additionally, if the user is not in the 'mock' group, it will now allow access if root password is given. You can change this through standard pam config in /etc/pam.d/mock. Since I have not ever configured userhelper or pam before, if somebody could review the userhelper/pam changes, that would be appreciated. -- Michael From paul at city-fan.org Mon Dec 10 11:52:04 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Dec 2007 11:52:04 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071208112907.GB17849@jasmine.xos.nl> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> Message-ID: <475D2864.7030701@city-fan.org> Jos Vos wrote: > On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > >> Yesterday I noticed that mock/yum seem to be having trouble finding >> pathname-based buildreqs. > > I had this problem with RHEL5, mock 0.7.4 and yum 3.0.x, but not > with yum 3.2.x. Is this maybe a yum problem? Did you directly > query yum to search for these files as a test? Looking at the code in mock, it appears to use this command: yum --installroot=/var/lib/mock/fedora-devel-i386/root resolvedep But even that works when run manually: # yum --installroot=/var/lib/mock/fedora-devel-i386/root resolvedep openssl-devel /usr/include/tcpd.h openldap-devel Yum Version: 3.2.8 COMMAND: yum --installroot=/var/lib/mock/fedora-devel-i386/root resolvedep openssl-devel /usr/include/tcpd.h openldap-devel Installroot: /var/lib/mock/fedora-devel-i386/root Ext Commands: openssl-devel /usr/include/tcpd.h openldap-devel Reading Local RPMDB Setting up Package Sacks kludge 100% |=========================| 951 B 00:00 primary.xml.gz 100% |=========================| 199 B 00:00 city-fan.org 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 86 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 5.5 MB 00:00 Searching pkgSack for dep: openssl-devel skipping reposetup, pkgsack exists Potential match for openssl-devel from openssl-devel - 0.9.8g-2.fc9.i386 Matched openssl-devel - 0.9.8g-2.fc9.i386 to require for openssl-devel 0:openssl-devel-0.9.8g-2.fc9.i386 Searching pkgSack for dep: /usr/include/tcpd.h skipping reposetup, pkgsack exists Importing additional filelist information filelists.xml.gz 100% |=========================| 192 B 00:00 filelists.sqlite.bz2 100% |=========================| 93 kB 00:00 filelists.sqlite.bz2 100% |=========================| 9.2 MB 00:00 skipping reposetup, pkgsack exists Potential match for /usr/include/tcpd.h from tcp_wrappers-devel - 7.6-50.fc8.i386 0:tcp_wrappers-devel-7.6-50.fc8.i386 Searching pkgSack for dep: openldap-devel skipping reposetup, pkgsack exists Potential match for openldap-devel from openldap-devel - 2.4.6-1.fc9.i386 Matched openldap-devel - 2.4.6-1.fc9.i386 to require for openldap-devel 0:openldap-devel-2.4.6-1.fc9.i386 It's really strange that this doesn't work from within mock. Paul. From rob.myers at gtri.gatech.edu Mon Dec 10 16:10:45 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 10 Dec 2007 11:10:45 -0500 Subject: Koji-1.3 and SVN In-Reply-To: <6a28481b0712071212t79f1d933h5bca7ba9b9f5b8f4@mail.gmail.com> References: <6a28481b0712071212t79f1d933h5bca7ba9b9f5b8f4@mail.gmail.com> Message-ID: <1197303045.29836.182.camel@rxm-581b.stl.gtri.gatech.edu> On Fri, 2007-12-07 at 15:12 -0500, Oscar Victorio Calixto Bacho wrote: > How should I set my SVN repository for Koji use? it needs to have the same function and structure as the fedora build system. koji will attempt to checkout the package as well as the common bits. for example, my svn tree looks like: trunk/common trunk/common/Makefile trunk/common/Makefile.common trunk/common/branches trunk/somerpmpackagename/Makefile trunk/somerpmpackagename/sources trunk/somerpmpackagename/somerpmpackagename.spec you'll also have to modify then Makefile.common from Fedora to use svn data instead of cvs data for the build command. hope that helps, and good luck. rob. From Michael_E_Brown at dell.com Mon Dec 10 23:13:38 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 10 Dec 2007 17:13:38 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <475D2864.7030701@city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> Message-ID: <20071210231337.GA19686@humbolt.us.dell.com> On Mon, Dec 10, 2007 at 11:52:04AM +0000, Paul Howarth wrote: > Jos Vos wrote: > >On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > > > >>Yesterday I noticed that mock/yum seem to be having trouble finding > >>pathname-based buildreqs. > > > >I had this problem with RHEL5, mock 0.7.4 and yum 3.0.x, but not > >with yum 3.2.x. Is this maybe a yum problem? Did you directly > >query yum to search for these files as a test? > > Looking at the code in mock, it appears to use this command: > > yum --installroot=/var/lib/mock/fedora-devel-i386/root resolvedep > Can you look in the root.log for this resolvedep command and check out what is going on? There isnt anything specifically in mock to disallow this. It should work, afaict. Send a pastebin link to the root.log, if possible, or a URL to an SRPM with this problem. -- Michael From paul at city-fan.org Tue Dec 11 00:37:24 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Dec 2007 00:37:24 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071210231337.GA19686@humbolt.us.dell.com> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> Message-ID: <20071211003724.5c32762a@metropolis.intra.city-fan.org> On Mon, 10 Dec 2007 17:13:38 -0600 Michael E Brown wrote: > On Mon, Dec 10, 2007 at 11:52:04AM +0000, Paul Howarth wrote: > > Jos Vos wrote: > > >On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > > > > > >>Yesterday I noticed that mock/yum seem to be having trouble > > >>finding pathname-based buildreqs. > > > > > >I had this problem with RHEL5, mock 0.7.4 and yum 3.0.x, but not > > >with yum 3.2.x. Is this maybe a yum problem? Did you directly > > >query yum to search for these files as a test? > > > > Looking at the code in mock, it appears to use this command: > > > > yum --installroot=/var/lib/mock/fedora-devel-i386/root resolvedep > > > > Can you look in the root.log for this resolvedep command and check out > what is going on? > > There isnt anything specifically in mock to disallow this. It should > work, afaict. > > Send a pastebin link to the root.log, if possible, or a URL to an SRPM > with this problem. Root log: http://www.city-fan.org/~paul/ntop-3.3-2.fc8.CF-root.log SRPM: http://www.city-fan.org/~paul/ntop-3.3-2.fc8.CF.src.rpm Cheers, Paul. From Michael_E_Brown at dell.com Tue Dec 11 18:16:53 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 12:16:53 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071211003724.5c32762a@metropolis.intra.city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> Message-ID: <20071211181652.GA7777@humbolt.us.dell.com> On Tue, Dec 11, 2007 at 12:37:24AM +0000, Paul Howarth wrote: > On Mon, 10 Dec 2007 17:13:38 -0600 > Michael E Brown wrote: > > Can you look in the root.log for this resolvedep command and check out > > what is going on? > > > > There isnt anything specifically in mock to disallow this. It should > > work, afaict. > > > > Send a pastebin link to the root.log, if possible, or a URL to an SRPM > > with this problem. > > Root log: http://www.city-fan.org/~paul/ntop-3.3-2.fc8.CF-root.log > > SRPM: http://www.city-fan.org/~paul/ntop-3.3-2.fc8.CF.src.rpm Paul, First, you enabled yum debugging. How did you do that, in the yum config file? This may throw off mock because atm mock parses stdout from yum. (this isnt the case here, though, just pointing it out, also want to know how you did it for my own debugging purposes later. Next: $ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h autoconf gdbm-devel No Package Found for 1.2.0 No Package Found for /usr/include/tcpd.h No Package Found for /usr/include/pcap.h I get the exact same error here on my F-8 box that you are getting. Yum problem? Need some input from yum folks. -- Michael From paul at city-fan.org Tue Dec 11 18:24:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Dec 2007 18:24:27 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071211181652.GA7777@humbolt.us.dell.com> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> Message-ID: <475ED5DB.2080904@city-fan.org> Michael E Brown wrote: > Paul, > First, you enabled yum debugging. How did you do that, in the yum > config file? This may throw off mock because atm mock parses stdout > from yum. (this isnt the case here, though, just pointing it out, also > want to know how you did it for my own debugging purposes later. debuglevel=10 in the yum.conf part of the mock config. > Next: > > $ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel > net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel > rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h > autoconf gdbm-devel > No Package Found for 1.2.0 Perhaps this one is a quoting issue; it should be looking for "rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? > No Package Found for /usr/include/tcpd.h > No Package Found for /usr/include/pcap.h These are the ones I've been having trouble with. > I get the exact same error here on my F-8 box that you are getting. Yum > problem? > > Need some input from yum folks. Ah good, it's not just me then. Paul. From skvidal at fedoraproject.org Tue Dec 11 18:31:26 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Dec 2007 13:31:26 -0500 Subject: Pathname-based buildreqs not working? In-Reply-To: <475ED5DB.2080904@city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> <475ED5DB.2080904@city-fan.org> Message-ID: <1197397886.31537.61.camel@cutter> On Tue, 2007-12-11 at 18:24 +0000, Paul Howarth wrote: > Michael E Brown wrote: > > Paul, > > First, you enabled yum debugging. How did you do that, in the yum > > config file? This may throw off mock because atm mock parses stdout > > from yum. (this isnt the case here, though, just pointing it out, also > > want to know how you did it for my own debugging purposes later. > > debuglevel=10 in the yum.conf part of the mock config. > > > Next: > > > > $ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel > > net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel > > rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h > > autoconf gdbm-devel > > No Package Found for 1.2.0 > > Perhaps this one is a quoting issue; it should be looking for > "rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? > > > No Package Found for /usr/include/tcpd.h > > No Package Found for /usr/include/pcap.h > > These are the ones I've been having trouble with. > > > I get the exact same error here on my F-8 box that you are getting. Yum > > problem? > > > > Need some input from yum folks. > > Ah good, it's not just me then. > yum resolvedep /usr/include/tcpd.h works for me on f8 with 3.2.8 and 3.2.7 - confirmed with other folks on irc, too. -sv From paul at city-fan.org Tue Dec 11 18:58:12 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Dec 2007 18:58:12 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <1197397886.31537.61.camel@cutter> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> <475ED5DB.2080904@city-fan.org> <1197397886.31537.61.camel@cutter> Message-ID: <475EDDC4.9080501@city-fan.org> seth vidal wrote: > On Tue, 2007-12-11 at 18:24 +0000, Paul Howarth wrote: >> Michael E Brown wrote: >>> Paul, >>> First, you enabled yum debugging. How did you do that, in the yum >>> config file? This may throw off mock because atm mock parses stdout >>> from yum. (this isnt the case here, though, just pointing it out, also >>> want to know how you did it for my own debugging purposes later. >> debuglevel=10 in the yum.conf part of the mock config. >> >>> Next: >>> >>> $ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel >>> net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel >>> rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h >>> autoconf gdbm-devel >>> No Package Found for 1.2.0 >> Perhaps this one is a quoting issue; it should be looking for >> "rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? >> >>> No Package Found for /usr/include/tcpd.h >>> No Package Found for /usr/include/pcap.h >> These are the ones I've been having trouble with. >> >>> I get the exact same error here on my F-8 box that you are getting. Yum >>> problem? >>> >>> Need some input from yum folks. >> Ah good, it's not just me then. >> > > yum resolvedep /usr/include/tcpd.h works for me on f8 with 3.2.8 and > 3.2.7 - confirmed with other folks on irc, too. It works for me too from the command line, but not from within mock. Paul. From Michael_E_Brown at dell.com Tue Dec 11 19:05:07 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 13:05:07 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <475EDDC4.9080501@city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> <475ED5DB.2080904@city-fan.org> <1197397886.31537.61.camel@cutter> <475EDDC4.9080501@city-fan.org> Message-ID: <20071211190507.GB7777@humbolt.us.dell.com> On Tue, Dec 11, 2007 at 06:58:12PM +0000, Paul Howarth wrote: > seth vidal wrote: > >On Tue, 2007-12-11 at 18:24 +0000, Paul Howarth wrote: > >>Michael E Brown wrote: > >>>Paul, > >>> First, you enabled yum debugging. How did you do that, in the yum > >>>config file? This may throw off mock because atm mock parses stdout > >>>from yum. (this isnt the case here, though, just pointing it out, also > >>>want to know how you did it for my own debugging purposes later. > >>debuglevel=10 in the yum.conf part of the mock config. > >> > >>> Next: > >>> > >>>$ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel > >>>net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel > >>>rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h > >>>autoconf gdbm-devel > >>>No Package Found for 1.2.0 > >>Perhaps this one is a quoting issue; it should be looking for > >>"rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? > >> > >>>No Package Found for /usr/include/tcpd.h > >>>No Package Found for /usr/include/pcap.h > >>These are the ones I've been having trouble with. > >> > >>>I get the exact same error here on my F-8 box that you are getting. Yum > >>>problem? > >>> > >>>Need some input from yum folks. > >>Ah good, it's not just me then. > >> > > > >yum resolvedep /usr/include/tcpd.h works for me on f8 with 3.2.8 and > >3.2.7 - confirmed with other folks on irc, too. > > It works for me too from the command line, but not from within mock. But for me it was failing from the cmdline... :) It fails for me on F7 and F8, yum 3.2.7 and 3.2.8: $ yum resolvedep /usr/include/tcpd.h Importing additional filelist information No Package Found for /usr/include/tcpd.h [michael_e_brown at localhost mock]$ cat /etc/issue Fedora release 8 (Werewolf) Kernel \r on an \m $ rpm -q yum yum-3.2.8-1.fc8.noarch -- Michael From skvidal at fedoraproject.org Tue Dec 11 19:32:15 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 11 Dec 2007 14:32:15 -0500 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071211190507.GB7777@humbolt.us.dell.com> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> <475ED5DB.2080904@city-fan.org> <1197397886.31537.61.camel@cutter> <475EDDC4.9080501@city-fan.org> <20071211190507.GB7777@humbolt.us.dell.com> Message-ID: <1197401535.31537.75.camel@cutter> On Tue, 2007-12-11 at 13:05 -0600, Michael E Brown wrote: > On Tue, Dec 11, 2007 at 06:58:12PM +0000, Paul Howarth wrote: > > seth vidal wrote: > > >On Tue, 2007-12-11 at 18:24 +0000, Paul Howarth wrote: > > >>Michael E Brown wrote: > > >>>Paul, > > >>> First, you enabled yum debugging. How did you do that, in the yum > > >>>config file? This may throw off mock because atm mock parses stdout > > >>>from yum. (this isnt the case here, though, just pointing it out, also > > >>>want to know how you did it for my own debugging purposes later. > > >>debuglevel=10 in the yum.conf part of the mock config. > > >> > > >>> Next: > > >>> > > >>>$ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel > > >>>net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel > > >>>rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h > > >>>autoconf gdbm-devel > > >>>No Package Found for 1.2.0 > > >>Perhaps this one is a quoting issue; it should be looking for > > >>"rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? > > >> > > >>>No Package Found for /usr/include/tcpd.h > > >>>No Package Found for /usr/include/pcap.h > > >>These are the ones I've been having trouble with. > > >> > > >>>I get the exact same error here on my F-8 box that you are getting. Yum > > >>>problem? > > >>> > > >>>Need some input from yum folks. > > >>Ah good, it's not just me then. > > >> > > > > > >yum resolvedep /usr/include/tcpd.h works for me on f8 with 3.2.8 and > > >3.2.7 - confirmed with other folks on irc, too. > > > > It works for me too from the command line, but not from within mock. > > But for me it was failing from the cmdline... :) > > It fails for me on F7 and F8, yum 3.2.7 and 3.2.8: > > $ yum resolvedep /usr/include/tcpd.h > Importing additional filelist information > No Package Found for /usr/include/tcpd.h > > [michael_e_brown at localhost mock]$ cat /etc/issue > Fedora release 8 (Werewolf) > Kernel \r on an \m > > $ rpm -q yum > yum-3.2.8-1.fc8.noarch > > are you getting funny mirrors or some other weirdness? can you post me a copy of your filelists.sqlite? -sv From Michael_E_Brown at dell.com Tue Dec 11 19:45:31 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 13:45:31 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <1197401535.31537.75.camel@cutter> References: <20071208112907.GB17849@jasmine.xos.nl> <475D2864.7030701@city-fan.org> <20071210231337.GA19686@humbolt.us.dell.com> <20071211003724.5c32762a@metropolis.intra.city-fan.org> <20071211181652.GA7777@humbolt.us.dell.com> <475ED5DB.2080904@city-fan.org> <1197397886.31537.61.camel@cutter> <475EDDC4.9080501@city-fan.org> <20071211190507.GB7777@humbolt.us.dell.com> <1197401535.31537.75.camel@cutter> Message-ID: <20071211194531.GA17326@humbolt.us.dell.com> On Tue, Dec 11, 2007 at 02:32:15PM -0500, seth vidal wrote: > > On Tue, 2007-12-11 at 13:05 -0600, Michael E Brown wrote: > > On Tue, Dec 11, 2007 at 06:58:12PM +0000, Paul Howarth wrote: > > > seth vidal wrote: > > > >On Tue, 2007-12-11 at 18:24 +0000, Paul Howarth wrote: > > > >>Michael E Brown wrote: > > > >>>Paul, > > > >>> First, you enabled yum debugging. How did you do that, in the yum > > > >>>config file? This may throw off mock because atm mock parses stdout > > > >>>from yum. (this isnt the case here, though, just pointing it out, also > > > >>>want to know how you did it for my own debugging purposes later. > > > >>debuglevel=10 in the yum.conf part of the mock config. > > > >> > > > >>> Next: > > > >>> > > > >>>$ yum resolvedep ccache mysql-devel pcre-devel groff gd-devel > > > >>>net-snmp-devel pkgconfig openssl-devel automake lm_sensors-devel > > > >>>rrdtool-devel >= 1.2.0 libtool /usr/include/tcpd.h /usr/include/pcap.h > > > >>>autoconf gdbm-devel > > > >>>No Package Found for 1.2.0 > > > >>Perhaps this one is a quoting issue; it should be looking for > > > >>"rrdtool-devel >= 1.2.0" rather than "rrdtool-devel" ">=" "1.2.0"? > > > >> > > > >>>No Package Found for /usr/include/tcpd.h > > > >>>No Package Found for /usr/include/pcap.h > > > >>These are the ones I've been having trouble with. > > > >> > > > >>>I get the exact same error here on my F-8 box that you are getting. Yum > > > >>>problem? > > > >>> > > > >>>Need some input from yum folks. > > > >>Ah good, it's not just me then. > > > >> > > > > > > > >yum resolvedep /usr/include/tcpd.h works for me on f8 with 3.2.8 and > > > >3.2.7 - confirmed with other folks on irc, too. > > > > > > It works for me too from the command line, but not from within mock. > > > > But for me it was failing from the cmdline... :) > > > > It fails for me on F7 and F8, yum 3.2.7 and 3.2.8: > > > > $ yum resolvedep /usr/include/tcpd.h > > Importing additional filelist information > > No Package Found for /usr/include/tcpd.h > > > > [michael_e_brown at localhost mock]$ cat /etc/issue > > Fedora release 8 (Werewolf) > > Kernel \r on an \m > > > > $ rpm -q yum > > yum-3.2.8-1.fc8.noarch > > > > > > are you getting funny mirrors or some other weirdness? > > can you post me a copy of your filelists.sqlite? I think I have found the root cause of the problem. Mock runs the 'yum resolvedeps' as the calling (unprivileged) user. This means that yum cannot download the filelists.sqlite it needs to resolve the dep. It was part of a general strategy of trying to run everything that had user-input components in an unprivileged env. I can remove the privilege drop around this call and that should fix it. -- Michael From Michael_E_Brown at dell.com Tue Dec 11 20:00:37 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 14:00:37 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071208110802.3c43672a@metropolis.intra.city-fan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> Message-ID: <20071211200036.GB17326@humbolt.us.dell.com> On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > Yesterday I noticed that mock/yum seem to be having trouble finding > pathname-based buildreqs. > > For example, buildreqs of /usr/include/tcpd.h and /usr/include/pcap.h > aren't getting found. I use these to maintain spec compatibility across > various releases, where these files can be found in either tcp_wrappers > or tcp_wrappers-devel, or libpcap or libpcap-devel packages > respectively. > > I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it hasn't > helped. > > Is this intentional behaviour (not getting/reading the filelists > metadata) for speed purposes? Paul, This should be fixed in latest mock git repo. This is an important fix and I'll be releasing it later this week (0.8.17/0.9.1). Thanks for reporting this and for your responsiveness in debugging it. Thanks also to the yum folks who helped debug as well. -- Michael From mail-lists at karan.org Tue Dec 11 22:26:10 2007 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 11 Dec 2007 22:26:10 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071211200036.GB17326@humbolt.us.dell.com> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071211200036.GB17326@humbolt.us.dell.com> Message-ID: <475F0E82.4080300@karan.org> Michael E Brown wrote: > On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: >> Yesterday I noticed that mock/yum seem to be having trouble finding >> pathname-based buildreqs. >> >> For example, buildreqs of /usr/include/tcpd.h and /usr/include/pcap.h >> aren't getting found. I use these to maintain spec compatibility across >> various releases, where these files can be found in either tcp_wrappers >> or tcp_wrappers-devel, or libpcap or libpcap-devel packages >> respectively. >> >> I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it hasn't >> helped. >> >> Is this intentional behaviour (not getting/reading the filelists >> metadata) for speed purposes? > > Paul, > This should be fixed in latest mock git repo. This is an important > fix and I'll be releasing it later this week (0.8.17/0.9.1). Thanks for > reporting this and for your responsiveness in debugging it. Thanks also > to the yum folks who helped debug as well. Just to be complete here, this fix isnt going to fix it on rhel5 / centos5, is it ? -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From Michael_E_Brown at dell.com Tue Dec 11 22:53:01 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 16:53:01 -0600 Subject: Pathname-based buildreqs not working? In-Reply-To: <475F0E82.4080300@karan.org> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071211200036.GB17326@humbolt.us.dell.com> <475F0E82.4080300@karan.org> Message-ID: <20071211225301.GA17148@humbolt.us.dell.com> On Tue, Dec 11, 2007 at 10:26:10PM +0000, Karanbir Singh wrote: > Michael E Brown wrote: > > On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > >> Yesterday I noticed that mock/yum seem to be having trouble finding > >> pathname-based buildreqs. > >> > >> For example, buildreqs of /usr/include/tcpd.h and /usr/include/pcap.h > >> aren't getting found. I use these to maintain spec compatibility across > >> various releases, where these files can be found in either tcp_wrappers > >> or tcp_wrappers-devel, or libpcap or libpcap-devel packages > >> respectively. > >> > >> I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it hasn't > >> helped. > >> > >> Is this intentional behaviour (not getting/reading the filelists > >> metadata) for speed purposes? > > > > Paul, > > This should be fixed in latest mock git repo. This is an important > > fix and I'll be releasing it later this week (0.8.17/0.9.1). Thanks for > > reporting this and for your responsiveness in debugging it. Thanks also > > to the yum folks who helped debug as well. > > Just to be complete here, this fix isnt going to fix it on rhel5 / > centos5, is it ? As of now, I am missing one prerequisite in the EPEL 5 repo: python-ctypes. As soon as that pkg gets added to the EPEL repo, I will be able to release updated mock with this bugfix. I've sent a note to the maintainer, and there are a couple other people looking to get it added as well, so hopefully it will be added soon. If there is a huge demand, I might be able to backport some of the fixes (there are a couple of fixes that are relevant at this point), but RHEL5 is not my primary focus at the moment, so I cant spend too much time backporting. -- Michael From Michael_E_Brown at dell.com Wed Dec 12 04:38:30 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 11 Dec 2007 22:38:30 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071207204043.GC20952@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <47569B22.6060307@city-fan.org> <20071207204043.GC20952@humbolt.us.dell.com> Message-ID: <20071212043830.GC17326@humbolt.us.dell.com> On Fri, Dec 07, 2007 at 02:40:44PM -0600, Michael E Brown wrote: > On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote: > > The way I *think* it used to work was that mock-helper would set the > > LD_PRELOAD and then exec() the required program (rpm, yum, whatever). > > When it came to running yum, it didn't exec() yum directly, it exec()-ed > > mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD > > from the environment (the libselinux-mock already being in place from > > the exec() that called it). The result of this was that child processes > > of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the > > fake libselinux without the LD_PRELOAD being visible. > > > > The more integrated architecture of mock now may make this sort of hack > > quite difficult to implement. > > s/difficult/easy/g; > > It should be extremely easy to do this, *if* it is necessary. We just > need to set/unset the variable as necessary around all calls to external > programs. Like this: os.environ['LD_PRELOAD'] = "..."; or > del(os.environ["LD_PRELOAD"]); > > Luckily, we have *one* entry point to call all external programs, atm, > which is mock.util.do(). We just need to decide before each external > call if we need to set the variable or not. > > We also have *one* wrapper for running yum, which then calls down to > mock.util.do(). If necessary, we could easily set/unset this variable in > that call and insulate all other callers from this knowledge. > > All-in-all, if we can come up with a test case for why we would still > need the preload, I could quite easily add this functionality back. So > far, though, I'm not seeing a lot of evidence of what is broken, and I'm > the sort that likes to see the broken pieces before I implement the fix. Paul, I have recreated the git selinux branch at http://linux.dell.com/git/mock.git (if you have previously cloned, please re-clone.) It is based on the current 0.8 codebase. This version passes all unit tests with no messages about missing libraries, and also unsets LD_PRELOAD prior to running mock. Could you please give it a runthrough and see if you notice it doing anything? I get the same (nonfatal) AVC denials that I get without the patch when running in enforcing mode. -- Michael From jwboyer at gmail.com Wed Dec 12 15:40:29 2007 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 12 Dec 2007 09:40:29 -0600 Subject: [PATCH] Allow pungi to gather for arch != host Message-ID: <20071212094029.50b550cb@weaponx> There might be really good reasons not to do this, but it seems the Gather step of pungi could be useful for gathering packages for other architectures. The patch below allows users to set --arch, but only for the gather step. Perhaps eventually some of the other steps could also allow this, like createrepo. IIRC, the buildinstall and iso steps are the only ones that are arch specific. Feel free to flame away. josh diff -r d0417d60748e pungi --- a/pungi Tue Dec 11 10:35:59 2007 -0500 +++ b/pungi Wed Dec 12 09:35:40 2007 -0600 @@ -130,6 +130,9 @@ if __name__ == '__main__': parser.add_option("--name", dest="name", type="string", action="callback", callback=set_config, callback_args=(config, ), help='the name for your distribution (defaults to "Fedora")') + parser.add_option("--arch", dest="arch", type="string", + action="callback", callback=set_config, callback_args=(config, ), + help='the architecture to do gather for') parser.add_option("--ver", dest="version", type="string", action="callback", callback=set_config, callback_args=(config, ), help='the version of your distribution (defaults to datestamp)') @@ -181,6 +184,14 @@ if __name__ == '__main__': print >> sys.stderr, "Flavor must be alphanumeric." sys.exit(1) + if config.get('default', 'arch') != os.uname()[4]: + if not opts.do_gather: + print >> sys.stderr, "Arch must be used with gather." + sys.exit(1) + elif opts.do_all or opts.do_createrepo or opts.do_install or opts.createiso: + print >> sys.stderr, "Arch can only be used with gather." + sys.exit(1) + if opts.do_gather or opts.do_createrepo or opts.do_buildinstall or opts.do_createiso: opts.do_all = False return (opts, args) From jkeating at redhat.com Wed Dec 12 17:17:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 12:17:39 -0500 Subject: [PATCH] Add-update-call-to-update-existing-buildroot Message-ID: <20071212121739.63826795@redhat.com> This is for mock. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-update-call-to-update-existing-buildroot.patch Type: text/x-patch Size: 3222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Wed Dec 12 17:42:47 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 12 Dec 2007 17:42:47 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <20071212043830.GC17326@humbolt.us.dell.com> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <47569B22.6060307@city-fan.org> <20071207204043.GC20952@humbolt.us.dell.com> <20071212043830.GC17326@humbolt.us.dell.com> Message-ID: <47601D97.7070105@city-fan.org> Michael E Brown wrote: > On Fri, Dec 07, 2007 at 02:40:44PM -0600, Michael E Brown wrote: >> On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote: >>> The way I *think* it used to work was that mock-helper would set the >>> LD_PRELOAD and then exec() the required program (rpm, yum, whatever). >>> When it came to running yum, it didn't exec() yum directly, it exec()-ed >>> mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD >>> from the environment (the libselinux-mock already being in place from >>> the exec() that called it). The result of this was that child processes >>> of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the >>> fake libselinux without the LD_PRELOAD being visible. >>> >>> The more integrated architecture of mock now may make this sort of hack >>> quite difficult to implement. >> s/difficult/easy/g; >> >> It should be extremely easy to do this, *if* it is necessary. We just >> need to set/unset the variable as necessary around all calls to external >> programs. Like this: os.environ['LD_PRELOAD'] = "..."; or >> del(os.environ["LD_PRELOAD"]); >> >> Luckily, we have *one* entry point to call all external programs, atm, >> which is mock.util.do(). We just need to decide before each external >> call if we need to set the variable or not. >> >> We also have *one* wrapper for running yum, which then calls down to >> mock.util.do(). If necessary, we could easily set/unset this variable in >> that call and insulate all other callers from this knowledge. >> >> All-in-all, if we can come up with a test case for why we would still >> need the preload, I could quite easily add this functionality back. So >> far, though, I'm not seeing a lot of evidence of what is broken, and I'm >> the sort that likes to see the broken pieces before I implement the fix. > > Paul, > I have recreated the git selinux branch at > http://linux.dell.com/git/mock.git (if you have previously cloned, > please re-clone.) It is based on the current 0.8 codebase. OK, I'll give that a go as soon as I can find a reasonable amount of time. > This version passes all unit tests with no messages about missing > libraries, and also unsets LD_PRELOAD prior to running mock. Great. > Could you please give it a runthrough and see if you notice it doing > anything? I get the same (nonfatal) AVC denials that I get without the > patch when running in enforcing mode. I think that any AVCs, even if they don't cause build failures, are a problem; they add clutter to the audit log, can pop up an setroubleshoot alert on the desktop and may hide other problems unrelated to mock. Could you post some examples of the AVCs youre getting? Could you also test the version with the LD_PRELOAD after removing the target root entirely and also any root cache and see if you still get the denials. If you do get any denials, could you check (ls -lZ) if any of the files installed in the target's /bin, /sbin, /usr/bin, /usr/sbin directories have context types ending in _exec_t? Paul. From Michael_E_Brown at dell.com Wed Dec 12 17:47:44 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 12 Dec 2007 11:47:44 -0600 Subject: [PATCH] Add-update-call-to-update-existing-buildroot In-Reply-To: <20071212121739.63826795@redhat.com> References: <20071212121739.63826795@redhat.com> Message-ID: <20071212174743.GB23520@humbolt.us.dell.com> On Wed, Dec 12, 2007 at 12:17:39PM -0500, Jesse Keating wrote: > This is for mock. Approved, taking into account the IRC discussion about removing the back-compat chunk (second diff chunk). Thanks, Michael From paul at city-fan.org Thu Dec 13 12:01:47 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 13 Dec 2007 12:01:47 +0000 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <47601D97.7070105@city-fan.org> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <47569B22.6060307@city-fan.org> <20071207204043.GC20952@humbolt.us.dell.com> <20071212043830.GC17326@humbolt.us.dell.com> <47601D97.7070105@city-fan.org> Message-ID: <47611F2B.3010300@city-fan.org> Paul Howarth wrote: > Michael E Brown wrote: >> On Fri, Dec 07, 2007 at 02:40:44PM -0600, Michael E Brown wrote: >>> On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote: >>>> The way I *think* it used to work was that mock-helper would set the >>>> LD_PRELOAD and then exec() the required program (rpm, yum, >>>> whatever). When it came to running yum, it didn't exec() yum >>>> directly, it exec()-ed mock-yum instead, which was a simple wrapper >>>> that removed the LD_PRELOAD from the environment (the >>>> libselinux-mock already being in place from the exec() that called >>>> it). The result of this was that child processes of mock-yum (e.g. >>>> rpm, package scriptlets running in the chroot) got the fake >>>> libselinux without the LD_PRELOAD being visible. >>>> >>>> The more integrated architecture of mock now may make this sort of >>>> hack quite difficult to implement. >>> s/difficult/easy/g; >>> >>> It should be extremely easy to do this, *if* it is necessary. We just >>> need to set/unset the variable as necessary around all calls to external >>> programs. Like this: os.environ['LD_PRELOAD'] = "..."; or >>> del(os.environ["LD_PRELOAD"]); >>> >>> Luckily, we have *one* entry point to call all external programs, atm, >>> which is mock.util.do(). We just need to decide before each external >>> call if we need to set the variable or not. >>> >>> We also have *one* wrapper for running yum, which then calls down to >>> mock.util.do(). If necessary, we could easily set/unset this variable in >>> that call and insulate all other callers from this knowledge. >>> >>> All-in-all, if we can come up with a test case for why we would still >>> need the preload, I could quite easily add this functionality back. So >>> far, though, I'm not seeing a lot of evidence of what is broken, and I'm >>> the sort that likes to see the broken pieces before I implement the fix. >> >> Paul, >> I have recreated the git selinux branch at >> http://linux.dell.com/git/mock.git (if you have previously cloned, >> please re-clone.) It is based on the current 0.8 codebase. > > OK, I'll give that a go as soon as I can find a reasonable amount of time. Just tried it, seems to have the same LIBDIR problem as last time: $ mock -r fedora-8-x86_64 rebuild mock-0.8.17-0.se.fc8.src.rpm INFO: mock.py version 0.8.17 starting... State Changed: init plugins State Changed: start ERROR: global name 'LIBDIR' is not defined Traceback (most recent call last): File "/usr/libexec/mock.py", line 529, in main(retParams) File "/usr/libexec/mock.py", line 512, in main do_rebuild(config_opts, chroot, args) File "", line 3, in do_rebuild def do_rebuild(config_opts, chroot, srpms): return __decorated(config_opts, chroot, srpms) File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/libexec/mock.py", line 312, in do_rebuild os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so" NameError: global name 'LIBDIR' is not defined Having fixed that, I found that some packages I tried built OK but there were still lots of messages about the LD_PRELOAD in the root and build logs. The visibility of LD_PRELOAD in the build phase caused builds of proftpd to fail on f8.x86_64 with a linker error (complaint about a relocation). So I added: del(os.environ["LD_PRELOAD"]) between the calls to chroot.init() and chroot.build() in do_rebuild, and that fixed that problem (there are still the messages in the root logs though. The resulting target root directories now contain a mix of var_lib_t and rpm_var_lib_t files, and apparently nothing else. That should fix pretty well all of the selinux denials now. I still need to contrive an example of a package that needs the mock selinux policy module from the wiki page; I'll keep trying. Paul. From williams at redhat.com Thu Dec 13 20:52:07 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 13 Dec 2007 14:52:07 -0600 Subject: [PATCH] add --copyin and --copyout to mock. Message-ID: <47619B77.4090506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is a patch that adds the --copyin and --copyout options to mock. These options allow people to add to a chroot and to pull files out of a chroot, without having to know the path to the chroot. Usage: mock -r --copyin foo bar baz /tmp copies the files foo, bar and baz to the chroot /tmp directory for mock -r --copyout /tmp/result.txt /opt/mydir/something ./results copies the files /tmp/result.txt and /opt/mydir/something into the local dir ./results. In the process of doing this I was bitten by os.path.join()'s "intelligent behavior", in that when using it to do a copyin, it would refuse to join two absolute paths. While coming up with a utility function to do what I wanted, Michael saw that we were manipulating the self.rootdir a bit haphazardly and we arrived at makeChrootPath() as a method in the Root object. I then did a first cut at replacing ad hoc usage of self.rootdir with self.makeChrootPath(). Unless someone objects strenuously, I'll commit this tonight. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYZt3Hyuj/+TTEp0RAq6hAKDkVtmPrWH3NmKGcjEI46HhM6GpCQCfY8oe lJAtUdxKXWDS3ilnYdJR1fY= =SNv7 -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: copy-in-out.patch URL: From jkeating at redhat.com Thu Dec 13 21:03:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Dec 2007 16:03:21 -0500 Subject: [PATCH] add --copyin and --copyout to mock. In-Reply-To: <47619B77.4090506@redhat.com> References: <47619B77.4090506@redhat.com> Message-ID: <20071213160321.64b54e79@redhat.com> On Thu, 13 Dec 2007 14:52:07 -0600 Clark Williams wrote: > Usage: > > mock -r --copyin foo bar baz /tmp > > copies the files foo, bar and baz to the chroot /tmp directory for > > > mock -r > --copyout /tmp/result.txt /opt/mydir/something ./results > > copies the files /tmp/result.txt and > /opt/mydir/something into the local dir ./results. Ooh, this is pretty cool. It can make some things easier. What if you pass it a directory instead of a file? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Thu Dec 13 22:09:39 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 13 Dec 2007 16:09:39 -0600 Subject: [PATCH] add --copyin and --copyout to mock. In-Reply-To: <20071213160321.64b54e79@redhat.com> References: <47619B77.4090506@redhat.com> <20071213160321.64b54e79@redhat.com> Message-ID: <4761ADA3.5080404@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Thu, 13 Dec 2007 14:52:07 -0600 > Clark Williams wrote: > >> Usage: >> >> mock -r --copyin foo bar baz /tmp >> >> copies the files foo, bar and baz to the chroot /tmp directory for >> >> >> mock -r >> --copyout /tmp/result.txt /opt/mydir/something ./results >> >> copies the files /tmp/result.txt and >> /opt/mydir/something into the local dir ./results. > > Ooh, this is pretty cool. It can make some things easier. What if you > pass it a directory instead of a file? > Hmmm, I'd have to look at what it would take to do a directory. I suppose I could detect that source is a directory and use shutil.copytree()... Would that make life easier with punji/koji? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYa2jHyuj/+TTEp0RAtSFAKDAFM4sZnrfVT+t39NsbrNobCukkACeIiDe NVg8vr7LWSOfTdS4uC3SEFo= =J37l -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Thu Dec 13 22:10:06 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 13 Dec 2007 16:10:06 -0600 Subject: [PATCH] add --copyin and --copyout to mock. In-Reply-To: <47619B77.4090506@redhat.com> References: <47619B77.4090506@redhat.com> Message-ID: <20071213221006.GA15717@humbolt.us.dell.com> On Thu, Dec 13, 2007 at 02:52:07PM -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Attached is a patch that adds the --copyin and --copyout options to mock. These > options allow people to add to a chroot and to pull files out of a chroot, without > having to know the path to the chroot. > > Usage: > > mock -r --copyin foo bar baz /tmp > > copies the files foo, bar and baz to the chroot /tmp directory for > > mock -r --copyout /tmp/result.txt /opt/mydir/something ./results > > copies the files /tmp/result.txt and /opt/mydir/something into the > local dir ./results. > > In the process of doing this I was bitten by os.path.join()'s "intelligent behavior", > in that when using it to do a copyin, it would refuse to join two absolute paths. > While coming up with a utility function to do what I wanted, Michael saw that we were > manipulating the self.rootdir a bit haphazardly and we arrived at makeChrootPath() as > a method in the Root object. I then did a first cut at replacing ad hoc usage of > self.rootdir with self.makeChrootPath(). > > Unless someone objects strenuously, I'll commit this tonight. > > Clark > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHYZt3Hyuj/+TTEp0RAq6hAKDkVtmPrWH3NmKGcjEI46HhM6GpCQCfY8oe > lJAtUdxKXWDS3ilnYdJR1fY= > =SNv7 > -----END PGP SIGNATURE----- > diff --git a/py/mock.py b/py/mock.py > index 5661dff..8fa0bd9 100755 > --- a/py/mock.py > +++ b/py/mock.py > @@ -65,6 +65,8 @@ import mock.util > def command_parse(config_opts): > """return options and args from parsing the command line""" > parser = OptionParser(usage=__doc__, version=__VERSION__) > + > + # modes (basic commands) nice touch. > parser.add_option("--rebuild", action="store_const", const="rebuild", > dest="mode", default='rebuild', > help="rebuild the specified SRPM(s)") > @@ -526,7 +537,37 @@ def main(ret): > > elif options.mode == 'orphanskill': > mock.util.orphansKill(chroot.rootdir) > - > + elif options.mode == 'copyin': > + chroot.tryLockBuildRoot() It would be a good idea to log these actions to the root log. Until we get a better way to do it, the best way to do that is to call chroot._resetLogging() right here. > + uidManager.dropPrivsForever() > + if len(args) < 2: > + log.critical("Must have source and destinations for copyin") > + sys.exit(50) > + dest = chroot.makeChrootPath(args[-1]) > + if len(args) > 2 and not os.path.isdir(dest): > + log.critical("multiple source files and %s is not a directory!" % dest) > + sys.exit(50) Nice error handling. > + args = args[:-1] > + import shutil > + for f in args: > + print "copying %s to %s" % (f, dest) > + shutil.copy(f, dest) Looking good. One small tweak: use log.info() instead of print. Print doesnt go to the logs properly. You should not see any print statements anywhere in the mock codebase. Additionally, if you are adding a debugging statement, if you use log.debug(), you never need to remove the logging statement as long as it is useful. ( "mock -v -v ..." will show log.debug() statements.) nb. mock.py uses log.XXX(), other places may have their own loggers. > + elif options.mode == 'copyout': > + chroot.tryLockBuildRoot() ditto. > + uidManager.dropPrivsForever() > + if len(args) < 2: > + log.critical("Must have source and destinations for copyout") > + sys.exit(50) > + dest = args[-1] > + if len(args) > 2 and not os.path.isdir(dest): > + log.critical("multiple source files and %s is not a directory!" % dest) > + sys.exit(50) ditto. > + args = args[:-1] > + import shutil > + for f in args: > + src = chroot.makeChrootPath(f) > + print "copying %s to %s" % (src, dest) > + shutil.copy(src, dest) ditto. > > if __name__ == '__main__': > # fix for python 2.4 logging module bug: > diff --git a/py/mock/backend.py b/py/mock/backend.py > index 4593357..ed283c9 100644 > --- a/py/mock/backend.py > +++ b/py/mock/backend.py > @@ -142,6 +142,11 @@ class Root(object): > return 1 > > decorate(traceLog()) > + def makeChrootPath(self, *args): Comment here would be good. "For safety reasons, self.rootdir should not be used directly. Instead use this handy helper function anytime you want to reference a path in relation to the chroot." or something similar > + tmp = self.rootdir + "/" + "/".join(args) > + return tmp.replace("//", "/") > + > + decorate(traceLog()) > def init(self): > self.state("init") > > @@ -188,41 +193,41 @@ class Root(object): > 'proc', > 'sys', > ]: > - mock.util.mkdirIfAbsent(os.path.join(self.rootdir, item)) > + mock.util.mkdirIfAbsent(self.makeChrootPath(item)) > > # touch files > self.root_log.debug('touch required files') > - for item in [os.path.join(self.rootdir, 'etc', 'mtab'), > - os.path.join(self.rootdir, 'etc', 'fstab'), > - os.path.join(self.rootdir, 'var', 'log', 'yum.log')]: > + for item in [self.makeChrootPath('etc', 'mtab'), > + self.makeChrootPath('etc', 'fstab'), > + self.makeChrootPath('var', 'log', 'yum.log')]: > mock.util.touch(item) > > # write in yum.conf into chroot > # always truncate and overwrite (w+) > self.root_log.debug('configure yum') > - yumconf = os.path.join(self.rootdir, 'etc', 'yum', 'yum.conf') > + yumconf = self.makeChrootPath('etc', 'yum', 'yum.conf') > yumconf_fo = open(yumconf, 'w+') > yumconf_fo.write(self.yum_conf_content) > yumconf_fo.close() > > # symlink /etc/yum.conf to /etc/yum/yum.conf (FC6 requires) > try: > - os.unlink(os.path.join(self.rootdir, "etc", "yum.conf")) > + os.unlink(self.makeChrootPath("etc", "yum.conf")) > except OSError: > pass > - os.symlink('yum/yum.conf', os.path.join(self.rootdir, "etc", "yum.conf")) > + os.symlink('yum/yum.conf', self.makeChrootPath("etc", "yum.conf")) > > # set up resolv.conf > if self.use_host_resolv: > - resolvdir = os.path.join(self.rootdir, 'etc') > - resolvpath = os.path.join(self.rootdir, 'etc', 'resolv.conf') > + resolvdir = self.makeChrootPath('etc') > + resolvpath = self.makeChrootPath('etc', 'resolv.conf') > if os.path.exists(resolvpath): > os.remove(resolvpath) > shutil.copy2('/etc/resolv.conf', resolvdir) > > # files in /etc that need doing > for key in self.chroot_file_contents: > - p = os.path.join(self.rootdir, *key.split('/')) > + p = self.makeChrootPath(*key.split('/')) This original *key.split("/") was to work around the os.path.join "intelligence". You could make this easier to read by getting rid of this and just directly using key. > if not os.path.exists(p): > # write file > fo = open(p, 'w+') > @@ -254,8 +259,8 @@ class Root(object): > decorate(traceLog()) > def _setupDev(self): > # files in /dev > - mock.util.rmtree(os.path.join(self.rootdir, "dev")) > - mock.util.mkdirIfAbsent(os.path.join(self.rootdir, "dev", "pts")) > + mock.util.rmtree(self.makeChrootPath("dev")) > + mock.util.mkdirIfAbsent(self.makeChrootPath("dev", "pts")) > prevMask = os.umask(0000) > devFiles = ( > (stat.S_IFCHR | 0666, os.makedev(1, 3), "dev/null"), > @@ -268,23 +273,23 @@ class Root(object): > ) > for i in devFiles: > # create node > - os.mknod( os.path.join(self.rootdir, i[2]), i[0], i[1] ) > + os.mknod( self.makeChrootPath(i[2]), i[0], i[1]) > # set context. (only necessary if host running selinux enabled.) > # fails gracefully if chcon not installed. > mock.util.do("chcon --reference=/%s %s" % > - (i[2], os.path.join(self.rootdir, i[2])), raiseExc=0) > + (i[2], self.makeChrootPath(i[2])), raiseExc=0) > > - os.symlink("/proc/self/fd/0", os.path.join(self.rootdir, "dev/stdin")) > - os.symlink("/proc/self/fd/1", os.path.join(self.rootdir, "dev/stdout")) > - os.symlink("/proc/self/fd/2", os.path.join(self.rootdir, "dev/stderr")) > + os.symlink("/proc/self/fd/0", self.makeChrootPath("dev/stdin")) > + os.symlink("/proc/self/fd/1", self.makeChrootPath("dev/stdout")) > + os.symlink("/proc/self/fd/2", self.makeChrootPath("dev/stderr")) > os.umask(prevMask) > > # mount/umount > - umntCmd = 'umount -n %s/dev/pts' % self.rootdir > + umntCmd = 'umount -n %s' % self.makeChrootPath('/dev/pts') > if umntCmd not in self.umountCmds: > self.umountCmds.append(umntCmd) > > - mntCmd = 'mount -n -t devpts mock_chroot_devpts %s/dev/pts' % self.rootdir > + mntCmd = 'mount -n -t devpts mock_chroot_devpts %s' % self.makeChrootPath('/dev/pts') > if mntCmd not in self.mountCmds: > self.mountCmds.append(mntCmd) > > @@ -405,7 +410,7 @@ class Root(object): > gid=self.chrootgid, > ) > > - bd_out = self.rootdir + self.builddir > + bd_out = self.makeChrootPath(self.builddir) > rpms = glob.glob(bd_out + '/RPMS/*.rpm') > srpms = glob.glob(bd_out + '/SRPMS/*.rpm') > packages = rpms + srpms > @@ -482,11 +487,11 @@ class Root(object): > > decorate(traceLog()) > def _makeBuildUser(self): > - if not os.path.exists(os.path.join(self.rootdir, 'usr/sbin/useradd')): > + if not os.path.exists(self.makeChrootPath('usr/sbin/useradd')): > raise mock.exception.RootError, "Could not find useradd in chroot, maybe the install failed?" > > # safe and easy. blow away existing /builddir and completely re-create. > - mock.util.rmtree(os.path.join(self.rootdir, self.homedir)) > + mock.util.rmtree(self.makeChrootPath(self.homedir)) > dets = { 'uid': self.chrootuid, 'gid': self.chrootgid, 'user': self.chrootuser, 'group': self.chrootgroup, 'home': self.homedir } > > self.doChroot('/usr/sbin/userdel -r %(user)s' % dets, raiseExc=False) > @@ -533,7 +538,7 @@ class Root(object): > self.uidManager.becomeUser(self.chrootuid, self.chrootgid) > try: > # create dir structure > - for subdir in ["%s/%s/%s" % (self.rootdir, self.builddir, s) for s in ('RPMS', 'SRPMS', 'SOURCES', 'SPECS', 'BUILD', 'originals')]: > + for subdir in ["%s" % self.makeChrootPath(self.builddir, s) for s in ('RPMS', 'SRPMS', 'SOURCES', 'SPECS', 'BUILD', 'originals')]: No longer a need for "%s" % ... here. Just get rid of it and directly use self.makeChrootPath(). > mock.util.mkdirIfAbsent(subdir) > > # change ownership so we can write to build home dir > @@ -543,7 +548,7 @@ class Root(object): > os.chmod(os.path.join(dirpath, path), 0755) > > # rpmmacros default > - macrofile_out = '%s%s/.rpmmacros' % (self.rootdir, self.homedir) > + macrofile_out = '%s/.rpmmacros' % self.makeChrootPath(self.homedir) Probably dont need string interpolation here, either. > rpmmacros = open(macrofile_out, 'w+') > for key, value in self.macros.items(): > rpmmacros.write( "%s %s\n" % (key, value) ) > @@ -559,7 +564,7 @@ class Root(object): > decorate(traceLog()) > def _copySrpmIntoChroot(self, srpm): > srpmFilename = os.path.basename(srpm) > - dest = self.rootdir + '/' + self.builddir + '/' + 'originals' > + dest = self.makeChrootPath(self.builddir, 'originals') > shutil.copy2(srpm, dest) > return os.path.join(self.builddir, 'originals', srpmFilename) > > diff --git a/docs/releasetests.sh b/docs/releasetests.sh > index df82523..3043a60 100755 > --- a/docs/releasetests.sh > +++ b/docs/releasetests.sh > @@ -53,6 +53,23 @@ if [ ! -e $CHROOT/usr/include/python* ]; then > exit 1 > fi > > +# test the copyin command > +time $MOCKCMD --copyin docs/release-instructions.txt /tmp > +if [ ! -f $(CHROOT)/tmp/release-instructions.txt ]; then > + echo "copyin test FAILED! could not find /tmp/release-instructions.txt" > + exit 1 > +fi > + > +# test the copyout command > +time $MOCKCMD --copyout /etc/passwd /tmp/my-copyout-passwd > +if [ ! -f /tmp/my-copyout-passwd ]; then > + echo "copyout test FAILED! could not find /tmp/my-copyout-passwd" > +fi > +mkdir /tmp/$uniqueext > +time $MOCKCMD --copyout /etc/passwd /etc/fstab /tmp/$uniqueext > +if [ ! -f /tmp/$uniqueext/passwd -o ! -f /tmp/$uniqueext/fstab ]; then > + echo "multiple copyout failed!" > +fi You could convert the daemontest test to use --copyin and kill two birds with one stone. (change the comment to say that it is testing both.) == shorter unit test runs... Really excellent overall. Thanks. -- Michael From Michael_E_Brown at dell.com Thu Dec 13 22:25:12 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 13 Dec 2007 16:25:12 -0600 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? In-Reply-To: <47611F2B.3010300@city-fan.org> References: <20071031062512.GB2487@humbolt.us.dell.com> <475037B0.8090302@city-fan.org> <20071130193556.GC4039@humbolt.us.dell.com> <475433A5.6050709@city-fan.org> <20071203223925.GC14186@humbolt.us.dell.com> <47569B22.6060307@city-fan.org> <20071207204043.GC20952@humbolt.us.dell.com> <20071212043830.GC17326@humbolt.us.dell.com> <47601D97.7070105@city-fan.org> <47611F2B.3010300@city-fan.org> Message-ID: <20071213222511.GB15717@humbolt.us.dell.com> On Thu, Dec 13, 2007 at 12:01:47PM +0000, Paul Howarth wrote: > Paul Howarth wrote: > > Just tried it, seems to have the same LIBDIR problem as last time: > > $ mock -r fedora-8-x86_64 rebuild mock-0.8.17-0.se.fc8.src.rpm > INFO: mock.py version 0.8.17 starting... > State Changed: init plugins > State Changed: start > ERROR: global name 'LIBDIR' is not defined > Traceback (most recent call last): > File "/usr/libexec/mock.py", line 529, in > main(retParams) > File "/usr/libexec/mock.py", line 512, in main > do_rebuild(config_opts, chroot, args) > File " 0x008BA668>", line 3, in do_rebuild > def do_rebuild(config_opts, chroot, srpms): return > __decorated(config_opts, chroot, srpms) > File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py", line > 70, in trace > result = func(*args, **kw) > File "/usr/libexec/mock.py", line 312, in do_rebuild > os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so" > NameError: global name 'LIBDIR' is not defined This is odd. I ran a full unit test until I didnt see this message at all. Might be having git sync issues with our public mirror, I'll check. -- Michael From jkeating at redhat.com Fri Dec 14 02:41:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Dec 2007 21:41:52 -0500 Subject: [PATCH] add --copyin and --copyout to mock. In-Reply-To: <4761ADA3.5080404@redhat.com> References: <47619B77.4090506@redhat.com> <20071213160321.64b54e79@redhat.com> <4761ADA3.5080404@redhat.com> Message-ID: <20071213214152.655a558b@redhat.com> On Thu, 13 Dec 2007 16:09:39 -0600 Clark Williams wrote: > Would that make life easier with punji/koji? Actually I'm not sure if pungi/koji would make use of it immediately. There are some places in the rawhide compose where we would though. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Fri Dec 14 15:53:51 2007 From: williams at redhat.com (Clark Williams) Date: Fri, 14 Dec 2007 09:53:51 -0600 Subject: [PATCH (v2)] added copyin/copyout options; add makeChrootPath Message-ID: <4762A70F.9090106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is the second version of the patch I posted yesterday. This version takes into account comments offered by the list. Jesse, I added tree copy code, but haven't heavily tested it yet. I will add a release-test option today though. Michael, this patch is essentially a 'git diff -p' of my stuff merged locally into master, but with your changes to releasetests.sh, et al, removed (didn't want to muddy the waters). Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHYqcPHyuj/+TTEp0RAhdXAKDPS58hBlTw2U04gVuxemq7usBjAgCcDpzm nduFWlb3+guUWWIekkcPbEg= =kber -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: copystuff.patch URL: From paul at city-fan.org Fri Dec 14 23:15:50 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Dec 2007 23:15:50 +0000 Subject: Pathname-based buildreqs not working? In-Reply-To: <20071211200036.GB17326@humbolt.us.dell.com> References: <20071208110802.3c43672a@metropolis.intra.city-fan.org> <20071211200036.GB17326@humbolt.us.dell.com> Message-ID: <20071214231550.09a4d229@metropolis.intra.city-fan.org> On Tue, 11 Dec 2007 14:00:37 -0600 Michael E Brown wrote: > On Sat, Dec 08, 2007 at 11:08:02AM +0000, Paul Howarth wrote: > > Yesterday I noticed that mock/yum seem to be having trouble finding > > pathname-based buildreqs. > > > > For example, buildreqs of /usr/include/tcpd.h > > and /usr/include/pcap.h aren't getting found. I use these to > > maintain spec compatibility across various releases, where these > > files can be found in either tcp_wrappers or tcp_wrappers-devel, or > > libpcap or libpcap-devel packages respectively. > > > > I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it > > hasn't helped. > > > > Is this intentional behaviour (not getting/reading the filelists > > metadata) for speed purposes? > > Paul, > This should be fixed in latest mock git repo. This is an important > fix and I'll be releasing it later this week (0.8.17/0.9.1). Thanks > for reporting this and for your responsiveness in debugging it. > Thanks also to the yum folks who helped debug as well. > -- This doesn't seem to be completely fixed yet. I can't put my finger on what makes it work or not but I seem to be able to build OK for Fedora 7/8/rawhide targets and CentOS5, but not older ones. I remade my Fedora Core 6 metadata to create the filelists.sqlite file and then that started working but the same trick doesn't seem to work with really old stuff like RHL9. And I can't get CentOS4 builds going using the metadata on the DVD (x86_64 at least, that's all I've tried). Paul. From opensource at till.name Sat Dec 15 15:07:30 2007 From: opensource at till.name (Till Maas) Date: Sat, 15 Dec 2007 16:07:30 +0100 Subject: mock: enable gpgcheck for f8 config file In-Reply-To: <20071119080158.GD6174@humbolt.us.dell.com> References: <200711182301.40871.opensource@till.name> <20071119080158.GD6174@humbolt.us.dell.com> Message-ID: <200712151607.37427.opensource@till.name> On Monday 19 November 2007 09:01:59 Michael E Brown wrote: > On Sun, Nov 18, 2007 at 11:01:40PM +0100, Till Maas wrote: > > now that the groups repo is not used anymore in mock, imho the gpgcheck > > option can be enabled by default and only be disabled for the local repo. > > It will only need the required gpg-keys be included in the mock rpm and > > some more lines in the config files. I will write a patch for this if you > > will apply it. > > This sounds reasonable. I can queue it up for 0.8.9. As long as the > patch is sane, I dont see why we cant do something like this. One problem here is, that mock should then contain a copy of the Fedora public rpm keys, because otherwise it would not work to build Fedora rpms on a rhel or centos machine. Would it be ok, to include them at these locations? /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-rawhide /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-test Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Sat Dec 15 15:34:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 15 Dec 2007 10:34:44 -0500 Subject: mock: enable gpgcheck for f8 config file In-Reply-To: <200712151607.37427.opensource@till.name> References: <200711182301.40871.opensource@till.name> <20071119080158.GD6174@humbolt.us.dell.com> <200712151607.37427.opensource@till.name> Message-ID: <20071215103444.1ff95eb1@redhat.com> On Sat, 15 Dec 2007 16:07:30 +0100 Till Maas wrote: > One problem here is, that mock should then contain a copy of the > Fedora public rpm keys, because otherwise it would not work to build > Fedora rpms on a rhel or centos machine. Would it be ok, to include > them at these locations? > > /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora > /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-rawhide > /etc/pki/rpm-gpg/RPM-GPG-KEY-mock-fedora-test Couldn't the repo configs just point to the online version of it, and have yum download the key when needed? (or if it's already on the file system use it?) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sat Dec 15 19:40:25 2007 From: opensource at till.name (Till Maas) Date: Sat, 15 Dec 2007 20:40:25 +0100 Subject: mock: enable gpgcheck for f8 config file In-Reply-To: <20071215103444.1ff95eb1@redhat.com> References: <200711182301.40871.opensource@till.name> <200712151607.37427.opensource@till.name> <20071215103444.1ff95eb1@redhat.com> Message-ID: <200712152040.33510.opensource@till.name> On Saturday 15 December 2007 16:34:44 Jesse Keating wrote: > Couldn't the repo configs just point to the online version of it, and > have yum download the key when needed? (or if it's already on the file > system use it?) It is possible afaik, but it is less secure, because yum can not check, whether or not the downloaded key is really the wanted. It would work, if the download url is an https one and there is a good certificate used and yum verifies whether or not the certificate is valid. But imho shipping the gpg keys with mock is less error-prone. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dhubler at gmail.com Mon Dec 17 14:54:23 2007 From: dhubler at gmail.com (Lazyboy) Date: Mon, 17 Dec 2007 14:54:23 +0000 (UTC) Subject: error/patch for pungi - No module named splittree Message-ID: Hello all, I just started using pungi. Given how new the project is, I decided to use the lasted source. I found this minor issue I think would be a blocker for anyone else (unless I did something wrong) so I thought I'd post the issue and fix I came up with. OS: F8 rawhide SRC: pungi "tip", rev 431 Command sudo pungi -c /usr/share/pungi/rawhide-fedora.ks Error: Traceback (most recent call last): File "/usr/bin/pungi", line 18, in import pypungi.pungi File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 20, in import splittree ImportError: No module named splittree Patch: --- a/src/pypungi/pungi.py Fri Dec 14 23:16:10 2007 -0500 +++ b/src/pypungi/pungi.py Mon Dec 17 09:40:02 2007 -0500 @@ -17,7 +17,6 @@ import os import os import sys sys.path.append('/usr/lib/anaconda-runtime') -import splittree import shutil import re import pypungi From jkeating at redhat.com Mon Dec 17 15:08:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Dec 2007 10:08:39 -0500 Subject: error/patch for pungi - No module named splittree In-Reply-To: References: Message-ID: <20071217100839.6a4afa04@redhat.com> On Mon, 17 Dec 2007 14:54:23 +0000 (UTC) Lazyboy wrote: > I just started using pungi. Given how new the project is, I decided > to use the lasted source. I found this minor issue I think would be a > blocker for anyone else (unless I did something wrong) so I thought > I'd post the issue and fix I came up with. That's not a "fix". You have to have anaconda-runtime installed, which provides splittree. If you just don't import splittree, you won't be able to produce split media. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From floydsmith at aol.com Wed Dec 19 00:36:26 2007 From: floydsmith at aol.com (floyd smith) Date: Wed, 19 Dec 2007 00:36:26 +0000 (UTC) Subject: F8 rawhide, error from method.py during kickstart install from cdrom References: <0240FDD68D6C1F4289F73D134A2536A1017AB96A@mail1.bluesocket.com> Message-ID: I get the exact same error with CDROM install using even a much simpler kickstart file with both graphfical and text install. Have you found any solution? Any help will be greatly appreciated. I have even tried the anaconda generated one as well as the a simple one from the kickstart generator tool. Floyd, From kanarip at kanarip.com Wed Dec 19 00:46:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 19 Dec 2007 01:46:17 +0100 Subject: F8 rawhide, error from method.py during kickstart install from cdrom In-Reply-To: References: <0240FDD68D6C1F4289F73D134A2536A1017AB96A@mail1.bluesocket.com> Message-ID: <476869D9.6050805@kanarip.com> floyd smith wrote: > I get the exact same error with CDROM install using even a much simpler > kickstart file with both graphfical and text install. Have you found any > solution? Any help will be greatly appreciated. I have even tried the anaconda > generated one as well as the a simple one from the kickstart generator tool. > The Fedora Unity Re-Spin oughta solve this; it is available for testing only currently, but the more testers check off an item of our testing matrix to ensure there is no regression compared to the original Fedora 8 installation media, the faster all items are checked off and we can release it for real. Check out http://spins.fedoraunity.org/, register and drop a mail on test-team at fedoraunity.org to get the appropriate access. You would download the Re-Spin, continue to do what it is you normally do with it and then give us some feedback as to what are the results. Should be fairly painless ;-) Thank you in advance, Kind regards, Jeroen van Meeuwen -kanarip From doug.chapman at hp.com Wed Dec 19 20:49:47 2007 From: doug.chapman at hp.com (Doug Chapman) Date: Wed, 19 Dec 2007 15:49:47 -0500 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") Message-ID: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> I am in the process of trying to build fedora on ia64. I updated to the latest mock today in order to get the new --copyin functionality which I think will help with a lot of the dependency issues I am having (very cool functionality by the way!). However, I have found that other changes made at some point after mock-0.7.6-1 breaks mock on ia64. The problem is it tries to load the libc.so.6 library. On ia64 this does not exist since it uses libc.so.6.1 (FYI, that is the case both on F8 and on RHEL5 for ia64). This also concerns me since if the version of the library changes mock will cease to work on other platforms as well. This bit of code is in both util.py and uid.py: import ctypes _libc = ctypes.cdll.LoadLibrary("libc.so.6") If I change it to libc.so.6.1 on my ia64 system it works OK. I tried just specifying libc.so but python is very unhappy about that (I tried that on x86_64 also and it is also unhappy with libc.so). Does anybody have ideas on how we can make this more portable? thanks, - Doug From Christian.Iseli at licr.org Thu Dec 20 08:28:32 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 20 Dec 2007 09:28:32 +0100 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> Message-ID: <20071220092832.473a7578@ludwig-alpha.unil.ch> On Wed, 19 Dec 2007 15:49:47 -0500, Doug Chapman wrote: > Does anybody have ideas on how we can make this more portable? The path to libc.so.6* is in libc.so: $ cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-ia64-little) GROUP ( /lib/libc.so.6.1 /usr/lib/libc_nonshared.a ) : cat /usr/lib64/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) ) From roland at redhat.com Thu Dec 20 09:19:13 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 20 Dec 2007 01:19:13 -0800 (PST) Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: Christian Iseli's message of Thursday, 20 December 2007 09:28:32 +0100 <20071220092832.473a7578@ludwig-alpha.unil.ch> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> <20071220092832.473a7578@ludwig-alpha.unil.ch> Message-ID: <20071220091913.B925426F98A@magilla.localdomain> What mock is doing there is a little freaky. Since the functions you want are in libc and you know it's always going to be there, you don't really need to ask for the right libc object by name. You can use dlsym (RTLD_DEFAULT, "function") to look up the functions in the global scope that the python executable uses, which gets to libc. The python code doesn't seem to have a way to use RTLD_DEFAULT. But, when you do: _libc = ctypes.cdll.LoadLibrary(None) That translates to dlopen (NULL, ...), which in fact works the same as dlopen ("", ...), i.e. opens the executable itself (python). Since libc is a dependency of the executable, its symbols are found by dlsym on the handle from dlopen (NULL, ...). In short, to the extent this whole kludge of the python code knowing the ABI details of some libc symbols is sane at all, it's probably fine enough to use "_libc = ctypes.cdll.LoadLibrary(None)" and be "portable". Thanks, Roland From oliver at linux-kernel.at Thu Dec 20 11:19:55 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 20 Dec 2007 12:19:55 +0100 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> Message-ID: <476A4FDB.7060804@linux-kernel.at> On 12/19/2007 09:49 PM, Doug Chapman wrote: > I am in the process of trying to build fedora on ia64. I updated to the > latest mock today in order to get the new --copyin functionality which I > think will help with a lot of the dependency issues I am having (very > cool functionality by the way!). > > However, I have found that other changes made at some point after > mock-0.7.6-1 breaks mock on ia64. > > The problem is it tries to load the libc.so.6 library. On ia64 this > does not exist since it uses libc.so.6.1 (FYI, that is the case both on > F8 and on RHEL5 for ia64). This also concerns me since if the version > of the library changes mock will cease to work on other platforms as > well. > > This bit of code is in both util.py and uid.py: > > import ctypes > _libc = ctypes.cdll.LoadLibrary("libc.so.6") > > > If I change it to libc.so.6.1 on my ia64 system it works OK. I tried > just specifying libc.so but python is very unhappy about that (I tried > that on x86_64 also and it is also unhappy with libc.so). > > Does anybody have ideas on how we can make this more portable? I just want to mention, that the same is true for alpha! -of From doug.chapman at hp.com Thu Dec 20 14:25:50 2007 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 20 Dec 2007 09:25:50 -0500 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: <20071220091913.B925426F98A@magilla.localdomain> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> <20071220092832.473a7578@ludwig-alpha.unil.ch> <20071220091913.B925426F98A@magilla.localdomain> Message-ID: <1198160750.29271.3.camel@athlon> On Thu, 2007-12-20 at 01:19 -0800, Roland McGrath wrote: > What mock is doing there is a little freaky. Since the functions you want > are in libc and you know it's always going to be there, you don't really > need to ask for the right libc object by name. > You can use dlsym (RTLD_DEFAULT, "function") to look up the functions in > the global scope that the python executable uses, which gets to libc. > > The python code doesn't seem to have a way to use RTLD_DEFAULT. > But, when you do: > > _libc = ctypes.cdll.LoadLibrary(None) > > That translates to dlopen (NULL, ...), which in fact works the same as > dlopen ("", ...), i.e. opens the executable itself (python). Since libc is > a dependency of the executable, its symbols are found by dlsym on the > handle from dlopen (NULL, ...). > > In short, to the extent this whole kludge of the python code knowing the > ABI details of some libc symbols is sane at all, it's probably fine enough > to use "_libc = ctypes.cdll.LoadLibrary(None)" and be "portable". > Roland, Thanks for the tip. I have verified this does indeed do the trick. Could one of the mock maintainers make the fix? Patch is below. thanks, - Doug diff -up mock-0.9.3/py/mock/uid.py.broken mock-0.9.3/py/mock/uid.py --- mock-0.9.3/py/mock/uid.py.broken 2007-12-20 09:23:05.000000000 -0500 +++ mock-0.9.3/py/mock/uid.py 2007-12-20 09:23:26.000000000 -0500 @@ -70,7 +70,7 @@ class uidManager(object): # python doesnt have native versions of these. :( import ctypes -_libc = ctypes.cdll.LoadLibrary("libc.so.6") +_libc = ctypes.cdll.LoadLibrary(None) _errno = ctypes.c_int.in_dll(_libc, "errno") def getresuid(): diff -up mock-0.9.3/py/mock/util.py.broken mock-0.9.3/py/mock/util.py --- mock-0.9.3/py/mock/util.py.broken 2007-12-20 09:22:57.000000000 -0500 +++ mock-0.9.3/py/mock/util.py 2007-12-20 09:23:15.000000000 -0500 @@ -193,7 +193,7 @@ personality_defs = { } import ctypes -_libc = ctypes.cdll.LoadLibrary("libc.so.6") +_libc = ctypes.cdll.LoadLibrary(None) _errno = ctypes.c_int.in_dll(_libc, "errno") _libc.personality.argtypes = [ctypes.c_ulong] _libc.personality.restype = ctypes.c_int From doug.chapman at hp.com Thu Dec 20 14:30:54 2007 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 20 Dec 2007 09:30:54 -0500 Subject: [mock patch] add ia64 and alpha to personality_defs Message-ID: <1198161054.29271.8.camel@athlon> Patch to quiet the "Unable to find predefined setarch personality" warnings seen on ia64. I added alpha as well while I was at it. Signed-off-by: Doug Chapman ---- diff -up mock-0.9.3/py/mock/util.py.arches mock-0.9.3/py/mock/util.py --- mock-0.9.3/py/mock/util.py.arches 2007-12-20 09:26:36.000000000 -0500 +++ mock-0.9.3/py/mock/util.py 2007-12-20 09:27:13.000000000 -0500 @@ -190,6 +190,7 @@ personality_defs = { 'x86_64': PER_LINUX, 'ppc64': PER_LINUX, 'sparc64': PER_LINUX, 'i386': PER_LINUX32, 'i586': PER_LINUX32, 'i686': PER_LINUX32, 'ppc': PER_LINUX32, 'sparc': PER_LINUX32, 'sparcv9': PER_LINUX32, + 'ia64' : PER_LINUX, 'alpha' : PER_LINUX, } import ctypes From oliver at linux-kernel.at Thu Dec 20 14:40:35 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 20 Dec 2007 15:40:35 +0100 Subject: [mock patch] add ia64 and alpha to personality_defs In-Reply-To: <1198161054.29271.8.camel@athlon> References: <1198161054.29271.8.camel@athlon> Message-ID: <476A7EE3.2010201@linux-kernel.at> On 12/20/2007 03:30 PM, Doug Chapman wrote: > Patch to quiet the "Unable to find predefined setarch personality" > warnings seen on ia64. I added alpha as well while I was at it. > > > Signed-off-by: Doug Chapman > > ---- > > diff -up mock-0.9.3/py/mock/util.py.arches mock-0.9.3/py/mock/util.py > --- mock-0.9.3/py/mock/util.py.arches 2007-12-20 09:26:36.000000000 -0500 > +++ mock-0.9.3/py/mock/util.py 2007-12-20 09:27:13.000000000 -0500 > @@ -190,6 +190,7 @@ personality_defs = { > 'x86_64': PER_LINUX, 'ppc64': PER_LINUX, 'sparc64': PER_LINUX, > 'i386': PER_LINUX32, 'i586': PER_LINUX32, 'i686': PER_LINUX32, > 'ppc': PER_LINUX32, 'sparc': PER_LINUX32, 'sparcv9': PER_LINUX32, > + 'ia64' : PER_LINUX, 'alpha' : PER_LINUX, > } > > import ctypes Thx a lot! -of From rdieter at math.unl.edu Thu Dec 20 15:56:53 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 20 Dec 2007 09:56:53 -0600 Subject: mock not processing /etc/profile.d/*, not a login shell? References: <20071203175201.4b7ffacc.bugs.michael@gmx.net> <20071203140040.0127e440@redhat.com> <20071204092347.170febf5@redhat.com> <1196795634.23743.2.camel@burren.boston.redhat.com> Message-ID: Rex Dieter wrote: > Mike Bonnet wrote: > >> Why not convert qt to use pkg-config like so many other projects do, >> rather than stuffing build configuration details into my environment, >> where I don't care about them 99% of the time? > > qt itself *does* use pkg-config, many qt-consuming apps don't use > pkg-config (yet). fyi, I submitted a patch to upstream kde so all future kde(3)-based apps can/will detect qt properly (with pkg-config support), without the need of any special/custom environment variables. See: http://bugs.kde.org/136377 -- Rex From williams at redhat.com Sat Dec 22 21:47:10 2007 From: williams at redhat.com (Clark Williams) Date: Sat, 22 Dec 2007 15:47:10 -0600 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: <1198160750.29271.3.camel@athlon> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> <20071220092832.473a7578@ludwig-alpha.unil.ch> <20071220091913.B925426F98A@magilla.localdomain> <1198160750.29271.3.camel@athlon> Message-ID: <476D85DE.90108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Chapman wrote: > On Thu, 2007-12-20 at 01:19 -0800, Roland McGrath wrote: >> What mock is doing there is a little freaky. Since the functions you want >> are in libc and you know it's always going to be there, you don't really >> need to ask for the right libc object by name. >> You can use dlsym (RTLD_DEFAULT, "function") to look up the functions in >> the global scope that the python executable uses, which gets to libc. >> >> The python code doesn't seem to have a way to use RTLD_DEFAULT. >> But, when you do: >> >> _libc = ctypes.cdll.LoadLibrary(None) >> >> That translates to dlopen (NULL, ...), which in fact works the same as >> dlopen ("", ...), i.e. opens the executable itself (python). Since libc is >> a dependency of the executable, its symbols are found by dlsym on the >> handle from dlopen (NULL, ...). >> >> In short, to the extent this whole kludge of the python code knowing the >> ABI details of some libc symbols is sane at all, it's probably fine enough >> to use "_libc = ctypes.cdll.LoadLibrary(None)" and be "portable". >> > > Roland, > > Thanks for the tip. I have verified this does indeed do the trick. > > Could one of the mock maintainers make the fix? Patch is below. > Both Michael and I are in and out due to Christmas holidays, but I'll try and get this (and the other patches) into a build by Monday. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkdthd4ACgkQHyuj/+TTEp3iGQCcD/McnKiPudrb99ZU3rDndWe5 DA4AnjHq66gLMUeMy5c/bhEjcUwL78gv =+Plj -----END PGP SIGNATURE----- From bugs.michael at gmx.net Sun Dec 23 18:39:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Dec 2007 19:39:51 +0100 Subject: Koji logs not found Message-ID: <20071223193951.2bab523d.bugs.michael@gmx.net> Koji sends a build failure notification which refers to non-existant log file locations: Forwarded message: sylpheed-2.4.8-1 (29013) failed on xenbuilder4.fedora.phx.redhat.com (i386), xenbuilder4.fedora.phx.redhat.com (noarch): BuildrootError: error building package (arch i386), mock exited with status 1 SRPMS: sylpheed-2.4.8-1.src.rpm Failed tasks: ------------- Task 308035 on xenbuilder4.fedora.phx.redhat.com Task Type: buildArch (sylpheed-2.4.8-1.src.rpm, i386) logs: http://koji.fedoraproject.org/packages/sylpheed/2.4.8/1/data/logs/i386/build.log http://koji.fedoraproject.org/packages/sylpheed/2.4.8/1/data/logs/i386/root.log http://koji.fedoraproject.org/packages/sylpheed/2.4.8/1/data/logs/i386/state.log Task 308031 on xenbuilder4.fedora.phx.redhat.com Task Type: build (dist-f9, devel:sylpheed-2_4_8-1) -snip- Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=308031 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=29013 From jkeating at redhat.com Sun Dec 23 18:49:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Dec 2007 13:49:45 -0500 Subject: Koji logs not found In-Reply-To: <20071223193951.2bab523d.bugs.michael@gmx.net> References: <20071223193951.2bab523d.bugs.michael@gmx.net> Message-ID: <20071223134945.08f487db@redhat.com> On Sun, 23 Dec 2007 19:39:51 +0100 Michael Schwendt wrote: > Koji sends a build failure notification which refers to non-existant > log file locations: This is known and filed upstream as https://fedorahosted.org/koji/ticket/71 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sun Dec 30 16:54:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 30 Dec 2007 17:54:51 +0100 Subject: plague: Job waited too long for repo to unlock. Killing it... Message-ID: <20071230175451.1ac8dad8.bugs.michael@gmx.net> If in a failed job.log you see the message Job waited too long for repo to unlock. Killing it... please notify me. It's a problem in the plague server code that results in a denial of service for subsequent build jobs. I have a traceback from Dec 28th, but in the context of the source code it doesn't make sense yet (because a few lines earlier the code ensures that the files to be copied exist and are readable). Buildsys runs a slightly modified version that adds a bit more debug output in this area. [...] 37683 (grads/ppc): Build result files - [ 'state.log', 'grads-1.9b4-21.el5.src.rpm', 'grads-debuginfo-1.9b4-21.el5.ppc.rpm', 'grads-1.9b4-21.el5.ppc.rpm', 'root.log', 'build.log', 'job.log' ] 37683 (grads/x86_64): Build result files - [ 'root.log', 'build.log', 'grads-debuginfo-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.src.rpm', 'state.log', 'job.log' ] 37683 (grads/i386): Build result files - [ 'build.log', 'state.log', 'grads-1.9b4-21.el5.i386.rpm', 'job.log', 'root.log', 'grads-debuginfo-1.9b4-21.el5.i386.rpm', 'grads-1.9b4-21.el5.src.rpm' ] Repo 'fedora-5-epel': updating repository metadata... Exception in thread Repo: fedora-5-epel: Traceback (most recent call last): File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/share/plague/server/Repo.py", line 233, in run self._update_repo() File "/usr/share/plague/server/Repo.py", line 137, in _update_repo shutil.copy(src, file_in_dst) File "/usr/lib64/python2.3/shutil.py", line 72, in copy copymode(src, dst) File "/usr/lib64/python2.3/shutil.py", line 49, in copymode st = os.stat(src) OSError: [Errno 2] No such file or directory: '/srv/rpmbuild/server_work/fedora-5-epel/37683-grads-1.9b4-21.el5/x86_64/grads-1.9b4-21.el5.x86_64.rpm' 37683 (grads): Job finished. From jdieter at gmail.com Sun Dec 30 18:14:36 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 30 Dec 2007 20:14:36 +0200 Subject: plague: Job waited too long for repo to unlock. Killing it... In-Reply-To: <20071230175451.1ac8dad8.bugs.michael@gmx.net> References: <20071230175451.1ac8dad8.bugs.michael@gmx.net> Message-ID: <1199038476.4324.30.camel@jndwidescreen.lesbg.loc> On Sun, 2007-12-30 at 17:54 +0100, Michael Schwendt wrote: > If in a failed job.log you see the message > > Job waited too long for repo to unlock. Killing it... > > please notify me. > I ran into this with deltarpm for EL-5, job 37699. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sun Dec 30 19:19:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 30 Dec 2007 20:19:08 +0100 Subject: plague: Job waited too long for repo to unlock. Killing it... In-Reply-To: <1199038476.4324.30.camel@jndwidescreen.lesbg.loc> References: <20071230175451.1ac8dad8.bugs.michael@gmx.net> <1199038476.4324.30.camel@jndwidescreen.lesbg.loc> Message-ID: <20071230201908.d4dc5638.bugs.michael@gmx.net> On Sun, 30 Dec 2007 20:14:36 +0200, Jonathan Dieter wrote: > On Sun, 2007-12-30 at 17:54 +0100, Michael Schwendt wrote: > > If in a failed job.log you see the message > > > > Job waited too long for repo to unlock. Killing it... > > > > please notify me. > > > > I ran into this with deltarpm for EL-5, job 37699. Yes, that's what the DoS symptoms look like: a short job.log and no other results. Every job after 37683 did not even start, waiting forever for a thread lock to be unlocked. From dcbw at redhat.com Mon Dec 31 16:00:12 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 31 Dec 2007 11:00:12 -0500 Subject: plague: Job waited too long for repo to unlock. Killing it... In-Reply-To: <20071230175451.1ac8dad8.bugs.michael@gmx.net> References: <20071230175451.1ac8dad8.bugs.michael@gmx.net> Message-ID: <1199116812.4697.1.camel@localhost.localdomain> On Sun, 2007-12-30 at 17:54 +0100, Michael Schwendt wrote: > If in a failed job.log you see the message > > Job waited too long for repo to unlock. Killing it... > > please notify me. > > It's a problem in the plague server code that results in a denial of > service for subsequent build jobs. I have a traceback from Dec 28th, but > in the context of the source code it doesn't make sense yet (because a few > lines earlier the code ensures that the files to be copied exist and are > readable). Buildsys runs a slightly modified version that adds a bit more > debug output in this area. Maybe just trap the exception, print it out, and continue? That way at least the server doesn't fall over, it just fails to copy one item. It might also help debugging to see if only specific files can't be copied... Dan > [...] > > 37683 (grads/ppc): Build result files - [ 'state.log', 'grads-1.9b4-21.el5.src.rpm', 'grads-debuginfo-1.9b4-21.el5.ppc.rpm', 'grads-1.9b4-21.el5.ppc.rpm', 'root.log', 'build.log', 'job.log' ] > 37683 (grads/x86_64): Build result files - [ 'root.log', 'build.log', 'grads-debuginfo-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.src.rpm', 'state.log', 'job.log' ] > 37683 (grads/i386): Build result files - [ 'build.log', 'state.log', 'grads-1.9b4-21.el5.i386.rpm', 'job.log', 'root.log', 'grads-debuginfo-1.9b4-21.el5.i386.rpm', 'grads-1.9b4-21.el5.src.rpm' ] > Repo 'fedora-5-epel': updating repository metadata... > Exception in thread Repo: fedora-5-epel: > Traceback (most recent call last): > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > self.run() > File "/usr/share/plague/server/Repo.py", line 233, in run > self._update_repo() > File "/usr/share/plague/server/Repo.py", line 137, in _update_repo > shutil.copy(src, file_in_dst) > File "/usr/lib64/python2.3/shutil.py", line 72, in copy > copymode(src, dst) > File "/usr/lib64/python2.3/shutil.py", line 49, in copymode > st = os.stat(src) > OSError: [Errno 2] No such file or directory: '/srv/rpmbuild/server_work/fedora-5-epel/37683-grads-1.9b4-21.el5/x86_64/grads-1.9b4-21.el5.x86_64.rpm' > 37683 (grads): Job finished. > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From bugs.michael at gmx.net Mon Dec 31 17:04:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 31 Dec 2007 18:04:06 +0100 Subject: plague: Job waited too long for repo to unlock. Killing it... In-Reply-To: <1199116812.4697.1.camel@localhost.localdomain> References: <20071230175451.1ac8dad8.bugs.michael@gmx.net> <1199116812.4697.1.camel@localhost.localdomain> Message-ID: <20071231180406.726fb4f0.bugs.michael@gmx.net> On Mon, 31 Dec 2007 11:00:12 -0500, Dan Williams wrote: > On Sun, 2007-12-30 at 17:54 +0100, Michael Schwendt wrote: > > If in a failed job.log you see the message > > > > Job waited too long for repo to unlock. Killing it... > > > > please notify me. > > > > It's a problem in the plague server code that results in a denial of > > service for subsequent build jobs. I have a traceback from Dec 28th, but > > in the context of the source code it doesn't make sense yet (because a few > > lines earlier the code ensures that the files to be copied exist and are > > readable). Buildsys runs a slightly modified version that adds a bit more > > debug output in this area. > > Maybe just trap the exception, print it out, and continue? That way at > least the server doesn't fall over, it just fails to copy one item. The buildsys runs such a patched Repo.py already. It catches OSError, IOError, unlocks the locks and prints/logs the results of the file access check prior to when files are copied. I also added a debug line in the package job code to see when it starts deleting the copied files. Normally it waits until a callback tells it that all files are copied. > It might also help debugging to see if only specific files can't be > copied... The offending file was copied, but shutil.copy() failed in its second part when trying to copy the file mode. It didn't find the source file it had just copied. :-} From Michael_E_Brown at dell.com Mon Dec 31 19:19:50 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 31 Dec 2007 13:19:50 -0600 Subject: mock issues on ia64 with LoadLibrary("libc.so.6") In-Reply-To: <476D85DE.90108@redhat.com> References: <1198097387.13375.27.camel@deimos.americas.hpqcorp.net> <20071220092832.473a7578@ludwig-alpha.unil.ch> <20071220091913.B925426F98A@magilla.localdomain> <1198160750.29271.3.camel@athlon> <476D85DE.90108@redhat.com> Message-ID: <20071231191950.GA14424@humbolt.us.dell.com> On Sat, Dec 22, 2007 at 03:47:10PM -0600, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Doug Chapman wrote: > > On Thu, 2007-12-20 at 01:19 -0800, Roland McGrath wrote: > >> What mock is doing there is a little freaky. Since the functions you want > >> are in libc and you know it's always going to be there, you don't really > >> need to ask for the right libc object by name. > >> You can use dlsym (RTLD_DEFAULT, "function") to look up the functions in > >> the global scope that the python executable uses, which gets to libc. > >> > >> The python code doesn't seem to have a way to use RTLD_DEFAULT. > >> But, when you do: > >> > >> _libc = ctypes.cdll.LoadLibrary(None) > >> > >> That translates to dlopen (NULL, ...), which in fact works the same as > >> dlopen ("", ...), i.e. opens the executable itself (python). Since libc is > >> a dependency of the executable, its symbols are found by dlsym on the > >> handle from dlopen (NULL, ...). > >> > >> In short, to the extent this whole kludge of the python code knowing the > >> ABI details of some libc symbols is sane at all, it's probably fine enough > >> to use "_libc = ctypes.cdll.LoadLibrary(None)" and be "portable". > >> > > > > Roland, > > > > Thanks for the tip. I have verified this does indeed do the trick. > > > > Could one of the mock maintainers make the fix? Patch is below. > > > > Both Michael and I are in and out due to Christmas holidays, but I'll try and get > this (and the other patches) into a build by Monday. I didnt see this pushed to the git repo, so I just pushed it. This is now in upstream git and will make it into the next fedora push. I dont have solid plans for another fedora push yet, unless Clark wants to do one. Thanks for the patch. -- Michael From Michael_E_Brown at dell.com Mon Dec 31 19:22:06 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 31 Dec 2007 13:22:06 -0600 Subject: [mock patch] add ia64 and alpha to personality_defs In-Reply-To: <476A7EE3.2010201@linux-kernel.at> References: <1198161054.29271.8.camel@athlon> <476A7EE3.2010201@linux-kernel.at> Message-ID: <20071231192206.GB14424@humbolt.us.dell.com> On Thu, Dec 20, 2007 at 03:40:35PM +0100, Oliver Falk wrote: > On 12/20/2007 03:30 PM, Doug Chapman wrote: > > Patch to quiet the "Unable to find predefined setarch personality" > > warnings seen on ia64. I added alpha as well while I was at it. > > > > > > Signed-off-by: Doug Chapman > > > > ---- > > > > diff -up mock-0.9.3/py/mock/util.py.arches mock-0.9.3/py/mock/util.py > > --- mock-0.9.3/py/mock/util.py.arches 2007-12-20 09:26:36.000000000 -0500 > > +++ mock-0.9.3/py/mock/util.py 2007-12-20 09:27:13.000000000 -0500 > > @@ -190,6 +190,7 @@ personality_defs = { > > 'x86_64': PER_LINUX, 'ppc64': PER_LINUX, 'sparc64': PER_LINUX, > > 'i386': PER_LINUX32, 'i586': PER_LINUX32, 'i686': PER_LINUX32, > > 'ppc': PER_LINUX32, 'sparc': PER_LINUX32, 'sparcv9': PER_LINUX32, > > + 'ia64' : PER_LINUX, 'alpha' : PER_LINUX, > > } > > > > import ctypes > > Thx a lot! Patch applied and pushed to upstream mock git repository. Thank you. -- Michael