You could just use mock directly - that is how most of our stuff
so far has been built. Get all the src.rpms, then do something like:
# sudo -u mock
$ mock -r epel-7-armv5tel \
--resultdir=/path/to/local/epel/destination/repo \
--rebuild /path/to/src/rpm
And do that for each src.rpm.
You should probably wrap that into a few lines of bash to do
things like:
- save the logs for failed builds
- rebuild/update the repository in
/path/to/local/epel/destination/repo using createrepo or
createrepo_c after every successful package build
- move the successfully build src.rpm out of the way
You will need to out together a suitable
/etc/mock/epel-7-armv5tel.cfg
file, but if you look at one of the existing ones you should
get the gist of it.
You will probably have to do a few passes of this process
as dependencies that are initially missing get built.
Once you have this going, you can pretty much leave it
unattended for days at a time until it's time for the next
pass. Eventually you'll have everything that builds out of
the box built, and you can start looking at the build failure
logs to figure out why the build failed (e.g. ExclusiveArch
or ExcludeArch in the spec file, missing dependenies,
compile error, etc.) and look into fixing them.
Gordan
On 2016-04-05 16:27, Mark Campbell wrote:
If you can give me some pointers on how you built EPEL 7, I don't mind
replicating that. Depending on how much time it takes for manual
intervention, I might be willing to do it from now on.
On Apr 5, 2016 02:36, "Jacco Ligthart" <[email protected]> wrote:
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]>
wrote:
I have (finally) opened up for remote access to my Koji
installation. It should be available at
http://koji.dev.saltbaek.dk/koji [1]
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/ [2] 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
Links:
------
[1] http://koji.dev.saltbaek.dk/koji
[2] http://koji.dev.saltbaek.dk/rpm/dist-epel6-testing/
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
