>>> So it's been discussed a little about doing a EPEL bootstrap for new >>> architectures. We have a number of arches wanting to do this (ppc64le, >>> aarch64, i686, s390x). So ppc64le will be our first and this is an >>> overview of the process I'll be using to do it. Once it's complete >>> I'll do a better write up as I suspect some things will evolve as we >>> go on down the path. >>> >>> So the general overview of the process is: >>> >>> 1) add new builders to koji (ppc64le complete) >>> 2) create separate inherited build target and tag >>> (epel7-archbootstrap) with associated architecture >>> 3) run scratch builds in that target using the git commit hashes from >>> the latest builds in the epel7, epel7-testing and epel7-candidate tags >>> 4) For each scratch build completed, run mergeScratch(task_id) >>> 5) when all builds are complete enable the arch on the main epel7 >>> target >>> 6) sign all new packages >>> 7) update bodhi, pkgdb, mash configs >>> 7) mirror out >>> >>> I have some scripts to do the above which I'll publish for reference >>> once I've cleaned them up a little. >>> >>> This process isn't perfect. The new arch builds may not have the exact >>> same build dependency NVRs because, at least in the case of ppc64le, >>> the first EL7 release with .el7 distags is 7.2 and obviously most of >>> epel7 is built against < 7.2. The mergeScratch koji API call imports >>> all the build logs which helps mitigate this from a debug PoV. There's >>> not really a good way to deal with this, and obviously once the new >>> arch is enabled they'll be the same moving forward. I don't see it as >>> an issue really, just making note of it here for reference. >>> >>> Looking at the current stable epel7 builds, as of a couple of days >>> ago, we have around 4763 source packages, of which 2686 are noarch >>> (and hence don't need to be rebuilt) and a touch under 2077 (2077 at >>> time of check) are arch dependent. >>> >>> Let me know of any queries, questions, concerns etc >> >> sounds sane :-) But how will be handled packages that require some >> boostrapping procedure - is a new combo of boostrap and final build >> required in existing EPEL (dist-git) or or will be the bootstrap build >> taken from the original EPEL bootstrap (built eg. against RHEL-7 Beta) >> and the current latest NVR will be then the final build? >> > Note that I have packages already built in my local ppc64le epel7 > environment and > some could be used to help in bootstrap.
Sorry, that's not going to happen, but if you've got a list of package sets that need specific bootstrapping that would be useful. Peter _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org