Re: mock-0.9.19 on CentOS5/RHEL5
On Fri, 13 Nov 2009 13:09:14 -0500 Mike McLean wrote: > On 11/12/2009 01:40 AM, Florian La Roche wrote: > > if you want to run the newest version of mock (0.9.19) > > with RHEL5/CentOS5, you can use a backported version from: > > > > http://www.jur-linux.org/rpms/el-updates/5/SRPMS/mock-0.9.19-1.el5.src.rpm > > http://www.jur-linux.org/rpms/el-updates/5/i386/mock-0.9.19-1.el5.noarch.rpm > > So basically just reverting the dbus patch (2046136e)? > > Perhaps since RHEL5 is something of an important platform for mock we > should consider making this codepath conditional, or otherwise fix this > without forking. > I've got a patch in my tree but I'm trying to figure out why my validation tests are failing on epel4. Should ahve a 0.9.20 out early next week though. Clark signature.asc Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bind-mounting files in mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 27 Mar 2009 08:57:17 -0700 Jesse Keating wrote: > On Fri, 2009-03-27 at 10:37 -0500, Clark Williams wrote: > > It's not described in the man page, so I'm a bit leery about depending > > on that behavior. That being said, it's not a normal use-case for mock > > builds, so it'll probably only bite the livecd creation stuff it the > > bind-mount behavior changes. > > > > Ok, I'll pull it in for the next release. > > I need that functionality too when building install images. Rather than > see more and different code paths when chroot generating, I think there > would be some value in using the same code path regardless of how the > chroot is used. I think the bind mounting of dev/ is only there for the > loop entries, I don't know of any other mock consumers that require a > real /dev/ tree. We might consider just always file bind mounting a few > loop entries in and only having one code path. That works for me. I'm currently trying to figure out the regression with 3rd party repos, so if you have the time and can gin up a patch, that'd be great; if not I'll work on it after I figure the BZ out. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknNF3QACgkQHyuj/+TTEp2kZgCfdrRSiGQLWukV3OT03EXFosZv 8VEAoLmdboXfdgVafNi7SYgfz4qnc+KZ =qdbd -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bind-mounting files in mock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wow, that's bizarre (but works). :)
It's not described in the man page, so I'm a bit leery about depending
on that behavior. That being said, it's not a normal use-case for mock
builds, so it'll probably only bite the livecd creation stuff it the
bind-mount behavior changes.
Ok, I'll pull it in for the next release.
Clark
On Fri, 27 Mar 2009 10:39:54 -0400
Jay Greguske wrote:
> Hi Clark,
>
> If you're bind mounting a file, you have to bind it to an existing file,
> not a directory. Try touching /dev/myloop first, and then mounting the
> real loop device to it.
>
> Thanks,
> -jay
>
>
> Clark Williams wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Wed, 18 Mar 2009 14:52:35 -0400
> > Jay Greguske wrote:
> >
> >
> >> Hello,
> >>
> >> While trying to get livecd-creator working in a mock-built chroot, I
> >> discovered that only directories could be bind-mounted using the
> >> bind_mount plugin. I made a few code changes and attached a patch for
> >> your consideration that enables the bind-mounting of files. Like
> >> directories, the bind-mounting of files will require
> >> 'internal_dev_setup' be set to False, otherwise the mount command will
> >> fail.
> >>
> >> In the chroot configuration file the following syntax would be allowed
> >> (which looks just like that which was used for bind-mounting directories):
> >>
> >> config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0',
> >>
> >> '/dev/loop0'))
> >>
> >> Please let me know what you think, and thanks in advance for your time!
> >>
> >> - Jay
> >>
> >
> > Jay,
> >
> > Finally got some time to pull in mock patches and work on bugs. Sorry
> > it's taken this long...
> >
> > I'm not seeing how your stuff would work. A bind-mount only works on
> > directories, not files. If I try to bind-mount /dev/loop0 somewhere by
> > hand I get the following:
> >
> > $ mkdir -p /tmp/foo && cd /tmp/foo
> > $ sudo mount -n --bind /dev/loop0 .
> > mount: Not a directory
> > $ mkdir dev
> > $ sudo mount -n --bind /dev/loop0 dev
> > mount: Not a directory
> >
> > What am I missing here?
> >
> > Clark
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.9 (GNU/Linux)
> >
> > iEYEARECAAYFAknM5GYACgkQHyuj/+TTEp1CWQCgsPClxT4qV2XCQx3oyHihhBlE
> > t9UAoIekmO6wJCgp9T+OwukEguLJ21Qz
> > =63u9
> > -END PGP SIGNATURE-
> >
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknM8swACgkQHyuj/+TTEp2i/QCfZa1y4KBC2z4A3ZP9+rO8muZF
Q3gAoItg2iK5NMf9vnfVLgaT4BSTWhLC
=j3Sw
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bind-mounting files in mock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Mar 2009 14:52:35 -0400
Jay Greguske wrote:
> Hello,
>
> While trying to get livecd-creator working in a mock-built chroot, I
> discovered that only directories could be bind-mounted using the
> bind_mount plugin. I made a few code changes and attached a patch for
> your consideration that enables the bind-mounting of files. Like
> directories, the bind-mounting of files will require
> 'internal_dev_setup' be set to False, otherwise the mount command will fail.
>
> In the chroot configuration file the following syntax would be allowed
> (which looks just like that which was used for bind-mounting directories):
>
> config_opts['plugin_conf']['bind_mount_opts']['files'].append(('/dev/loop0',
> '/dev/loop0'))
>
> Please let me know what you think, and thanks in advance for your time!
>
> - Jay
Jay,
Finally got some time to pull in mock patches and work on bugs. Sorry
it's taken this long...
I'm not seeing how your stuff would work. A bind-mount only works on
directories, not files. If I try to bind-mount /dev/loop0 somewhere by
hand I get the following:
$ mkdir -p /tmp/foo && cd /tmp/foo
$ sudo mount -n --bind /dev/loop0 .
mount: Not a directory
$ mkdir dev
$ sudo mount -n --bind /dev/loop0 dev
mount: Not a directory
What am I missing here?
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknM5GYACgkQHyuj/+TTEp1CWQCgsPClxT4qV2XCQx3oyHihhBlE
t9UAoIekmO6wJCgp9T+OwukEguLJ21Qz
=63u9
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock problems on f10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 15 Feb 2009 22:09:46 +0200 Lucian Langa wrote: > > > How are you running mock? As a user in the mock group? As a user > > that's not in the mock group? As root? Via sudo? > Changing this to an unprivileged user and adding it to mock group works > perfectly. Has anything changed lately ? Not having the unprivileged > user added to mock group, mock will ask for root password but it will > fail to build anything: > > We've been changing it over time (but nothing has happened wrt privileges in the past couple of releases). Essentially we start up privileged and pam authenticates us. We do whatever is needed (e.g. create directories, run rpm) as root, then drop privs for the build process. Obviously we haven't got it quite right for the running-as-root case. I suspect just adding root to the 'mock' group would take care of this problem. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmZfL0ACgkQHyuj/+TTEp293ACgpRE3VXq4revSzRaBqnqLcmHr 40IAn0G19hgdqlOSP/d0oIgynGHBBgGs =pFGt -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock problems on f10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 14 Feb 2009 19:32:38 +0200 Lucian Langa wrote: > Hello, > I'm having trouble building anything with mock > (mock-0.9.13-1.fc10.noarch) for fedora-rawhide-x86_64. > The error I'm getting is: rpmdb: Program version 4.5 doesn't match > environment version 4.7 > This happens even if I do a complete cleanup and reinit. > > wiping __db* from chroot, rebuilddb locally: > > rpmdb --dbpath /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm/ > --rebuilddb > > > seems to work but as soon as trying to rebuild any package won't work: > Sounds like you might have a cached mock root that has an old version of rpm. Try removing /var/lib/mock/cache/fedora-rawhide-x86_64 and see if that fixes it. If not we'll have to dig a little deeper. I'm about to push mock-0.9.14-1 for f10 (it's on rawhide now) and since that moves the cache directory from /var/lib/mock/cache to /var/cache/mock you'll have to rebuild caches again anway. I've been meaning to add that cache clean option. Guess I need to move that up the priority list... Clark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmYMJEACgkQHyuj/+TTEp07DgCgg3tkiQuXEOLCzd7CzeYtY/t4 33wAnjAuHmgcdXUqzHuI7mfWvh0Z3nPI =RnAp -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock 0.9 backport to F7/F8 -- Feb 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Thu, Mar 13, 2008 at 02:24:50PM -0500, Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael E Brown wrote: >>> On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: >>>> On Fri, Jan 4, 2008 at 4:49 PM, <[EMAIL PROTECTED]> wrote: >>>>> All mock users, >>>>> >>>>> The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 >>>>> to current 0.9 on/around Feb 1. >>>>> >>>>> The mock 0.9 branch has brewed in rawhide since early Dec, and so >>>>> far it looks good. The 0.9 branch is now being used on the official build >>>>> systems, so if there were any major problems, we would expect to have hit >>>>> them by now. >>>>> >>>>> The *only* difference between 0.8. and 0.9. at this >>>>> point is that we have dropped the old mock setuid wrapper and now use the >>>>> consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, >>>>> /etc/consolehelper/mock files which configure mock. The default config is >>>>> set up to operate exactly the same as the old 0.8 branch: ie. you must be >>>>> a member of the 'mock' group to run mock. Additionally, with >>>>> consolehelper comes one new feature: if you are not in the 'mock' group, >>>>> you will be prompted to enter the root password and it will run. This >>>>> means you can run mock without worrying about any pre-setup. >>>>> >>>> Do any changes, fixes, etc need to be done for EPEL since they are >>>> basically F-3/F-6? >>> We need to pull mock from EPEL 4, I havent put in the request for that >>> yet. >>> >>> I am pretty sure that clark put in the update for epel5 to migrate it to >>> the latest as well (since that is what is being used on the fedora build >>> systems.) Clark? >>> -- >>> Michael >>> >> The only requests I see in bodhi are the f7/f8 ones; same in koji. I did not >> build or >> push E-4 or E-5. >> >> Sounds like we (we == I) need to do so? > > EPEL 5 doesnt use bhodi/koji, it uses plague. If you can push it, that > would be great. If not, I still have the required client stuff installed > to do an EPEL 5 push. > -- > Michael > Ugh, when we went to koji, I dropped that stuff like, well, the plague. If you still have it, please do a EPEL 5 push. I'll see about getting plague-client and whatever it needs back on my box so I can do them too. Sorry I dropped the ball on EPEL. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfZn/IACgkQHyuj/+TTEp1bAQCffYG2wTtXG7YVN9GAkp5xiWFo jY8AoNnwuRsbrTTJFYsyOr92M9X/J+YB =J+CJ -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock 0.9 backport to F7/F8 -- Feb 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Thu, Mar 13, 2008 at 11:11:33AM -0600, Stephen John Smoogen wrote: >> On Fri, Jan 4, 2008 at 4:49 PM, <[EMAIL PROTECTED]> wrote: >>> All mock users, >>> >>> The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to >>> current 0.9 on/around Feb 1. >>> >>> The mock 0.9 branch has brewed in rawhide since early Dec, and so far >>> it looks good. The 0.9 branch is now being used on the official build >>> systems, so if there were any major problems, we would expect to have hit >>> them by now. >>> >>> The *only* difference between 0.8. and 0.9. at this >>> point is that we have dropped the old mock setuid wrapper and now use the >>> consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, >>> /etc/consolehelper/mock files which configure mock. The default config is >>> set up to operate exactly the same as the old 0.8 branch: ie. you must be a >>> member of the 'mock' group to run mock. Additionally, with consolehelper >>> comes one new feature: if you are not in the 'mock' group, you will be >>> prompted to enter the root password and it will run. This means you can run >>> mock without worrying about any pre-setup. >>> >> Do any changes, fixes, etc need to be done for EPEL since they are >> basically F-3/F-6? > > We need to pull mock from EPEL 4, I havent put in the request for that > yet. > > I am pretty sure that clark put in the update for epel5 to migrate it to > the latest as well (since that is what is being used on the fedora build > systems.) Clark? > -- > Michael > The only requests I see in bodhi are the f7/f8 ones; same in koji. I did not build or push E-4 or E-5. Sounds like we (we == I) need to do so? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfZf4IACgkQHyuj/+TTEp1SCgCg1zOFuCnvp/GABrp3DU8W7nuN FTUAn1ZidwAQMQt8WK1Fc+/9f9jRK4Qa =2Vbl -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: cache plugin behavior?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Clark Williams wrote:
> Michael E Brown wrote:
>> On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Michael,
>>>
>>> I was looking at BZ 233529 on mock and was wondering if the requested
>>> behavior seems
>>> valid (it does to me, just wanted a sanity check).
>>>
>>> As far as I can tell, the only time the root cache is invalidated is when
>>> it ages out
>>> (was looking at the plugin).
>> This is correct.
>
>>> Does it make sense to also invalidate the cache when the
>>> .cfg that defines it has a newer modification time?
>> Makes perfect sense. May be somewhat difficult to implement, I'm not
>> sure we store the config file name anywhere that the plugin can get to
>> it.
>> --
>> Michael
>
> Here's a way to do it.
>
> One thing that wasn't immediately apparent to me, but became clear when I
> started
> installing/debugging was that everytime you install a new mock rpm, the cfg
> file will
> have a timestamp newer than any existing root-cache file, which means with
> this patch
> each root-cache will be rebuilt. This seems like a reasonable thing to do
> (rebuild
> the caches after installing a new mock), but I wonder if it will break
> anything?
>
> Clark
>
Michael,
Following our IRC conversation, where you expressed admiration and unreserved
joy at
the ability to update the cache after an install (maybe I overstate a bit), I
modified the patch to check the timestamp of both the config file and the
site-default.cfg file. I think this does the job in that after an install, the
cache
is rebuilt because of an updated site-defaults.cfg and if you touch the config
file
it's also detected.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfIdWYACgkQHyuj/+TTEp1mFQCg2Ckelz5scAG73j+nSBJxxzS2
2cAAoN60hJOAcBF0x1UlFxWVtQM9M1pt
=Vutc
-END PGP SIGNATURE-
diff --git a/py/mock.py b/py/mock.py
index d5afbbe..a48ffe2 100755
--- a/py/mock.py
+++ b/py/mock.py
@@ -425,9 +425,13 @@ def main(ret):
if options.configdir:
config_path = options.configdir
+# save for use in Root object
+config_opts['config_paths'] = []
+
# Read in the config files: default, and then user specified
for cfg in ( os.path.join(config_path, 'site-defaults.cfg'), '%s/%s.cfg' %
(config_path, options.chroot)):
if os.path.exists(cfg):
+config_opts['config_paths'].append(cfg)
execfile(cfg)
else:
log.error("Could not find required config file: %s" % cfg)
diff --git a/py/mock/backend.py b/py/mock/backend.py
index 7d11532..6726deb 100644
--- a/py/mock/backend.py
+++ b/py/mock/backend.py
@@ -50,6 +50,7 @@ class Root(object):
self._state_log = getLog("mock.Root.state")
# config options
+self.configs = config['config_paths']
self.chrootuid = config['chrootuid']
self.chrootuser = 'mockbuild'
self.chrootgid = config['chrootgid']
diff --git a/py/mock/plugins/root_cache.py b/py/mock/plugins/root_cache.py
index 9cb0a13..5382912 100644
--- a/py/mock/plugins/root_cache.py
+++ b/py/mock/plugins/root_cache.py
@@ -61,12 +61,21 @@ class RootCache(object):
if self.rootCacheLock is None:
self.rootCacheLock = open(os.path.join(self.rootSharedCachePath,
"rootcache.lock"), "a+")
-# check cache age:
+# check cache status
try:
+# see if it aged out
statinfo = os.stat(self.rootCacheFile)
file_age_days = (time.time() - statinfo.st_ctime) / (60 * 60 * 24)
if file_age_days > self.root_cache_opts['max_age_days']:
+getLog().info("root cache aged out! cache will be rebuilt")
os.unlink(self.rootCacheFile)
+else:
+# make sure no config file is newer than the cache file
+for cfg in self.rootObj.configs:
+if os.stat(cfg).st_mtime > statinfo.st_mtime:
+getLog().info("%s newer than root cache; cache will be
rebuilt" % cfg)
+os.unlink(self.rootCacheFile)
+break
except OSError:
pass
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: cache plugin behavior?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael E Brown wrote:
> On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Michael,
>>
>> I was looking at BZ 233529 on mock and was wondering if the requested
>> behavior seems
>> valid (it does to me, just wanted a sanity check).
>>
>> As far as I can tell, the only time the root cache is invalidated is when it
>> ages out
>> (was looking at the plugin).
>
> This is correct.
>
>> Does it make sense to also invalidate the cache when the
>> .cfg that defines it has a newer modification time?
>
> Makes perfect sense. May be somewhat difficult to implement, I'm not
> sure we store the config file name anywhere that the plugin can get to
> it.
> --
> Michael
Here's a way to do it.
One thing that wasn't immediately apparent to me, but became clear when I
started
installing/debugging was that everytime you install a new mock rpm, the cfg
file will
have a timestamp newer than any existing root-cache file, which means with this
patch
each root-cache will be rebuilt. This seems like a reasonable thing to do
(rebuild
the caches after installing a new mock), but I wonder if it will break anything?
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfIY9cACgkQHyuj/+TTEp07nwCeMSIqBL3c8g9BXmr+BisitT2B
g50An2nDwD5xbJ+Nh6Or/ZDDuWwMecxt
=Ht8F
-END PGP SIGNATURE-
diff --git a/py/mock.py b/py/mock.py
index d5afbbe..cbd9ffe 100755
--- a/py/mock.py
+++ b/py/mock.py
@@ -425,6 +425,9 @@ def main(ret):
if options.configdir:
config_path = options.configdir
+# save for use in Root object
+config_opts['config_path'] = config_path
+
# Read in the config files: default, and then user specified
for cfg in ( os.path.join(config_path, 'site-defaults.cfg'), '%s/%s.cfg' %
(config_path, options.chroot)):
if os.path.exists(cfg):
diff --git a/py/mock/backend.py b/py/mock/backend.py
index 7d11532..274ea40 100644
--- a/py/mock/backend.py
+++ b/py/mock/backend.py
@@ -50,6 +50,7 @@ class Root(object):
self._state_log = getLog("mock.Root.state")
# config options
+self.configfile = os.path.join(config['config_path'],
config['chroot_name']) + ".cfg"
self.chrootuid = config['chrootuid']
self.chrootuser = 'mockbuild'
self.chrootgid = config['chrootgid']
diff --git a/py/mock/plugins/root_cache.py b/py/mock/plugins/root_cache.py
index 9cb0a13..d1ed152 100644
--- a/py/mock/plugins/root_cache.py
+++ b/py/mock/plugins/root_cache.py
@@ -66,6 +66,11 @@ class RootCache(object):
statinfo = os.stat(self.rootCacheFile)
file_age_days = (time.time() - statinfo.st_ctime) / (60 * 60 * 24)
if file_age_days > self.root_cache_opts['max_age_days']:
+getLog().info("root cache aged out! cache will be rebuilt")
+os.unlink(self.rootCacheFile)
+
+elif os.stat(self.rootObj.configfile).st_mtime > statinfo.st_mtime:
+getLog().info("root cache older than %s; cache will be
rebuilt" % self.rootObj.configfile)
os.unlink(self.rootCacheFile)
except OSError:
pass
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: cache plugin behavior?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Fri, Feb 29, 2008 at 09:58:35AM -0600, Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael, >> >> I was looking at BZ 233529 on mock and was wondering if the requested >> behavior seems >> valid (it does to me, just wanted a sanity check). >> >> As far as I can tell, the only time the root cache is invalidated is when it >> ages out >> (was looking at the plugin). > > This is correct. > >> Does it make sense to also invalidate the cache when the >> .cfg that defines it has a newer modification time? > > Makes perfect sense. May be somewhat difficult to implement, I'm not > sure we store the config file name anywhere that the plugin can get to > it. Ok, that's what I was trying to get to when I was looking at the plugin. There's probably something we can stash in the root object that the plugin can get to, maybe even the full path of the config file. My thought is that if we can get the config path, it's just stat'ing it and comparing the modification times. I'll poke at it a bit. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfISE0ACgkQHyuj/+TTEp2AFgCfXOB3gAHBokYqSra6byPe7qsz R6sAn1kciphuenG3Cu8lsDAcWsxJbxZV =faMP -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
cache plugin behavior?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, I was looking at BZ 233529 on mock and was wondering if the requested behavior seems valid (it does to me, just wanted a sanity check). As far as I can tell, the only time the root cache is invalidated is when it ages out (was looking at the plugin). Does it make sense to also invalidate the cache when the .cfg that defines it has a newer modification time? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIK6sACgkQHyuj/+TTEp1sxACg4cOB0uX5lsBSwprCenpVIVCS FnMAniBN93OFe9gf6znQreK26yzcB0b9 =Peks -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Oddly hanging mock build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason L Tibbitts III wrote:
> I'm not sure what to make of this so I haven't yet filed a bug. But I
> noticed that one of spot's jobs was taking way longer than it should:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=31678
> and so I grabbed the srpm and tried to build it on my local builder.
> It hung at the same place that spot's job was hung.
>
> Basically mock installs dependencies, then calls rpmbuild and stops:
>
> mock.util: Installed: ccache.x86_64 0:2.4-11.fc8 perl-DBI.x86_64
> 0:1.601-1.fc9 sqlite-devel.x86_64 0:3.5.4-2.fc9
> mock.util: Dependency Installed: perl-ExtUtils-Embed.x86_64 0:1.26-31.fc9
> perl-ExtUtils-MakeMaker.x86_64 0:6.30-31.fc9 perl-Test-Harness.x86_64
> 0:2.56-31.fc9 perl-devel.x86_64 4:5.8.8-31.fc9
> mock.Root.state: State Changed: build
> mock.util: run cmd timeout(0): ccache -M 4G
> mock.util: Ran setarch 'x86_64'
> mock.util: chroot /mock/fedora-development-x86_64/root/
> mock.Root.build: ENTER do("bash -l -c 'rpmbuild -bb --target x86_64 --nodeps
> //builddir/build/SPECS/perl-DBD-SQLite.spec'",
> '/mock/fedora-development-x86_64/root/', 0, True, 0, object at 0x90e210>, 7225, 493, 'x86_64', logger= object at 0x90e990>)
> mock.Root.build: run cmd timeout(0): bash -l -c 'rpmbuild -bb --target x86_64
> --nodeps //builddir/build/SPECS/perl-DBD-SQLite.spec'
> mock.util: Ran setarch 'x86_64'
> mock.util: chroot /mock/fedora-development-x86_64/root/
> mock.util: elevate privs to run chroot
> mock.util: back to other privs
> mock.util: about to drop privs
>
> There's no further output.
>
Jason,
I ran it on my box with the latest rawhide mock like this:
$ mock --verbose -r fedora-devel-x86_64 perl-DBD-SQLite-1.14-3.fc9.src.rpm
and then poked around when it hung. It looks like it's hanging while running
the test
t/06error.t:
use Test;
BEGIN { plan tests => 2 }
use DBI;
unlink('foo');
my $db = DBI->connect('dbi:SQLite:foo', '', '', { RaiseError => 1, PrintError
=> 0 });
eval {
$db->do('ssdfsdf sdf sd sdfsdfdsf sdfsdf');
};
ok($@);
$db->do('create table testerror (a, b)');
$db->do('insert into testerror values (1, 2)');
$db->do('insert into testerror values (3, 4)');
$db->do('create unique index testerror_idx on testerror (a)');
eval {
$db->do('insert into testerror values (1, 5)');
};
ok($@);
I poked around a bit with 'lsof' and it looks like the sqlite shared libraries
are
mapped and there is an open fd to a regular file named 'foo', so I'm guessing
something is going south in one of the db statements.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkeOKDAACgkQHyuj/+TTEp2oEQCg2fEplFccYKSgVurD69OFxN6q
WrIAoOb2AYPRWI40lCJCONxc15GXY0qY
=utah
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bash login shell invocation in mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Howarth wrote: > mock now uses a login shell for the build phase, invoking bash as: > > bash -l -c ... > > It would be nice if this was changed to: > > bash --login -c ... > > (twi lines need changing in backend.py) > > This is because the --login long option pre-dates the -l short option in > bash; the short version isn't understood in some really old > distributions (like RHL7, don't ask!) and its use precludes use of mock > in building packages for those releases. The long version seems to work > everywhere. > > Paul. > > done and pushed to git repo. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd+gKAACgkQHyuj/+TTEp0UnACeIFAi05f8lqmpJ3FKsQ7cTCIF ZfEAoOAjHDRDivrXm5kLUaeDMzzJiDWm =7of5 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock issues on ia64 with LoadLibrary("libc.so.6")
-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-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH (v2)] added copyin/copyout options; add makeChrootPath
-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-
diff --git a/configure.ac b/configure.ac
index 99bca21..91407cd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,7 +9,7 @@ AC_INIT([mock],[0.9.2])
temp_RELEASE_NAME=mock
temp_RELEASE_MAJOR=0
temp_RELEASE_MINOR=9
-temp_RELEASE_SUBLEVEL=2
+temp_RELEASE_SUBLEVEL=3
temp_RELEASE_EXTRALEVEL=
diff --git a/docs/mock.1 b/docs/mock.1
index ac295e6..4afde95 100644
--- a/docs/mock.1
+++ b/docs/mock.1
@@ -17,6 +17,10 @@ mock [options] \fB\-\-install\fR PACKAGE
mock [options] \fB\-\-update\fR
.LP
mock [options] \fB\-\-orphanskill\fR
+.LP
+mock [options] \fB\-\-copyin\fR \fIpath [\fIpath...\fR] \fIdestination\fR
+.LP
+mock [options] \fB\-\-copyout\fR \fIpath [\fIpath...\fR] \fIdestination\fR
.SH "DESCRIPTION"
.LP
@@ -97,24 +101,41 @@ Show version number and exit.
.SH "COMMANDS"
.LP
.TP
-\fB\-\-clean\fR \- purge the chroot tree
+\fB\-\-clean\fP
+Purge the chroot tree
.TP
-\fB\-\-init\fR \- initialize a chroot (clean, install chroot packages, etc.)
+\fB\-\-init\fP
+Initialize a chroot (clean, install chroot packages, etc.)
.TP
-\fB\-\-rebuild\fR \- If no command is specified, rebuild is assumed. Rebuilds
the specified SRPM(s). The buildroot is cleaned first, unless --no-clean is
specified.
+\fB\-\-rebuild\fP
+If no command is specified, rebuild is assumed. Rebuilds the specified
SRPM(s). The buildroot is cleaned first, unless --no-clean is specified.
.TP
-\fB\-\-shell\fR \- run the specified command interactively within the chroot
(which must already be initialized -- no 'clean' is performed). If no command
specified, /bin/sh is run.
+\fB\-\-shell\fP
+Run the specified command interactively within the chroot (which must already
be initialized -- no 'clean' is performed). If no command specified, /bin/sh is
run.
.TP
-\fB\-\-chroot\fR \- run the specified command non-interactively within the
chroot (which must already be initialized -- no 'clean' is performed). Command
output will be sent to the log files.
+\fB\-\-chroot\fP
+Run the specified command non-interactively within the chroot (which must
already be initialized -- no 'clean' is performed). Command output will be sent
to the log files.
.TP
-\fB\-\-installdeps\fR \- find out deps for SRPM or RPM, and do a yum install
to put them in the buildroot. Buildroot must already be initialized -- no
'clean' is performed
+\fB\-\-installdeps\fP
+Find out deps for SRPM or RPM, and do a yum install to put them in the
buildroot. Buildroot must already be initialized -- no 'clean' is performed
.TP
-\fB\-\-install\fR \- Do a yum install PACKAGE inside the buildroot. Buildroot
must already be initialized -- no 'clean' is performed
+\fB\-\-install\fP
+Do a yum install PACKAGE inside the buildroot. Buildroot must already be
initialized -- no 'clean' is performed
.TP
-\fB\-\-update\fR \- Do a yum update inside the buildroot. Buildroot must
already be initialized -- no 'clean' is performed
+\fB\-\-update\fP
+Do a yum update inside the buildroot. Buildroot must already be initialized --
no 'clean' is performed
.TP
\fB\-\-orphanskill\fP
Noop mode that simply checks that no stray processes are running in the
chroot. Kills any processes that it finds using specified root.
+.TP
+\fB\-\-copyin\fP
+Copies the source paths (files or directory trees) into the chroot at
+the specified destination path.
+.TP
+\fB\-\-copyout\fP
+Copies the source paths (files or directory trees) from the chroot to
+the specified destination path.
+
.SH "FILES"
.LP
\fI/etc/mock/\fP \- default configuration directory
diff --git a/py/mock.py b/py/mock.py
index e7790f0..a560c89 100755
--- a/py/mock.py
+++ b/py/mock.py
@@ -25,6 +25,8 @@
mock [options] {--shell|--chroot}
mock [options] --installdeps {SRPM|RPM}
mock [options] --install PACKAGE
+ mock [options] --copyin path [..path] destination
+ mock [options] --copyout path [..path] destination
"""
# library imports
@@ -65,6 +67,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)
parser.add_option("--rebuild", action="store_const", con
Re: [PATCH] add --copyin and --copyout to mock.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Thu, 13 Dec 2007 14:52:07 -0600 > Clark Williams <[EMAIL PROTECTED]> 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- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
[PATCH] add --copyin and --copyout to mock.
-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)
parser.add_option("--rebuild", action="store_const", const="rebuild",
dest="mode", default='rebuild',
help="rebuild the specified SRPM(s)")
@@ -93,6 +95,15 @@ def command_parse(config_opts):
dest="mode",
help="Kill all processes using specified buildroot.")
+parser.add_option("--copyin", action="store_const", const="copyin",
+ dest="mode",
+ help="Copy file(s) into the specified chroot")
+
+parser.add_option("--copyout", action="store_const", const="copyout",
+ dest="mode",
+ help="Copy file(s) from the specified chroot")
+
+# options
parser.add_option("-r", action="store", type="string", dest="chroot",
help="chroot name/config file name default: %default",
default='default')
@@ -526,7 +537,37 @@ def main(ret):
elif options.mode == 'orphanskill':
mock.util.orphansKill(chroot.rootdir)
-
+elif options.mode == 'copyin':
+chroot.tryLockBuildRoot()
+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)
+args = args[:-1]
+import shutil
+for f in args:
+print "copying %s to %s" % (f, dest)
+shutil.copy(f, dest)
+elif options.mode == 'copyout':
+chroot.tryLockBuildRoot()
+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)
+args = args[:-1]
+import shutil
+for f in args:
+src = chroot.makeChrootPath(f)
+print "copying %s to %s" % (src, dest)
+shutil.copy(src, dest)
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):
+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', '
Re: potential patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> Better patch:
>
> @@ -264,7 +264,7 @@ def main(retParams):
> log_cfg = ConfigParser.ConfigParser()
> logging.config.fileConfig(log_ini)
> log_cfg.read(log_ini)
> -except (IOError, OSError), e:
> +except (IOError, OSError, ConfigParser.NoSectionError), e:
> log.error("Could not find required logging config file: %s" %
> log_ini)
> sys.exit(50)
Thanks, I'll drop that in
>
>
> About branching:
> If they ever upgrade fedoraproject.org to a non-ancient version of git,
> that would be fine. With git >= 1.5, you can delete remote branches. With
> older git, there is no way to remove a remote branch.
Yeah, we need to bug Jessie about that.
>
> Are there any other changes you are needing for cross-building?
Don't know yet. I'm running into an SELinux problem where useradd is being
denied for
mockbuild. Haven't really got a clue as to why, other than it's happening in a
chroot.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHPcgMHyuj/+TTEp0RAu2EAJ9ONaama09+8vmVycWtvRAQP9+zpQCg3oEt
ITBY5edMNsCblvZ6jgAx1qA=
=/MQL
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Patch for BZ 303791?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Thu, Oct 04, 2007 at 02:06:12PM -0400, seth vidal wrote: >> On Thu, 2007-10-04 at 13:00 -0500, Clark Williams wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> seth vidal wrote: >>>> On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: >>>>> -BEGIN PGP SIGNED MESSAGE- >>>>> Hash: SHA1 >>>>> >>>> Is it time to start writing simple, custom yum-utils just for mock? So >>>> it can call them as a program but also so mock can more rigidly control >>>> its output? >>>> >>> Maybe >>> >>> Are you talking about stuff that is a part of mock, a part of yum, or a >>> separate >>> package altogether? >> part of mock. > > I agree. More of a long-term thing, though. Here is my list of stuff we > need to work on: > > 1) "inside-out" setuid scheme (part of an overall revamp on how we see > security for mock running. We currently dont have a coherent strategy or > vision). > 2) use yum-utils rather than calling cmdline > 3) better caching (downloaded yum stuff, chroot cache) > 4) more reliable mount/umount > 5) Speedup options: ccache/distcc All good. I agree completely. Now tell me if my short-term fix for $SUBJECT is acceptable :) Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHBS/vHyuj/+TTEp0RAqVWAJ4lK0QwHJ6Dda8VXQJD+q9ITga5hQCgkWP2 OXs1pxSeTnM6lmoEiv3S2Ho= =l1bJ -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Patch for BZ 303791?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
seth vidal wrote:
> On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Below is a patch for the $SUBJECT bz. I originally just changed the case of
>> the
>> search string to match what 'yum resolvedep' was printing, but then I
>> thought about
>> whether folks might not have the changed version of yum...
>>
>> After I took an aspirin to deal with the dependency combinatorial explosion
>> headache,
>> I looked at the code again. I didn't really want to pull in the re package
>> just for
>> this one case, so I resorted to doing a case-insensitive match, which I
>> *hope* will
>> deal with most cases.
>>
>> What do you guys think?
>>
>> Clark
>>
>> diff --git a/mock.py b/mock.py
>> index 54b8f8c..35c3592 100644
>> - --- a/mock.py
>> +++ b/mock.py
>> @@ -355,9 +355,11 @@ class Root:
>> # pass build reqs (as strings) to installer
>> if arg_string != "":
>> (retval, output) = self.yum('resolvedep %s' % arg_string)
>> +searchstr = 'no package found for'
>> for line in output.split('\n'):
>> - -if line.find('No Package found for') != -1:
>> - -errorpkg = line.replace('No Package found for', '')
>> +idx = line.lower().find(searchstr)
>> +if idx != -1:
>> +errorpkg = line[idx+len(searchstr):]
>> error(output)
>> raise BuildError, "Cannot find build req %s. Exiting."
>> % errorpkg
>> # nothing made us exit, so we continue
>
> Is it time to start writing simple, custom yum-utils just for mock? So
> it can call them as a program but also so mock can more rigidly control
> its output?
>
Maybe
Are you talking about stuff that is a part of mock, a part of yum, or a separate
package altogether?
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHBSpJHyuj/+TTEp0RAmAJAKCTOzowhq8DMT71CrfRLON79c35HQCfYD1k
S2qn/04z/xhtqRSgggvMd0o=
=za13
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Patch for BZ 303791?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Below is a patch for the $SUBJECT bz. I originally just changed the case of the
search string to match what 'yum resolvedep' was printing, but then I thought
about
whether folks might not have the changed version of yum...
After I took an aspirin to deal with the dependency combinatorial explosion
headache,
I looked at the code again. I didn't really want to pull in the re package just
for
this one case, so I resorted to doing a case-insensitive match, which I *hope*
will
deal with most cases.
What do you guys think?
Clark
diff --git a/mock.py b/mock.py
index 54b8f8c..35c3592 100644
- --- a/mock.py
+++ b/mock.py
@@ -355,9 +355,11 @@ class Root:
# pass build reqs (as strings) to installer
if arg_string != "":
(retval, output) = self.yum('resolvedep %s' % arg_string)
+searchstr = 'no package found for'
for line in output.split('\n'):
- -if line.find('No Package found for') != -1:
- -errorpkg = line.replace('No Package found for', '')
+idx = line.lower().find(searchstr)
+if idx != -1:
+errorpkg = line[idx+len(searchstr):]
error(output)
raise BuildError, "Cannot find build req %s. Exiting." %
errorpkg
# nothing made us exit, so we continue
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD4DBQFHBSWXHyuj/+TTEp0RAtzCAJYy31hDn5zsGedHFM/LcWnrBbR5AKDnO10u
ou94vu8Kf369iaF/VKiE7w==
=iG5Y
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BJ Dierkes wrote: >> >>> 1) more reliable mount/umount >>> several people have pointed out instances where mock exits leaving >>> mounts behind (specifically /dev), and the next invokation of mock >>> ends up 'rm -rf' the host machine's /dev. Bad >> >> And /dev/pts and /proc. >> > > Yes... this is one should be pushed way up in priority if possible... > building any apps around mock will lead to many a developer wondering > what just happened to their '/dev'... as is the case right now for > me atleast 10 times in the last few hours. > > Thanks. I'm looking at BZ 250985 now. I'd like to add code to do two things: 1. Find where we're exiting without umounting 2. Add some paranoia code in the startup logic to not screw up if #1 fails (like is happening now). To that end, would you run one of your failure cases with mock --debug and send me the output? Thanks, Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHBRApHyuj/+TTEp0RAqW5AJ9M0tEIi7wMRSxMPTOvGvLr4nwr0ACbB3Qm bdfOov8fGh0optB3JdQ3hwA= =FiXR -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: problems with orphanskill feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Do you want to do the patch or me? It will be tomorrow morning before I can get to it. (or very late tonight.) > -- > Michael > > I can do it, although I've somehow managed to hose my git configuration so that I can't seem to push to our fedoraproject repository. I've got a fix for BZ 303791 (just changing the search string for now to match the resolvdep output) and I'd like to get that up before trying the orphanskill fix. Since I never actually got bodhi working last time, I think I should give it another go. I'll make the BZ fix in devel/F-7/FC-6 and when I get that straightened out we can try an orphanskill fix in rawhide. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG/CJwHyuj/+TTEp0RAqinAKDZtJS8k2L7qmiNAQ+Kj6AUjHSqZACgidms ydMyyZlburkHY0KN9xkiUxA= =TvvK -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: problems with orphanskill feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Resent from my Red Hat account so the message isn't subject to moderation... Michael E Brown wrote: > On Thu, Sep 27, 2007 at 01:30:15PM -0500, Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael/Jesse, >> >> We're seeing odd failures with mock and the orphanskill feature. What seems to happen >> is that the '; mock-helper orphanskill ' string is tacked onto a command >> which is passed to do_chroot() and after the main command is run, an attempt is made >> to run mock-helper (which is not installed in the chroot). So people are seeing a >> "File not found" message after a successful command. >> >> Now it looks like to me that part of the reason for an orphanskill was that the do() >> routine might hang until all the child processes are done, so I'm loathe to just run >> the orphanskill after the do_chroot() is finished (I suspect twisty lines of logic, >> all alike). Seems like we can do a couple of things: >> >> 1. Copy mock-helper into each chroot, so it's available for orphanskill >> 2. Back out the orphanskill logic and try again >> >> Option #1 is somewhat easy, if kinda ugly (not sure I like the idea of scattering a >> setuid-root program into all our build roots). Option #2 requires that we look at the >> code in all the do_* and do() routines to make sure that orphanskill runs when we >> need it to. Ideally I'd like to insure that orphanskill runs *outside* the chroot and >> that it's not needed to keep self.do() from hanging. >> >> What you guys think? > > How about we just run two commands in a row? I see the comment but don't > really see why. Line 973, we dont need to run orphanskill if it isnt > chroot. For the my.do_chroot() on line 975, it looks like we could just > do a my.do_chroot() followed by a normal os.system(). That was my first thought, but I was concerned that we might be missing something subtle in the timeout code (hence my email to you :)). If you think we can just run the orphanskill stuff after running the do_chroot() then I say that's the way to go. > > The problem it is trying to fix is if the rpmbuild process spawns child > processes that fork and never exit. I believe this was seen in some code > that was running in the rpmbuild as a unit test? > > We should also be cc-ing fedora-buildsys-list. (done) wups (looks shamefaced) > > I also understand Jesse's sentiment to just back it out. If it is going > to take more than a day or two to fix, we could just back it out. Let's try running it right after the rpmbuild. If that doesn't work right, then we can just comment it out while we take a closer look at it. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG/B2xHyuj/+TTEp0RAp39AKCetOBTdrrXkAia7FETgL6Zy7A/SACfUW6g neURvZbXryWInfBOVe9tY6M= =PGG3 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Bonnet wrote: > On Tue, 2007-09-25 at 14:11 -0500, Michael E Brown wrote: >> So here is the list of things that have been requested lately and I'll >> be working on a few of these over the next few weeks. If anybody has any >> input, I'd take it. As I start on each, I'll most likely email the >> mailing list with the outline of what I'm doing. >> >> If anybody has existing patches for these (against current mock git), >> all the better... :) >> >> 1) more reliable mount/umount >> several people have pointed out instances where mock exits leaving >> mounts behind (specifically /dev), and the next invokation of mock >> ends up 'rm -rf' the host machine's /dev. Bad >> >> 2) caching yum downloads >> several people have commented that the autocache stuff is great for >> speeding up builds, others say that it can sometimes be bad for >> reproducability, and that simply saving the yum cache dir would be >> better. >> >> 3) ccache integration >> This is a new one that I havent seen before, but should significantly >> speed up builds for people who often do >> rebuild-the-entire-distribution-type things. I'm told by some that >> this is bad for reproducability, but good for speeding up builds when >> you are just sanity checking or when that small reproducability hit >> doesnt matter. I've also seen lots of empirical data that ccache >> should not cause any problems. This will be have to be specifically >> enabled through a commandline or config file option, so those who care >> can turn it on/off. >> >> 4) distcc integration >> Pretty much the same case as ccache. Has more things that need thought >> than the ccache case, above, though. > > A method for cleaning up stale/orphaned processes that get created > during a build was proposed a while ago: > > https://bugzilla.redhat.com/show_bug.cgi?id=221351 > > I'll leave it to you as to whether or not this is the correct > implementation, but I certainly think it's a good idea. I see rogue > processes consuming resources on the build machines all the time. The > process-cleanup code should probably be run before mock exits, whether > the build completed successfully or not. > Didn't this go in (orphanskill) in the last round of updates? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG+WsZHyuj/+TTEp0RAk9NAJwOhOmF6xmaIhbPDRVpaBKwHV65nwCgjBOU bjyOf43DXXIHJj/AW+jz2Ms= =cx6b -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: IA64 mock build issues ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prarit Bhargava wrote: > > > Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Prarit Bhargava wrote: >> >>> Jesse Keating wrote: >>> >>>> On Mon, 30 Jul 2007 09:05:10 -0400 >>>> Prarit Bhargava <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> I've never seen this error before, and previous instances of >>>>> Fedora have "just worked" ... anyone have ideas on what I might have >>>>> screwed up? >>>>> >>>> Is selinux tripping you up? Is the mock user (or root) allowed to read >>>> the repodata files? >>>> >>> I feel an selinux rant coming on >>> >>> Thanks Jesse -- that was it. >>> >>> :) >>> >>> >> >> If you are running with SELinux in enforcing mode, you can try: >> >> $ sudo /usr/sbin/setenforce 0 >> >> to turn it off, run your mock instance and then setenforce 1 to turn >> it back on. If >> it works, blame SELinux :). >> >> > > Yeah -- that was what I did when Jesse pointed me at selinux. > > P. I depend on Jesse for all my SELinux rant-needs. Did that fix it? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGrfobHyuj/+TTEp0RAoZPAKDc0TC6X6S6psWe3pAeUDapoPHH0wCfW0qr PmqVkHiMPdahM2M754dlahI= =SThg -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: IA64 mock build issues ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prarit Bhargava wrote: > > > Jesse Keating wrote: >> On Mon, 30 Jul 2007 09:05:10 -0400 >> Prarit Bhargava <[EMAIL PROTECTED]> wrote: >> >> >>> I've never seen this error before, and previous instances of >>> Fedora have "just worked" ... anyone have ideas on what I might have >>> screwed up? >>> >> >> >> Is selinux tripping you up? Is the mock user (or root) allowed to read >> the repodata files? >> > > I feel an selinux rant coming on > > Thanks Jesse -- that was it. > > :) > If you are running with SELinux in enforcing mode, you can try: $ sudo /usr/sbin/setenforce 0 to turn it off, run your mock instance and then setenforce 1 to turn it back on. If it works, blame SELinux :). If it's not SELinux, I'm not sure what it could be. Are the permissions correct on the repo? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGrfZTHyuj/+TTEp0RAq1YAKCaF15GN//6kbGMFzzrQZLJHy/ewQCg2n/G 4LWvRWoi9yDqaP/cOvqNm2s= =Avbx -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Tue, Jul 10, 2007 at 01:13:33PM -0400, Mike Bonnet wrote: >> On Tue, 2007-07-10 at 11:53 -0500, Clark Williams wrote: >>> Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' >>> command to >>> mock-helper (a setuid root program used by mock). The patch traverses the >>> /proc >>> directory, looking for tasks with a "root" link that matches the chroot >>> currently in >>> use, and sends a SIGKILL to each matching task. >>> >>> As far as I can tell this is only useful to the GDB build. The testsuite >>> for GDB >>> seems to have some either abnormal terminations or so other oddity that >>> leaves jobs >>> hanging. I've looked at the C code and it looks well written, without >>> obvious >>> security holes. >>> >>> I've mixed feelings regarding adding the command. Michael and I have been >>> fairly >>> resistant to adding things to mock-helper, on the general principle that >>> adding >>> features to a setuid root program is fraught with peril. I see the utility >>> of the >>> code, but I'm torn as to whether the 'orphanskill' command is sufficiently >>> useful to >>> the general community. >>> >>> So, that's the question. Is 'orphanskill' worth adding to mock? >> GDB is not the only build that leaves orphaned processes lying around. >> I've seen similar behavior when building gcc, glibc, and mysql, to name >> a few. The problems are usually caused by test suites called during the >> build process, and leaving them around after a build has completed (or >> failed) can tie up system resources or in some cases cause subsequent >> builds to fail. >> >> Just as mock cleans up the filesystem after a build, it should probably >> be cleaning up the process list as well. I'd be in favor of adding this >> patch. Koji could certainly make use of it. > > It looks to me that, no matter the design of mock, we need to have this > functionality. > > As long as the patch looks reasonable, we probably need to include it > for now, until we get to the point where we drop the suid binary. > That makes sense. I've got Jan's patch and I'll apply it to the current head (locally) and make sure it still works, then I'll push it to my public tree for you guys to review. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGlAO0Hyuj/+TTEp0RAtpNAKC5K52QYeCDq/2kVFWixd5NPy5McACgvK3h wVcqiMvrKdMjer3yL5RuPmM= =pVg6 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael/Jesse (and the buildsys list), Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' command to mock-helper (a setuid root program used by mock). The patch traverses the /proc directory, looking for tasks with a "root" link that matches the chroot currently in use, and sends a SIGKILL to each matching task. As far as I can tell this is only useful to the GDB build. The testsuite for GDB seems to have some either abnormal terminations or so other oddity that leaves jobs hanging. I've looked at the C code and it looks well written, without obvious security holes. I've mixed feelings regarding adding the command. Michael and I have been fairly resistant to adding things to mock-helper, on the general principle that adding features to a setuid root program is fraught with peril. I see the utility of the code, but I'm torn as to whether the 'orphanskill' command is sufficiently useful to the general community. So, that's the question. Is 'orphanskill' worth adding to mock? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGk7miHyuj/+TTEp0RAlkFAKDgVLDuNdcGpVU3rtnv0gFTDMYPtwCePiKX IbGKSbEeD62CyrwZlZwTqo0= =bkbg -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock rfe - buildgroup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > > My currently posted git repo does exactly this: > > -- adds 'chroot_setup_cmd' to every individual chroot config file > -> install buildsys-build for legacy configs > -> groupinstall buildsys-build for -devel > > -- mock.py remains with default of "install buildsys-build" to give > everybody one release to update their config files. > > -- next release will change mock.py config default. > > This should be forward/backward compatible with everybody's config files > for this release. Everybody is encouraged to update any site-local > config files before the next release. > > I'm just waiting on feedback from Clark. I think this is a good solution. It certainly prevents the weird hiccups when you can't get to the buildsys-build rpm repo... I'm not sure why anyone would experience problems with changing over, but if they do and the outcry is loud enough, we can always delay the default change. +1. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGkoywHyuj/+TTEp0RAkZUAKCHMQoil/2sBu7SSn2amC2wt5Bt3ACfbVx5 NV45CTSYuYtf/3IiGp8dQOw= =69WM -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock rfe - buildgroup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael E Brown wrote: > On Fri, Jul 06, 2007 at 03:32:17PM -0400, Jesse Keating wrote: >> On Friday 06 July 2007 15:26:42 Michael E Brown wrote: >>> Looking through your patch: >>> >>> +++ b/etc/defaults.cfg >>> +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' >>> >>> This could be problematic for F7, F6, EPEL4/5 and others. >>> >>> I see two (three?) ways to handle this: >>> >>> 1) only add this line to -devel. >>> >>> 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 >>> configs. >>> >>> 3) add this line to -devel, and then migrate it to (2) above after a >>> period of time (perhaps when we drop F6?) >> Yeah, I had this fleeting thought when I was doing it, then promptly forgot >> about it. One of those days... >> >> I think 2 is probably safest, if people have locally modified their configs, >> but I was also thinking we'd only make this change in rawhide, so it would >> only be rawhide people who get it, not pushing it out to existing >> Fedora/RHEL >> setups, so 3 is probably fine too. > > I dont like to make changes specific to one distribution as that > requires thought on my part and I am likely to mess it up, or forget > about the distro specifics next update. The only solution in that case > is to branch, which brings its own overhead. > -- > Michael Man, take a few days off and your co-maintainers run amock! :) I'll get caught up this morning and try to look at what you and Jesse have done. I don't really have a strong opinion on how we construct a chroot (buildsys-build rpm or group). So, whatever you and Jesse work out will be ok with me. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGkkE4Hyuj/+TTEp0RAtBgAKDhTLogaDTS+mgk0G0ysca6PQ8d/gCgunT4 1T31h2KPWW/OLFDGge8LhMg= =B1Er -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [RFC] mock release plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Tuesday 12 June 2007 15:35:43 Michael E Brown wrote: >> Proposal #3: mock 0.7 release >> We are overdue for a release. To that end, I will tag the current >> master branch as 0.7 for release. I will push mock 0.7 to rawhide. After >> a period of time in rawhide (one week?), I will create a release for >> Fedora 7 to push into updates-testing/. Announcements will be sent to >> the lists for each of these releases. >> > > I'd rather not wait for a rawhide timeout to get it into updates-testing for > Fedora 7/6. I've done some extensive testing and I'm satisfied with it > myself, but want to get it into updates-testing asap for Fedora 7. Fedora 6 > doesn't have a -testing for Extras packages so that's a bit more risky, I'd > be OK with delaying that one a bit. So instead I'd propose a release to > rawhide and updates-testing ASAP, give it a short time or enough good > feedback before releasing to Extras 6 and stable updates 7. > I agree that we need to get this one to updates-testing as soon as possible (entirely because we've gone too long without pushing bugfixes). I think our normal mode should be to push to rawhide, wait a bit for the screaming to die down (maybe fix a few bugs), then push to updates-testing. Is that the intended flow of events? >> We will implement the above after signoff by Clark Williams and Jesse >> Keating. > > I sign off on the policy, and apologize for the duplicate -jesse branches. > > I sign off as well. Not a problem about the branches; we just realized after talking that we needed a policy on how it should be done and it seemed like we'd be "in a maze of twisty branches, all alike" if we didn't set a policy. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGbv1vHyuj/+TTEp0RAhwKAJ9edgV9tMVsEF/RBiBuV1MUrq71eQCeJAQi tGggP0iEnNAy+ITzXaILQC0= =XyUK -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: feature request: mock --timeout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Domsch wrote: > I'd like to make a feature request for mock: the ability for it to > determine a job has taken too long and kill it. mock --timeout N (with N > in minutes) is the UI I'm picturing. > > > I've been doing these mass rebuilds for a while. Every so often we'll > wind up with a package with the halting problem - it continues to run, > or not, but it doesn't ever finish building either. Ever. Several > days later, it's still going, but not making progress. > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > good number of hours. But even those don't run for days. The latest > culprits was a few perl modules that ran for >2 days with no end in > sight. > File an RFE BZ on it and I'll look at it. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGI7dTHyuj/+TTEp0RAmyTAKC4M3Pl/pFlUHkuCeS8X48Rspt7JACfR+rt fksWcDbzd8jiTfpRY8g3epY= =4xb7 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock can't read /dev/tty for FC5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Number Cruncher wrote: > I've been using mock to compile RPMs for everything from RH7.3 to FC4 > and some SUSE distributions, but can't build for FC5 because my source > RPM requires the input of a licence key and and the mock environment gives: > > cannot open `/dev/tty': No such device or address > > Yet if I run a mock shell, I can easily, e.g. "echo test > /dev/tty" > > Any advice would be great, > Thanks, > Simon > H. What version of mock are you using? The reason I ask is that the stdout/stderr for any command run under most versions of mock is going to be a pipe. I can envision scenarios where stdout/stderr could be a pipe and stdin is a pty, so /dev/tty gets setup, but I have to work hard at imagining it. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF6J48Hyuj/+TTEp0RAmHNAJ9Wlw8fBtZoRqVI8r+awvwSRUx0sgCggwh4 dF/v4o/ehbp+eNbShhKJhH8= =98y9 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: troubleshooting a build failure under mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony Joseph Seward wrote: > On Sat, 2007-02-24 at 00:13 +, Karanbir Singh wrote: >> Anthony Joseph Seward wrote: >>> On Fri, 2007-02-23 at 17:42 -0600, Connie Sieh wrote: On Fri, 23 Feb 2007, Anthony Joseph Seward wrote: > My situation is this: my build system is running Scientific Linux 4.4 > (basically RHEL 4) with mock 0.6.12. It fails to build a particular RPM > when trying to compile a fortran file. The error issued is > >mkscrlib.f:381: internal compiler error: Illegal instruction What rpm are you trying to build? >>> An in-house application for work. >> if you post your .src.rpm online somewhere, someone might be able to >> help debug the issue. >> > > I don't think the .src.rpm is the issue. > > Again, using the same version of mock, the RPM will build when mock is > hosted on an FC 6 system but not when running SL 4.4. > > Tony Hmmm. That sounds like the version of gfortran on SL4.4 has a problem. What's the version of the fortran package (gcc4-gfortran or gcc-gfortran)? Also, if you run the build by hand on SL4.4, do you still get the internal compiler error? If not, then there's something going on in the environment set up by mock. If you do, then you have a toolchain issue with gfortran and will need to take it up with your distro vendor :). Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF4vobHyuj/+TTEp0RAoNKAJ9UTS5Vsw/wuwjADz4Y7mS9KD9QRgCgtNz/ XxEqEA1x9NWD234igALf3Lg= =yMET -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Quick question for mock users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike McLean wrote: > Clark Williams wrote: >> Will adding the error output of a failed command to the stderr stream >> from mock cause problems to programs calling mock? > > I don't believe it will matter to Koji. > Works for me. Next version (0.6.11) will have this in it. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFygIjHyuj/+TTEp0RAlHaAJ4/Js8YPB8AWjIxq0LpSq3KPjujWQCgp1T8 m7myFJu2zXbcBdB6rLlHGko= =o+Me -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Quick question for mock users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While working on a cross compilation project that uses mock to manage a long-term chroot, I got quite annoyed that when mock throws an error due to a failed command, I would have to go dig into the log files to find what went wrong. It occurred to me that since there's error output going out from an exception, there *shouldn't* be a problem with printing the output of the failing command on stderr. So the question to users of mock (especially the plague folks): Will adding the error output of a failed command to the stderr stream from mock cause problems to programs calling mock? Thanks, Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFyO4YHyuj/+TTEp0RAoS/AJ9qCwisXA43dMU4DGGAUdHocnOeKgCfejM4 2bCFKihmCi+LDYj8dmevVWg= =KZw0 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock "Could not find useradd in chroot, maybe the install failed?"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Janssen wrote: > Hi, > > I have been trying to build F7Test1 for a couple of days now, but I > seem to be doing something wrong. Since I'm running a FC6 (latest > updates) system, I need to run pungi within mock in order to generate > the F7Test1 installation media. > > However, I can't seem to get mock to work, so I cannot build the > installation media. > > As a test, I'm running the following: > mock --debug -r fedora-6-i386-core init > > and the latest part of the output is: > > DEBUG: Executing /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-6-i386-core/root update > Could not find useradd in chroot, maybe the install failed? > ending > > I get the same error when trying to setup a mock for fedora-devel. > > This is with mock 0.6.10-1.fc6, with the default mock configfiles. > > Anyone here having the same problem, or is it just me? > > Best regards, > > Jeroen Janssen Well, I was going to say that it might not be in the path, since mock-helper doesn't inherit a path, but /usr/sbin is in that path and that's usually where useradd is found. After a failure, try running : mock -r fedora-6-i386-core --no-clean shell and poke around in the chroot. Is useradd actually there? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFvikhHyuj/+TTEp0RArJ0AJ9VwwFsg2bG8VpPnKvY0AtheJnrKwCffNEO +E8neXWDzYJbxu/JbpCC1pQ= =tPgs -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: RFC: new mock: strategy, selinux, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Axel Thimm wrote: > On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: >> Axel Thimm wrote: >>> In a nutshell: you now carry much more unlimited root power throughout >>> all of mock's invocation cycle in comparison to a confined set of >>> priviledges that the helper was giving. >> Good point. I still think it's easier to audit python code than C code, >> but you're talking 500 lines of C versus 1000 lines of python. So, I may >> just reconsider this change. >> >> One of the reasons I liked moving to a setuid/setgid launcher was that >> we could move the process into the mock group and fix a bunch of chroot >> sharing problems with appropriate group permissions. Oh, and we actually >> kick off the python process in a separate namespace, which means we >> won't dirty up the mount table if for some reason we exit unexpectedly. >> >> If we just made the launcher setgid:mock and kept mock-helper for >> rootiness things, would that still trigger your security alarms? Hmmm, >> now that I think about it, we probably have to be root to create a new >> namespace, so the launcher might have to stay setuid:root and drop >> privileges before exec'ing python. >> >> Thoughts? > > How about a very radical approach: Removing the neccessity to have > root priviledges at the first place anywhere. The benefits are clear > security-wise, and you get the added bonus that you can have people > install mock under their $HOME w/o being root on these system (imagine > students working on campus/lab PCs). One could even create a Fedora > SDK that runs on non-rpm Linux platforms - mock infiltrates everything > ;) > > The question is whether that is technically possible - for what I use > at ATrpms, an ancient bunch of shell scripts being the equivalent of > mock, I use fakechroot/fakeroot to maintain chroots as a simple > user. I think that will work with eliminating the need for the chroot > part in the mock helper as well. If we check the remaining parts in > mock requiring root priviledges (perhaps just for mounting?) perhaps > we can eliminate these, too, and end up with a pure non-root working > mock. > > I submitted fakeroot/fakechroot shortly before 2006 phased out, once > they are through one can start playing with them (I think fakechroot > is there, still waiting for fakeroot+dependency reviews to complete). > > BTW the Debian/Ubuntu build systems make extensive use of > fakeroot/fakechroot for exactly the same scenarios. > I've used fakeroot/fakechroot in the past, but ran into RPM problems (where RPM wanted to take a lock that required root). I'm not positive, but I think that particular RPM problem has been fixed. I'm not adverse to trying it in the long run, but I don't really want to try and put it in for the next release. I want to get three things working for the next release: 1. Simplified uid/gid scheme so that multiple users can work properly 2. Running in our own namespace. 3. Proper SELinux integration What I'd like for #1 is for the process to setgid:mock once the user has been verified. At that point every file created has gid mock and so there shouldn't be any ownership conflicts in chroots. As far as I can tell the only way to setgid group is to run from a setgid program, so that means the launcher. I've seen two ways we can do namespaces. The first is a couple of patches that modify mock-helper. The other is to do it in the launcher. I'd prefer the launcher since it's less code than the patches to mock-helper. If we keep the launcher *and* mock-helper, and have the launcher do a setreuid(getuid(), getuid()) before exec'ing python, I /think/ that means we lose the ability to switch back to root (the euid). I'll need to go dig into my copy of Advanced Programming in the Unix Environment and probably write a test case to be sure. So again I ask: if we modify the launcher to setgid:mock and to drop root privilege after it's created the new namespace and before it exec's python, keeping mock-helper for root access, will that satisfy your security concerns for now? If so, we can get the three above things in, push it to rawhide and then discuss moving to fakeroot/fakechroot. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnqE0Hyuj/+TTEp0RAqBAAKDfFdrUgnm2Bpf0kRQ/xnVZkLnHWwCgwx5w L8JqelaoriBUY+HDS6IusO8= =EOJa -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: RFC: new mock: strategy, selinux, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Axel Thimm wrote: > In a nutshell: you now carry much more unlimited root power throughout > all of mock's invocation cycle in comparison to a confined set of > priviledges that the helper was giving. Good point. I still think it's easier to audit python code than C code, but you're talking 500 lines of C versus 1000 lines of python. So, I may just reconsider this change. One of the reasons I liked moving to a setuid/setgid launcher was that we could move the process into the mock group and fix a bunch of chroot sharing problems with appropriate group permissions. Oh, and we actually kick off the python process in a separate namespace, which means we won't dirty up the mount table if for some reason we exit unexpectedly. If we just made the launcher setgid:mock and kept mock-helper for rootiness things, would that still trigger your security alarms? Hmmm, now that I think about it, we probably have to be root to create a new namespace, so the launcher might have to stay setuid:root and drop privileges before exec'ing python. Thoughts? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnoI0Hyuj/+TTEp0RAgs+AJ4wD3jbqZsb425aUEZ0O91phHWFygCeI+hQ 2V64J/BN6VINwdJSdFFfLDU= =vqnq -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: RFC: new mock: strategy, selinux, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Axel Thimm wrote: > On Thu, Jan 04, 2007 at 01:13:25PM -0600, Clark Williams wrote: >> One of the first thing that the __init__() method for class Root does in >> mock.py is to call self.drop() to lower the privilege level. Thereafter, >> any command that new mock does as root is done via the do_elevated() >> method of the Root class, and any time the actual python code needs root >> access (e.g. the rpm library routines), it's bracketed by elevate() and >> drop() calls. This makes it easy to audit how the commands are used and >> in what context code is executed. > > I understand the mechanism, but what if a security issue elsewhere in > mock allows one to inject code and elevate privildeges? Until now any > rogue mock takeover would only be able to do what the confined C > helper program would allow, now everything is possible. > I'm trying to figure out how someone would inject code into mock and not already be root (which to me means Game Over). To successfully exploit something, an attacker must cause some code to be loaded that either: 1. runs between an elevate and a drop or 2. does it's own os.setreuid(0, ...) To do #2, they would have to gain control of one of the 15 the files in /usr/lib/python2.X/* that we import. I'm not sure how someone would be able to gain control of a running instance of mock and be able to insert code arbitrarily. Please don't misunderstand me, I'm not dismissing your concerns, but I don't really see how this is any less secure than what we had previously. To me it's just a matter of where we focus our efforts in making mock secure. >> The main reason we wanted to get rid of mock-helper is that it was >> non-trivial C code and the thought was to limit the amount of work >> that's done at the C level. Yeah, I realize that it's easy to write bad >> code in Python too, but it's harder to inadvertently set up a buffer >> overflow situation in Python than in C. > > But now you have several times more code that can lead to priviledge > escalations compared to before - in fact it sounds like all of the > python code including all used non-mock python modules could run > setreuid or not? It's the same amount of privilege escalations as before, just under the control of the python code. You might want to take a look at this list thread: http://www.redhat.com/archives/fedora-buildsys-list/2006-June/msg00018.html which is what prompted this change. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnW17Hyuj/+TTEp0RAtY/AJ4zC1IS20iQtOLlkav/DqlQGQg2mgCfQbkF AmfG3awGJcGdXzp1yOZQQEA= =DcHc -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: RFC: new mock: strategy, selinux, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Axel Thimm wrote: > On Thu, Jan 04, 2007 at 10:37:03AM -0600, Clark Williams wrote: >> New mock will no longer use mock-helper. When it needs to do something >> that requires root privileges, it will elevate it's privilege level to >> root (using os.setreuid()), execute the command and then drop privileges >> back to the normal user. > > But isn't this a security regression towards the previous model? > Previously all elevation procedures were confined and well > controlled. > One of the first thing that the __init__() method for class Root does in mock.py is to call self.drop() to lower the privilege level. Thereafter, any command that new mock does as root is done via the do_elevated() method of the Root class, and any time the actual python code needs root access (e.g. the rpm library routines), it's bracketed by elevate() and drop() calls. This makes it easy to audit how the commands are used and in what context code is executed. The main reason we wanted to get rid of mock-helper is that it was non-trivial C code and the thought was to limit the amount of work that's done at the C level. Yeah, I realize that it's easy to write bad code in Python too, but it's harder to inadvertently set up a buffer overflow situation in Python than in C. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnVHVHyuj/+TTEp0RAsYmAKDeX7r3eT8GWxcjLUXR/8ApknA+wQCgpKAF fDvADWjSl24DCt19MPwYwO8= =q/bR -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
RFC: new mock: strategy, selinux, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, It's been some number of months (six+) since we decided to change the way mock works. We (Michael Brown and I, with input from skvidal and others) came up with a change in how mock launches, manages permissions and runs privileged commands. Old mock (mock-0.6 and previous) is a python script that does some sanity checking (insures that the person running mock is not root and is in the mock group) and then processes the input commands. Whenever it needed to do something that required root privileges, old mock ran a setuid root program named mock-helper. Mock-helper is a C program that knows how to do a limited number of things (mount/unmount, run chroot, etc.). The new mock (mock-0.7 and beyond) turns things around a bit. In new mock, the program /usr/bin/mock is a setuid:root, setgid:mock C program that does one thing only: launches the command "python /usr/libexec/mock.py " in it's own kernel namespace. The mock.py logic still sanity checks that the user is in the mock group and drops privileges to the actual uid while keeping the gid of the process the mock group. As long as we're careful to maintain proper group ownership and permissions of created file and directories, this should go a long way toward fixing the issues we're having with multiple users on a single machine. New mock will no longer use mock-helper. When it needs to do something that requires root privileges, it will elevate it's privilege level to root (using os.setreuid()), execute the command and then drop privileges back to the normal user. All of this is working, although it has not been extensively testing (hello rawhide!). I've merged the BZ bugfixes from the mock-0.6 branch of CVS into the head (which is the new mock) and would like to push the new mock out to rawhide for testing. What I'm looking for from the readership of this list is: 1. Review of strategy and code for security issues 2. Help in formulating an SELinux plan/policy for mock We had some discussion on this issue back in June 2006, but I'd like to look at it one more time before inflicting the new mock on the rawhide faithful. With regard to SELinux, I'm not sure where we need to go with mock. I want mock to function properly and securely on a system running SELinux, but I'm just not sure how to go about that. I've looked at the steps mentioned on: http://fedoraproject.org/wiki/Extras/MockTricks But I'm too SELinux ignorant to be able to make an informed judgment on whether that's the right thing to do. Help on this would be greatly appreciated. Thanks, Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFnS0vHyuj/+TTEp0RAtmUAJ0X6axpPl9UNA8JeSYBeiT++OBtQwCg1/Vj 3NGUFzEmfw5b10NJq3LhxT0= =sIYO -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock BZ #215321
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clark Williams wrote: > Seth, > > This bug occurs on systems that don't have a /var/lib/rpm directory. The > failure occurs while installing the chroot. Here's a snippet of a log of > the failure: > I hate replying to my own email, but... David Smith just reminded me that there are some rpm issues where rpm cheerfully ignores any --root argument and attempts to grab a lock on /var/lib/rpm/db*. It's entirely possible that this issue is hitting one of those spots. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFiB2KHyuj/+TTEp0RAo1EAJ9J8nhwRSIF9XrB5Yor/R0h9VPIVgCfbU5Q cXnd/fqj81RxEtF7hnKw57k= =ZwgP -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
mock BZ #215321
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth, This bug occurs on systems that don't have a /var/lib/rpm directory. The failure occurs while installing the chroot. Here's a snippet of a log of the failure: Transaction Summary = Install100 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 103 M warning: mktemp-1.5-23.2.2: Header V3 DSA signature: NOKEY, key ID 897da07a warning: rpmdevtools-5.3-1.fc6: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 error: can't create transaction lock on /var/lib/rpm/__db.000 I'm having trouble seeing where this is a mock versus a yum bug. At the point of the failure, we're running yum and we've passed in - --installroot= on the command line. Not sure what else mock can do. I did try adding an _rpmlock_path to the macros that are setup by mock, but that was really grasping at straws, since I wasn't convinced that the macros are actually used. In any case adding the _rpmlock_macro to the rpmmacros file didn't effect the bug behavior. Is there someplace in yum that you're setting up a transaction and are defaulting the installroot to '/'? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFiBppHyuj/+TTEp0RAnRtAJ9hDO6CH3dPtecV/ZcD5TzIh7tkIACeONDX HzP2dIuYYUeuVLMeCYabrsk= =ZY3s -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock hangs - why?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Al Pacifico wrote: > I have fifteen CPAN packages that I'm packaging as > RPMs for FC5, and one (and only one) of them seems to > hang mock. Is this an appropriate place to ask for > advice? > Thanks. > -al Sure, although you could file a bugzilla on mock as well. Won't hurt my feelings. Which package hangs? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFP8O9Hyuj/+TTEp0RArjgAKCfx9tSuU/1JDvTEsYEqOpkMwEbXQCgyDlS Q5EUyR2iqlvlgKJcOhqWKe8= =hn/Z -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock builds failing under CentOS 4.4 host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Sheltren wrote: > Cool, thanks - it wasn't there when I did a checkout this morning ;) > Well, it *should* have been... /me roots around in his mock HEAD sandbox... GAH! there it sits, not committed. In my defense, it's actually there in the FC6 branch. But I didn't commit it to the HEAD. It's there now. Mea Culpa... Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFGVYnHyuj/+TTEp0RAqXUAKDAJ6mVSlsPRmeDnk/hBK3+/FzlWQCglqWs wG982R2SCC8EEeZf+z2yvAQ= =1l4s -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock builds failing under CentOS 4.4 host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Sheltren wrote: > Thanks, Rex. I'm also happy with it on my mock 0.4 installs, and > haven't seen any ill effects :) > > So, any objections to me committing the attached patch? It is simply > Karanbir's patch adapted for current CVS. > > Thanks, > Jeff > Yeah, that patch (or my version of it) is already in CVS. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFGTV7Hyuj/+TTEp0RAuLUAJ9OIocr9PUCk63VtbkZOA9/KwmbBACcCcdi p3v09u3MX7BK2d35li4rOKE= =Zw8J -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock builds failing under CentOS 4.4 host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Sheltren wrote: > On Sep 8, 2006, at 9:23 PM, Karanbir Singh wrote: > >> Jeff Sheltren wrote: >>> Was this a change to the filesystem or rpm RPM(s) or what? >> >> basically, rpm issue ( feature ? ) lots of info here : >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151255 > > Cool, thanks for the link! So, can somebody verify this bug w/ the > latest version of mock? If so, I think we should apply Karanbir's patch... > This one looks like a no-brainer, but I'm doing a bit of testing just to make sure (I've been bitten by "no-brainers" before :)). Once I verify that I haven't broken anything obvious, I'll push a new tarball up for Jesse to grab and stuff into Extras. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFBaMSHyuj/+TTEp0RAqFVAKCMgU7jrm9Wdbk15RtA/4uGqO4bfACg0cCI wEfguIz/MPW/aFNXwesFYZw= =ZgVf -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Jeremy Katz >> Sent: Sunday, September 03, 2006 5:12 PM >> To: Discussion of Fedora build system >> Subject: Re: Mock going forward >> >> On Sun, 2006-09-03 at 16:32 -0500, Clark Williams wrote: >>> Jeremy Katz wrote: >>>> Kind of an aside... >>>> >>>> On Sat, 2006-09-02 at 13:38 -0500, Clark Williams wrote: >>>>> Well, because in 0.7 and greater, there is no mockhelper. The >>>>> /usr/bin/mock program is a setuid root launcher that >> starts "python >>>>> /usr/bin/mock.py" with whatever arguments were passed in. >>>> It might be worth moving /usr/bin/mock.py to be somewhere >> that's not in >>>> the path... otherwise, this is bound to be somewhat confusing[1] >>>> >>>> Jeremy >>>> >>>> [1] To me, if to no one else :-) >>> Ah, it's all about you, Jeremy :) >> As often as I can arrange :-P >> >>> I had considered it but was more concerned with other things (like >>> trying to clean up the BZ's for 0.6). >>> >>> Where would you suggest? /opt/mock? >> Nah, just that /usr/bin/mock should probably execute >> perhaps /usr/libexec/mock.py -- that way, you don't do >> moc >> and get hits for both mock and mock.py and become confused as to which >> you're actually supposed to use > > /opt/ is reserved for sysadmin installation of add-on packages and iirc > is normally empty on a clean install. /usr/libexec/mock/mock.py sounds > like a good choice. The other option is to do similar to how yum does > it: /usr/share/mock-cli/mock.py. > -- > Michael I think I like /usr/libexec/mock.py. Will that be acceptable to everyone? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE/t2OHyuj/+TTEp0RAgriAKDfgdXIn9uhI0qDStYfaAZ966P9/gCg3X6i SFMrQMQ/iDKdlLFUre+cMQI= =sCBq -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Sat, 2006-09-02 at 13:38 -0500, Clark Williams wrote: >> Well, because in 0.7 and greater, there is no mockhelper. The >> /usr/bin/mock program is a setuid root launcher that starts "python >> /usr/bin/mock.py" with whatever arguments were passed in. > > Ok, I haven't played with the 0.7, but surely you've made some space > available to do commands like this? We depend heavily on being able to > install a package or package list in the buildroot then run some > commands in the buildroot. Its an integral part of our tree composition > tools. > The 'chroot' command for running commands in the build root is still there, so you can run whatever you need in the chroot. What remains is to make it easy to install arbitrary rpms into the chroot. I think the way to do this is to have an 'install' command that accepts binary rpms (i.e. doesn't involve yum repositories) and runs the host rpm to put the contents into the build root. Hmmm. Thinking about this a bit more makes me wonder if we need to be able to install rpm's *using* yum, since yum brings with it the ability to resolve dependencies. I say this because the RPM we just generated with mock might have Requires: that aren't in the build chroot and would need to be there for installing the the rpm prior to running rpmlint. I hate to add one command to install a local rpm and another to install using yum. A quick scan of the yum man page makes me think that it might work to just invoke 'yum install '. Can anyone confirm/deny that invoking yum with a path to an rpm will work (I'm not in a position to do so at the moment). Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+09oHyuj/+TTEp0RAvuDAKDHCAALdFPNR5cOYMixEeU974xP3gCfQ8OS yzNM0ThtwBjdhKI1lU1Hwgg= =26V1 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Katz wrote: > Kind of an aside... > > On Sat, 2006-09-02 at 13:38 -0500, Clark Williams wrote: >> Well, because in 0.7 and greater, there is no mockhelper. The >> /usr/bin/mock program is a setuid root launcher that starts "python >> /usr/bin/mock.py" with whatever arguments were passed in. > > It might be worth moving /usr/bin/mock.py to be somewhere that's not in > the path... otherwise, this is bound to be somewhat confusing[1] > > Jeremy > > [1] To me, if to no one else :-) > Ah, it's all about you, Jeremy :) I had considered it but was more concerned with other things (like trying to clean up the BZ's for 0.6). Where would you suggest? /opt/mock? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+0mrHyuj/+TTEp0RArG9AKCks5F7dpZgxVTmFP3rwQMVLCFE1QCdEeRp JRKJt+IsfUmKwarWrFkjQgI= =ouVA -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Sat, 2006-09-02 at 08:42 -0500, Clark Williams wrote: >> What I haven't gotten my head around is what needs to be done for the >> hypothetical "install" command. It may just be running yum with the >> appropriate root arguments to install rpmlint, then just running rpm >> to >> install the target rpms into the chroot. Or maybe we just add rpmlint >> to >> the default package set. It may be that we don't need a new command >> and >> we can get everything done with what exists and external logic. >> >> I'd welcome discussion on how to do this and on how to improve chroot >> management in general. >> > > Whats wrong with using mockhelper yum --installroot /chroot > localinstall /path/to/buildrpms/*.rpm ? > Well, because in 0.7 and greater, there is no mockhelper. The /usr/bin/mock program is a setuid root launcher that starts "python /usr/bin/mock.py" with whatever arguments were passed in. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+c+RHyuj/+TTEp0RAne4AKDB6kfE7tgaa2gQXxWUw6Aac735IQCbB+8b mwMm86+KP6wQrqzdlUdpl4w= =Ehob -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Weyl wrote:
> On 8/16/06, Clark Williams <[EMAIL PROTECTED]> wrote:
>> Keeping in line with our razor-blade focus for mock ("we just build
>> packages in chroots"), I actually don't think there's much more to do
>> for 1.0. Once we are comfortable with the functional and security
>> aspects of the 0.7 mock, I'd call it cooked. Assuming of course no one
>> comes up with a killer feature that is :).
>
> A while ago and on a different list, tibbs proposed adding one last
> bit to the buildcycle:
>
> * installing rpmlint into the buildroot
> * installing the built packages into the buildroot
> * running rpmlint against the installed packages and providing the
> rpmlint reports in results/
>
> The idea here is to seamlessly give rpmlint reports on installed
> packages (there's a difference than on binaries, apparently) without
> having the builder/reviewer needlessly clutter up their host. Mock
> wouldn't have anything to do with the results once rpmlint is run;
> they'd just be another bit of information for the reviewers/packagers
> to use.
>
> My memory is a bit foggy on what happened to this, but is this
> something we could think about doing for mock, either 0.7 or 1.0?
> IMHO, something like this would be a great time saver, as it's
> something that's fairly routine.
>
I actually had code in my local sandbox that would run rpmlint on the
generated SRPM and RPMs, but going much farther than that gets a bit
more complicated. The discussion we had at the time indicated that most
folks thought that it was testing not building and that it was best done
by other logic. While I kinda think that adding an rpmlint feature would
be cool, an objective look makes me think they're right. Lets keep mock
a chroot manager, not a test framework.
I think I would prefer to make it easy to install things into the chroot
so that what you want to do turns into:
$ mock -r SRPM
$ mock --no-clean -r install rpmlint
$ mock --no-clean -r install
$ mock --no-clean -r chroot rpmlint
What I haven't gotten my head around is what needs to be done for the
hypothetical "install" command. It may just be running yum with the
appropriate root arguments to install rpmlint, then just running rpm to
install the target rpms into the chroot. Or maybe we just add rpmlint to
the default package set. It may be that we don't need a new command and
we can get everything done with what exists and external logic.
I'd welcome discussion on how to do this and on how to improve chroot
management in general.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE+Yo8Hyuj/+TTEp0RAtAVAKDhsjGjAfHrjgKPkLBm1dtoK18qpgCfemcT
Ugvx4v20/UTIFerUevFgCYU=
=zSS+
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: sparc weirdness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis Gilmore wrote: > Hey all, > > I have a odd situtation that im trying to work out the best way to handle. > gcc on sparc needs glibc for sparc and sparc64 but it gets built as sparc. > somehow i need to have sparc64 glibc in the buildroot only for gcc. even > though the target is sparc. > > Dennis > I've started three replies to this and have bogged down every time. Sigh. If I'm correct here, the problem is that you need both 32-bit and 64-bit glibc's in the same chroot to build gcc for a sparc. I looked on a x86_64 FC5 system and it has two glibc-2.4-8 packages, but if you list them both, one is the 64 bit version and the other is the 32-bit version. This implies to me that they were both "installed" as opposed to "updated". I can't really see an easy way to force mock/yum to do this, so I think the only way will be multiple invocations of mock and rpm. Something like: $ mock -r fedora-devel-sparc-core init $ rpm --root /var/lib/mock/fedora-development-sparc-core/root \ -ihv glibc-2.4-8.sparc64.rpm $ mock -r fedora-devel-sparc-core --no-clean You can't install the 64-bit rpm while inside the chroot, because you're using the native RPM to do all RPM manipulations; hence the invocation of rpm. It's ugly, but I'm not sure I see any other way to do what you're asking. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE5gtvHyuj/+TTEp0RAucgAKCjoJxHbTxh0mOQPYPRzQco1BLPnwCeNEha yN19ABYID2WOEmDo10qCbac= =a50F -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock SELinux policy as RPM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Clark Williams >> Sent: Thursday, August 17, 2006 10:56 AM >> To: Discussion of Fedora build system >> Subject: Re: mock SELinux policy as RPM package >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hans Ulrich Niedermann wrote: >>> Hi, >>> >>> the question of a package of the mock SELinux policy from >>> >>> http://fedoraproject.org/wiki/Extras/MockTricks >>> >>> has come up a few times in the past, and I have made an RPM >> package for >>> my own use some time ago: >>> >>>http://n-dimensional.de/software/mock-selinux-policy/ >>> >>> It doesn't have all the bells and whistles Paul Howarth has >> mentioned in >> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyMo >> dules yet >>> (my package predates that document by several weeks), but >> should be too >>> difficult to adapt if someone is interested. >>> >>> (This is my second try to post here as my last message seems to have >>> been eaten by the moderation system.) >>> >>> Gruß, >>> >> >> - From a quick read of the Wiki, it looks like there are packages that >> fail to build on FC5 hosts due to policy problems (I didn't realize >> that). This means to me that we should add a loadable policy >> module as >> part of the mock package. >> >> Seth, Michael, Dan, et al, what do you guys think? > > I think it would be a good idea to package an selinux policy directly in with > the mock package. This would give people a good starting place for tweaking > if they have problems, and encourage them to send their fixes upstream. > > Hans policy might be a good starting point if it passes review by somebody > who knows more about selinux than I do. > -- Yeah, you and I are in the same boat. I can *spell* SELinux, but that's about it. I'll poke around a bit with the policy and see what it would take to integrate it. Might be able to get Dan Walsh to look at it as well. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE5NCaHyuj/+TTEp0RAjAtAJ9LGRhjBlmVCUynuRFDa+dfSRD+rQCg1lvM Kj/kgW53htgL82aWEYiISII= =ZKzj -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock SELinux policy as RPM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans Ulrich Niedermann wrote: > Hi, > > the question of a package of the mock SELinux policy from > > http://fedoraproject.org/wiki/Extras/MockTricks > > has come up a few times in the past, and I have made an RPM package for > my own use some time ago: > >http://n-dimensional.de/software/mock-selinux-policy/ > > It doesn't have all the bells and whistles Paul Howarth has mentioned in > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules yet > (my package predates that document by several weeks), but should be too > difficult to adapt if someone is interested. > > (This is my second try to post here as my last message seems to have > been eaten by the moderation system.) > > Gruß, > - From a quick read of the Wiki, it looks like there are packages that fail to build on FC5 hosts due to policy problems (I didn't realize that). This means to me that we should add a loadable policy module as part of the mock package. Seth, Michael, Dan, et al, what do you guys think? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE5JGMHyuj/+TTEp0RAo0AAKC8kcKFQBIxlz81FB+/i7bdnCK/qgCfaJM7 u/I7yrLpa2CQnT5qHS0Ws0M= =DUj/ -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock hangs - why
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Williams wrote: > > Is some process taking up all your CPU? Is that process part of the > build of your package? > > Install and look at the output of the 'pstree' command; that will show > you exactly what mock has launched and the parent/child relationships > between the build processes and mock. You can also try to 'strace' the > process that seems to be hanging and perhaps get more information out of > it. Sometimes attaching to the hung build process with gdb shows usable > backtrace info, sometimes not. > > In the Extras buildsystem we've had problems with reproducible build > hangs a few times, which were generally solved by updating the kernel. > What kernel are you running on the build system? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE5I0aHyuj/+TTEp0RAgMLAJ4vw8P4giSWkjqd4cJwxAdBOey8KQCeIP0t 7KsZJmvVQrtUHtss67SOzQY= =DJxo -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
updated man page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I lied about not posting another mock message today. You can dock
my mock pay 50%...
Attached is an updated man page for mock. Please take a moment to look
it over (man ./mock.1) and see if there are any egregious errors.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE450OHyuj/+TTEp0RAkL6AJ99q+dJl1yjjAxYsZCsurgFa440iQCg291S
mGMG87HdfVug6x6V0YAAdEg=
=Dc9E
-END PGP SIGNATURE-
.TH "mock" "1" "0.4" "Seth Vidal" ""
.SH "NAME"
.LP
mock \- build SRPMs in a chroot
.SH "SYNTAX"
.LP
mock [options] [\fBrebuild\fR] \fISRPM [\fISRPM...\fR]
.LP
mock [options] \fBchroot\fR \fI\fR
.LP
mock [options] {\fBinit\fR|\fBclean\fR|\fBshell\fR}
.SH "DESCRIPTION"
.LP
Mock is a simple chroot/rpm building program. It doesn't do anything
terribly fancy other than populate a chroot with the contents
specified by a configuration file, then build any input SRPM(s) in
that chroot.
.LP
The content of a chroot is specified by the configuration
specified with the \fB\-r\fR option. A default configuration file is
specified in /etc/mock/default.cfg, which is usually a symlink to one
of the installed configurations.
.SH "OPTIONS"
.LP
.TP
\fB\-r\fR \fICHROOT\fP
Uses specified chroot configuration as defined in
/etc/mock/<\fIchroot\fP>.cfg If none specified, uses the chroot linked
to by /etc/mock/default.cfg
.TP
\fB\-\-no\-clean\fR
Do not clean chroot before building package.
.TP
\fB\-\-arch=\fR\fIARCH\fP
Specify target build arch.
.TP
\fB\-\-debug\fR
Output copious debugging information.
.TP
\fB\-\-resultdir=\fR\fIRESULTDIR\fP
Change directory where resulting files (RPMs and build logs) are written
.TP
\fB\-\-statedir=\fR\fISTATEDIR\fP
Change directory where state information is written
.TP
\fB\-\-uniqueext=\fR\fItext\fP
Arbitrary, unique extension to append to buildroot directory name
.TP
\fB\-\-configdir=\fR\fICONFIGDIR\fP
Change directory where config files are found
.TP
\fB\-\-quiet\fR
Suppress most output
.TP
\fB\-\-autocache\fR
Turn on build-root caching
.TP
\fB\-\-rebuildcach\fR
Force rebuild of build-root cache
.TP
\fB\-\-help\fR
Show usage information and exit.
.TP
\fB\-\-version\fR
Show version number and exit.
.SH "COMMANDS"
.LP
.TP
\fBinit\fR \- initialize a chroot (install packages, setup devices, etc.)
.TP
\fBchroot\fR \- run the specified command within the chroot (which must already
be initialized)
.TP
\fBclean\fR \- purge the chroot tree
.TP
\fBshell\fR \- start an interactive shell in the specified chroot
.TP
\fBrebuild\fR \- If no command is specified, rebuild is assumed. Rebuilds the
specified SRPM(s)
.SH "FILES"
.LP
\fI/etc/mock/\fP \- default configuration directory
.LP
\fI/var/lib/mock\fP \- directory where chroots are created
.SH "EXAMPLES"
.LP
To rebuild test.src.rpm under the default chroot:
.LP
.RS 5
\fBmock /path/to/test.src.rpm\fR
.RE
.LP
To specify a different chroot (which must be defined in /etc/mock):
.LP
.RS 5
\fBmock \-r fedora\-4\-i386\-core /path/to/test.src.rpm\fR
.RE
.SH "BUGS"
.LP
To report bugs in mock, go to:
.LP
.RS 5
\fIhttp://bugzilla.redhat.com/bugzilla\fR.
.RE
.LP
Select the query option, using product \fBFedora Hosted Projects\fR
and component \fBmock\fR and press the \fBStart Search\fR
button. If there is a bug similar to the one you are seeing, add your
information to the comments. If not, go to the new bug page using the
same product and component and fill in the form.
.SH "AUTHORS"
.LP
Seth Vidal <[EMAIL PROTECTED]>
.LP
and a cast of...tens
.SH "SEE ALSO"
.LP
yum(8) rpmbuild(8)
http://fedoraproject.org/wiki/Projects/Mock
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Disttags in mock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Looks fine to me. > -- > Michael > Ok, it's in. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE43UXHyuj/+TTEp0RAho4AJ4zkwZpuYTCsyFTG31h8AxWFiVfCQCeNCPj CoTJvS2MAnYUrudgEAamyEM= =oON+ -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> On Wednesday 16 August 2006 14:30, Clark Williams wrote:
>> Keeping in line with our razor-blade focus for mock ("we just build
>> packages in chroots"), I actually don't think there's much more to do
>> for 1.0. Once we are comfortable with the functional and security
>> aspects of the 0.7 mock, I'd call it cooked. Assuming of course no one
>> comes up with a killer feature that is :).
>
> I'd be happy to see a 1.0 mock in FC7 released (:
>
> Once 0.7 settles down a bit, I'd really like to get Red Hat's
buildsystem guys
> to beat up on it and see if we can get anything they need upstream
before 1.0
> so that when upstream mock goes 1.0, Red Hat can consume 1.0 and
runwith an
> unmodified mock.
>
I think we're agreed here. The tentative plan is we let FC6 go gold,
then when development becomes pre-FC7, we push mock-0.7 into
development. We then figure out some way to force Dan and Jeremy to
use the new mock in the buildsystem and as we fix bugs we up the mock
version until when it's stable, it becomes 1.0 for the FC7 release.
Viola! (or Walla, as we say in the South).
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE42iXHyuj/+TTEp0RAk/3AJ4zKSNQRYFTXde+Hk2J4c4uAeeSagCfRX+G
AYS7Q0TshTLG2tTc3jvN1q0=
=QZQw
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Mock going forward
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> On Wednesday 16 August 2006 13:59, Clark Williams wrote:
>> Anyway, I'd be interested to hear what everyone thinks and I'd like to
>> learn what the mechanism is for implementing it. Is implementation
>> merely telling Jeremy or Jesse what branch to pull from? Or do we have
>> to do more?
>
> In other projects, upstream picks a time to make a 'release' of a
tarball.
> Then downstream distros, like Fedora, would decide when to consume that
> tarball and push it out to their users.
>
> Personally I'd like to see 0.6 be The Shipped mock for FC6. Once we start
> development toward FC7 (when we branch all packages for FC-6 / FE-6),
we can
> then look at either packaging a cvs snapshot of HEAD, or the mock upstream
> could pick a time to make a "0.7" release. Downstream, Extras, I would
> package either the snapshot or the 0.7 release into development and our
happy
> rawhide users would get to beat up on it. Hopefully we'd be able to reach
> some sort of stability with the feature set of 0.7 by the time FC7Test2 or
> FC7Test3 is ready to ship, and 0.7 could be "The Mock" for FC7 (neat that
> the numbers line up...)
I agree that 0.6 should be shipped with FC6. I like the idea of
beating up the 0.7 branch on the development branch for FC7.
>
> Soon we should figure out what feature set we would want to be happy
with for
> the magical 1.0 release of mock, and shoot for a timeline. Then the fun
> starts (:
Keeping in line with our razor-blade focus for mock ("we just build
packages in chroots"), I actually don't think there's much more to do
for 1.0. Once we are comfortable with the functional and security
aspects of the 0.7 mock, I'd call it cooked. Assuming of course no one
comes up with a killer feature that is :).
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE42RHHyuj/+TTEp0RAju4AJ4h1UpdD1t2cPTbWLO0meZkid1hxQCg4R0R
og9uobVVvikk+BfOXIt1fJo=
=slzL
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Disttags in mock?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> On Wednesday 16 August 2006 13:50, Clark Williams wrote:
>> Gladly, but I have no idea where that repo is :). Should I just pull
>> the SRPM from an extras repo?
>
> Sure you can do that... I've attached it here too.
>
Thanks, comments below
>
> %install
> rm -rf $RPM_BUILD_ROOT
> make DESTDIR=$RPM_BUILD_ROOT install
> # make the default.cfg link
> cd $RPM_BUILD_ROOT/%{_sysconfdir}/%{name}
>
> %if 0%{?fedora:1}
> if [ -f fedora-%{fedora}-%{_target_cpu}-core.cfg ]; then
>ln -s fedora-%{fedora}-%{_target_cpu}-core.cfg default.cfg
> fi
> %endif
>
> # if we haven't created a default link yet, try to do so as devel
> if [ ! -f default.cfg ]; then
> if [ -f fedora-development-%{_target_cpu}-core.cfg ]; then
> ln -s fedora-development-%{_target_cpu}-core.cfg default.cfg
> else
> ln -s fedora-development-i386-core.cfg default.cfg
> fi
> fi
>
Here's the only real difference between your spec file and mine. Mine
just has an unconditional symlink from development-i386 to default. As
I read your logic, if the fedora tag is set, use that for setting the
default symlink. Then if we haven't set default.cfg, if the target_cpu
is set, use it to link to development, else default to development-i386.
I think that will work for me. Michael/Seth, what do you guys think?
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE42EuHyuj/+TTEp0RAqvuAKCKBC3UlzvzFrvGM7YQkm9PyOeyFQCgjJK+
3T9rM/JucfBjODWTEOnnDvA=
=6J4p
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Mock going forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, last unsolicited mock email of the day. Really! I promise... We're currently shipping mock from the mock-0.6 branch of the mock CVS repository. The HEAD (0.7) is the branch that contains the re-architected launcher and the elevate/drop privilege logic. I'm wondering when/how we push the new version of mock out to the world? My preference would be to wait for FC6 to go gold, then switch over to HEAD and deal with mock breakage at that point. Of course, the complete lack of complaints from all you dedicated fedora buildsys readers probably means that mock-0.7 is perfect in every way, so we probably don't have to worry about that, eh? :) Anyway, I'd be interested to hear what everyone thinks and I'd like to learn what the mechanism is for implementing it. Is implementation merely telling Jeremy or Jesse what branch to pull from? Or do we have to do more? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE410cHyuj/+TTEp0RAsmsAKDDlOns80a9CorfSURSSEzjp+wslgCeLRrK 9Mcp4IziZ6O3ojXjcm64GoQ= =IeOW -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Disttags in mock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Wednesday 16 August 2006 13:23, Clark Williams wrote: >> So, you'd like it if we added it to the upstream copy? I'm not against >> since there seems to be a use for it. > > Yes please (: Okey doke, it's in both the mock-0.6 branch (what's being released to the world, atm) and the HEAD branch (currently 0.7). > > Also, you should do a diff against the spec that is in extras CVS. I don't > _think_ I changed much (and I didn't comment in the changelog about any such > changes), but a diff would be good to do anyway. > Gladly, but I have no idea where that repo is :). Should I just pull the SRPM from an extras repo? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE41rrHyuj/+TTEp0RApUEAKCyYpaOB/bVtxaiGxqiS1dLfwaojACePv2J GlBMF7EiWDD2Pa2PnWJpRv0= =KgBP -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Disttags in mock?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> On Wednesday 16 August 2006 13:11, Clark Williams wrote:
>> Do we need to add a disttag to the mock specfile?
>>
>> My initial thought was no, since it's a noarch and pretty much should
>> run on any python >= 2.2. But, I'm not positive that we shouldn't add
>> a disttag; just a nagging feeling. So I thought I'd throw it out there...
>
> I added a disttag in the Extras CVS for this reason:
>
> When I want to release a new mock to extras, I'm usually releasing the
same
> thing across all releases. Because of this, the spec is going to be
> identical, and the only thing that would change between the releases is
the
> release number. Since %{?dist} lets that be autogenerated, the exact same
> spec can be used across all the releases. Makes it easy for me.
So, you'd like it if we added it to the upstream copy? I'm not against
since there seems to be a use for it.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFE41SCHyuj/+TTEp0RAsfWAKCMM5uv2DQD/TKrjuztc7TLR0KcdACfdFyX
tH2Cz7M2l0bxYB5UJaifYus=
=QHdy
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Disttags in mock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do we need to add a disttag to the mock specfile? My initial thought was no, since it's a noarch and pretty much should run on any python >= 2.2. But, I'm not positive that we shouldn't add a disttag; just a nagging feeling. So I thought I'd throw it out there... Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE41HDHyuj/+TTEp0RAi8oAKCpi9CC53V16ppZBdlzVmNd/qoZGQCcDx9D jAmtiHxP+Zcv+W7PkfO4aEI= =n2Xp -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: mock BZ#196930 questions/thoughts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Seconded. > -- > Michael > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Jesse Keating >> Sent: Wednesday, August 16, 2006 11:09 AM >> To: fedora-buildsys-list@redhat.com >> Subject: Re: mock BZ#196930 questions/thoughts >> >> On Wednesday 16 August 2006 11:59, Clark Williams wrote: >>> For number 3, I don't have a problem including the buildsys-build >>> specfile in the mock package for people to use, but I wondered if we >>> do, where should we put it? /usr/share/doc/mock? /etc/mock? >> /var/lib/mock? >> >> I would think doc. It's considered an "example" imho. >> So let it be written. So let it be done! Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE40uBHyuj/+TTEp0RAkyjAKC3JxRcA4SeDd0ZbixKyIcnZuvBfwCgwB3A 2peZyCuj8JqMlH2pI385H7A= =jxvY -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
mock BZ#196930 questions/thoughts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I actually had a couple of hours without having to go to a meeting or be on a conference call, so I started looking at the open BZ's on mock. BZ #196930 has been partially addressed by updating the buildsys-build specfile and generating binary RPMS for each supported distro. The remaining items are: 1. Adding a config_opts['runuser'] = '/bin/su' for FC[12] cfg files. 2. Potentially adding an RHL 8 cfg file 3. Potentially including the buildsys-build.spec in the mock binary RPM I think #1 is a no brainer and will commit changes to CVS in a bit. The second part gave me a bit of pause. It was easy enough to copy the RHL9 cfg file to an RHL8 one and mangle the paths, but I hesitate to actually ship a file with a URL which implies that Fedora Legacy supports it. My though was to remove the Fedora Legacy host from the URL and insert in the yum repo specifications. That way it should be painfully obvious that it's not supported by Fedora Legacy and that there's Some Assembly Required(tm). For number 3, I don't have a problem including the buildsys-build specfile in the mock package for people to use, but I wondered if we do, where should we put it? /usr/share/doc/mock? /etc/mock? /var/lib/mock? Thoughts? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE40DUHyuj/+TTEp0RAi5FAJ9/BAc7qvfAmWbLrRueeAOcUGbPIwCfbJUw 9AF0Ec1DWpiTuscUMMeaa8c= =8+L4 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Upstream bugzilla for mock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Thursday 10 August 2006 15:41, Clark Williams wrote: >> Wouldn't that be Michael and I? > > There can be only one! Well, not knowing what Michael looks like or how big he is, I'm not going to sign up to take him on with a large edged weapon :) > > Well, one email that is. If you wanted to create a bugzilla account that was > an alias to you two, or to some list we could do that, or I could use one of > you for the assignee and the other for initial CC, or any combination of the > above. > Put me down as the assignee for now (I'm assuming that if we put together an email alias solution, you would help us straighten it out). If it's a pain to go back and modify we can set up an alias now. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE24+OHyuj/+TTEp0RAiekAJ0em7ljaLMDVrEQvDJcDeX2/m160wCgy+EU CcD9moRE4zLFYAxHiAXOEa0= =j1ql -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Upstream bugzilla for mock?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Thursday 10 August 2006 15:23, seth vidal wrote: >> upstream mock IS fedora. >> >> primary mock cvs is in /cvs/fedora >> >> maybe we need an infrastructure/mock item? > > The Fedora Project is upstream for mock yes, but the distribution isn't (: > > I was thinking more of a Fedora Projects product, with mock being one > componet. This could be used for other things that are Fedora hosted. > > I'll take this to FAB. In the mean time, who would own the componet mock? > Wouldn't that be Michael and I? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE24vQHyuj/+TTEp0RAjkEAKCmkzbjeHFKUjd3Ki3/BJ7nvzykdwCgtO1z 6ylNWRXVvkKKSiTKRZFuBiw= =5Qk9 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Fix problems building Extras packages for FC3 and FC4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (removed extras-list since I'm tired of the nastygrams) Clark Williams wrote: > Thorsten Leemhuis wrote: > >> Hi! > >> > >> Now that mock on the Extras builders was updated to 0.6 (thx dgilmore > >> for your work) we noticed that there are big problems building Extras > >> packages for FC3 and FC4. For details see this thread: > >> > https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00091.html > >> > >> The problem is well know and described in #196930 -- opened by Paul > >> Howarth on 2006-06-27 > >> > >> We really should fix this as soon as possible. That means: > >> > >> - add elfutils to the default buildroot in all Fedora Dists < FC5 > >> - add python to the default buildroot in FC3 and FC4 > >> > >> Everyone (especially fedora-packaging) fine with that? I'd like > to see > >> this fixed soon and would like to avoid waiting for the next > meetings. > >> > >> If yes: can somebody (skvidal) please apply this patch: > >> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=133705 > >> and update http://buildsys.fedoraproject.org/buildgroups/ please? > > I've applied the patch and committed it to the mock-0.6 branch, but > there's a bit more to do before we can push an update. We need N > buildsys-build binary packages for this to work and we don't do that > (yet) in the build mechanism. I believe we need to build fedora[12345] > and devel as well as rhl[89], which gives us 8 buildsys-build packages > to generate. > > I've made a start on it by modifying the Makefile to look like this: > > RPMARGS := --define "_sourcedir $(PWD)" \ >--define "_builddir $(PWD)/buildsys" \ >--define "_srcrpmdir $(PWD)/buildsys" \ >--define "_rpmdir $(PWD)/buildsys" > buildsys-rpm: > rm -rf buildsys > mkdir buildsys > for i in 1 2 3 4 5 devel; do \ > rpmbuild $(RPMARGS) --define "fedora $$i" --define "dist > fc$$i" -ba buildsys-build.spec; \ > done > for i in 8 9; do \ > rpmbuild $(RPMARGS) --define "rhl $$i" --define "dist rhl$$i" > -ba buildsys-build.spec; \ > done > > But, I'm not sure if I'm abusing the %dist macro and I'm not at all > sure how we should name the devel package. Would someone more > knowledgeable than me (and that's most folks on these lists), please > look at the above make rule and comment/correct? > > Clark > > (once we get this straightened out I'll add it to the mock CVS HEAD). > After a bit of tweaking, the Makefile logic now looks like this: RPMARGS := --define "_sourcedir $(PWD)" \ --define "_builddir $(PWD)/buildsys" \ --define "_srcrpmdir $(PWD)/buildsys" \ --define "_rpmdir $(PWD)/buildsys" buildsys-rpm: rm -rf buildsys mkdir buildsys for i in 1 2 3 4 5 devel; do \ rpmbuild $(RPMARGS) --define "fedora $$i" --define "dist .fc$$i" -bb buildsys-build.spec; \ done for i in 73 8 9; do \ rpmbuild $(RPMARGS) --define "rhl $$i" --define "dist .rhl$$i" - -bb buildsys-build.spec; \ done for i in 3 4; do \ rpmbuild $(RPMARGS) --define "rhel $$i" --define "dist .rhel$$i" -bb buildsys-build.spec; \ done An rpm -qp --requires shows what I would expect for these guys, so I'll be committing this stuff this afternoon (unless I get a passle of emails indicating that I'm completely inept). After I commit it and get some other suckers^Wtesters to see if it works right on targets other than FC5 and devel, we can figure out how to push the resulting binaries to the buildgroups repo (since I've never done that). Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE12rwHyuj/+TTEp0RAlbfAJ4/2tLGQW2pXo2nO35aVU11tIeRxACgoHs1 bv2l64Oxl/H/x+W4WjvMgdM= =lsKR -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Fix problems building Extras packages for FC3 and FC4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Leemhuis wrote: > Hi! > > Now that mock on the Extras builders was updated to 0.6 (thx dgilmore > for your work) we noticed that there are big problems building Extras > packages for FC3 and FC4. For details see this thread: > https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00091.html > > The problem is well know and described in #196930 -- opened by Paul > Howarth on 2006-06-27 > > We really should fix this as soon as possible. That means: > > - add elfutils to the default buildroot in all Fedora Dists < FC5 > - add python to the default buildroot in FC3 and FC4 > > Everyone (especially fedora-packaging) fine with that? I'd like to see > this fixed soon and would like to avoid waiting for the next meetings. > > If yes: can somebody (skvidal) please apply this patch: > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=133705 > and update http://buildsys.fedoraproject.org/buildgroups/ please? I've applied the patch and committed it to the mock-0.6 branch, but there's a bit more to do before we can push an update. We need N buildsys-build binary packages for this to work and we don't do that (yet) in the build mechanism. I believe we need to build fedora[12345] and devel as well as rhl[89], which gives us 8 buildsys-build packages to generate. I've made a start on it by modifying the Makefile to look like this: RPMARGS := --define "_sourcedir $(PWD)" \ --define "_builddir $(PWD)/buildsys" \ --define "_srcrpmdir $(PWD)/buildsys" \ --define "_rpmdir $(PWD)/buildsys" buildsys-rpm: rm -rf buildsys mkdir buildsys for i in 1 2 3 4 5 devel; do \ rpmbuild $(RPMARGS) --define "fedora $$i" --define "dist fc$$i" -ba buildsys-build.spec; \ done for i in 8 9; do \ rpmbuild $(RPMARGS) --define "rhl $$i" --define "dist rhl$$i" - -ba buildsys-build.spec; \ done But, I'm not sure if I'm abusing the %dist macro and I'm not at all sure how we should name the devel package. Would someone more knowledgeable than me (and that's most folks on these lists), please look at the above make rule and comment/correct? Clark (once we get this straightened out I'll add it to the mock CVS HEAD). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE11y8Hyuj/+TTEp0RAhQ3AKC5+q7UCRbOBLgNNBKwAmDO1xoRYwCfewYy NOyPGcOvQEBOaDlOSplC4lA= =2zaw -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: proposed mock changes (diff)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Sheltren wrote: > > On Jul 17, 2006, at 4:57 PM, Clark Williams wrote: > >> >> Now, I really don't like the idea of adding *anything* to the default >> build chroot (other than what's required to build a package). It's >> slow enough as it is and for the most common usage (plague/mock >> builds) we don't want anything except what's absolutely needed. So, >> how would we go about managing a chroot for tasks like testing? Do we >> add an 'install' command to install stuff from the configured >> repositories into the chroot, like this: >> >> $ mock install rpmlint >> >> Or do we do something else? Do we make tester's put together their own >> cfg with a modified buildsys-build rpm that includes the packages they >> need? Is there a simpler mechanism for someone that wants a chroot for >> testing? >> >> Clark >> > > I've always just used yum from the host system with the > --installroot flag. You don't want to rely upon the RPM tools > inside of the chroot because those won't always work - remember, we > are doing all the package installs with the host system's yum in the > first place. My vote would be to keep mock as simple/minimal as > possible. > Ah, I hadn't thought about that. RPM and friends work fine in the FC5 chroot on my FC5 laptop, but I'm betting an FC2 chroot would yak all over the place. :) So someone wanting to put together a testing chroot would do something like this: $ mock -r fedora-5-i386-core init $ yum --installroot=/var/lib/mock/fedora-5-i386-core/root - --enablerepo= install $ mock -r fedora-5-i386-core chroot I probably don't have that yum command right, but you should get my intent. Is that the way you use it? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEvBcTHyuj/+TTEp0RAgN2AJ0RF1KLvomfnbA8/g/9w2sDUZm6RQCeMvnB TxuUnKmqAkcAQJjeDCbF/iU= =174P -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: proposed mock changes (diff)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason L Tibbitts III wrote: >> "MEB" == Michael E Brown <[EMAIL PROTECTED]> writes: > > MEB> Can rpmlint just be done outside of mock (using mock chroot, for > MEB> example)? > > Yes, as long as mock continues to give me a way to run a command in > the chroot and some equivalent of "mock-helper yum". I was just > asking for a way to do it, not that it actually be added as base > functionality. Well, there I was about to tell you to do this: $ mock --no-clean chroot yum install foo $ mock --no-clean chroot rpmlint -vi foo Then I thought, hey, I should try that first (what a concept, eh?). I did and about that time I realized that we don't install yum into the chroot (chroot manipulations occur outside the chroot). So what I did above won't work. Now, I really don't like the idea of adding *anything* to the default build chroot (other than what's required to build a package). It's slow enough as it is and for the most common usage (plague/mock builds) we don't want anything except what's absolutely needed. So, how would we go about managing a chroot for tasks like testing? Do we add an 'install' command to install stuff from the configured repositories into the chroot, like this: $ mock install rpmlint Or do we do something else? Do we make tester's put together their own cfg with a modified buildsys-build rpm that includes the packages they need? Is there a simpler mechanism for someone that wants a chroot for testing? Clark Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEu/nKHyuj/+TTEp0RAtWJAJsEfykRVC3RX/DXKibbf1zsBinEbACfYYDX Zd3ifqYv65iMf+zFvdDo1JM= =Clon -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: proposed mock changes (diff)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > I am leaving for OLS 2006 and wont be able to do any review for the next > week. > > I just caught up on the rpmlint discussion, and have a few concerns. > -- Security of installing just-built RPM > -- Can rpmlint just be done outside of mock (using mock chroot, > for example)? Why do we have to extend mock for this? > We don't really have to. I wondered if it could be done without a major upheaval in the code. Turns out it can if we're just talking about running it against the package files. But it would take quite a bit more to do it automagically against an installed package (i.e. install the just-built package into the chroot and run rpmlint on the installed package(s)). My thought is that running rpmlint against the just-generated RPM/SRPMs is a nice thing to have around, so that a developer could get a regular sanity check on the package (since the results are kept in an rpmlint.log file). Note that you'd still have to invoke mock with the --rpmlint command line option. I think that installing the package in a chroot and doing more extensive testing is job for a testing tool (not mock). So left to myself I'd probably add the --rpmlint option as is and let someone use 'mock --no-clean chroot ' to do more extensive testing. But I don't feel strongly enough about it that I'd argue for it in the face of determined resistance. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEu/CRHyuj/+TTEp0RAsiIAKCJaWb5Oi8fFBLwPSPokx3jPGkJ4gCfcG9o mLa7aQdS89Wgq8t7OiXtv6w= =QV6u -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
proposed mock changes (diff)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
I was poking around in the mock source last week and did some minor
refactoring, a couple of name-changes and tried out the rpmlint
request. Attached below is a CVS diff of my mock.py with the head of
CVS. Please review and comment. A quick summary of the changes:
1. Changed version to 0.7.
2. Added code to avoid exec'ing mount for proc, sys, and dev/pts if
we've already done it
3. Oh yeah, added /sys to chroot mount
4. Refactoring: renamed _mount to _mountall, created _mount routine
that is called by _mountall
5. Renamed _umount_by_file to _umountall
6. Added code to run rpmlint
7. Added elevate/drop around raw chroot command
I'd especially like some thought on #7, since any time you elevate and
drop you can introduce a security hole and I freely admit that I'm not
always thinking security first.
If I don't get any push-back (or if I do and then get things
resolved), I'll commit these later this week.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEu6y9Hyuj/+TTEp0RAgumAJ9STO3Qc/7Ca4xYNdIAifcKs4oPvACgqpDD
zOm5eNJ1Gwsgc4KqhS8WW0s=
=0mBy
-END PGP SIGNATURE-
Index: mock.py
===
RCS file: /cvs/fedora/mock/mock.py,v
retrieving revision 1.55
diff -u -r1.55 mock.py
--- mock.py 17 Jul 2006 15:04:00 - 1.55
+++ mock.py 17 Jul 2006 15:15:16 -
@@ -31,7 +31,7 @@
from optparse import OptionParser
-__VERSION__ = '0.6'
+__VERSION__ = '0.7'
def error(msg):
print >> sys.stderr, msg
@@ -162,12 +162,18 @@
cfgout.write('statedir = %s\n' % self.statedir)
cfgout.flush()
cfgout.close()
-
+
+# note that we haven't mounted anything (yet)
+self._mounted = 0
+self.run_rpmlint = config['run_rpmlint']
+
def elevate(self):
+"elevate privileges by changing to privileged uid"
self.debug("elevate: setting uid to %d" % self.highuid)
os.setreuid(self.highuid, self.lowuid)
def drop(self):
+"drop privileges by changing to unprivileged uid"
self.debug("drop: setting uid to %d" % self.lowuid)
os.setreuid(self.lowuid, self.highuid)
@@ -293,7 +299,7 @@
# mock-helper yum --installroot=rootdir cmd
basecmd = '%s --installroot %s' % (self.config['yum'], self.rootdir)
-self._mount() # check it again
+self._mountall() # check it again
command = '%s %s' % (basecmd, cmd)
self.debug("yum: command %s" % command)
@@ -308,7 +314,7 @@
"""take an srpm, install it, rebuild it to srpm,
return chroot-local path to the resulting srpm"""
-self._mount() # check it again
+self._mountall() # check it again
bd_out = '%s%s' % (self.rootdir, self.builddir)
# init build_dir
self._build_dir_setup()
@@ -366,6 +372,10 @@
arg_string = arg_string + " " + "'%s'" % item
+# if running rpmlint add it to the transaction set
+if self.run_rpmlint:
+arg_string = arg_string + " 'rpmlint'"
+
# everything exists, okay, install them all.
# pass build reqs (as strings) to installer
if arg_string != "":
@@ -412,13 +422,24 @@
for item in packages:
shutil.copy2(item, self.resultdir)
+if self.run_rpmlint:
+self.rpmlint(packages)
-
+def rpmlint(self, packages):
+"""Run the rpmlint utility on the list of input packages and append the output
+to an rpmlint log file"""
+cmd = "rpmlint -iv %s" % " ".join(packages)
+(retval, output) = self.do_elevated(cmd)
+lintlog = open(os.path.join(self.resultdir, "rpmlint.log"), "w+")
+lintlog.write(output)
+lintlog.close()
+return (retval, output)
+
def close(self):
"""unmount things and clean up a bit"""
self.root_log("Cleaning up...")
self.state("ending")
-self._umount_by_file()
+self._umountall()
self._build_log.close()
self.state("done")
self.root_log("Done.")
@@ -438,45 +459,43 @@
except OSError, e:
raise Error, "Could not create dir %s. Error: %s" % (path, e)
-def _mount(self):
-"""mount proc and devpts into chroot"""
+def _mount(self, type, device, path):
+"mount a device, given a filesystem type and a path"
+mntpath = os.path.join(self.rootdir, path)
+self._ensure_dir(mntpath)
+self.debug("mounting %s as %s" % (device, mntpath))
+command = '%s -n -t %s %s %s' % (self.config['mount'], type, device, mntpath)
mf = os.path.join(self.statedir, 'mounted-locations')
-track = open(mf, 'w+')
-
-# make the procdir if we don't have it
-# mount
Re: Running rpmlint within mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason L Tibbitts III wrote: >>>>>> "CW" == Clark Williams <[EMAIL PROTECTED]> writes: > > CW> Just so you know, I have a version of mock that takes a > --rpmlint CW> command line option which will add rpmlint to the > chroot CW> transaction set, install it in the chroot and then run > rpmlint on CW> the generated SRPM and RPMs, putting the output in > an rpmlint.log CW> results file. > > Ah, very very cool. One important thing, and the whole reason for > actually doing this, is that in addition to the SRPM and RPMs, you > need to run rpmlint in the chroot on the package name itself. For > example, build the aplus-fsf package under review. rpmlint will > find nothing real to complain about with the SRPM or binary RPMs, > but if you run "rpmlint aplus-fsf" in the chroot with that package > installed you get 3800 warnings. Well dang, now you're going to make me work for it :). What I've got now just runs rpmlint inside the chroot on the source and binary packages. How about we go with that for a bit and let me think on how we could install into the chroot? I'm not really against it, since I think it goes with the "chroot manager" task of mock, but I'd like to look at how to do it without creating more problems than we solve. The way I see it, mock's primary mission is to be the tool that creates a pristine chroot for the purpose of buiding a package (or set of packages); everything we do here needs to keep that in mind. A related secondary mission though could be management of a longer lived chroot used for various purposes (testing, cross-building, etc.). Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEumcfHyuj/+TTEp0RAuuLAJ4x0mweM+j+yGwNBJ+mcKb2DA+XeQCeKrcs mjsmeV5HcgqdONQgUE151+k= =zNi5 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Running rpmlint within mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason L Tibbitts III wrote: > OK, here's a first pass hack. This could be better written in Python > and could extract some bits from the mock configuration, but this does > at least work. It builds the package, installs rpmlint and all of the > newly-built binary RPMs and (hopefully) their dependencies into the > chroot. It then runs rpmlint on the SRPM, the binary RPMs and the > installed package names. I have tested this against packages which > show different warnings for each and it seems to actually work. > > You'll have to edit to taste, and try not to hurl as some of the > quoting is nasty. > > - J< > Note that using mockhelper is deprecated, since we've re-architected so that mock becomes a chroot launcher for mock.py. Mockhelper will go away in the next release (0.7). Just so you know, I have a version of mock that takes a --rpmlint command line option which will add rpmlint to the chroot transaction set, install it in the chroot and then run rpmlint on the generated SRPM and RPMs, putting the output in an rpmlint.log results file. It wasn't very intrusive and won't affect build systems unless they specifically invoke it. As an aside, I wouldn't mind looking at mock as a chroot builder for things like the test project. It's mostly there, since it's main job is to build a chroot and run rpmbuild within that chroot. We should discuss. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEukxNHyuj/+TTEp0RAgR2AKCOviuiwMw1apU/YXSXig7bzvmzggCeI+fB qJ6PTlrYp5XRxGhMbrGWiLA= =rQrE -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Running rpmlint within mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Friday 14 July 2006 22:10, Jason L Tibbitts III wrote: >> Oh, awesome. Honestly, very many thanks. Might I be so bold as to >> suggest something like the following patch? > > Looks reasonable to me. Alas, I have no commit access (: (maybe that's a > good thing...) > Well, I have commit access and as soon as I get back to the house, this will go in. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEukrDHyuj/+TTEp0RAh+cAKCLefB3+jvXIilFfMUALRV3keB3nQCeJ0AB ZYWrZiOmErdIYu66MGqKvks= =D+nL -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Running rpmlint within mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] said: >> Christian Iseli and I were discussing the possibility of automatically >> running rpmlint somehow. > > Hey, thanks for posting this... I was just about to post such a message > myself :-) > > I've tried to give some thought and get some feedback from the f-e-l list > already. > > Basically for each built package, I'd like to > - get rpmlint output, possibly comparing it against a reference output to see >if unknown problems have crept in Getting the rpmlint output is easy enough. Doing anything more than that sounds like something out of the scope of mock. > - analyze the compiler warnings > - check the Provide'd things from the packages and compare against an >expected set of things provided > > For starters, the whole bunch of tests would just generate a warning to the > build submitter for things to verify. Ah, we're talking automated test suite here. That's not mock. > > Down the road, we might like to fail the build, or put the resulting package > in a quarantine, if bad things are detected. > > I had a first look at adding the checks in the plague builder, but after > discussing this a bit with Jason, probably a good parts of the checks would be > better performed while still in the mock buildroot... > > My python skills are pretty much nil ATM, but I'm willing to learn too... > > Any and all pieces of advice and/or code gladly accepted I applaud your desire to automate this stuff, but I don't think that mock is the right place for it. Mock is strictly a tool for managing a chroot and building SRPMs in those chroots. Anything else just introduces the potential for breaking builds and then Jeremy and Dan start sending me nasty emails :). That being said, I think it would be fairly straightforward to run rpmlint on the generated RPMs and on the SRPM and stash the output somewhere that's easily accessible. At that point you're talking about writing an analysis tool to classify the output of a mock build. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEt+7NHyuj/+TTEp0RAuVPAKCKRg/kINpep85DA3F7OXFA+nUi6gCgnPsd AfZkfqe9NkWCDNzngIHLqZ0= =nvO5 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Running rpmlint within mock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason L Tibbitts III wrote: > Christian Iseli and I were discussing the possibility of automatically > running rpmlint somehow. It seems that the end of the mock build > process is the ideal place for this. It has a chroot already set up > with the package's build requirements already installed. (Obviously > this doesn't include the runtime requirements, but generally there's > quite some overlap.) It also has easy access to the freshly built > binary and source RPMs. > > How difficult would it be to, at the end of the build process, install > the freshly built package, install rpmlint, and run rpmlint on the > source and any binary RPMs that were built? Sounds like a good idea. Why do we need to install the just-generated binary RPMs in the chroot? Can't we get the same info by just running rpmlint against the binary and source RPMs? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEt+abHyuj/+TTEp0RAvtPAJ4iHlPJFP2ofetHfwFGrSSKuv1wogCcDn2u 8Rv7tZiv3JZkXadh9+mK/Es= =/0dA -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
mock launcher changes checked into head of CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The branch for mock 0.6 has been cut and my modifications for the new launcher mechanism have been checked into the head of CVS (which is now at 0.7). Please pull the new stuff and beat on it. You'll need to clean up the links in /etc/mock, since there are no fedora-6-* config files yet. Sorry about that... I'm not completely sure I have things right wrt to uid/gid manipulations. I'd appreciate a critical eye being cast on that portion of the code. Michael, I stuffed the flock calls in, around the state file write. Just wanted to see what they'd do and I forgot when I did my check in. Easy enough to back out if we decide they're not needed. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoqsMHyuj/+TTEp0RAp4AAJ94Wu8doF5En6WUFjdfsM5RcAjw+wCdFYMz 8YbPBDQr2+mFyIiySKIJ2sY= =yEDy -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Sorry for the format of the posts today, forced to use stupid webmail which is slow and ugly. > > How about the old unix everything is a file concept? We could just have a --status_file parameter that could take a file or a named pipe as input, it would look the same to us, whether it was a pipe or a regular file. Either that, or we could even have a --status_fd parameter for people that might want to pre-open a file and pass it to us as an fd when they fork/exec. > > We might want to consider removing the open()/close() and instead just flush() it. We still shouldnt really need locking. I'd just as soon put the flock's around the write for explicitness's sake. It's an import of fcntl and then two calls to fcntl.flock()... Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEobgsHyuj/+TTEp0RAsztAJ9nezD09sNR0lyA/BBp3kFJHgji0ACg2utd j598GRugOIiLB/9iYBTWLCU= =X3dv -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Branch mock CVS today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Looks good to me. > -- > Michael It's done. There is now a mock-0-6-branch that we can use if we have to make any emergency fixes to the currently released mock. I'm getting ready to check in the launcher changes, which are src/mock.c and mods to src/Makefile, as well as changes to mock.py and the top level Makefile and spec file. I'll report to the list when it goes in. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoajnHyuj/+TTEp0RAuq7AJ9QlphOpkGswQkgjP4VKctrdao2ZQCbBOo2 ZXMC/PohrPIC4S8P2VmXqC0= =Alnb -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Williams wrote: > On Tue, 2006-06-27 at 11:15 -0500, Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Mike McLean wrote: >>> Clark Williams wrote: >>>> Not smart enough to argue that we should wait for our build >>>> system clients to weigh in. Sigh... >>>> >>>> Dan/Jeremy/Mike/Andreas/et al >>>> >>>> How are you going to use file locking? Do you just want mock >>>> to lock the status file when we're changing state, or is >>>> there something else I'm missing? >>> Pretty much. The lock is to prevent the watcher from reading a >>> partially written status file. >> Something like : >> >> flock(fileno, LOCK_EX) flock(fileno, LOCK_UN) >> >> That what you're looking for? > > In python: > > import fcntl lkfd = open(, 'w') rc = > fcntl.flock(lkfd, fcntl.LOCK_EX) > fcntl.flock(lkfd, fcntl.LOCK_UN) close(lkfd) > > Yes. > > Dan > What, you couldn't tell that was pseudo-python? :) Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoXbRHyuj/+TTEp0RAnUlAJ9HfAgDZP+teHPSeQNdNcCoAWcKuACgslBO aeOz/hsxMBY6afa7COrXu+I= =HiV2 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Branch mock CVS today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: > On Tue, 2006-06-27 at 12:07 -0500, Clark Williams wrote: >> I'm not wedded to the names or the methodology (that's just how we >> tend to manage branches in my group). > > My feeble brain has a hard time grasping a branch _from_ 0.6 named > mock-0-6-branch. Wouldn't we want to name it something that is post > 0.6? > I just look at it as a branch that began life at 0.6. I suppose it makes more sense as HEAD progresses on to other versions. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoWgRHyuj/+TTEp0RAtxGAKCAN+XUDnFZ8cnDxwRaLpCoiDWlUgCgry19 q71HfKa76eioA6ovs7EXNyg= =PZO+ -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Branch mock CVS today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't get any reply on my question about CVS manipulation, so I thought I'd start a new thread. The HEAD of mock's CVS tree is currently at v0.6. I'd like to branch that so that we have a safe point to drop back to, before we move to the new launcher, add some file locking or whatever we decide to do for reporting status, etc. To do that, I'm proposing the following in CVS: $ cvs co mock $ cd mock $ cvs tag mock-0-6-branchpoint $ cvs tag -r mock-0-6-branchpoint -b mock-0-6-branch Theoretically, this will create a static tag (the branchpoint tag) and then create a branch named mock-0-6-branch, based on the branchpoint tag. We can then do our wild-and-crazy checkins to head and know that we have a safe haven. I'm not wedded to the names or the methodology (that's just how we tend to manage branches in my group). If no one has any suggestions or objections, I'll branch later this afternoon (US Central time) and we can start putting the new code in and testing. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoWXXHyuj/+TTEp0RAsC8AKCY2nfmuuRtUyXzk01MxWJa6bcUYQCfdYn7 Wg7vMZFDutSFm2K5i+GYSAA= =FXyD -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike McLean wrote: > Clark Williams wrote: >> Not smart enough to argue that we should wait for our build system >> clients to weigh in. Sigh... >> >> Dan/Jeremy/Mike/Andreas/et al >> >> How are you going to use file locking? Do you just want mock to lock >> the status file when we're changing state, or is there something else >> I'm missing? > > Pretty much. The lock is to prevent the watcher from reading a > partially written status file. Something like : flock(fileno, LOCK_EX) flock(fileno, LOCK_UN) That what you're looking for? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoVmjHyuj/+TTEp0RAlGBAKDJNG/nSNZX0CGMLgWZjuXuVrwrmwCghKPn JcaPW7HZCR00+Q7Genx7luA= =IdtH -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 seth vidal wrote: > On Tue, 2006-06-27 at 10:13 -0500, Clark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jeremy Katz wrote: >>> On Tue, 2006-06-27 at 10:12 -0400, Dan Williams wrote: >>>> I hate to throw water on the fire, but to me XML-RPC seems like a >>>> sledgehammer. There's actually a ton of code in xmlrpclib.py and for >>>> this specific instance of pushing status information back to a >>>> controlling process, I think it's somewhat heavy-handed. >>> And I'll just pick this point in the thread to say that I agree with >>> dcbw here KISS goes a long way. And while we can say that it's >>> configurable and you enable it if you want or don't if not -- that's >>> then two code paths for status to have to keep working and ensure we >>> don't break as well as maintaining them for some time >>> >> So where were you guys when I was playing Horatius at the bridge? :) >> > > I'd like to take this opportunity to point to lesscode.org > > thanks, > -sv Thanks for that link. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoVjaHyuj/+TTEp0RAudxAJ49NekRv0HFiauK1OP7ya1+MQD0twCdHLS7 ymeHY1y8p9TE6179JYvhcjY= =Zums -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg DeKoenigsberg wrote: > On Tue, 27 Jun 2006, Clark Williams wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jeremy Katz wrote: >>> On Tue, 2006-06-27 at 10:12 -0400, Dan Williams wrote: >>>> I hate to throw water on the fire, but to me XML-RPC seems like a >>>> sledgehammer. There's actually a ton of code in xmlrpclib.py and for >>>> this specific instance of pushing status information back to a >>>> controlling process, I think it's somewhat heavy-handed. >>> And I'll just pick this point in the thread to say that I agree with >>> dcbw here KISS goes a long way. And while we can say that it's >>> configurable and you enable it if you want or don't if not -- that's >>> then two code paths for status to have to keep working and ensure we >>> don't break as well as maintaining them for some time >>> >> So where were you guys when I was playing Horatius at the bridge? :) > > They were letting you win the argument yourself, to prove how gosh-darned > smart you are, Clark. ;-) > Not smart enough to argue that we should wait for our build system clients to weigh in. Sigh... Dan/Jeremy/Mike/Andreas/et al How are you going to use file locking? Do you just want mock to lock the status file when we're changing state, or is there something else I'm missing? Clark P.S. Who let the marketing dweeb on this channel? :) Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoU7VHyuj/+TTEp0RAkrtAKDhdyQHZxmW+8ilshXePqcgJNGigACgtqgn fcPt8h7/oZ/Irw5Jv4mrNnI= =HYDS -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Katz wrote: > On Tue, 2006-06-27 at 10:12 -0400, Dan Williams wrote: >> I hate to throw water on the fire, but to me XML-RPC seems like a >> sledgehammer. There's actually a ton of code in xmlrpclib.py and for >> this specific instance of pushing status information back to a >> controlling process, I think it's somewhat heavy-handed. > > And I'll just pick this point in the thread to say that I agree with > dcbw here KISS goes a long way. And while we can say that it's > configurable and you enable it if you want or don't if not -- that's > then two code paths for status to have to keep working and ensure we > don't break as well as maintaining them for some time > So where were you guys when I was playing Horatius at the bridge? :) Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoUsnHyuj/+TTEp0RAq4XAKDMeKTgIn1TkGA1ikNq9CzETi054ACfZF8L t2OhL8a/aKJ1QmxHpTq8jA0= =qSJp -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Default config file contents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Default config file contents > > Discussion topic: > > With the recent changes to mock, several default config file options > have changed. I am of the opinion that we should provide a config > file with only the basic things that the user would like to change, > and leave the defaults in mock.py (with an option to dump the > config). For example, I believe we should take out the mount, > unmount, rm, chroot, etc from our default configs, as it is highly > unlikely that average users would change these. > > The reason for this proposed change is to make it easier to migrate > from one version to the next. As it is, mock 0.7 will not be able to > use %config(noreplace) on the config files, because too many things > changed. The user will have to manually merge any site-specific > changes. > > The final config file, I believe, should only contain the yum config > relating to repository locations, which the user is likely to want > to mirror for speed reasons. > > Comments? > I agree. Sounds like we'll end up with a file that only contains options that modify behavior, as opposed to basic utilities. Possibly the following: config_opts['basedir'] = '/var/lib/mock/' config_opts['chrootuser'] = 'mockbuild' config_opts['chrootgroup'] = 'mockbuild' config_opts['chroothome'] = '/builddir' config_opts['clean'] = True # caching related options config_opts['rebuild_cache'] = True config_opts['use_cache'] = True config_opts['cache_topdir'] = "root-cache" config_opts['max_cache_age_days'] = 15 My only addition would be to say that I'd really like a better name than "defaults.cfg", which is one letter removed from the symlink default.cfg, which is the default configuration file. I don't really have a preference, just something not so easily confused. Maybe "configuration.cfg" or something like that? Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoF3VHyuj/+TTEp0RAqMOAJ95OimI96dn9n2CCGIvBjfSab2tRwCgmsB3 pWCZFFCsumEx8Mjim1fG3Zg= =6ygx -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Clark Williams >> Sent: Monday, June 26, 2006 4:07 PM >> To: Discussion of Fedora build system >> Subject: Re: New version of mock working (I think) >> >> Ok, I can go with that. Probably the most convincing portion >> of the above argument is the idea of implementing a >> root-privilege server as opposed to pushing that back to the >> build system maintainers. >> >> So I suppose it means that we should publish a call-out >> specification that says: if you invoke mock with the >> --server-mumble=X on the command line, mock will use X as a >> URL to make an XML-RPC call with the state as an argument in >> form. We will then have to wrap >> that in a try/except and possibly some timeout logic to make >> sure that if the other end isn't speaking our language, we >> continue or fail in a controlled fashion. > > I have some stock timeout and exception handling code that we can cut > and paste in. It adds another 5-10 lines of code, and should make the > code robust against what you describe. > > First order of business would be to get Dan's opinion on the matter, > then settle on an API. I can code this up, along with a test harness. > -- > Michael I have some changes to mock.py that go with the new launcher philosophy that should probably go in at the same time. We probably want to tag and branch before we go off in this new direction. Shouldn't we do something like the following: $ cd mock $ cvs tag r0_6-branchpoint $ cvs tag -r r0_6-branchpoint -b r0_6-branch I believe that this creates a branchpoint, then creates a branchtag and leaves our head alone. We could then go merrily on our way with the new launcher and the XML-RPC stuff while leaving 0.6 safe and sound. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoFaLHyuj/+TTEp0RAsReAJ9OKB2DUQpw8zsKletz+qOW7wlZ2QCg3DGY GBHpYn6aEUOYp/Jy3i4SBSw= =Wxt5 -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Williams wrote: > On Fri, 2006-06-23 at 13:40 -0500, [EMAIL PROTECTED] wrote: >> Any chance we could get a better defined method of mock<->plague >> communication? Parsing output is bound to be fragile and hard to >> maintain. > > Yup. Quite right. And I've had problems in the past with the reads of > the file blocking (since you evidently can't do NONBLOCK on filesystem > file sockets or something either?) and hanging the plague-builder > process until more data gets written to the file. So as a quick hack > plague-builder will only read & match the first 4 characters of the > status string anyway. > > I'd rather not read the status file either. Any ideas that don't suck > would be greatly appreciated. > After being convinced that calling out with XML-RPC from mock wouldn't trigger a nuclear winter, I went back to read Dan's request and think about it in the context of making an XML-RPC to the build-server. If we presuppose that mock will make XML-RPC's to a URL supplied by the build system to indicate status changes, would it make sense to send the complete list of status's to the build system before we start? In other words, when we crank up, make an initial call to the status URL with "Here is the list of status values you can receive", maybe as a list of strings or a hash with descriptive text. This would give the build system a mechanism to quickly detect when it and mock are out-of-sync with respect to state changes (i.e. brew/plague could receive the state list and abort if it sees a state change it doesn't understand). Of course it can do that anyway, but that might be a long while into a glibc build before the build system sees an unknown state, as opposed to 3 seconds into startup. Just a thought. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoFAFHyuj/+TTEp0RAqn5AJ92YcCIj0fJcLpzhY6E7VfNWK7ohwCeKbKk bug2S0DNv892S46r/MKbkhg= =MkFS -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Clark Williams >> Sent: Monday, June 26, 2006 3:07 PM >> To: Discussion of Fedora build system >> Subject: Re: New version of mock working (I think) >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> [EMAIL PROTECTED] wrote: >>> Yes, feedback from Dan would be good. My initial thoughts >> are that a >>> client implementation would be best at this point, due to >> the security >>> implications of a server. Something where we call a server API >>> provided by plague like: >>> server.begin_mock_status( "my.src.rpm", MY_PID) >>> server.set_mock_status( "my.src.rpm", "status_string", MY_PID) >>> ... >>> server.end_mock_status( "my.src.rpm", return_code, MY_PID) >>> >> Ah, and you thought I really *meant* it when I said I'd shut up. Ha! >> >> Don't you think that a simple server where we just have a >> listen socket and respond to "what's your status?" would be >> more straight forward? > > I would like to foster discussion. It would be bad if one of the > co-maintainers failed to voice their concerns over project direction, so > no, I would hope that you never shut up. /me hopes everyone takes note of the above. Please don't construe my opposition to a proposal on the list as anything personal. It's just my opinions based on a couple of decades of programming experience. My programming philosophy will pretty much always boil down to: simpler is better. I can be talked around to solution that I initially oppose. I just need some encouragement :) > > My initial thoughts around this is that having an xmlrpc server exposes > too much of our (running with elevated privs) internals to random, > untrusted strangers. There has already been one reported vulnerability > in the python xmlrpc code. > > Both code-wise (7-10 lines for client, vs at least 20 for server), and > security-wise, I think a client would be 'simpler'. > > Also, adding a server entices future additions along the lines you > already said we don't want to go, and starts to supplant plague/brews > role. Ok, I can go with that. Probably the most convincing portion of the above argument is the idea of implementing a root-privilege server as opposed to pushing that back to the build system maintainers. So I suppose it means that we should publish a call-out specification that says: if you invoke mock with the --server-mumble=X on the command line, mock will use X as a URL to make an XML-RPC call with the state as an argument in form. We will then have to wrap that in a try/except and possibly some timeout logic to make sure that if the other end isn't speaking our language, we continue or fail in a controlled fashion. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoEyNHyuj/+TTEp0RAoToAJ9jNUmUqLkyxsAh0HoUNEu94lEq8wCffdIh YTkO7OshBbqn1eymgtrMP3c= =pl/z -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > > Yes, feedback from Dan would be good. My initial thoughts are that a > client implementation would be best at this point, due to the security > implications of a server. Something where we call a server API provided > by plague like: > server.begin_mock_status( "my.src.rpm", MY_PID) > server.set_mock_status( "my.src.rpm", "status_string", MY_PID) > ... > server.end_mock_status( "my.src.rpm", return_code, MY_PID) > Ah, and you thought I really *meant* it when I said I'd shut up. Ha! Don't you think that a simple server where we just have a listen socket and respond to "what's your status?" would be more straight forward? >> >> Just for 2cents, I'd like to make sure we don't forget the >> other use cases of mock: >> >> 1. in brew > > I don't know what brew is. Link? > I wasn't sure if brew used mock. It's the RHEL build system. Clark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoD5fHyuj/+TTEp0RAtqWAKC0ltOzM0+GBTb1Ss9GR23XHqVMUwCfdi/d uBGXAWEzercmDocQlYBwT1M= =lANN -END PGP SIGNATURE- -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
>>
>> Ugh. I get the feeling that this is a case of "Oooo shiny!".
>>
>> What benefit is it to mock to add either client or server RPC
>> capabilities so that someone can determine mock's state? Are
>> we talking about communicating something besides a string?
>> XML-RPC works GREAT as a marshaling/unmarshaling mechanism to
>> describe complex data structures. In this case however we're
>> talking about telling someone that we're in the "prep" state,
>> or in the "cache_unpack" state.
>>
>> If there is a wealth of information that we're not making
>> available to the outside world (i.e. distributed build
>> systems) then yeah, lets set up a series of remote procedure
>> calls and publish them; I'll gladly work on client/server
>> code in the mock codebase if it's justified. But if we're
>> only changing state and not allowing the outside world to
>> interact with us to change our behavior while building, then
>> let's keep it simple.
>
> It is simple, we can do an xmlrpc client in about 7 lines of code and
> add it to the status() function. Here are all the lines that I can think
> to add that would fully enable this:
>
> In setup_default_config_opts():
> config["status_server"] = None
>
> In command_parse():
> parser.add_option("--statusserver", action="store", type="string",
> dest="status_server",
>default=None, help="server to contact for status info.")
>
> In set_config_opts_per_cmdline():
> if options.status_server is not None: config["status_server"] =
> options.status_server
>
> In state():
> if self.config["status_server"]:
> import xmlrpclib
> server = xmlrpclib.Server(config["status_server"])
> server.set_mock_status(some_string)
>
> A server would probably take another 10-20 lines of code.
>
> An additional argument could probably be made for shared mem or a named
> pipe, but I havent coded those, so I don't know. As for simplicity,
> another file descriptor pre-opened by plague, or a named pipe passed via
> command line would probably be "simpler", but probably not in terms of
> lines of code.
> --
> Michael
I can see I'm on the losing end of this argument. My first suggestion
would have been to use mmap to map the status file, but re-reading
Dan's email, my guess is that's not significantly different from
reading the file. And on the plus side, we can pass structured data
using XML-RPC, so that might "suck less" :).
Let me just state two things and then I'll shut up on this issue:
1. I think that adding XML-RPC has great potential to be a Pandora's
Box, in terms of potential code bloat. We need to be on guard to
avoid the "Now that we have XML-RPC, let's add this feature!". Please
remember that the intent behind mock is to rebuild an SRPM inside a
chroot. Everything else is secondary.
2. We need to hear from Dan as to whether the likes the idea. My guess
is he will since plague already has XML-RPC elements.
Clark "Back in my day we didn't need fancy XML-RPCs! We had DCE!"
Williams
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEoDlfHyuj/+TTEp0RAjfhAKCeX6yfVFTudHZ9ox1JTU4vwLXGWgCggQbu
vOpb6nSP6QQJgK4jCd4tvk0=
=0Wvu
-END PGP SIGNATURE-
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New version of mock working (I think)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Clark Williams wrote:
> Enrico Scholz wrote:
>>> Why write complicated code, when same thing can be done
>>> shorter, faster and less error-prone?
>>>
>>>
> Hoist on my own petard. When it comes down to it, I'm all about
> less code. I'll go rework mock.c (the mock-helper replacement) and
> post a new one for further review.
In between whining about complexity, I modified the new launcher to
use stack instead of heap for the argument vector. Attached is the
source for the modified launcher, mock.c
Comments please.
Clark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEoDPgHyuj/+TTEp0RAouKAKDEH6y79paANJ9h6iIaTZZdnCmdRACgtcRI
40ONAAZz+eNuTo76nqIEOy0=
=jvIT
-END PGP SIGNATURE-
//
// mock.c - setuid program for launching mock.py
//
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU Library General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
//
// Copyright (c) 2006 - Clark Williams <[EMAIL PROTECTED]>
// portions lifted from mock-helper.c by Seth Vidal
// namespace idea courtesy Enrico Scholz <[EMAIL PROTECTED]>
//#define _GNU_SOURCE
#include "config.h"
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if 0
#ifdef USE_SELINUX
#include
#endif
#endif
#define PYTHON_PATH "/usr/bin/python"
#define MOCK_PATH "/usr/bin/mock.py"
static char const * const ALLOWED_ENV[] =
{
"dist",
"ftp_proxy",
"http_proxy",
"https_proxy",
"no_proxy",
"PS1",
};
#define ALLOWED_ENV_SIZE (sizeof (ALLOWED_ENV) / sizeof (ALLOWED_ENV[0]))
#define SAFE_PATH "PATH=/bin:/usr/bin:/usr/sbin"
#define SAFE_HOME "HOME=/root"
#define NSFLAG "NAMESPACE=1"
// Note that MAX_ENV_SIZE is allowed size, plus the ones we add plus a null entry
// so, if you add more variables, increase the constant below!
#define MAX_ENV_SIZE 4 + ALLOWED_ENV_SIZE
//
// helper functions
//
//
// print formatted string to stderr and terminate
//
void error (const char *format, ...)
{
va_list ap;
va_start (ap, format);
fprintf (stderr, "mock: error: ");
vfprintf (stderr, format, ap);
va_end (ap);
fprintf (stderr, "\n");
exit (1);
}
//
// debug print
//
static int debugging = 0;
void debug(const char *format, ...)
{
if (debugging) {
va_list ap;
va_start (ap, format);
fprintf (stderr, "DEBUG: ");
vfprintf (stderr, format, ap);
va_end (ap);
}
}
///
//
// main logic
//
//
int main (int argc, char **argv)
{
char * env[MAX_ENV_SIZE+1] = {
[0] = SAFE_PATH,
[1] = SAFE_HOME,
[2] = NSFLAG,
};
char **newargv;
int newargc, newargvsz;
int i, idx = 2;
int status;
pid_t pid;
if (getenv("MOCKDEBUG"))
debugging = 1;
// copy in allowed environment variables to our environment
debug("copying envionment\n");
for (i = 0; i < ALLOWED_ENV_SIZE; ++i) {
char *ptr = getenv (ALLOWED_ENV[i]);
if (ptr==0) continue;
ptr -= strlen (ALLOWED_ENV[i]) + 1;
env[idx++] = ptr;
}
assert(idx <= MAX_ENV_SIZE);
env[idx] = NULL;
// set up a new argv/argc
// new argv[0] will be "/usr/bin/python"
// new argv[1] will be "/usr/bin/mock.py"
// remainder of new argv will be old argv[1:n]
// allocate one extra for null at end
newargc = argc + 1;
newargvsz = sizeof(char *) * (newargc + 1);
newargv = alloca(newargvsz);
newargv[0] = PYTHON_PATH;
debug("argv[0] = %s\n", newargv[0]);
newargv[1] = MOCK_PATH;
debug("argv[1] = %s\n", newargv[1]);
for (i = 1; i < argc; i++) {
newargv[i+1] = argv[i];
debug("argv[%d] = %s\n", i+1, newargv[i+1]);
}
newargv[newargc] = NULL;
// clone a new process with a separate namespace
// Note: we have to use syscall here, since we want the
// raw system call 'clone', not the glibc library wrapper
// Also note: The SIGCHLD or'ed into the flags argument. If you
// don't specify an exit signal, the child is detached and waitpid
// won't work (h
