[packagers] autobuilding assumptions
cmr at financial.com
Thu Dec 24 20:52:10 CET 2009
Am Donnerstag, den 24.12.2009, 12:19 +0100 schrieb Karanbir Singh:
> Hi Guys,
> On 12/21/2009 11:51 AM, Karanbir Singh wrote:
> > I've done some of the work required to have auto-builds work. There are
> > a couple of assumptions ( or rules ? ) that we would need to work with
> > here.
> Can we get agreement to the assumptions and notes so far posted ?
> Ideally all of the following people would ack this:
e) it would be really handy if the files could be accessible directly
without the need of unpacking an archive.
f-g) as said before I think one builder per target (os/arch) would be
optimal, that way builds are serialized and you still can have a lot of
h) we need to things additionally to centos mock setups:
- include rpmforge repo for dependencies
- put rpm-macros-rpmforge in the buildgroup for essential macros
1G for tmpfs should be sufficient, the only build i ever had blowing it
was RHWAS php. Maybe we can define a keyword to disable tmpfs for
I would like to see mock-configs and buildgroup definitions linked in a
prominent place so anyone can easily setup up his own compatible
And if please someone could help me with my wiki account i would write a
step-by-step doc how to set up a buildsys plus some other things I
wanted to share.
Concerning the list of authors:
A special place should be reserved for dag, dries and arrfab. Currently
active seem cmr, shuff, yury, david, ae. I really wonder if thias and
and herrold still have time and/or interest you should ask them in a
private mail. I cannot comment on the others as I never heared of them.
Another thing i pointed out before: currently rpmforge is a package pool
I would like to make a distribution out of it by selecting packages from
the pool and build a clean (repoclosure clean) selection of latest
versions in a seperate repo. I propose to start out with an empty set
and subsequently add packages as they are updated. Also this "gold" repo
should be scanned for freshness. If packages appear to be not "fresh"
anymore they should be updated/touched to keep them in otherwise they
should be dropped.
Yet another thing. I said this like a million of times. We need a
tracker, i don't care which one any will do but we really need it. Maybe
we could also auto-file tickets for failed builds, we need some method
to get notified of those....
Last, thanks for taking on the topic. Have a nice Christmas time.
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany
Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany
Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach
Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender)
Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
More information about the packagers