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]> 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] > To: [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]> 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]> > Sent: tirsdag, april 5, 2016 3:14 AM > Subject: Re: [RedSleeve-Users] arm EPEL > To: <[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]> 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] > To: [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] > > To: [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] > > > http://lists.redsleeve.org/mailman/listinfo/users > > _______________________________________________ > > users mailing list > > [email protected] > > http://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 > > > > > _______________________________________________ > users mailing list > [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 > >
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
