Hey, folks - just thought I'd drop a note about this. I wound up on a
bit of a wiki deep dive after looking through the 'welcome' pages I
sent to Drew and Rich and realized a lot of our process pages were
kinda out of date for the changes in the last few months. So I did some
whirlwind fixes to a f
he 'TC' / 'RC'
> > distinction at the validation event level, but instead the events will
> > follow the Pungi compose versioning quite closely, so we'll have
> > something like Test Results:Fedora 24 Alpha 1.1 Installation . If that
> > seems terrible to an
On Mon, Mar 14, 2016 at 1:05 PM, Adam Williamson
wrote:
> For now I'm inclined to similarly try and keep the validation stuff as
> simple as possible, so I won't try to recreate the 'TC' / 'RC'
> distinction at the validation event level, but instead the
lpha-1.1, Alpha-1.2, Alpha-1.3 and so
on, without worrying about the TC/RC distinction.
At least that's the initial plan - once we've actually done a couple of
composes and seen what exactly comes out of the sausage machine, and
we've tried to set up validation events for them and se
On Mon, 2016-03-14 at 11:52 +, Peter Robinson wrote:
> On Mon, Mar 14, 2016 at 11:29 AM, Kamil Paral wrote:
> >
> > >
> > > releng flipped any necessary switches for
> > > 'release' behaviour.
> > I think this is the only meaningful argument for having TC/RC
> > distinction. Personally I'm f
On Mon, Mar 14, 2016 at 11:29 AM, Kamil Paral wrote:
>> releng flipped any necessary switches for
>> 'release' behaviour.
>
> I think this is the only meaningful argument for having TC/RC distinction.
> Personally I'm fine with it both ways. It's nice to see which images are the
> ones "almost r
> releng flipped any necessary switches for
> 'release' behaviour.
I think this is the only meaningful argument for having TC/RC distinction.
Personally I'm fine with it both ways. It's nice to see which images are the
ones "almost ready", but I'm not sure it's worth having more bits for releng
On Wed, 2016-03-09 at 13:57 -0700, Chris Murphy wrote:
>
> So if "RC-1.8" passes all tests and is a go, how is this renamed? Or
> is it not renamed?
> I assume you don't want to do a production compose at this point
> because then it's a compose that isn't tested, while ostensibly
> identical the
7;
> > > > milestone,
> > > > only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be
> > > > 'RC1', which
> > > > is kinda strange; again we could add a 'Final' milestone to
> > > &
sure the thing we're going-or-not-going-with meets all the
'RC' requirements, but it doesn't have to be explicitly labelled an
'RC' for that purpose, I don't think.
For Pungi 4 I'm assuming the 'label' winds up in the image filenames
and volume labe
27;s a good time
>> to decide what to do about milestone builds with Pungi 4. :)
>>
>> I'm assuming here that we're going to use more or less the same "TCs
>> and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems
>> a bit late to mak
On Wed, Mar 9, 2016 at 11:16 AM, Adam Williamson
wrote:
> Hi folks!
>
> So we're now frozen for Alpha and we have an anaconda build with
> blocker fixes in updates-testing...I guess this means it's a good time
> to decide what to do about milestone builds with Pungi 4.
> Subject: Re: Pungi 4 milestone builds: proposals
> From: adamw...@fedoraproject.org
> To: test@lists.fedoraproject.org; rel-...@lists.fedoraproject.org
> Date: Wed, 9 Mar 2016 10:33:41 -0800
>
> On Wed, 2016-03-09 at 13:26 -0500, John Dulaney wrote:
>> .
>>>
&
1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2).
> >
> > This seems like the closest possible way to map to our current system.
> > Again it's a bit weird at Final because there is no 'Final' milestone,
> > only 'RC', so 'RC1.1' would b
ible way to map to our current system.
> Again it's a bit weird at Final because there is no 'Final' milestone,
> only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which
> is kinda strange; again we could add a
Hi folks!
So we're now frozen for Alpha and we have an anaconda build with
blocker fixes in updates-testing...I guess this means it's a good time
to decide what to do about milestone builds with Pungi 4. :)
I'm assuming here that we're going to use more or less the same &q
> > I do, immediately, and that's the point. When I see all the composes
> > in the pungi directory, I can immediately see what is the today's
> > latest one, and I see which ones are yesterday ones.
>
> Oh, but you referred to running tools.
Yes, but I meant
n't
> > know.
> I do, immediately, and that's the point. When I see all the composes
> in the pungi directory, I can immediately see what is the today's
> latest one, and I see which ones are yesterday ones.
Oh, but you referred to running tools.
If you want to o
er which is
> > which?
>
> Except this doesn't work, because the compose before 20160225.0 is not
> necessarily 20160224.0, it might be 20160224.3. You just don't know.
I do, immediately, and that's the point. When I see all the composes in the
pungi directory,
On Thursday, February 25, 2016 02:57:04 PM Matthew Miller wrote:
> On Thu, Feb 25, 2016 at 11:34:57AM -0800, Adam Williamson wrote:
> > > Maybe I'm Dumb (™), but I'm not following the problem with the
> > > "because". *Shouldn't* the override packages be the equivalent of
> > > stable updates?
> >
pose"?
waaitaminute...
> Instead of including overrides in "candidates", include them only in...
> "override tests", which would only be used to test that the particular
> override package was not a terrible idea.
>
> Then, the _next_ snapshot could be ev
On Thu, Feb 25, 2016 at 11:34:57AM -0800, Adam Williamson wrote:
> > Maybe I'm Dumb (™), but I'm not following the problem with the
> > "because". *Shouldn't* the override packages be the equivalent of
> > stable updates?
> No.
[...]
> In other cases, though, we need to try out a potential fix for
On Thu, 2016-02-25 at 10:45 -0500, Matthew Miller wrote:
>
> On Mon, Feb 22, 2016 at 02:11:10PM -0800, Adam Williamson wrote:
> >
> >
> > When I think about 'composes' I tend to just think about a sort of
> > isolated thing with a bunch of images in it, but of course that's
> > not
> > (all) a "
whether to call it an "RC" and sync it to the mirrors?
How hard is it to say, from now on we're not going to have a "final
release" but we're gonna build these four sets of outputs on different
schedules and ship each one after some testing?
Right now my belief is tha
On Mon, Feb 22, 2016 at 02:11:10PM -0800, Adam Williamson wrote:
> When I think about 'composes' I tend to just think about a sort of
> isolated thing with a bunch of images in it, but of course that's not
> (all) a "snapshot compose" is. The snapshot composes are what will
> ultimately be staged o
> > If you mean that we will have a sequentially growing integer number
> > of any kind of compose, and we'll define everything somewhere else
> > (PDC), then it's probably cleaner, but it's harder to use by humans
> > and therefore less useful.
>
> But the compose has dozens and dozens of propert
On Tue, 2016-02-23 at 19:09 -0800, Adam Williamson wrote:
> On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote:
> >
> > Hi folks!
> >
> > So I've been working lately on revamping the release validation process
> > for Pungi 4 composes. I'v
On Wed, 2016-02-24 at 06:43 -0500, Kamil Paral wrote:
> If you can distill everything above into a 30-seconds explanation how
> things work, which is easy to understand and doesn't sound like a
> university paper on nuclear physics merged with philosophy, then
> maybe :) Because it can be easily d
> The more I think about it the more I tend to like my general proposal
> from the follow-up to this email, which is that we should build the
> tooling to think about the *essential properties* of composes. This is
> in specific contrast to building the tooling to work on *constructed*
> properties
On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote:
> Hi folks!
>
> So I've been working lately on revamping the release validation process
> for Pungi 4 composes. I've made quite a bit of progress, but I'm now
> kind of stuck, because we don't know how t
On Tue, 2016-02-23 at 11:05 -0500, Kamil Paral wrote:
> >
> > When I think about 'composes' I tend to just think about a sort of
> > isolated thing with a bunch of images in it, but of course that's not
> > (all) a "snapshot compose" is. The snapshot composes are what will
> > ultimately be staged
> On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote:
> > > > Also not visible in the mockup: "compose override" packages are *always
> > > > included in all types of compose*. This is the concept Dennis and I
> > > > came up with for handling blocker / freeze exception fixes; it's just a
> >
On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote:
> > > Also not visible in the mockup: "compose override" packages are *always
> > > included in all types of compose*. This is the concept Dennis and I
> > > came up with for handling blocker / freeze exception fixes; it's just a
> > > more
On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote:
> This hasn't been a problem so far, because I actually built Wikitcms
> and fedfind kinda backwards - their conception of how composes should
> be identified is actually derived directly from how we name release
> validation events. :P In A
#x27;essential property' that's indicated by the compose ID instead
of / as well as metadata (or PDC).
So yeah: on second thoughts, I don't think it's a good idea to
construct and denote 'synthetic properties' in the compose ID.
It is significantly *less* of a problem to
> # tl;dr
>
> (LATER) OK, this email got really long, so here's my tl;dr summary.
> Proposed compose ID scheme: (RELEASE)-(DATE).(INDEX).(TYPE), e.g.
> 24-20160401.0.s (types are SNAPSHOT, CANDIDATE, POSTRELEASE).
> Alternatively: type is stored as separate bit of metadata instead of
> / as well a
On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote:
> As a pre-note: I'm really only concerning myself with the "Official
> Release Process Composes" here, the composes we consider part of the
> (still) more-or-less monolithic 'release cycle'. I didn't try to
> think of a design that accounts
Hi folks!
So I've been working lately on revamping the release validation process
for Pungi 4 composes. I've made quite a bit of progress, but I'm now
kind of stuck, because we don't know how the full release cycle is
actually going to work with Pungi 4 composes. There are
en was the last time
> > pungi has been successfully run? Yes, I know that TC3 was built by
> > something but was pungi involved? I have been assuming it was but
> > I am unable to run it myself.
> >
> > To keep things simple, I am using
> > /usr/share/s
On 11/26/2014 03:08 PM, Gene Czarcinski wrote:
On 11/24/2014 04:14 PM, Gene Czarcinski wrote:
I know we are into this product-zed stuff with lots of emphasis on
Live installs including Live Workstation but when was the last time
pungi has been successfully run? Yes, I know that TC3 was built
On 11/24/2014 04:14 PM, Gene Czarcinski wrote:
I know we are into this product-zed stuff with lots of emphasis on
Live installs including Live Workstation but when was the last time
pungi has been successfully run? Yes, I know that TC3 was built by
something but was pungi involved? I have
son wrote:
>>>
>>>> On Mon, 2014-11-24 at 23:25 +0100, poma wrote:
>>>>> On 24.11.2014 22:35, Adam Williamson wrote:
>>>>>> On Mon, 2014-11-24 at 16:14 -0500, Gene Czarcinski wrote:
>>>>>>> I know we are into this product-zed
-24 at 16:14 -0500, Gene Czarcinski wrote:
I know we are into this product-zed stuff with lots of emphasis
on Live installs including Live Workstation but when was the
last time pungi has been successfully run? Yes, I know that TC3
was built by something but was pungi involved? I have been
gt;>> On Mon, 2014-11-24 at 16:14 -0500, Gene Czarcinski wrote:
>>>>> I know we are into this product-zed stuff with lots of emphasis
>>>>> on Live installs including Live Workstation but when was the
>>>>> last time pungi has been successfully ru
t;> I know we are into this product-zed stuff with lots of emphasis
> > >> on Live installs including Live Workstation but when was the
> > >> last time pungi has been successfully run? Yes, I know that TC3
> > >> was built by something but was pungi invol
ation but when was the last time pungi has
> >> been successfully run? Yes, I know that TC3 was built by something but
> >> was pungi involved? I have been assuming it was but I am unable to run
> >> it myself.
> >
> > Yes. It always is. There are su
On 24.11.2014 22:35, Adam Williamson wrote:
> On Mon, 2014-11-24 at 16:14 -0500, Gene Czarcinski wrote:
>> I know we are into this product-zed stuff with lots of emphasis on Live
>> installs including Live Workstation but when was the last time pungi has
>> been successfu
On Mon, 2014-11-24 at 16:14 -0500, Gene Czarcinski wrote:
> I know we are into this product-zed stuff with lots of emphasis on Live
> installs including Live Workstation but when was the last time pungi has
> been successfully run? Yes, I know that TC3 was built by something but
&g
I know we are into this product-zed stuff with lots of emphasis on Live
installs including Live Workstation but when was the last time pungi has
been successfully run? Yes, I know that TC3 was built by something but
was pungi involved? I have been assuming it was but I am unable to run
it
People,
While trying to build rawhide with the attached kickstart file and:
pungi -c system_config_kickstart.ks --nosource --force --ver=F18
--all-stages
I get this error. It appears that this was a problem with F15/16 as
well?
I want to build a minimal F18 install CD (ie NOT a Live CD
On 29-08-2011 20:20, Jens Falsmar Oechsler wrote:
> Hello there
> I'm trying out Pungi build on Fedora 16 "branch":
> pungi --force --nosource --nodebuginfo --cachedir=/home/joe/Pungibuild/cache
> -G
> -C -B -I --flavor Fedora --name Fedora --ver 16 -c
> /home/
Hello there
I'm trying out Pungi build on Fedora 16 "branch":
pungi --force --nosource --nodebuginfo --cachedir=/home/joe/Pungibuild/cache -G
-C -B -I --flavor Fedora --name Fedora --ver 16 -c
/home/joe/fedora-16-pre-install.ks
It gives this error at the end:
Parallel mksq
On Sun, Jun 19, 2011 at 8:49 PM, Genes MailLists wrote:
>> By the way the same technique used to build an i386 f15 install iso
>> worked fine for me in my f14 build machine, so I did not alter the
>> basic technique between the two.
>>
>> I am puzzled getting the failed build - if anyone else is
nd then inside the chroot I installed spin-kickstarts as
>> usual when preparing to do a build.
>>
>> I then set up a fairly standard f15 x86_64 pungi build, but towards
>> the end of the process it failed.
> snip
>> Any help would be appreciated.
>
> By the way
en preparing to do a build.
>
> I then set up a fairly standard f15 x86_64 pungi build, but towards
> the end of the process it failed.
snip
> Any help would be appreciated.
By the way the same technique used to build an i386 f15 install iso
worked fine for me in my f14 build machine, s
I have a fully updated f15 x86_64 system in which I have mock installed.
I set up a mock chroot for building f15 x86_64 which appeared to work
normally, and then inside the chroot I installed spin-kickstarts as
usual when preparing to do a build.
I then set up a fairly standard f15 x86_64 pungi
On Mon, May 23, 2011 at 3:37 PM, James Laska wrote:
>> However I have a problem with the build that I can't resolve.
>> The machine running the build is f13 up to date, and the command I use
>> to run pungi is as follows:
>> pungi --nosource --nodebuginfo -G -C
> > Attaching the root.log from the chroot.
> >>
> >> And additionally the versions of lorax and pungi within the chroot are:
> >> lorax-0.4.6-1.fc15.i686
> >> pungi-2.5-2.fc15.noarch
> >>
> >> Any additional hints on a way forward would be appreciated.
On Mon, May 23, 2011 at 7:09 PM, James Laska wrote:
> On Mon, 2011-05-23 at 18:56 +0100, mike cloaked wrote:
>> On Mon, May 23, 2011 at 6:55 PM, mike cloaked wrote:
>>
>> > Attaching the root.log from the chroot.
>>
>> And additionally the versions of l
On Mon, 2011-05-23 at 18:56 +0100, mike cloaked wrote:
> On Mon, May 23, 2011 at 6:55 PM, mike cloaked wrote:
>
> > Attaching the root.log from the chroot.
>
> And additionally the versions of lorax and pungi within the chroot are:
> lorax-0.4.6-1.fc15.i686
> pungi-2.
On Mon, May 23, 2011 at 6:55 PM, mike cloaked wrote:
> Attaching the root.log from the chroot.
And additionally the versions of lorax and pungi within the chroot are:
lorax-0.4.6-1.fc15.i686
pungi-2.5-2.fc15.noarch
Any additional hints on a way forward would be appreciated.
--
mik
On Mon, May 23, 2011 at 6:38 PM, mike cloaked wrote:
> On Mon, May 23, 2011 at 3:37 PM, James Laska wrote:
>
>> Hmm, no idea off-hand. You probably already did this, but double check
>> the versions of pungi and lorax being used inside the chroot. They have
>> change
On Mon, May 23, 2011 at 3:37 PM, James Laska wrote:
> Hmm, no idea off-hand. You probably already did this, but double check
> the versions of pungi and lorax being used inside the chroot. They have
> changed recently, so make sure you are using the latest versions of
> each. Are
On Sat, 2011-05-21 at 22:07 +0100, mike cloaked wrote:
> I have been trying to build f15 from the development/f15 plus f15
> updates repos using pungi from a mock chroot. I have been doing this
> process since f11 days.
>
> I use a standard .cfg file to create the chroot w
I have been trying to build f15 from the development/f15 plus f15
updates repos using pungi from a mock chroot. I have been doing this
process since f11 days.
I use a standard .cfg file to create the chroot with the mock -r
command as user with only changes to the repo definitions, and then
run
e case of
> installation media, you can add packages to the ISO, but you also need
> to modify the yum repodata as well. Also, in the case of lorax or
> pungi, you need to rebuild the ISO media using those utilities. I don't
> think something like isomaster would help there.
Yes
nstalled) - I guess that would do it too?
I've never used that, I imagine that is helpful for a graphical way to
add/edit files on an ISO ... and emit a new ISO. In the case of
installation media, you can add packages to the ISO, but you also need
to modify the yum repodata as well. Also, in
On Fri, May 13, 2011 at 4:58 PM, James Laska wrote:
> I use the compose_tree.sh script included in AutoQA...
>
> $ git clone git://git.fedorahosted.org/autoqa.git
> $ autoqa/tests/compose_tree/compose_tree.sh -a x86_64 -r fedora-15 -e
> lorax-0.4.5-1.fc15
>
> This test pulls down provided updates
included in AutoQA...
$ git clone git://git.fedorahosted.org/autoqa.git
$ autoqa/tests/compose_tree/compose_tree.sh -a x86_64 -r fedora-15 -e
lorax-0.4.5-1.fc15
This test pulls down provided updates and uses and includes then to
build a boot.iso (or DVD).
> Does anyone know how to run a pungi
I build my own Fedora DVD install isos - and currently I have a need
to build an F15 DVD install isp using the latest version of the lorax
rpm that is in updates testing, but not yet in stable.
Does anyone know how to run a pungi build based on a standard
development/f15 mirror repo, but to use a
On Fri, 2010-10-22 at 13:54 +, "Jóhann B. Guðmundsson" wrote:
> On 10/22/2010 01:29 PM, James Laska wrote:
> > On Thu, 2010-10-21 at 03:24 -0400, Gregory Woodbury wrote:
> >> Hving given up on Revisor, I looked at pungi.py and stuff and see that
> >> it really wants a kickstart file?
> >>
> >>
On 10/22/2010 01:29 PM, James Laska wrote:
> On Thu, 2010-10-21 at 03:24 -0400, Gregory Woodbury wrote:
>> Hving given up on Revisor, I looked at pungi.py and stuff and see that
>> it really wants a kickstart file?
>>
>> Are these the kickstart files in the spins-ks package (whatever its
>> real na
On Thu, 2010-10-21 at 03:24 -0400, Gregory Woodbury wrote:
> Hving given up on Revisor, I looked at pungi.py and stuff and see that
> it really wants a kickstart file?
>
> Are these the kickstart files in the spins-ks package (whatever its
> real name is)?
>
> Is there currently a tool to make ki
On 10/21/2010 06:28 AM, Adam Williamson wrote:
> On Thu, 2010-10-21 at 03:24 -0400, Gregory Woodbury wrote:
> > Hving given up on Revisor, I looked at pungi.py and stuff and see that
> > it really wants a kickstart file?
> >
> > Are these the kickstart files in the spins-ks package (whatever its
On Thu, 2010-10-21 at 03:24 -0400, Gregory Woodbury wrote:
> Hving given up on Revisor, I looked at pungi.py and stuff and see that
> it really wants a kickstart file?
>
> Are these the kickstart files in the spins-ks package (whatever its
> real name is)?
>
> Is there currently a tool to make ki
nes in
the package by hand... it is not too difficult once you see the basic
structure.
Pungi works well - but I always run it inside a mock chroot - I have
posted details on this list in the past if you dig for it...
--
mike c
--
test mailing list
test@lists.fedoraproject.org
T
On Thu, 21 Oct 2010 03:24:22 -0400, Gregory wrote:
> Hving given up on Revisor, I looked at pungi.py and stuff and see that it
> really wants a kickstart file?
>
> Are these the kickstart files in the spins-ks package (whatever its real
> name is)?
>
> Is there currently a tool to make kickstart
Hving given up on Revisor, I looked at pungi.py and stuff and see that it
really wants a kickstart file?
Are these the kickstart files in the spins-ks package (whatever its real
name is)?
Is there currently a tool to make kickstart files?
Thanks for any guidance.
--
Greg Woodbury
aka redwolfe
78 matches
Mail list logo
