[CentOS-devel] Latest builds are now online 2014-06-25_build 4

Sat Jul 5 22:40:51 UTC 2014
Karanbir Singh <mail-lists at karan.org>

On 07/05/2014 04:49 PM, Nico Kadel-Garcia wrote:
>> https://git.centos.org/tree/sig-core!bld-seven.git
> 
> Wow! What an intuitive, apparent, and well labeled name, completely
> obvious from the git.centos.org front page! And its name makes it
> completely apparent that it contains the mock configurations,
> especially since it has no description whatsoever for the repo itself!

given that this is SIG Core effort, I'd expect people to look at that
project's code for this content, and its clearly marked. But feel free
to submit patches to docs etc.

also, please use git format-patch and post to this list; if you want to
use bugs.c.o as a marker, thats fine, but the patch content needs to
come to this list and will be commited from here.

> And boy, do I understand and sympathize with that process. I'd love to
> see the relevant mock configurations get into a relevant RPM with
> daily build compatible config files, but that would be dependent on
> the installation of a 'mock' RPM. That gets into weirdness with CentOS
> build environments being dependent on mock from a third party (such as
> the EPEL beta 7 repository), and needing something like a
> 'yum-conf-epel' RPM to enable EPEL, then something like a
> "mock-conf-centos-daily' package to enable CentOS nightly build
> access. Would that be acceptable?

all of this is already in place, look at the buildlogs site and track
down a build target, it has the mock config, the environment around it
and the input + ouput results. And this is per build, so address's the
concern around environment changes etc.

creating 'chaser' or 'shadow' builder threads is easy, chain it from a
reposync call ( each of the build targets has a complete repodata/ dir )

> That signature is, IMHO, too late. I'd love to see the signatures on
> git tags from the git repository itself, to help ensure provenance.
> But since you're the one doing signatures, I'm also afraid that would
> probably double *your* workload.

the piece that is still missing is the quantification of what that delivers.

- KB


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc