Hi Mark, mock is a wrapper around rpmbuild. basically it'll create a chroot to build in, populate that with all the build dependencies needed for the build at hand and then run rpmbuild in there.
What I like about it is that it is a repeatable process. sometimes RPMS build differently if extra things are installed. hmm this is not a clear sentence, let's go for an example: Suppose a piece of software that could do something useful with LDAP, but LDAP is not mandatory for the working of the software. The developers of the software made a test in the configure stage, if LDAP present, include that in this build, if not not. bottom line is here that the result of your rpm building might differ if you had LDAP installed or not. downside of mock is that for every build it first destroys the chroot, unpacks a clean one and installs dependencies. All-in-all, this takes 30-60 seconds for every rpm you want to build. For the 'simpler' RPMS, I guess that the majority of the time is used in this stage. (same goes for most of the failures) koji is (as far as I understand) a workflow tool with a webfrontend, which uses mock to do actual builds. If you look at the links Bjarne sent, I'm sure you'll understand what it does. looking at the numbers you mention for EPEL, I hope you're not rebuilding things that are already in our EPEL7. about 64bit things: well, CentOS already got an aarch64 build. I don't think anyone feels the urge to repeat that effort, just to put another nametag on it. (same for armv7) Jacco On 04/09/2016 08:40 AM, Mark Campbell wrote: > So I'm a few days behind on reading my email, so I only just now saw > these replies. However, I did some research, and I started with a Centos > wiki page that told me to use rpmbuild to rebuild Source RPMs. I started > out using this method since it was the only one I knew. Does mock / Koji > use rpmbuild as its base? I wrote a simple script that did a for loop of > all of the source RPMs (synced them all from mirror service 's copy of > epel), and ran them through rpmbuild. Started off with a buttload of > errors in the form of non installed dependencies. Just today, I told my > Raspberry Pi 3 to install something like 9 gigs worth (expanded) of > packages (my script parsed the output of all of the failed builds for > the packages they needed, and piped them into yum install). I had to > leave for work (well) before it finished so I'm not sure how far it's > gotten. Is mock / Koji easier on these dependencies in the OS? > > I will say this for the Raspberry Pi 3, though, it seems to be > comparatively powerful for building. While I did have a lot of failed > packages I must have gotten a good 500-1000 or so (epel totals ~10000) > built in just several hours. > > That also reminds me. Are there any plans for 64 bit builds of > redsleeve in the future? I didn't care that much before, but now the Pi > 3 is a 64 bit process, and I'm curious if it would have any better > performance in 64 bit vs 32 bit. > > On Apr 8, 2016 07:26, "Bjarne Saltbæk" <[email protected] > <mailto:[email protected]>> wrote: > > Hi Mark. > > If you want to step in (re)building EPEL6 (or EPEL7) using my koji > installation please start by reading: > > http://www.saltbaek.dk/dokuwiki/doku.php?id=koji:installation:05:start > > I use RSEL6 for building EPEL6 packages and plan to use RSEL7 for > building EPEL7 packages. I think mock can build EPEL6 packages on > RSEL7 without any quirks, but to make sure I don't mix it for now. > > You need to: > > 1) yum install koji-builder (from an existing EPEL6 repo - if you > want the latest koji-builder package, use my testing EPEL6 repo at - > http://www.saltbaek.dk:9080/rpm/dist-epel6-testing/arm/os/ ). > > Then we need to agree on your hostname for the host ssl client. It > can be any name - I use Lego names for my hosts but you can use a > FQDN if you want. Send me the name and I will send you back the > needed client and server ssl clients. > > You install the certificates and start the kojid service. > > I don't have any access to you builder what so ever, but you builder > must be able to connect to my koji hub at > http://koji.dev.saltbaek.dk and https://koji.dev.saltbaek.dk > together with http://gitserver.saltbaek.dk > You builder will request tasks via XML-RPC and get/send RPM's via > http/https and git clone via http. > > I will also send you a user client ssl certificate that you need to > install in your browser in able to log in at > https://koji.dev.saltbaek.dk/koji > > --- > > Let me know if you want to join "The Force" :) > > BR, > Bjarne > > > > ------------------------------------------------------------------------ > Date: Tue, 5 Apr 2016 01:28:28 -0400 > From: [email protected] > <mailto:[email protected]> > To: [email protected] <mailto:[email protected]> > Subject: Re: [RedSleeve-Users] arm EPEL > > I've got hardware, primarily raspberry pis of all shapes and sizes, > and I'm willing to use some of them for the cake, but I don't have > any experience in building the packages. If you can give me some > pointers on setting it up, I'll be happy to kick-start it. > > On Apr 5, 2016 01:16, "Bjarne Saltbæk" <[email protected] > <mailto:[email protected]>> wrote: > > Hi Mark. > > I am still working on getting EPEL6 up to date (still missing > some 100+ that needs manual attention). I dont have any RSEL7 > builders available since all my builders are running RSEL6. > If someone want to step in and supply RSEL7 building power (and > optimal do the koji maintenance for the repo please let me know). > > BR, > Bjarne > > > > _____________________________ > From: Mark Campbell <[email protected] > <mailto:[email protected]>> > Sent: tirsdag, april 5, 2016 3:14 AM > Subject: Re: [RedSleeve-Users] arm EPEL > To: <[email protected] <mailto:[email protected]>> > > > Hello, I was just wondering how up to date EPEL 7 is? I see > some datestamps being around end of January. Reason I ask, is > I'm looking for python 3.4. Fedora's EPEL has it as of the end > of January, but I don't see it in our EPEL. > > On Mar 2, 2016 07:58, "Bjarne Saltbæk" <[email protected] > <mailto:[email protected]>> wrote: > > I have (finally) opened up for remote access to my Koji > installation. It should be available at > http://koji.dev.saltbaek.dk/koji > EPEL6 is currently building in the "dist-epel6" build target. > > Building repo is being pushed to > http://koji.dev.saltbaek.dk/rpm/dist-epel6-testing/ every hour. > > BR, > Bjarne > > > > ------------------------------------------------------------------------ > From: [email protected] <mailto:[email protected]> > To: [email protected] <mailto:[email protected]> > Date: Thu, 28 Jan 2016 22:16:31 +0100 > Subject: Re: [RedSleeve-Users] arm EPEL > > Hi Gordan. > > If you ignore the original date on the mail I respond on now > :D - do your offer still stand? > I have now (I think) a working Koji setup. Took me almost a > year (of spare time) to understand how Koji work and now I > badly need build power :-D > Compile time on a RPI 2B is sooo slow and it will take more > than a week to compile the whole EPEL6 repo. > I plan to move my esx host to my scullery so it can run 24/7 > this weekend. Then I can provide public access to the > koji hub and the git server. > The builders can then pull code from git and transfer > packages to/from the hub. I also need to grant the builders > access to the Sigul bridge (just a port) for RPM signing. > I have made a "RedSleeve Test" gpg key that I sign the > packages with. I can rename the key if it is not appropriate. > > On a side note: Speaking of the performance of the RPI - I > have looked at the specs on the Banana PI. It looks rather > good. More RAM, a SATA connetion. > Is it any good or will I get the same low performance as the > RPI? > > BR, > Bjarne > > > > Date: Thu, 9 Apr 2015 15:39:07 +0100 > > From: [email protected] <mailto:[email protected]> > > To: [email protected] > <mailto:[email protected]> > > Subject: Re: [RedSleeve-Users] arm EPEL > > > > For me the deciding factor is that my entire set of build > scripts > > took me less than an hour to write. I gave up on Koji > documentation > > after about an hour because there just seemed to be far > too many > > moving parts involved. > > > > Fancy becoming a RSEL Koji maintainer? What are the resource > > requirements (CPU, RAM, disk)? I could easily enough spin > > something up and get you ssh access to it (<= 512MB DreamPlug, > > 1GB -> 4GB I could probably get my Arndale OCTA or Cornfed > > machine up and running next weekend (I've had them gathering > > dust for a year, could rather do with the extra motivation to > > get them up and running), or if you need more than that, > > anything up to a fairly beefy x86-64 VM could be provided > > easily enough. > > > > Let me know if you're interested. Maybe it's time to switch > > to Koji, if what you are saying is correct. Even if you could > > just comprehensively document the installation process for the > > wiki, it would be really useful. > > > > Gordan > > > > On 2015-04-09 15:20, Bjarne wrote: > > > Hi Gordan. > > > > > > I have focused on using standard components as much as > possible. > > > I saw how the RPMforge died out. I believe it was mainly > because it is > > > always really hard to take over custom made solutions > like Daag's DAR > > > system. > > > I am new to Koji and do not quite get it yet, but I have > an initially > > > solution working. > > > One cool thing about Koji is it is like a virus. It is > so super easy > > > to set up new build slaves. So if somebody has system > available which > > > is accessible by SSH and can install EPEL packages it > can be an Koji > > > slave in no time. > > > I agree that Koji is rather undocumented, or I have not > found the > > > complete documentation. Taking bits and pieces from > pages found by > > > Google. > > > So about the dependency issue I have not an answer to > that since I do > > > not know. > > > > > > And since Fedoraproject use Koji, so do I. I will not > use time to > > > invent the wheel over again :) > > > And since CentOS have been adopted by RedHat i guess > that it might be > > > used with Koji. > > > > > > So, I can not say you should use Koji. Just think about > if you should > > > have other people to participate or take over your build > system :) > > > > > > BR, > > > Bjarne > > > > > > > > > On 09-04-2015 11:58, Gordan Bobic wrote: > > >> I have to say I found koji to be a major pain in the > backside last > > >> time I looked it - to the point where I abandoned it in > favour of > > >> abut 50 lines of bash scripts that produced results > every bit as > > >> good using mock (which koji builds use anyway) as using the > > >> monstrosity that is koji in to drive it. > > >> > > >> One killer feature that I had hoped koji would have is > dependency > > >> analysis (look at what packages have which dependencies > and direct > > >> the builds (--with bootstrap if required) in a way that > avoids > > >> tons of unnecessary package extraction/cleanups for all the > > >> packages that don't have all the dependencies built yet. > > >> Unfortunately, > > >> koji does not in fact have such a feature, so I could > not for > > >> the life of me see what it brought to the table to > justify the > > >> complexity involved. So I abandoned the idea and stuck > with a > > >> few lines of bash that worked just fine. > > >> > > >> Unless, of course, you are about to tell me that koji > has gained > > >> the said feature in the past 3 years or so... > > >> > > >> Gordan > > >> > > > _______________________________________________ > > > users mailing list > > > [email protected] <mailto:[email protected]> > > > http://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________ > > users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________users mailing > [email protected] > > <mailto:[email protected]>https://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] <mailto:[email protected]> > https://lists.redsleeve.org/mailman/listinfo/users > > > > > _______________________________________________ > users mailing list > [email protected] <mailto:[email protected]> > https://lists.redsleeve.org/mailman/listinfo/users > > > _______________________________________________ users mailing list > [email protected] <mailto:[email protected]> > https://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] <mailto:[email protected]> > https://lists.redsleeve.org/mailman/listinfo/users > > > > _______________________________________________ > users mailing list > [email protected] > https://lists.redsleeve.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
