good to know that you're working on EPEL6. I will probably announce an
updated EPEL7 this weekend :)

for reference about hardware, I use an odroid U3 for building. The CPU
is good, in has 2GB of mem, but no sata. the sata part is now solved
with an usb disk. Another device I can recommend is the XU4. better CPU,
still no sata, but now usb3.

After the EPEL7 ordeal, I will create regular updates for 7.2 and 6.7.

Jacco

On 01/28/16 22:16, Bjarne Saltbæk wrote:
> 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

Reply via email to