Hi all,
i've made a patch that extends mock-helper for the two new internal commands 'save' and 'restore' for use with the new added script /usr/libexec/mock-cache-copy that generates a root cache, which is linked against the root tree and which is copied statically. This takes the double harddisk space of the root tree (buildsys-build install) but hard disks are big enough today.
The advantage of this is that the files in the cache are hard-linked to the files in the mock root tree that makes it extremely fast to delete files (mock clean phase) and to relink them (copy -ax ... on mock init phase) while unpacking the cache. The static copy is used to repair touched and modified (linked) files with rsync.
With this new option 'mock init' takes only 5 Seconds (between Enter press and shell prompt).
The source package (with the patch included) can be found on the Beuth repo at: http://141.64.26.2/repo/bs/el5/SRPMS/mock-0.6.13-5.bs.el5.src.rpm
Especially my old PowerBook G4 / 400 MHz PowerPC (running C-5 ppc edition) benefits of this feature (keeps the CPU away from tar and gzip and uses the slow harddisk efficiently).
I hope this useful patch find a way to upstream (Fedora). Please give me feedback and comparing benchmarks (against mock's standard cache). ( The global config /etc/mock/defaults.cfg is set up for using the additional caching method).
cheers,
B.S.
Am Dienstag, den 27.10.2009, 01:24 +0100 schrieb Brian Schueler:
Hi all,
i've made a patch that extends mock-helper for the two new internal commands 'save' and 'restore' for use with the new added script /usr/libexec/mock-cache-copy that generates a root cache, which is linked against the root tree and which is copied statically. This takes the double harddisk space of the root tree (buildsys-build install) but hard disks are big enough today.
Cool thing, my idea was to use an lvm and snapshots, that could be even faster but noone wants to code that it seems ;) Did you send your patch upstream?
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
No, I didn't.
The Upstream Vendor has already switched to Koji and it makes no sense to feed a full-blown software with a long rat tail of another software that will blast my embedded machines (which also uses mock for building software native (a lot of packages needs that)).
CentOS is still using mock I see and this is a really good tool. I'm also going to make it work for Minix-3 (and also RPM and rpmbuild). So I have to deal with Python, again. It seems that apt-get support wants also to get in ...
regards,
Brian
Am Dienstag, den 27.10.2009, 23:49 +0100 schrieb Brian Schueler:
No, I didn't.
The Upstream Vendor has already switched to Koji and it makes no sense to feed a full-blown software with a long rat tail of another software that will blast my embedded machines (which also uses mock for building software native (a lot of packages needs that)).
Koji is not a mock replacement and afaik koji still uses mock for the actual build process, and will continue to do so.
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
but what about the big database it carries around? Maybe el6 will be "kojied" rather than "mocked". The koji infrastructure is too overweight for my little pieces.
Am Mittwoch, den 28.10.2009, 00:20 +0100 schrieb Brian Schueler:
but what about the big database it carries around? Maybe el6 will be "kojied" rather than "mocked". The koji infrastructure is too overweight for my little pieces.
I think we are talking about different things. I mean take your mock patches upstream to the mock team https://fedoraproject.org/wiki/Projects/Mock. Koji is a totally different story wich just uses mock.
Btw we met at linuxtag.
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
On 10/27/2009 11:20 PM, Brian Schueler wrote:
but what about the big database it carries around? Maybe el6 will be "kojied" rather than "mocked". The koji infrastructure is too overweight for my little pieces.
At the moment, not in CentOS-6. The problem I have now is that quite a lot of the buildsystem state and policy is static to the machines its running on and plague is just a wrapper around the real scripts. It would be trivial to use something like rabitmq and actually completely lose the plague setup around the buildsystem. something that is very much on the cards. Its just a case of working out who is going to do the stuff and how and what the scope of something like this might be.
However, the base common denominator is still mock and I dont see that changing in the near future. Also, while we still support and work with CentOS-3, its quite nice to see us support it. Is there anything in mock-0.9 that results in a build output that is different from the one that mock-0.6.x is able to produce ?
- KB
Koji is not a mock replacement and afaik koji still uses mock for the actual build process, and will continue to do so.
Koji only makes sense if you have some more machines to setup and a larger group to work with. Otherwise mock is much faster to use and tweak.
btw: It is great to have to "how to build CentOS" wiki more active and actually collecting additional tools to use.
regards,
Florian La Roche
On 10/27/2009 09:59 AM, Christoph Maser wrote:
Cool thing, my idea was to use an lvm and snapshots, that could be even faster but noone wants to code that it seems ;)
you can perhaps just script around mock to do the snapshots after an init. Just remember to keep plenty of COW space for the snapshot so it survives a large build run :)
Brian Schueler wrote:
Especially my old PowerBook G4 / 400 MHz PowerPC (running C-5 ppc edition)
Hmm, i think you really want to join the SIG (we need to create one for that though) for the CentOS PPC/PPC64 arch ... I'm still building RPMforge PPC RPMS on an old G4 400Mhz too (with mock on top of FC6) and i have a replacement machine that i'd love to use for that (waiting for c5 PPC to appear) : a macmini G4 1200Mhz / 1Gb ram. I actually use the autocache feature and that's not a big problem here .. but maybe (surely) faster with your patch ..
Yes, my starting point was also Fedora Core 6 ppc and it grew to CentOS 5.2 . On the LinuxTag 2009 I was also there at the CentOS booth with my PowerBook G4 ( http://picasaweb.google.com/ribalba/LinuxTag09#5350925153100143234 ) If you want to continue CentOS/ppc with your faster machine - it's cool so I can focus ARMv5T which is harder to port - because there are patches to be made (or to be taken from fedora-arm).
My mobile phone and a NSLU2 really run CentOS/ARM (where only a quarter of the packages are CentOS - the rest is still Fedora). Now I got a SheevaPlug development kit with a 1.2 GHz ARM9 (Marvell). For (cross) debugging I use JTAG in conjunction with a cross-toolchain and OpenOCD (urjtag and openocd packages are also on the Beuth Repository (see top message)). The sources for the cross compilers begins with noarch-novendor-nosystem-* and are only available as SRPMS because they have to be controlled with definitions (see .spec files).
The CentOS ports are not ready for productive environments so they mustn't have an 'Enterprise' in its name for now.
On Wed, Oct 28, 2009 at 12:14:40AM +0100, Brian Schueler wrote:
If you want to continue CentOS/ppc with your faster machine - it's cool so I can focus ARMv5T which is harder to port - because there are patches to be made (or to be taken from fedora-arm).
My mobile phone and a NSLU2 really run CentOS/ARM (where only a quarter of the packages are CentOS - the rest is still Fedora). Now I got a SheevaPlug development kit with a 1.2 GHz ARM9 (Marvell).
I'm interested in a version of CentOS for ARM also. FWIW, I did the original FC6/ARM (eabi) port, and admin the Fedora/ARM builder farm -- I'm sure we can dedicate some cycles to building CentOS/ARM packages as well.
Brian Schueler napsal(a):
Hi all,
i've made a patch that extends mock-helper for the two new internal commands 'save' and 'restore' for use with the new added script /usr/libexec/mock-cache-copy that generates a root cache, which is linked against the root tree and which is copied statically. This takes the double harddisk space of the root tree (buildsys-build install) but hard disks are big enough today.
Hi Brian, nice shot. Why didn't you patched 0.9.x tree which is significantly faster to 0.6.x? Thanks, David Hrbáč
Mock 0.6.13 came out about when CentOS 5.1 was released. Sorry that I slept newer releases - (that sounds for me "why do you not developing for rawhide?")
Okay I will feet it into 0.9.x and also hope to increase its performance.
On 10/27/2009 11:32 PM, Brian Schueler wrote:
Mock 0.6.13 came out about when CentOS 5.1 was released. Sorry that I slept newer releases - (that sounds for me "why do you not developing for rawhide?")
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
Were not fedora, and were not upstream for mock either. So keep that in mind.
- KB
Am Mittwoch, den 28.10.2009, 10:50 +0100 schrieb Karanbir Singh:
On 10/27/2009 11:32 PM, Brian Schueler wrote:
Mock 0.6.13 came out about when CentOS 5.1 was released. Sorry that I slept newer releases - (that sounds for me "why do you not developing for rawhide?")
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
Were not fedora, and were not upstream for mock either. So keep that in mind.
- KB
That was not my point of asking. I just wanted his patch to go into upstream for future releases too.
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
Karanbir Singh napsal(a):
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
Mock 0.9.x works pretty well on Centos and with Centos... David Hrbáč
On 10/28/2009 12:11 PM, David Hrbáč wrote:
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
Mock 0.9.x works pretty well on Centos and with Centos...
what ver of python / yum does it need to work with ?
- KB
Karanbir Singh wrote:
On 10/28/2009 12:11 PM, David Hrbáč wrote:
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
Mock 0.9.x works pretty well on Centos and with Centos...
what ver of python / yum does it need to work with ?
I just pull the mock from epel and use it on a stock COS5 box. There are some dependencies but they can all be satisfied by epel as well.
[slords@b64-5 mock]$ rpm -q mock python yum mock-0.9.14-2.el5 python-2.4.3-27.el5 yum-3.2.22-20.el5.centos
-Shad
On 10/28/2009 02:32 PM, Shad L. Lords wrote:
I just pull the mock from epel and use it on a stock COS5 box. There are some dependencies but they can all be satisfied by epel as well.
[slords@b64-5 mock]$ rpm -q mock python yum mock-0.9.14-2.el5 python-2.4.3-27.el5 yum-3.2.22-20.el5.centos
how about on CentOS-3 ?
- KB
Karanbir Singh wrote:
On 10/28/2009 02:32 PM, Shad L. Lords wrote:
I just pull the mock from epel and use it on a stock COS5 box. There are some dependencies but they can all be satisfied by epel as well.
[slords@b64-5 mock]$ rpm -q mock python yum mock-0.9.14-2.el5 python-2.4.3-27.el5 yum-3.2.22-20.el5.centos
how about on CentOS-3 ?
Why would you need to run it on cos3? You just need to create a config file that populates a cos3 build env.
-Shad
On 10/28/2009 03:31 PM, Shad L. Lords wrote:
Why would you need to run it on cos3? You just need to create a config file that populates a cos3 build env.
we have buildservers running across c3/c4/c5 - and I know atleast a couple of people who are in the same situation.
- KB
On Wed, Oct 28, 2009 at 5:55 PM, Karanbir Singh mail-lists@karan.org wrote:
On 10/28/2009 03:31 PM, Shad L. Lords wrote:
Why would you need to run it on cos3? You just need to create a config file that populates a cos3 build env.
we have buildservers running across c3/c4/c5 - and I know atleast a couple of people who are in the same situation.
imho the buildserver should have to be very minimal basic setup and in this case updating the buildserver to the latest centos version is recommended. but if you still like to run c3 on it you can still run 0.9 on c5 servers and the resulted rpms should have to be identical.
On 10/28/2009 05:26 PM, Farkas Levente wrote:
imho the buildserver should have to be very minimal basic setup
that is just noise. I'd really like to hear you argue package policy on the hosted buildserver that does chrooted builds for the same arch it runs as native.
in some corner cases, one might find socket overlap issues, but I'm unaware of anything like that on the centos tree.
- KB
Farkas Levente napsal(a):
imho the buildserver should have to be very minimal basic setup and in this case updating the buildserver to the latest centos version is recommended. but if you still like to run c3 on it you can still run 0.9 on c5 servers and the resulted rpms should have to be identical.
I do so with our building production. I have migrated everything to C5.x with mock 0.9. I see no point in running C3 as build host. We are also running all build hosts as vmware virtuals and C5 behaves better on VI than C3. David Hrbáč
On Wed, Oct 28, 2009 at 10:50 AM, Karanbir Singh mail-lists@karan.org wrote:
On 10/27/2009 11:32 PM, Brian Schueler wrote:
Mock 0.6.13 came out about when CentOS 5.1 was released. Sorry that I slept newer releases - (that sounds for me "why do you not developing for rawhide?")
yes, and 0.6.x is the only one we 'officially' support for CentOS3/4/5 - none of the other newer releases work for and with CentOS - so keep that in mind.
this is not true. we use mock 0.9 for all of our rebuild and mock 0.9 work perfectly for us what's more it's faster the 0.6.
On Wed, 28 Oct 2009, David Hrbáč wrote:
Farkas Levente napsal(a):
this is not true. we use mock 0.9 for all of our rebuild and mock 0.9 work perfectly for us what's more it's faster the 0.6.
Right, it's much faster...
I've been following this discussion for a while. If there are items you want to get into upstream mock you should post them to the list where mock's upstream is:
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
this list covers mock and koji.
-sv
On 10/27/2009 12:24 AM, Brian Schueler wrote:
The source package (with the patch included) can be found on the Beuth repo at: http://141.64.26.2/repo/bs/el5/SRPMS/mock-0.6.13-5.bs.el5.src.rpm
if you post just the patch against the mock src.rpm, we can include that and get a testing package into c5-testing.
I can see there is quite a lot of use for this on some platforms. But I quite like the fact that having zero state residue between builds is a high value point for mock at the moment.
- KB
The patch is 'mock-cp_al.patch' and applies to mock-0.6.13. I have no place at CentOS to drop packages in. On RPMforge I have (/had) svn access, but this build infrastructure relies on valid URLs in the source lines in the .specs and I don't had the change to put own software tarballs (like Player/ Stage) or (old) software with broken links.
And as you see, the real URL in the mock 0.6.13.x-spec is no longer valid, so RPMforge wouldn't build it for me except I change the URL to point to the tarball that I can put onto the Beuth http server - but this is not the idea behind the source line(s).
wget http://fedoraproject.org/projects/mock/releases/mock-0.6.13.tar.gz --2009-10-28 15:22:40-- http://fedoraproject.org/projects/mock/releases/mock-0.6.13.tar.gz Resolving fedoraproject.org... 209.132.176.122, 152.46.7.221, 66.35.62.162, ... Connecting to fedoraproject.org|209.132.176.122|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-10-28 15:22:42 ERROR 404: Not Found.
Brian Schueler wrote:
The patch is 'mock-cp_al.patch' and applies to mock-0.6.13.
The problem with linking files inside the chroot with files in a "base" copy is there are a few programs that will modify a file directly. If this happens you will modify the "base" file and taint your original copy.
-Shad
Therefore is the second copy named 'clean-cache-copy', which repairs the tainted files. The clean-cache-copy is _not_ linked and represent the original root cache. rsync syncs it to the 'linked-cache-copy' and ensures that the content is always the same before each mock build.
Brian Schueler wrote:
Therefore is the second copy named 'clean-cache-copy', which repairs the tainted files. The clean-cache-copy is _not_ linked and represent the original root cache. rsync syncs it to the 'linked-cache-copy' and ensures that the content is always the same before each mock build.
And do all mock builds link against this copy? What happens if you have 3-4 builds going on at the same time? Are there any files that would be linked between chroots? (If all the chroots link to linked-cache-copy then the answer would be yes)
If you are just making a copy for each chroot then that isn't really any different then just modifying existing behavior but removing the gzip on the tarball
-Shad
On Oct 28, 2009, at 1:34 PM, Shad L. Lords wrote:
Brian Schueler wrote:
Therefore is the second copy named 'clean-cache-copy', which repairs the tainted files. The clean-cache-copy is _not_ linked and represent the original root cache. rsync syncs it to the 'linked-cache-copy' and ensures that the content is always the same before each mock build.
And do all mock builds link against this copy? What happens if you have 3-4 builds going on at the same time? Are there any files that would be linked between chroots? (If all the chroots link to linked-cache-copy then the answer would be yes)
If 3-4 builds are going on simultaneously, then the issue is "minimal suffcient" install to support all 3-4 builds, not anything to do with hard links.
I would claim (but will not argue) that any build that is affected by having more than the "minimal sufficient" set of packages installed is broken for other reasons.
If you are just making a copy for each chroot then that isn't really any different then just modifying existing behavior but removing the gzip on the tarball
Yes. Exactly. Hard links are just less costly than gunzip on a tarball.
And any package that changes a hard-linked file (your other msg) is broken for reasons that have nothing to do with whether hard links were used to populate a build system. Use chattr(8) after doing the hard links if you are worried about contamination. But some build, not the hard linking, is what was broken if pollution occurs. But yes, contamination of a stateful store also needs to be worried about.
hth
73 de Jeff
No, the caches don't overlap - they are strictly separated for each configuration: /var/lib/mock/root-cache/<config_root>/{clean,linked}-cache-copy So you can have builds simultaneously (i.e C-4, C-5 and FC-8).
And yes, linking is much faster then copying or extracting an uncompressed tarball.
The only cost of the system is only linking and replacing dirty linked files with rsync that may be changed from previous build operations.
Please keep in mind, that the link count of the base files in the build root are only decreased instead of the files are deleted when a 'mock clean' is made. So not only the restore from cache operation is faster, also the cleaning one is.
-
Brian Schueler -
Christoph Maser -
David Hrbáč -
Fabian Arrotin -
Farkas Levente -
Florian La Roche -
Jeff Johnson -
Karanbir Singh -
Lennert Buytenhek -
Seth Vidal -
Shad L. Lords