On 11/28/2014 11:06 PM, Adam Williamson wrote:
On Fri, 2014-11-28 at 21:22 -0600, Mike Chambers wrote:
On Fri, 2014-11-28 at 21:50 -0500, Gene Czarcinski wrote:
Currently, the packages for Fedora 21 are in development/21 and
updates/testing/21. Based on my current understanding of how kojo and
the compose process works, all of kojo's current packages are collected
into a single yum repository which is used to compose as well as create
the Live images and that single repo may or may not be the same as the
two repos/
Are all of kojo's "current" (or more recent) packages also in
development/21 and updates/testing/21? That is, could we use the two
repos as input to create the equivalent of RC1, etc.
Gene
Yes for now they are in testing and development/21. Once in testing, at
some point, instead of going straight to development/21 they will go to
updates, but haven't as of yet.
Well, it's called koji, not kojo.
Okay, okay ... so I are a injunear and spelling is not one of my strengths.
The current 'stable' packages for a Branched release - that is, the last
build of a given package that was given the 'stable' tag, which is
always 'fXX', e.g. 'f21' for 21 - always live in development/(release),
so development/21. I don't know where you get the term 'current', it
isn't used by koji or Bodhi so far as I know. 'testing' packages -
packages with the 'f21-updates-testing' tag, that have been submitted
via Bodhi - live in updates/testing .
TCs and RCs do not use packages from updates/testing at all, so forget
about it, if you're trying to generate images that approximate the
'official' ones. But they *do* use packages from bleed:
http://kojipkgs.fedoraproject.org/mash/bleed/
because we like to pull in Blocker and FE bug fixes before they go all
the way through the Bodhi and mash process and show up in
development/21. bleed is the side repo into which Blocker/FE fixes that
are requested for a given TC/RC compose are put. So, when I do a TC/RC
compose here:
https://fedorahosted.org/rel-eng/ticket/6031
and say "Please pull (list of packages)", releng puts the packages from
that list into the bleed repository before they run the compose.
So, if you're trying to match the package set of the current TC/RC, the
repos for your compose should be 'fedora' (which is the 'stable' repo)
and bleed. Do not use updates-testing. You also will want to make sure
you have the f21 branch of spin-kickstarts, and try to use the git
commit that was the latest at the time the compose was run.
I can see some pluses to what you are doing but also some minuses. The
pluses are that you are geting some critical stuff tested sooner rather
than later. The minuses are that anyone doing a netinstall will not get
any of these packages. Only those fixes that are on the Fedora-Server
DVD or on a Live CD/DVD will get more testing.
Also, I am not trying to duplicate what will be in the final release so
much as to create Live images which include potential updates. I am
still testing and if something out in updates-testing is going to break
things, I want to know that so I can report it and, if possible, propose
a fix.
Also, I have bought into this Workstation product as well as the other
Live "nonproducts" (really, I consider them to be "semi-products"). I
am trying to figure out my new install/reinstall process ... should I
create my own Live image which has everything I want or use a standard
Live install followed by a post-install script to add in the rest of the
stuff I want.
I will still b e creating my own Live images because there are some
packages I have locally updated which need to be there for the install.
For example, my version of grubby updated to support booting off a btrfs
subvolume.
Gene
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
