up to date till January 10 2016. That's the date I downloaded all sources. The dates you see are probably build dates. It took a couple of weeks to build the new stuff.
Jacco On 04/05/16 03:14, Mark Campbell wrote: > > 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 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
