Hi,
Been recently more and more tempted to use mock for building rpms, but looking at it I have one problem. As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
Cheers!
-- Nux! www.nux.ro
On Thu, Dec 30, 2010 at 8:51 AM, nux@li.nux.ro wrote:
Hi,
Been recently more and more tempted to use mock for building rpms, but looking at it I have one problem. As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
You can use rpmbuild -bs --nodeps to build the SRPM without the dependency checking. The SRPM is just a compilation of the spec, source code, and patches.
Ryan
Ryan Wagoner writes:
On Thu, Dec 30, 2010 at 8:51 AM, nux@li.nux.ro wrote:
Hi,
Been recently more and more tempted to use mock for building rpms, but looking at it I have one problem. As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
You can use rpmbuild -bs --nodeps to build the SRPM without the dependency checking. The SRPM is just a compilation of the spec, source code, and patches.
Ryan
Great tip, Ryan! Thank you.
On Thursday 30 Dec 2010 14:11:20 Ryan Wagoner wrote:
On Thu, Dec 30, 2010 at 8:51 AM, nux@li.nux.ro wrote:
Hi,
Been recently more and more tempted to use mock for building rpms, but looking at it I have one problem. As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
You can use rpmbuild -bs --nodeps to build the SRPM without the dependency checking. The SRPM is just a compilation of the spec, source code, and patches.
Actually, mock can build an SRPM from spec file and dir with sources:
$ mock --buildsrpm --spec=/path/to/spec --source=/path/to/src/dir
I've been using it at least since 1.0.5, which is definitely in EPEL, not sure if it was available in older versions. Sure it may require some scripting around it to automate it but it has the advantage of verifying build depends, etc. so it's worth it IMO.
Michael Gliwinski writes:
Actually, mock can build an SRPM from spec file and dir with sources:
$ mock --buildsrpm --spec=/path/to/spec --source=/path/to/src/dir
I've been using it at least since 1.0.5, which is definitely in EPEL, not sure if it was available in older versions. Sure it may require some scripting around it to automate it but it has the advantage of verifying build depends, etc. so it's worth it IMO.
Cheers for that!
-- Nux! www.nux.ro
On Tue, Jan 4, 2011 at 4:00 PM, nux@li.nux.ro wrote:
Michael Gliwinski writes:
Actually, mock can build an SRPM from spec file and dir with sources:
$ mock --buildsrpm --spec=/path/to/spec --source=/path/to/src/dir
I've been using it at least since 1.0.5, which is definitely in EPEL, not sure if it was available in older versions. Sure it may require some scripting around it to automate it but it has the advantage of verifying build depends, etc. so it's worth it IMO.
Cheers for that!
I wonder if it would help with the "nosrc.rpm" packages for JPackage?
On Wednesday 05 Jan 2011 00:18:36 Nico Kadel-Garcia wrote:
On Tue, Jan 4, 2011 at 4:00 PM, nux@li.nux.ro wrote:
Michael Gliwinski writes:
Actually, mock can build an SRPM from spec file and dir with sources:
$ mock --buildsrpm --spec=/path/to/spec --source=/path/to/src/dir
I've been using it at least since 1.0.5, which is definitely in EPEL, not sure if it was available in older versions. Sure it may require some scripting around it to automate it but it has the advantage of verifying build depends, etc. so it's worth it IMO.
Cheers for that!
I wonder if it would help with the "nosrc.rpm" packages for JPackage?
It does, sort of ;) Before openjdk I was building nosrc.rpm for Java from JPackage using this method, but IIRC it requires some manual mocking about (sth like init mock buildroot, download files required by the nosrc.rpm (e.g. the Java distributable for Java) into some specific directory in the buildroot, then continue the build).
Hi,
On Thu, 2010-12-30 at 13:51 +0000, nux@li.nux.ro wrote:
As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
Since CentOS is an rpm based system you will almost always be rebuilding from srpms and *not* from plain tar balls. Repos catering for RHEL/CentOS/Fedora provide srpms by default.
However, if you want to make your own (s)rpms or patch existing ones you will indeed need a "classical" build environment to do so. And since there are a couple of packages that mock will not build you will need a fallback build environment for such cases.
Regards, Leonard.
On Thu, Dec 30, 2010 at 9:45 AM, Leonard den Ottolander leonard@den.ottolander.nl wrote:
Hi,
On Thu, 2010-12-30 at 13:51 +0000, nux@li.nux.ro wrote:
As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
Since CentOS is an rpm based system you will almost always be rebuilding from srpms and *not* from plain tar balls. Repos catering for RHEL/CentOS/Fedora provide srpms by default.
However, if you want to make your own (s)rpms or patch existing ones you will indeed need a "classical" build environment to do so. And since there are a couple of packages that mock will not build you will need a fallback build environment for such cases.
Regards, Leonard.
You can do it inside the mock chroot cage. I do, on occasion. The difficult is that I find myself wanting things like emacs to edit code and patches, RCS to manage versions of my new .spec files, and unpredictable dependencies as I wrote the code.
If necessary, I use one text window (with Alt-F2) to run "mock --shell" and get that working shell window, and another window (with Alt-F3) to drop other RPM's into /var/lib/mock/[whatever]/root/tmp/ and be able to install them in the other windows. But I'm a complete weasel.
I also use the 'mock' from 'epel-testing', which has some very useful features not in the version of mock from CentOS 5.
On Sun, Jan 2, 2011 at 4:00 AM, Nico Kadel-Garcia wrote:
You can do it inside the mock chroot cage. I do, on occasion. The difficult is that I find myself wanting things like emacs to edit code and patches, RCS to manage versions of my new .spec files, and unpredictable dependencies as I wrote the code.
If necessary, I use one text window (with Alt-F2) to run "mock --shell" and get that working shell window, and another window (with Alt-F3) to drop other RPM's into /var/lib/mock/[whatever]/root/tmp/ and be able to install them in the other windows. But I'm a complete weasel.
I also use the 'mock' from 'epel-testing', which has some very useful features not in the version of mock from CentOS 5. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks Nico. I ended up building the srpms outside mock as it was just too much hassle. What are the advantages in using mock from epel-testing?
Regards,
Lucian
On Sun, Jan 2, 2011 at 12:48 AM, Lucian lucian@lastdot.org wrote:
On Sun, Jan 2, 2011 at 4:00 AM, Nico Kadel-Garcia wrote:
You can do it inside the mock chroot cage. I do, on occasion. The difficult is that I find myself wanting things like emacs to edit code and patches, RCS to manage versions of my new .spec files, and unpredictable dependencies as I wrote the code.
If necessary, I use one text window (with Alt-F2) to run "mock --shell" and get that working shell window, and another window (with Alt-F3) to drop other RPM's into /var/lib/mock/[whatever]/root/tmp/ and be able to install them in the other windows. But I'm a complete weasel.
I also use the 'mock' from 'epel-testing', which has some very useful features not in the version of mock from CentOS 5. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks Nico. I ended up building the srpms outside mock as it was just too much hassle. What are the advantages in using mock from epel-testing?
Regards,
Lucian
Better behavior with extensive autofs tables. (Older mock, in my experience, gets very confused and starts force unmounting direct automount targets in the midst of processing, which is *nasty* and disables my home directory in my fairly odd setup.) Also, the 'lastlog' tables and other sparse files make for *much* too large of cache.tar.gz files. See this bug (https://bugzilla.redhat.com/show_bug.cgi?id=633435)
On Sun, Jan 2, 2011 at 1:03 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Better behavior with extensive autofs tables. (Older mock, in my experience, gets very confused and starts force unmounting direct automount targets in the midst of processing, which is *nasty* and disables my home directory in my fairly odd setup.) Also, the 'lastlog' tables and other sparse files make for *much* too large of cache.tar.gz files. See this bug (https://bugzilla.redhat.com/show_bug.cgi?id=633435)
Interesting, maybe I will give the testing version a shot. Thanks.
On Sun, Jan 2, 2011 at 3:18 PM, Lucian lucian@lastdot.org wrote:
On Sun, Jan 2, 2011 at 1:03 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Better behavior with extensive autofs tables. (Older mock, in my experience, gets very confused and starts force unmounting direct automount targets in the midst of processing, which is *nasty* and disables my home directory in my fairly odd setup.) Also, the 'lastlog' tables and other sparse files make for *much* too large of cache.tar.gz files. See this bug (https://bugzilla.redhat.com/show_bug.cgi?id=633435)
Interesting, maybe I will give the testing version a shot. Thanks.
I'd love to see it backported to CentOS 'extras' or 'build' setups. It's a better tool and supports more releases, including hooks now for CentOS 6 when it is published. (The hooks assume that CentOS 6 will live in the same location as CentOS 5, just a different '%releasever'.
On Sun, 2011-01-02 at 22:14 -0500, Nico Kadel-Garcia wrote:
I'd love to see it backported to CentOS 'extras' or 'build' setups. It's a better tool and supports more releases, including hooks now for CentOS 6 when it is published. (The hooks assume that CentOS 6 will live in the same location as CentOS 5, just a different '%releasever'.
Which Version Number? There are a few of them already patched from F12 to Rawhide. No I do not have anything to do with CentOS Extras but I have the currious mind.
John
On Mon, Jan 3, 2011 at 12:13 AM, JohnS jses27@gmail.com wrote:
On Sun, 2011-01-02 at 22:14 -0500, Nico Kadel-Garcia wrote:
I'd love to see it backported to CentOS 'extras' or 'build' setups. It's a better tool and supports more releases, including hooks now for CentOS 6 when it is published. (The hooks assume that CentOS 6 will live in the same location as CentOS 5, just a different '%releasever'.
Which Version Number? There are a few of them already patched from F12 to Rawhide. No I do not have anything to do with CentOS Extras but I have the currious mind.
I'm using the mock-1.0.14 from "epel-testing", that has all the relevant patches.
On Mon, 2011-01-03 at 00:20 -0500, Nico Kadel-Garcia wrote:
Which Version Number? There are a few of them already patched from F12 to Rawhide. No I do not have anything to do with CentOS Extras but I have the currious mind.
I'm using the mock-1.0.14 from "epel-testing", that has all the relevant patches.
Of which it has been in testing since September which would make me a little weary of it. One thing from looking at the bug report no one is giving any feedback on it. Any way I guess this does not answer the n00b mock ? ?
John
On Mon, Jan 3, 2011 at 2:11 AM, JohnS jses27@gmail.com wrote:
On Mon, 2011-01-03 at 00:20 -0500, Nico Kadel-Garcia wrote:
Which Version Number? There are a few of them already patched from F12 to Rawhide. No I do not have anything to do with CentOS Extras but I have the currious mind.
I'm using the mock-1.0.14 from "epel-testing", that has all the relevant patches.
Of which it has been in testing since September which would make me a little weary of it. One thing from looking at the bug report no one is giving any feedback on it. Any way I guess this does not answer the n00b mock ? ?
John
I think they're busy campers with RHEL 6 integration and integration with a *lot* of utilities that RHEL selected not to include. It looks like it's not that high a priority for EPEL release engineers right now, but I really recommend it.
On 12/30/2010 05:51 AM, nux@li.nux.ro wrote:
Been recently more and more tempted to use mock for building rpms, but looking at it I have one problem. As far as I could read about it, mock essentially rebuilds srpms so to use it I would need a separate "classical" build environment to create those srpms in the first place. Am I right or did I get something terribly wrong?
You can always use "mock --shell" to use the mock environment as your interactive build environment.
-
Gordon Messmer -
JohnS -
Leonard den Ottolander -
Lucian -
Michael Gliwinski -
Nico Kadel-Garcia -
nux＠li.nux.ro -
Ryan Wagoner