Building Updates
by Chris Tyler
(Cross-posted to arm@ and secondary@)
We're approaching the release of F13 for ARM. It's about to hit EOL on
the primary archs, so it has a short shelf life, but I'm going to use
that time to figure out the best process for building updates -- with a
goal of having the updates procedure well in hand by the time we hit F15
on ARM. (Paul Whalen, meanwhile, is going to continue to head up the
drive towards the F14/F15 ARM releases).
On the primary archs (PA), updates are built, targeted at
dist-fX-updates-candidate, then shepherded via Bodhi through a sequence
of tags:
dist-fX-updates-candidate ->
dist-fX-updates-testing-pending ->
dist-fX-updates-testing ->
dist-fX-updates-pending
dist-fX-updates
There are a few options here:
[A] Use koji-shadow against dist-fX-updates-candidate PA (and targeting
dist-fX-updates-candidate SA) and use a separate process to manage the
tag-shadowing between PA and SA.
[B] Watch dist-fX-updates PA for packages tagged in, and then build
those, targeted to dist-fX-updates on the SA. This saves a bunch of
package building on the SA side (though I'm not sure what the ratio is
between packages built and pushed to stable).
I'm leaning towards some version of [B]. Any thoughts/comments on this
approach?
-Chris
13 years, 1 month
- 3
- 3
changes in pungi/anaconda effecting all secondary arches
by Dennis Gilmore
Hey all,
Wanted to give a heads up to everyone,
pungi awhile ago dropped support for split media. this means no install cds.
just the boot.iso and a install dvd are supported. sparc hardware has a 10Mb
limit for tftp installs. the kernel and initrd will be over 200Mb now we have
not been able to network install sparc since F-9 this might effect other arches
also. this is due to the drop of stage2 the initrd now holds all of anaconda
needed to install the box.
there is another massive change, the switch from buildinstall to using lorax
to make the anaconda images. its a huge difference. and right now only
supports primary arches. this code is all live in F-15 now. my understanding
is that it will be up to the arch teams to add support for their arch to
lorax. its currently a noarch package but will likely need to become
noarch. it has a Requires on syslinux perhaps we can keep it noarch and add
a Requires install-bootloader or something like that and put a matching
Provides in the respective packages.
Please feel free to bring up on this list anything effecting secondary arches.
quite a few of the people involved are involved in more than one arch and it
seems we are doing a poor job of communications.
Dennis
13 years, 1 month
- 2
- 1
- ← Newer
- 1
- Older →