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
