-----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
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...)
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 (:
-----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
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.
-----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
On 8/16/06, Clark Williams williams@redhat.com 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.
-Chris
"CW" == Chris Weyl cweyl@alumni.drew.edu writes:
CW> A while ago and on a different list, tibbs proposed adding one CW> last bit to the buildcycle:
Actually I think it was this list.
Honestly I don't think this needs to be in mock, but mock really needs to continue to give me the means to do that kind of thing. I already have this running just fine with no mock modifications (with the caveat that I can't figure out how to do this full process on an x86_64 when building an i386 package).
- J<
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Weyl wrote:
On 8/16/06, Clark Williams williams@redhat.com 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 <config> SRPM $ mock --no-clean -r <config> install rpmlint $ mock --no-clean -r <config> install <generated-pkgs> $ mock --no-clean -r <config> chroot rpmlint <pkgnames>
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
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 ?
-----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
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.
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 :-)
-----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 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 <path to rpm>'.
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
On Sun, 2006-09-03 at 16:56 -0500, Clark Williams wrote:
-----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 <path to rpm>'.
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).
yes, it works. You might want to check where it expects to find the rpm when using an installroot ie: does it find it in /path/to/rpm or installroot/path/to/rpm.
I don't remember which at this moment.
-sv
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<tab><tab> and get hits for both mock and mock.py and become confused as to which you're actually supposed to use
Jeremy
On Sun, 03 Sep 2006 16:56:40 -0500, Clark Williams wrote:
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.
Yes, I think we'll need yum.
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.
Exactly.
Cheers, Christian
-----Original Message----- From: fedora-buildsys-list-bounces@redhat.com [mailto:fedora-buildsys-list-bounces@redhat.com] 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<tab><tab> 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
Jeremy
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael_E_Brown@Dell.com wrote:
-----Original Message----- From: fedora-buildsys-list-bounces@redhat.com [mailto:fedora-buildsys-list-bounces@redhat.com] 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<tab><tab> 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
On Wednesday 06 September 2006 10:39, Clark Williams wrote:
I think I like /usr/libexec/mock.py.
Will that be acceptable to everyone?
WORKSFORME
buildsys@lists.fedoraproject.org
-
Chris Weyl -
Christian Iseli -
Clark Williams -
Jason L Tibbitts III -
Jeremy Katz -
Jesse Keating -
Michael E Brown -
seth vidal