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
[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
