[EPEL-devel]Re: Boostrapping a new architecture for EPEL

[Matej Stuchlik]

- Original Message -
> From: "Peter Robinson" 
> To: "EPEL Development List" 
> Sent: Wednesday, November 25, 2015 5:33:17 PM
> Subject: [EPEL-devel]Re: Boostrapping a new architecture for EPEL
> 
> >>> 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.
> 

I'm wondering if [0] could be of any use for you. It's not quite ready for
a release, but it should hopefully make rebuilds (including bootstrapping)
a lot simpler (eventually, anyway :) ).

You tell the tool the names of packages you want to rebuild, where it should get
those packages from and where it should build them, and it builds them
it the right order, using what we call a "recipe" [1] to break a dep cycle
whenever it finds one.

If you think it could be helpful, I'll let the author know he should improve
the README. :)

Matt

[0] https://github.com/mcyprian/sclbuilder (please disregard the name, it's not
SCL specific :) )
[1] 
https://github.com/mcyprian/sclbuilder/blob/master/input_data/recipe1_py35.yml
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC

[Matej Stuchlik]

Hey,
I've unfortunately had other things on my plate, but this is now on the top,
so I'll get things moving. :)

Cheers,
Matt

- Original Message -
 From: Bohuslav Kabrda bkab...@redhat.com
 To: Stephen John Smoogen smo...@gmail.com
 Cc: epel-devel@lists.fedoraproject.org, epel-us...@lists.fedoraproject.org, 
 Matej Stuchlik mstuc...@redhat.com
 Sent: Friday, March 6, 2015 10:39:38 AM
 Subject: Re: EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC
 
 - Original Message -
 
  Sorry for the delay in getting this out. We will be continuing the EPEL
  Python discussion
 
  We will be in #epel on Freenode for our weekly EPEL Steering
  Committee meeting Friday 06-Mar-2015 at 17:00 UTC.
 
  Proposed Agenda items:
 
  1.) Python 3.X Discussion
  - Dual stack support?
  - Macros?
  - How can people help?
 
 Hi, I'm sorry but I won't be able to attend today's meeting for some personal
 reasons that appeared suddenly. I believe the proposal is in a good shape
 and most pressing concerns have been discussed on the ML. If any more are
 concerns are voiced on the meeting, I'll try to handle them during next
 Monday.
 Also, since I've been in a huge time press lately, I'd like to pass ownership
 of this proposal to someone else during next week or week after that. One of
 my colleagues, Matej Stuchlik (CCed), has expressed an interest and would be
 willing to take this - that's unless someone else who's participated up
 until now wants to take it.
 I'll still be around doing suggestions and trying to help, I just don't have
 the time to really drive this effort and do all the hard work. I'll try to
 ask Matej to come to the meeting, assuming he has the time today.
 
 Thanks for understanding,
 Slavek
 
  2) Keep the meeting at the same UTC time? [I would like to do so.]
 
  3) Open Floor / Other Items
 
  --
  Stephen J Smoogen.
 
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel