Leslie Satenstein wrote:

Mike

A reason for a withdraw may be due to security flaws detected.  The replacement will probably be a later version with the flaw corrected. (or some similar problem forcing a retraction).

Leslie

Hi Leslie

I would have thought there would be some hint of this on one of the forums if this were the case - but some have said the file is still accessible via ftp but not http! Weird. Also the same file is still visible on a couple of mirrors I checked.. maybe someone who knows from within Fedora might comment?

Mike

Going to http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/i... offers the file for download - so maybe it is a simple server error after all? ftp does work though as reported previously...

Leslie Satenstein wrote:

A reason for a withdraw may be due to security flaws detected.  The replacement will probably be a later version with the flaw corrected. (or some similar problem forcing a retraction).

Perhaps you'd want to include some rationale for making this statement? Otherwise, it seems inappropriate to make such a claim.

Its time for a respin. As Chuck Foresburg pointed out, there is nearly 800meg of updates available since the Nov 25th release date.

More bytes if one chooses all packages.

--- On Sun, 12/28/08, Kevin Kofler kevin.kofler@chello.at wrote: From: Kevin Kofler kevin.kofler@chello.at Subject: Re: Where has the F10 DVD iso file gone? To: fedora-test-list@redhat.com Date: Sunday, December 28, 2008, 8:02 PM

Leslie Satenstein wrote:

A reason for a withdraw may be due to security flaws detected.

No. Security flaws are fixed by updates, release ISOs are not respun.

Kevin Kofler

Leslie Satenstein wrote:

Its time for a respin. As Chuck Foresburg pointed out, there is nearly 800meg of updates available since the Nov 25th release date.

More bytes if one chooses all packages.

--- On Sun, 12/28/08, Kevin Kofler kevin.kofler@chello.at wrote: From: Kevin Kofler kevin.kofler@chello.at Subject: Re: Where has the F10 DVD iso file gone? To: fedora-test-list@redhat.com Date: Sunday, December 28, 2008, 8:02 PM

Leslie Satenstein wrote:

...

A reason for a withdraw may be due to security flaws detected.

No. Security flaws are fixed by updates, release ISOs are not respun.

I downloaded and installed F10 from CDs yesterday. I was not well impressed to find I needed a further 600 Mbytes of updates for a basic ia32 desktop install.

There is a need for regularly respun ISOs.

The taste became even more bitter when I found it doesn't work on an HP EVO D510 - xorg locks the system, and without a working network the only way to regain control is the power button, but that's another story.

On Tue, 2008-12-30 at 19:18 -0700, Lawrence E. Graves wrote:

I don't know what's all involved in the making of an iso, but it sound feasible.

I don't know what's all involved in the making of cold fusion, but it sounds feasible.

Chris Adams wrote:

Once upon a time, Lawrence E. Graves lgraves@risingstarmbc.com said:

...

John, strange you should say that. A few days ago, I asked a friend of mine that same question. I personally think that whenever there are updates to Fedora 10 after you have installed it, there should automatically be an undated ISO. When the need arises, there will always be a fresh version of Fedora 10. I don't know what's all involved in the making of an iso, but it sound feasible.

That certainly isn't feasible. There are updates almost every day, especially for the first couple of months after release. Ignoring the actual work involved in spinning a release, even if you just respin the DVD ISO and not the CDs or LiveCDs, and only for the binaries and not the sources, that would be almost 12G of daily churn (plus the actual updates) on the mirrors. Torrents wouldn't help with only a 24 hour "shelf life".

It also makes debugging somebody's install problems virtually impossible, since you have no idea what release-of-the-day they are using.

I think that you take Lawrence too literally. He and I agree the existing situation isn't good.

While I'm here, and since you mention torrents, I'm on this broadband plan: http://www.westnet.com.au/internet/broadband/broadband2+ULL.aspx

I can download F10 (and CentOS) from an approved mirror and that's fine. I use a torrent today, or install off the 'net as I did with F10 recently, I will be throttled (I'm a whisker under the limit) to 64 kBits/sec instead of the 1.8 Mbytes/sec I can get normally.

The reason I'm so close to the wind right now is (in part) that I did a network install of F10 early in the month, and instead of asking about my preferred mirror it used one (or several) outside my free zone.

Lawrence E. Graves wrote:

There's no need to be nasty, I very new at this and had no idea what's involve (as I mentioned before) in the making of an ISO. One day if I keep at it I will be as good as you profess to be.

The idea is fine, and should be taken seriously. IMV the main topic for discussion is "how often."

The resources are available, there are people making unofficial respins. I think "management" needs to take a good hard look at how to make those unofficial builds official.

It doesn't make sense to me to report a problem unless my software (especially in Fedora, OpenSUSE etc) is fully up to date.

A respin done on the first of the month (unless circumstances such as brokenware mandate otherwise), published and provisional for a week then made official (unless circumstances mandate otherwise).

On first thought the major risk here is that a broken Anaconda gets in and makes the result uninstallable. That sort of thing has happened in the past, it _could_ happen in Fedora.

A good alternative might be a weekly updates ISO, that contains just the latest versions of everything not in the base release, and formatted as a repo. Then, instead of downloading six CD images I'd have downloaded seven.

The updates image would be a good candidate for updating with jigdo too, basically all users need to do keep their ISO set current would be to run jigdo to get its latest .jigdo file and template, and the new packages.

Anaconda might need training to look for the updates CD or ISO image. That doesn't seem a big deal, I notice it can find install ISOs pretty well regardless of their filenames. Which reminds me, I have a CentOS to install.

CU

On Wed, 2008-12-31 at 13:27 +0900, John Summerfield wrote:

Lawrence E. Graves wrote:

...

There's no need to be nasty, I very new at this and had no idea what's involve (as I mentioned before) in the making of an ISO. One day if I keep at it I will be as good as you profess to be.

The idea is fine, and should be taken seriously. IMV the main topic for discussion is "how often."

The resources are available, there are people making unofficial respins. I think "management" needs to take a good hard look at how to make those unofficial builds official.

It doesn't make sense to me to report a problem unless my software (especially in Fedora, OpenSUSE etc) is fully up to date.

Exactly!

A respin done on the first of the month (unless circumstances such as brokenware mandate otherwise), published and provisional for a week then made official (unless circumstances mandate otherwise).

I would be a big supporter of a monthly respin. Even every 6 weeks might make sense if monthly is too fast for management. It seems to me that if we can automate much of the package update processes, why could we not do similar for a monthly respin update?

I've looked into the respins from Fedora Unity and frankly, their jigdo delivery method is far too much trouble. Why can't I download an ISO? Why do I have to use their ..umm.. tested build process and tools set? I've followed their instructions multiple times and have always ended up with a set of error messages and a huge cache of downloaded rpms a couple of hours after taking the trouble to try.

I don't fault jigdo per se on this. I think the base idea is a good one. It's the execution part that is at issue here.

The updates image would be a good candidate for updating with jigdo too, basically all users need to do keep their ISO set current would be to run jigdo to get its latest .jigdo file and template, and the new packages.

Indeed. If we can make the tools easy to manage, I think jigdo has great potential. Getting Revisor to work reliably for custom spins and updates would be another option. Work in this direction is clearly moving forward.

But again, if we are to go this far, why not go the extra step and make monthly updated ISOs available instead?

Cheers,

Chris

-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.

--Socrates

On Wed, 2008-12-31 at 10:26 -0500, Chuck Anderson wrote:

On Wed, Dec 31, 2008 at 06:16:27AM -0700, Christopher A. Williams wrote:

...

But again, if we are to go this far, why not go the extra step and make monthly updated ISOs available instead?

It is really a lot more difficult than you might think. Doing this "in-house" would put a stress on the already overworked releng team. The mirrors would need more space to store these extra ISOs. Bandwidth would be needed for mirroring and end-user downloads. Efforts would need to be spent doing QA on these respins. All of these tasks would detract developers and testers from working on the next Fedora release and maintaining the current ones.

It's not more difficult than I think. I know it's hard, but then again if this were easy to do, I submit a lot of us would already have done it by now.

I really would like to see more of us using our expertise to come up with options of how we could overcome these kinds of issues with realistic, workable solutions instead of using our collective knowledge and skills to come up with excuses for why it couldn't be done. I demand no less than this from the teams I lead. See my e-mail signature for part of my philosophy in this.

Not to mention--there already is a project to do respins, Fedora Unity. Ask them how much work it has been. If you want to improve their distribution method, then help them out instead of complaining that Fedora should do the work instead. Perhaps you could start your own mirror with ISO downloads of Fedora Unity respins.

I know all about, have been somewhat active with Fedora Unity, and appreciate their very hard work to date. I also do try to participate regularly as I am able, so perhaps it would be better if you stopped making assumptions about my so-called complaints...

Now - in the time it took for you to respond, I decided one again to go about the process of using Revisor to try and create my own updated, custom spin for myself. My experience underscores the points I was making before.

Revisor:

1) Failed to use the kickstart file I created despite that I specified one I had created using system-config-kickstart

2) Failed to connect to the repositories correctly at first - because it was looking by default for the F10 Updates-Newkey repository, which doesn't exist.

3) Although it allowed me to say I wanted to build a custom 64-bit spin, it got itself confused in package selection between 32-bit and 64-bit packages. There was no way to exclude the unwanted 32-bit packages. This resulted in...

...A set of conflicts where, after downloading and caching over 2GB of RPMs, dependency conflicts between 32-and 64-bit packages caused the entire process to fail.

Thus, as I mentioned in a previous post, I wound up once again with a stack of error messages and a huge cache of RPMs (almost half of which I didn't need for the task) on my hard drive for 90 minutes worth of work.

Shall I try to repeat the process with jigdo to make the others happy...?

My bottom line point is this: There is an established need for regularly updated ISOs. Fedora Unity, for example, would likely not exist at all if this need didn't exist. It doesn't matter that this is hard to do - it's still necessary. If the QA process is such that it's hard to get this through, then we need to not only fix the tools used to do spins / respins, we also need to fix and optimize (as necessary) the QA process which is involved in the effort. We should be finding ways to work smarter - not harder.

I'm a big believer in that a high quality set of efficient process and tools generally leads to quality products that are efficiently built and distributed. I also believe that the existing tools (both Revisor and Jigdo) are actually pretty close to being able to support the need. The problems I have found with them smack more of the kind of mistakes made because people are stressed, overworked, or just plain "brain farted" and forgot something really simple along the way. There are well-established things that could be done to address these issues.

As they own the distribution, the Fedora team absolutely needs to take ownership of fixing the overall issue. No excuses. That would allow groups like Fedora Unity to do what they do more easily. I'm willing to be a part of that process on an as available basis, but like others I still have my day job I need to do to feed my family. My wife has also made it perfectly clear that I need to continue being "Dad" to our kids and a husband to her (which is a good thing, by the way).

Cheers,

Chris

-- ==================================== "Ninety-nine percent of the failures come from people who have the habit of making excuses."

--George Washington Carver

On Wed, 2008-12-31 at 10:19 -0600, Chris Adams wrote:

Once upon a time, Christopher A. Williams chriswfedora@cawllc.com said:

...

As they own the distribution, the Fedora team absolutely needs to take ownership of fixing the overall issue. No excuses. That would allow groups like Fedora Unity to do what they do more easily. I'm willing to be a part of that process on an as available basis, but like others I still have my day job I need to do to feed my family. My wife has also made it perfectly clear that I need to continue being "Dad" to our kids and a husband to her (which is a good thing, by the way).

So, it's okay for you to make excuses why you can't help more, but you demand other volunteers do more?

Nice try.

No what I said is that I'm willing to do what I am able to do.

What I am NOT willing to do is to make promises I know I can't keep. I make no bones or excuses about it. More of us should try that. It would help negotiating the process of fixing the problem between all of us faster and much more painless...

On Wed, 2008-12-31 at 11:35 -0500, Chuck Anderson wrote:

On Wed, Dec 31, 2008 at 09:12:12AM -0700, Christopher A. Williams wrote:

...

Shall I try to repeat the process with jigdo to make the others happy...?

Have you tried an HTTP install, additionally specifying the updates repo? After all, why should you download an entire DVD iso when you might not need all those packages.

Because the goal was to create an updated ISO and (ideally) USB drive to install from.

I agree that HTTP installs are a solution for certain situations, but they don't cover the need I'm trying to address. That includes systems that, at least at the time of install, might not necessarily be connected or might not have a fast Internet connection...

-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.

--Socrates

On Wed, Dec 31, 2008 at 10:38 AM, Jesse Keating jkeating@redhat.com wrote:

On Wed, 2008-12-31 at 09:12 -0700, Christopher A. Williams wrote:

...

Revisor:

A small note here. Revisor isn't used by Fedora releng to create the install trees/isos we offer at release time. We use pungi, which is only command line, and lacks many of the extra features that Revisor has. However for the basic task of creating an install set, pungi is worth a try if revisor is giving you trouble.

-- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

There is also a great posting here about how to do it, http://jons-thoughts.blogspot.com/2008/05/pungi-and-mock-for-fun-and-profit....

--Brennan Ashton

On Wed, 2008-12-31 at 10:12 -0700, Christopher A. Williams wrote:

This does bring up another issue though. If Revisor isn't getting the job done and Pungi is what releng uses, why do we have Revisor? Or more to the point, why is there not a coordinated effort to share code between both for everyone's benefit? We all win of that happens.

They're kind of hitting two different targets. pungi was written to handle the task of creating Fedora, and creating things that look and act like Fedora. The only features I've really put in it were things usually necessary to getting the job of creating Fedora done, with some exceptions. The fact that people can use it on their own to create things that look like Fedora is a real bonus side-effect. The tool that was used to create Fedora before we merged Core and Extras was internal to Red Hat, and not actually licensed, and far too complicated for our needs, so I created something simple and usable.

Revisor adds to this a lot of features and functionality (like a gui!) that people have requested over the years for making things that look like Fedora, and things look completely different. Functionality and Features that I either was unable or unwilling to add to pungi.

There is some code sharing, or at least idea sharing. Over time as APIs mature there can be more code sharing.

Revisor should be getting the job done. If it's not, it would behoove you to either file bugs or talk directly to the authors to get it sorted out.

Christopher A. Williams-3 wrote:

Well - a little good new here. After beating on Revisor most of the afternoon today, I managed to get it to actually create a 64-bit DVD Install ISO! I'm going to try it out on a virtual machine in a minute to see how it does. Next up will be 64-bit live media.

In the meantime, I'm trying to find updated documentation. The Revisor Wiki pages only show stuff through version 2.0.5 while F10 has 2.1 and I've already read through all of that...

Now that sounds excellent - if you could share your steps in getting revisor to make a usable DVD iso with the rest of us then I bet it would be truly appreciated - and presumably using updated packages that were released since F10 release?

I have been slowly moving in that direction also - documentation is sparse and a good tutorial would be hugely valued.

Happy 2009!

On Thu, 2009-01-01 at 03:38 -0800, Mike Cloaked wrote:

Christopher A. Williams-3 wrote:

...

Well - a little good news here. After beating on Revisor most of the afternoon today, I managed to get it to actually create a 64-bit DVD Install ISO! I'm going to try it out on a virtual machine in a minute to see how it does. Next up will be 64-bit live media.

In the meantime, I'm trying to find updated documentation. The Revisor Wiki pages only show stuff through version 2.0.5 while F10 has 2.1 and I've already read through all of that...

Now that sounds excellent - if you could share your steps in getting revisor to make a usable DVD iso with the rest of us then I bet it would be truly appreciated - and presumably using updated packages that were released since F10 release?

I have been slowly moving in that direction also - documentation is sparse and a good tutorial would be hugely valued.

Well - I wish the news was as good as I had hoped...

Revisor did indeed spit out a DVD ISO for me. It even booted and ran an install in my VM. Unfortunately, what it installed turned out to be almost completely unusable. I also managed to build a custom 32-bit Live CD. Unfortunately it was no more usable than the DVD. I think I'm close though. Next step is to try this using the base F10 kickstart files (now that I have found a couple of them).

Side Question: Where is the official place the F10 kickstart files are supposed to be kept? This should be something relatively easy to get to, shouldn't it?

I have found a few other things about Revisor that should be highlighted brightly because I've seen the same problems with several other tools like Yum Extender.

It seems the reason why I can't build 64-bit Live images at all is because something in the package selection process / tools arbitrarily includes BOTH the 32-bit and 64-bit versions of everything you select in the package manifest instead of including just the 64-bit packages if they exist. This leads to the conflicts that cause the whole thing to fail. I think the reason it doesn't happen with 64-bit DVDs is because the selected package RPMs are only added to a specific directory on the DVD. Live images actually do a system installation as a part of the build process.

I've also seen this package selection behavior in Yum Extender (including the current version in F10). At least with Yum Extender, you can manually de-select all of the non-64-bit packages by hand. It's incredibly tedious to do, but it works. This also happened in versions of the package selection tool fka Add Or Remove Programs in F8 and earlier. Moreover, it also happens with kickstart files created via system-config-kickstart. I don't know if Package Kit has this problem or not yet.

Of note, this does NOT happen when trying to build 32-bit systems. The 64-bit packages are (correctly) ignored. It is only when trying to add package groups to 64-bit systems that the 32-bit packages are also selected. Since this is something common to several tools, I suspect the problem is either in something under the covers they all use or it is in code that they all share.

As to other issues with Revisor, what I'm finding is that a lot of stuff in the GUI either just doesn't work at all or is just plain broken. It clearly looks like a work in progress - with a lot of work left to be done. What I can tell you so far is:

1) Read the doc that does exist. It at least will give you a clue about how Revisor was intended to work, even if it doesn't exactly work that way because so much is broken or has been changed since the doc was written.

2) Develop as good an understanding of what the build process involves as a part of this so you know what the tools are trying to do along the way. Believe it or not, the doc on Pungi - sparse as it is - was extremely helpful to me in understanding more about Revisor.

3) Watch Revisor (and the other tools) closely. Every little error message will give you clues about things that you might be able to fix or find work-arounds for in this trial and error process.

Now - back to my original point: I still believe Revisor (along with the others) has terrific potential. It seems to be about 80% of the way there in terms of functionality and also needs some major bug fixing. If I were a coder, I would gladly help with fixing that stuff, but I'm not. As an Enterprise Infrastructure Architect, I can only help with this kind of testing and feedback unless you need help with designing the underlying server and network infrastructure needed to support the development platforms...

If these fixes can be implemented, we then have a reliable tool for creating custom spins. With that, we have the ability to begin automating the technical process for generating monthly ISO updates from the "gold" kickstart files. All that is then left is to examine and optimize the process for QA and release such that people who are already very busy don't have to take on more. I submit that, since the updated RPMs already have to go through a testing process, what actually needs to be tested for such an interim respin should be much smaller than a full release.

If people put their collective brains to this, it should be solvable.

Cheers,

Chris

-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.

--Socrates

On Thu, 2009-01-01 at 11:56 -0600, Brennan Ashton wrote:

On Thu, Jan 1, 2009 at 11:26 AM, Christopher A. Williams chriswfedora@cawllc.com wrote:

...

Well - I wish the news was as good as I had hoped...

Revisor did indeed spit out a DVD ISO for me. It even booted and ran an install in my VM. Unfortunately, what it installed turned out to be almost completely unusable. I also managed to build a custom 32-bit Live

Welcome to the life of Fedora QA

If this is the life you encounter and accept, I feel sorry for you. Based on my experience, you're living with a number of issues you shouldn't need to. The QA process is suffering from a lack of proper procedure and tools. Additional experience I'll note later supports what I'm saying, and the good news is that I think this can be fixed rather easily (thus making everybody happy).

...

Side Question: Where is the official place the F10 kickstart files are supposed to be kept? This should be something relatively easy to get to, shouldn't it?

yum whatprovides *-fedora.ks Loaded plugins: refresh-packagekit pungi-2.0.8-1.fc10.noarch : Distribution compose tool Repo : fedora Matched from: Filename : /usr/share/pungi/rawhide-fedora.ks Filename : /usr/share/pungi/f9-fedora.ks

spin-kickstarts-0.10.3-1.fc10.noarch : Kickstart files and templates for : creating your own Fedora Spins Repo : fedora Matched from: Filename : /usr/share/spin-kickstarts/fedora-install-fedora.ks

Based on history of your replies, this is a perfectly technical answer that really doesn't provide the answer. Since, fortunately, I am technical I was able to dig through this. HEre's the plain English translation for people who might be interested:

The "gold" kickstart files are part of a package called spin-kickstarts which is in the main Fedora repository. Install this package and all of them will be neatly deposited in the directory:

/usr/share/spin-kickstarts

My advice on this to everyone is to then read through the kickstart files. You'll find they are actually are modularized and then assembled on the fly via a series of include statements. There really aren't that many of them (I got through what I needed in 10 minutes of reading) and the naming convention used makes logical sense. By going through each of them, you'll begin to understand 1) how they get put together and 2) which one you really need to start with to build what you want.

...

I have found a few other things about Revisor that should be highlighted brightly because I've seen the same problems with several other tools like Yum Extender.

It seems the reason why I can't build 64-bit Live images at all is because something in the package selection process / tools arbitrarily includes BOTH the 32-bit and 64-bit versions of everything you select in the package manifest instead of including just the 64-bit packages if they exist. This leads to the conflicts that cause the whole thing to fail. I think the reason it doesn't happen with 64-bit DVDs is because the selected package RPMs are only added to a specific directory on the DVD. Live images actually do a system installation as a part of the build process.

Mock will make your life a lot easier

Perhaps. But mock is traditionally used with pungi. That helps with pungi, but not Revisor. It does at least have the potential / intent to do things that were never intended for pungi. The best scenario would be to get all of these tools working properly.

...

I've also seen this package selection behavior in Yum Extender (including the current version in F10). At least with Yum Extender, you can manually de-select all of the non-64-bit packages by hand. It's incredibly tedious to do, but it works. This also happened in versions of the package selection tool fka Add Or Remove Programs in F8 and earlier. Moreover, it also happens with kickstart files created via system-config-kickstart. I don't know if Package Kit has this problem or not yet.

Of note, this does NOT happen when trying to build 32-bit systems. The 64-bit packages are (correctly) ignored. It is only when trying to add package groups to 64-bit systems that the 32-bit packages are also selected. Since this is something common to several tools, I suspect the problem is either in something under the covers they all use or it is in code that they all share.

As to other issues with Revisor, what I'm finding is that a lot of stuff in the GUI either just doesn't work at all or is just plain broken. It clearly looks like a work in progress - with a lot of work left to be done. What I can tell you so far is:

1. Read the doc that does exist. It at least will give you a clue about

how Revisor was intended to work, even if it doesn't exactly work that way because so much is broken or has been changed since the doc was written.

I gave up of Revisor for straight ks builds

Well - I'm glad at this point that I didn't. Guess what? I have SUCCESSFULLY BUILT a respin of F10 Live i386 US English with all patches as of today! Once I figured out what needed to be done, it took all of a few minutes to re-spin. The install from my respun Live CD worked flawlessly in my VM, with yum correctly reporting that no updates were needed.

I'll sell how I did it to you for a small fee of $100... :)

Nah - seriously, I'll post how I did it later on today. Gotta go to my mom's house for some major New Year's Day eating first!

Building a 64-bit system was NOT successful - for the same reasons I brought up before about 32-bit packages being arbitrarily included with their 64-bit counterparts. Whatever is happening here has to be with code that is likely shared between Revisor, Yum Extender, and a few other tools. If we can get this part fixed, we will have made major strides forward.

...

2. Develop as good an understanding of what the build process involves

as a part of this so you know what the tools are trying to do along the way. Believe it or not, the doc on Pungi - sparse as it is - was extremely helpful to me in understanding more about Revisor.

Mock + pungi

While I will still also play around with this, I think I've been able to demonstrate for myself that this isn't a requirement. What I fail to understand from you on this is that, if you knew this combo to work, why you would refuse to provide step-by-step instructions (or at least point out where they might be) instead of taking positions like "it's too hard" and "join with Fedora Unity" when I (and others) have already been providing such feedback - and have clearly stated as such. This smacks of someone who is technically savvy, but has more interest in demonstrating that technical ability than helping to solve the actual issues.

Just because the Fedora Project currently puts out full releases faster than other groups right now doesn't mean this isn't a problem. Further, there is clearly evidence that this is something that can be fixed.

I stand by my original points:

1) The respin process should be something that is fully automated 2) The QA process clearly needs refinement so that people aren't overwhelmed by the work 3) Some basic fixes to existing tools would greatly help 4) The Fedora Team should be the overall owner of this issue. Not Fedora Unity or anyone else. This is particularly true since the ability to create custom spins quickly and easily is a highly advertised goal of the Fedora Project.

If the Fedora team wants to delegate this work, Fine. But then that should be done formally with all of the access points and processes and resources needed to support it.

Now - based on what I have found (some of which I will post later), can we please get some forward motion on organizing both the technical and process oriented pieces needed to fix this? I've put a lot of time into this already and will continue to do what I can. "It's too hard" and "Go work with Fedora Unity" are not acceptable answers - they're excuses.

-- ================================ "There's two strategies to arguin' with a woman: Neither one of 'em works."

--Cowboy Wisdom

On Thu, Jan 1, 2009 at 1:13 PM, Christopher A. Williams chriswfedora@cawllc.com wrote:

On Thu, 2009-01-01 at 11:56 -0600, Brennan Ashton wrote:

...

On Thu, Jan 1, 2009 at 11:26 AM, Christopher A. Williams chriswfedora@cawllc.com wrote:

...

Well - I wish the news was as good as I had hoped...

Revisor did indeed spit out a DVD ISO for me. It even booted and ran an install in my VM. Unfortunately, what it installed turned out to be almost completely unusable. I also managed to build a custom 32-bit Live

Welcome to the life of Fedora QA

If this is the life you encounter and accept, I feel sorry for you. Based on my experience, you're living with a number of issues you shouldn't need to. The QA process is suffering from a lack of proper procedure and tools. Additional experience I'll note later supports what I'm saying, and the good news is that I think this can be fixed rather easily (thus making everybody happy).

I am referring to all the test cases that get run before each release. Test, fix, test, release. This could go smooth or it could be a nightmare, it all depends on what little hidden bugs show there heads.

...

...

Side Question: Where is the official place the F10 kickstart files are supposed to be kept? This should be something relatively easy to get to, shouldn't it?

yum whatprovides *-fedora.ks Loaded plugins: refresh-packagekit pungi-2.0.8-1.fc10.noarch : Distribution compose tool Repo : fedora Matched from: Filename : /usr/share/pungi/rawhide-fedora.ks Filename : /usr/share/pungi/f9-fedora.ks

spin-kickstarts-0.10.3-1.fc10.noarch : Kickstart files and templates for : creating your own Fedora Spins Repo : fedora Matched from: Filename : /usr/share/spin-kickstarts/fedora-install-fedora.ks

Based on history of your replies, this is a perfectly technical answer that really doesn't provide the answer. Since, fortunately, I am technical I was able to dig through this. HEre's the plain English translation for people who might be interested:

The "gold" kickstart files are part of a package called spin-kickstarts which is in the main Fedora repository. Install this package and all of them will be neatly deposited in the directory:

/usr/share/spin-kickstarts

I thought about that I as I pasted it, but I came to the conclusion that this way people can see how to find the answers to some of these type of questions. But thank you for translating.

My advice on this to everyone is to then read through the kickstart files. You'll find they are actually are modularized and then assembled on the fly via a series of include statements. There really aren't that many of them (I got through what I needed in 10 minutes of reading) and the naming convention used makes logical sense. By going through each of them, you'll begin to understand 1) how they get put together and 2) which one you really need to start with to build what you want.

...

...

I have found a few other things about Revisor that should be highlighted brightly because I've seen the same problems with several other tools like Yum Extender.

It seems the reason why I can't build 64-bit Live images at all is because something in the package selection process / tools arbitrarily includes BOTH the 32-bit and 64-bit versions of everything you select in the package manifest instead of including just the 64-bit packages if they exist. This leads to the conflicts that cause the whole thing to fail. I think the reason it doesn't happen with 64-bit DVDs is because the selected package RPMs are only added to a specific directory on the DVD. Live images actually do a system installation as a part of the build process.

Mock will make your life a lot easier

Perhaps. But mock is traditionally used with pungi. That helps with pungi, but not Revisor. It does at least have the potential / intent to do things that were never intended for pungi. The best scenario would be to get all of these tools working properly.

I dont trust building outside of a chroot, because I do not know what is going to be drawn in from my system. This might not be a valid concern feel free to correct me / educate me.

...

...

I've also seen this package selection behavior in Yum Extender (including the current version in F10). At least with Yum Extender, you can manually de-select all of the non-64-bit packages by hand. It's incredibly tedious to do, but it works. This also happened in versions of the package selection tool fka Add Or Remove Programs in F8 and earlier. Moreover, it also happens with kickstart files created via system-config-kickstart. I don't know if Package Kit has this problem or not yet.

Of note, this does NOT happen when trying to build 32-bit systems. The 64-bit packages are (correctly) ignored. It is only when trying to add package groups to 64-bit systems that the 32-bit packages are also selected. Since this is something common to several tools, I suspect the problem is either in something under the covers they all use or it is in code that they all share.

As to other issues with Revisor, what I'm finding is that a lot of stuff in the GUI either just doesn't work at all or is just plain broken. It clearly looks like a work in progress - with a lot of work left to be done. What I can tell you so far is:

1. Read the doc that does exist. It at least will give you a clue about

how Revisor was intended to work, even if it doesn't exactly work that way because so much is broken or has been changed since the doc was written.

I gave up of Revisor for straight ks builds

Well - I'm glad at this point that I didn't. Guess what? I have SUCCESSFULLY BUILT a respin of F10 Live i386 US English with all patches as of today! Once I figured out what needed to be done, it took all of a few minutes to re-spin. The install from my respun Live CD worked flawlessly in my VM, with yum correctly reporting that no updates were needed.

I'll sell how I did it to you for a small fee of $100... :)

Nah - seriously, I'll post how I did it later on today. Gotta go to my mom's house for some major New Year's Day eating first!

I will give what you put up a try, its not that I am anti revisor, it is that I understand mock and pungi much more.

Building a 64-bit system was NOT successful - for the same reasons I brought up before about 32-bit packages being arbitrarily included with their 64-bit counterparts. Whatever is happening here has to be with code that is likely shared between Revisor, Yum Extender, and a few other tools. If we can get this part fixed, we will have made major strides forward.

This is what I like about mock, it will keep that from happening.

...

...

2. Develop as good an understanding of what the build process involves

as a part of this so you know what the tools are trying to do along the way. Believe it or not, the doc on Pungi - sparse as it is - was extremely helpful to me in understanding more about Revisor.

Mock + pungi

While I will still also play around with this, I think I've been able to demonstrate for myself that this isn't a requirement. What I fail to understand from you on this is that, if you knew this combo to work, why you would refuse to provide step-by-step instructions (or at least point out where they might be) instead of taking positions like "it's too hard" and "join with Fedora Unity" when I (and others) have already been providing such feedback - and have clearly stated as such. This smacks of someone who is technically savvy, but has more interest in demonstrating that technical ability than helping to solve the actual issues.

The comment about fedora unity was that what they are trying to do is what (i think) you are trying to do and a joint effort might help build a better fedora, I am not trying to smack anyone down, a little over a year ago I knew nothing about koji/mock/pungi etc...

Just because the Fedora Project currently puts out full releases faster than other groups right now doesn't mean this isn't a problem. Further, there is clearly evidence that this is something that can be fixed.

I stand by my original points:

1. The respin process should be something that is fully automated

In the long run I agree, but until someone makes the magic tools to do all the install test cases that is going to be hard. Think https://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install every week. If you want to do this kind of automation I really think mock/pungi is going to be your friend that is what it was made for.

2. The QA process clearly needs refinement so that people aren't

overwhelmed by the work

Some automation might be nice see above.

3. Some basic fixes to existing tools would greatly help

Not to be blunt, but what is "broken" bug #?

4. The Fedora Team should be the overall owner of this issue. Not Fedora

Unity or anyone else. This is particularly true since the ability to create custom spins quickly and easily is a highly advertised goal of the Fedora Project.

I agree, but a project larger group backing I would expect to be more likely to be considered by FESCo. As they have said for the Long-Term-Support get something going independently and they will pull it in.

If the Fedora team wants to delegate this work, Fine. But then that should be done formally with all of the access points and processes and resources needed to support it.

See above.

Now - based on what I have found (some of which I will post later), can we please get some forward motion on organizing both the technical and process oriented pieces needed to fix this? I've put a lot of time into this already and will continue to do what I can. "It's too hard" and "Go work with Fedora Unity" are not acceptable answers - they're excuses.

Did you click the link that I pointed to now 3 times, I also offered to help via IRC. http://jons-thoughts.blogspot.com/2008/05/pungi-and-mock-for-fun-and-profit.... I am trying to help not make excuses.

--

"There's two strategies to arguin' with a woman: Neither one of 'em works."

--Cowboy Wisdom

On Thu, 2009-01-01 at 13:52 -0600, Brennan Ashton wrote:

On Thu, Jan 1, 2009 at 1:13 PM, Christopher A. Williams chriswfedora@cawllc.com wrote:

...

On Thu, 2009-01-01 at 11:56 -0600, Brennan Ashton wrote:

...

On Thu, Jan 1, 2009 at 11:26 AM, Christopher A. Williams

New Year's Day eating was much more serious than anticipated. Thus the delay in posting this due to a requirement to sleep it off. Boy was that gumbo good though - thanks Mom!!!!

...

Perhaps. But mock is traditionally used with pungi. That helps with pungi, but not Revisor. It does at least have the potential / intent to do things that were never intended for pungi. The best scenario would be to get all of these tools working properly.

I dont trust building outside of a chroot, because I do not know what is going to be drawn in from my system. This might not be a valid concern feel free to correct me / educate me.

I agree that the level of risk of hosing your system with something like this is greater outside of a chrooted environment. I too get a little queasy feeling with this, but the risk admittedly is not a wholly unacceptable one. At some point, every system requires the use of certain programs that have to run with root authority.

Now that said, I would actually like to see improvements to anaconda such that things like root authority and putting selinux into permissive mode are not requirements for building this stuff. I do consider having this is a requirement to be a bug.

...

Well - I'm glad at this point that I didn't. Guess what? I have SUCCESSFULLY BUILT a respin of F10 Live i386 US English with all patches as of today! Once I figured out what needed to be done, it took all of a few minutes to re-spin. The install from my respun Live CD worked flawlessly in my VM, with yum correctly reporting that no updates were needed.

I'll sell how I did it to you for a small fee of $100... :)

Nah - seriously, I'll post how I did it later on today. Gotta go to my mom's house for some major New Year's Day eating first!

I will give what you put up a try, its not that I am anti revisor, it is that I understand mock and pungi much more.

OK - Here's what I did:

I'm assuming that everyone has all of the revisor tools, along with pungi and it's supporting components, and the kickstart examples installed. You probably don't need all of this, but that's what I wound up with after all of the playing around.

As a side note, if you read the Revisor documentation, you will find that it actually depends quite a bit on pungi for what it does. It seems to be more a GUI based extension of pungi with more options and a lot of still to be implemented ideas. I would tend to characterize its relationship to pungi as being similar to the relationship between yum and Yum Extender.

The biggest key is understanding that a bunch of stuff is broken in the Revisor GUI. It ranges from many features that are grayed out because they aren't fully implemented to little stuff like that the Help--> About dialog does not properly launch the Revisor Website when you click the URL. If you dig around their bug tracking system, you'll find much of this is known and documented. It's just not fixed / completed / etc.

Make sure that selinux is in permissive mode when you start. If you don't do this, Revisor will complain to you that this is needed and will then exit.

Okay... After clicking the Get Started button, you get to the first wizard dialog. Make sure that the model is set for f10 i386, and that you de-select the (non-existent) F10-Updates-Newkey repository. Everything else on this menu turns out to be OK for the task at hand. Click forward to the next step...

At the next dialog, specify that you want to use the fedora-livecd-desktop-en_US.ks kickstart file located in /usr/share/spin-klickstarts (Note to others: you did install spin-kickstarts, right...?). If you want a different language or Live CD (like with KDE), select the appropriate kickstart file for what you want instead.

Be sure that:

1) The "Use the repositories specified in the kickstart file" option is NOT checked

2) The "Use the package manifest specified in the kickstart file" option IS checked.

At your option, you can check that you want to further customize the package list. I've done this both ways and it does work, although the GUI might lead you to believe otherwise. More on that later.

Next, click forward through the rest of the setup menus. Note that when the package list is first displayed, it appears as if there are no packages selected. This is a lie!!! Everything in the kickstart list has been selected - it just doesn't show up.

Further, if you opt to customize the package list even more, it will still look like nothing is selected other than what you picked. This another problem I consider to be a bug (like the other things I'm writing about). In reality, everything in the kickstart file will be used, and you are just going through the list to add whatever else you want.

Unfortunately, because this list is NOT pre-populated with items from the kickstart file, you can't opt to NOT use something that might be in the kickstart package list. You can only use this dialog to ADD more things to the manifest.

OK - once you are satisfied with these choices and hit the forward button, it will throw one last error message at you that a small number of rather obscure packages don't exist and that the results might therefore not be what you expect. Take a deep breath and ignore this. I call this trusting that the people who built the kickstart files actually knew what they were doing...

Then we wait for a very long time as Revisor downloads RPM files, builds all of the options and creates the final ISO. It will look like it's not responding on numerous occasions. Just let it be - it will finish. Depending on the speed of your computer, Internet connection, and how much was already cached from previous attempts, this could easily take a couple of hours.

If all goes well, in the end you will wind up with a newly minted F10 i386 Live CD ISO built from the latest available RPMs. Mine works great!

From this, you can use the livecd tools to build a bootable USB drive,

or you can just burn a CD - your choice as usual.

...

Building a 64-bit system was NOT successful - for the same reasons I brought up before about 32-bit packages being arbitrarily included with their 64-bit counterparts. Whatever is happening here has to be with code that is likely shared between Revisor, Yum Extender, and a few other tools. If we can get this part fixed, we will have made major strides forward.

This is what I like about mock, it will keep that from happening.

OK - Good info. This then supports the notion Revisor and some other tools like Yum Extender are doing something they should not be doing with package selection, and may be doing it because they share the same (buggy) code. This needs to be investigated and fixed. I would propose that, if they only selected 64-bit packages instead of overcompensating like they apparently are, the dep resolver could work out the rest when changes are committed. Since the resolver is going to run anyway, it would probably make things a lot cleaner.

The comment about fedora unity was that what they are trying to do is what (i think) you are trying to do and a joint effort might help build a better fedora, I am not trying to smack anyone down, a little over a year ago I knew nothing about koji/mock/pungi etc...

I don't have a problem with that. It's just that this came as if my pointing out that my previously noted efforts to work with Fedora Unity seemed to fall on deaf ears. I think what Fedora Unity is doing is very similar, but it isn't exactly the same. It is close enough that cooperation is something that would seem critical to success. They also seem to be flailing with tools selection and use. For example, instead of fixing Revisor, we add jigdo for obtaining Fedora Unity respins and a process of using it that is just as complex and prone to errors.

This seems to happen a lot - instead of improving / fixing the tools we have, we throw the baby out with the bathwater and write completely new tools that are just as complex, but with different problems that never get fixed because we decide to just write something completely new again...

I'm all for choice in tools. I just prefer having a choice of tools that all actually work reliably.

...

Just because the Fedora Project currently puts out full releases faster than other groups right now doesn't mean this isn't a problem. Further, there is clearly evidence that this is something that can be fixed.

I stand by my original points:

1. The respin process should be something that is fully automated

In the long run I agree, but until someone makes the magic tools to do all the install test cases that is going to be hard. Think https://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install every week. If you want to do this kind of automation I really think mock/pungi is going to be your friend that is what it was made for.

I think the solution is multi-faceted. Respins should not need to go through the same level of testing as a full release to begin with.

That said, I think this could be automated using a combination of technologies -including mock and pungi. I've done this kind of work before using virtual infrastructure tools and systems. While these will not cover every scenario listed in the URL, they can do a surprising amount of this kind of work very quickly and effectively.

...

2. The QA process clearly needs refinement so that people aren't

overwhelmed by the work

Some automation might be nice see above.

...

3. Some basic fixes to existing tools would greatly help

Not to be blunt, but what is "broken" bug #?

Blunt answer. Lots of stuff is broken - some of it is captured and marked as bugs, and some of it isn't. I think I have been describing stuff that is broken in pretty good detail already. Just because something isn't in Bugzilla doesn't mean it's not broken. It just means it should be put in there AND it should be fixed.

...

4. The Fedora Team should be the overall owner of this issue. Not Fedora

Unity or anyone else. This is particularly true since the ability to create custom spins quickly and easily is a highly advertised goal of the Fedora Project.

I agree, but a project larger group backing I would expect to be more likely to be considered by FESCo. As they have said for the Long-Term-Support get something going independently and they will pull it in.

Perhaps this is just a philosophical difference. If FESCo advertises respin / custom spin capability as a new feature that will be a part of Fedora, it is not something they should then wait for some other group to start for them and then decide to pick it up when they're happy it works. They should be seeding those groups and actively supporting them if they aren't going to do it themselves.

Announcing new, promised features and then hoping someone out there picks it up and actually implements it for you is not a good way to manage software development.

...

Now - based on what I have found (some of which I will post later), can we please get some forward motion on organizing both the technical and process oriented pieces needed to fix this? I've put a lot of time into this already and will continue to do what I can. "It's too hard" and "Go work with Fedora Unity" are not acceptable answers - they're excuses.

Did you click the link that I pointed to now 3 times, I also offered to help via IRC. http://jons-thoughts.blogspot.com/2008/05/pungi-and-mock-for-fun-and-profit.... I am trying to help not make excuses.

Actually, I'm not a frequenter of IRC. But indeed I did look at that URL the first time you posted it. I thought it was a terrific "geeks guide" commentary for mock and pungi. It was definitely not for beginners though, and it also should not be considered a stand-alone guide - you definitely still want to read the pungi doc itself. It is one of the articles I mentioned before that gave me more clues about what really needed to happen.

In all, I read it, the pungi doc, the Revisor doc, some of the fedoraforum posts on the topic, the Revisor bug lists, and some of the available release notes. Oddly enough, I actually found the pungi documentation extremely helpful for Revisor. Once I understood the dependency / relationship Revisor has with pungi, both tools made a lot more sense.

With the holiday season coming to an end and my work schedule picking back up, I'm going to have much less time to work on this over the next several weeks. I'll continue to do what I can, but it would be really nice if this could be pushed forward more by others.

Cheers,

Chris

On 12/31/08, Chuck Anderson cra@wpi.edu wrote:

On Wed, Dec 31, 2008 at 06:16:27AM -0700, Christopher A. Williams wrote:

...

But again, if we are to go this far, why not go the extra step and make monthly updated ISOs available instead?

It is really a lot more difficult than you might think. Doing this "in-house" would put a stress on the already overworked releng team. The mirrors would need more space to store these extra ISOs. Bandwidth would be needed for mirroring and end-user downloads. Efforts would need to be spent doing QA on these respins. All of these tasks would detract developers and testers from working on the next Fedora release and maintaining the current ones.

The world does not end during the *weekly* snapshots built during the many weeks prior to release. We're not asking for that - I think even a single 3rd Month respin is a reasonable start. Not any great investment, for potentially good result.

Not to mention--there already is a project to do respins, Fedora Unity. Ask them how much work it has been. If you want to improve their distribution method, then help them out instead of complaining that Fedora should do the work instead. Perhaps you could start your own mirror with ISO downloads of Fedora Unity respins.

Not the same, and you know it. We're not asking Fedora to do any extra "work", just manipulate a few more bits. Finally, even RHEL releases iso's every six months. Fedora should be improving on that, not be satisfied with it.

jerry

On 1/1/09, Chuck Anderson cra@wpi.edu wrote:

On Thu, Jan 01, 2009 at 01:50:35PM -0600, Jerry Amundson wrote:

...

Not the same, and you know it.

How is Fedora Unity not exactly the same as what people here are asking for?

Because it doesn't have the Fedora Project behind it, duh.

jerry

On 1/2/09, Jesse Keating jkeating@redhat.com wrote:

The Fedora Project, that you're not asking to do any extra work? Ok.

Oh puuuhlease! The "extra work" card? Bzzt, try again. Run the script, send the announcement e-mail. It's not like we're asking for someone to walk ten miles, uphill, to hand deliver a respin DVD. As I mentioned earlier, if it were *really* that difficult, the snapshot releases shouldn't happen either.

jerry

On Fri, 2009-01-02 at 14:05 -0800, Jesse Keating wrote:

Do you really not have any idea how much work gets put into the snapshot releases? Let alone something that wouldn't be "snapshot, if it breaks, you keep the pieces" quality, but instead something high enough quality to put the Fedora name and official release stamp on it.

You seriously seriously underestimate the amount of work that goes into these things, particularly the QA side.

Lets not even talk about how many of the tools that Anaconda uses to install systems change within a release enough to require modifications to Anaconda to work with the new versions.

There is a good reason why the "Fedora Project" doesn't spend time on respins. 6 months is a very short cycle between major releases, especially when you consider all the developmental releases done from Rawhide. Adding more compose targets to that mix greatly stretches the already small handful of volunteers and employees who spend their time trying to make these things show up, try to improve the software used for making them, and try to improve the software used for building and testing Fedora.

OK - So if that's true, they why did the Fedora Project make such a hoopla about being able to do custom spins and respins in the first place? You can't have this both ways.

This sounds like more excuses to cover for that we haven't really gone back and looked into what it would take to optimize a set of very important processes so people don't have to be overworked in the first place.

Why are we not questioning Anaconda as something that isn't capable of handling the current and likely to accelerate rate of change?

Why is the testing procedure so complex and daunting? And if it's such a big deal, why then are updates that come out post-spin NOT considered to be in need of the same degree of testing? After all, they get the official Fedora Project seal of quality too.

Just to check it out, I just reloaded a system with a fresh copy of 32-bit F10 Live from the CD. This is an older system that was running F8, but it has 1GB RAM and a 2.4GHz Pentium processor. Time to install, including updates and not including adding any additional packages, was just over 2 hours, and more than half of that time was devoted to downloading and installing the updates. Adding the extra custom packages after the updates is faster than installing everything I need from DVD and then running updates on all of it. I'd be here all night. Instead, I can queue up the extra packages I want from Yum Extender and let it run all night.

...And that, by the way, is exactly why this is an issue many people have.

If this is too hard, change review and optimize the process and improve the tools - and do it before we add even more features and complexity to Fedora lest the problem get even bigger.

...And please stop it with the "Let Fedora Unity" do it tripe. Unless and until Fedora Unity is an officially sanctioned and supported part of the Fedora Project, this is the Fedora Project's issue. Fedora Unity is doing the Fedora Project a favor by trying to help solve a problem that the Fedora Project, to date, has only made excuses about as opposed to thinking outside of the box and looking for solutions.

-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.

--Socrates

On Tue, 2009-01-13 at 16:10 -0800, Jesse Keating wrote:

On Fri, 2009-01-02 at 22:01 -0700, Christopher A. Williams wrote:

...

On Fri, 2009-01-02 at 14:05 -0800, Jesse Keating wrote:

...

...

There is a good reason why the "Fedora Project" doesn't spend time on respins. 6 months is a very short cycle between major releases, especially when you consider all the developmental releases done from Rawhide. Adding more compose targets to that mix greatly stretches the already small handful of volunteers and employees who spend their time trying to make these things show up, try to improve the software used for making them, and try to improve the software used for building and testing Fedora.

OK - So if that's true, they why did the Fedora Project make such a hoopla about being able to do custom spins and respins in the first place? You can't have this both ways.

Custom spins is what we were advertising, taking the GOLD package set and mixing it up in different ways to accomplish different goals. This doesn't include adding newer versions of software that is very much not tested in this scenario (ie the install environment).

OK fine. This is news that hasn't been communicated before.

...

This sounds like more excuses to cover for that we haven't really gone back and looked into what it would take to optimize a set of very important processes so people don't have to be overworked in the first place.

Why are we not questioning Anaconda as something that isn't capable of handling the current and likely to accelerate rate of change?

We do question the various pieces of software that anaconda uses very time they change. ABI/API changes happen, sometimes more frequently than we'd like, especially when they happen in a "stable" release tree. I've brought this up many times and I always get yelled at for trying to stifle Fedora's freedom to change things in a stable release. Fedora maintainers/users can't have it both ways either.

Well, at least we can find some agreement here. Within a release, you absolutely have to draw a line in some places. Things that directly impact core function would be a good example. Next time people yell at you over this, let me know and I'll join your chorus of yelling back.

But since we know there is always going to be an extremely high rate of change, the question remains about if core packages can be readily adapted to handle it well. So far, the example given was about the software that anaconda uses as opposed to anaconda itself.

...

Why is the testing procedure so complex and daunting? And if it's such a big deal, why then are updates that come out post-spin NOT considered to be in need of the same degree of testing? After all, they get the official Fedora Project seal of quality too.

The updates get as much testing as the community of users for those packages provide. Some get a lot, some get none. Fedora is what the maintainers and users make of it. Hardly any of this testing covers usage of that software in the scenario of the anaconda environment, that's just not a use case that many of us aren't really interested in outside of rawhide preparing for the next release. We'd rather be working on new features, infrastructure for automated testing, faster compose tools, better maintainer tools, etc... instead of spending our time worrying about updated spins of a distribution that will only be the "newest" for 6 short months.

This is a scary answer. So what you're saying here means changes to software components could potentially go out completely untested between releases. Yet at the same time, if someone has a problem, the first question almost always is, "Have you installed all of the updates?" That means the moment I run updates on a Fedora release, I have what equates to a not fully tested and certified system that isn't much better in quality than rawhide itself. At least from a software change management discipline perspective that's what I have. And I have to move to this configuration before most in the community will help.

Meanwhile, the people deploying these changes have new features for the next release as a higher priority. The only saving grace is a similar priority for better and automated testing / maintainer tools exists. And all because we're going to start anew in 6 months or less.

Might as well run rawhide all the time.

I don't see how respinning an updated install tree really helps. No matter how late you get on the Fedora train, for these people the updates will be too fast and too numerous. The only way to fix that is to slow down the updates, and well I wish you good luck in convincing the Fedora contributors at large to agree to that one.

...Which is why you might not understand the rationale behind Fedora Unity respin effort. I disagree that the solution is to slow down the update process. The solution is to optimize a process whereby an updated respin is easy to do. I and others have already demonstrated this is closer than you may realize. And, given the previous statements about patches, the support / certification / QA arguments about respins go out the window. Just leave the "gold" media as the only officially certified, make it easy to do updated respins, and make sure people who use them understand they do so on their own.

Of course, an alternate solution for speedy updates is also now apparently in the works. That would be making Presto the default mechanism.

...

...And please stop it with the "Let Fedora Unity" do it tripe. Unless and until Fedora Unity is an officially sanctioned and supported part of the Fedora Project, this is the Fedora Project's issue. Fedora Unity is doing the Fedora Project a favor by trying to help solve a problem that the Fedora Project, to date, has only made excuses about as opposed to thinking outside of the box and looking for solutions.

This is not even worth replying to.

...Ahhh, but you DID reply to it didn't you. Must have struck a nerve.

Look, I admit this was in part a barb - placed there in rebuttal to other barbs where people were clearly passing the buck. The "it can't be done" argument was getting pretty old. The call for people to start looking for solutions instead of complaining how something couldn't be done is absolutely valid given the context and history of this thread.

Isn't thinking outside of the box and asking how we would be able to do something how we drive innovations and new features in Fedora? The same kinds of new features and capabilities you yourself stated are a high priority?

-- ==================================== "Behind every double standard lies a single hidden agenda."

--G. K. Chesterton

On Tue, 2009-01-13 at 22:01 -0600, Bruno Wolff III wrote:

On Tue, Jan 13, 2009 at 18:41:49 -0700, "Christopher A. Williams" chriswfedora@cawllc.com wrote:

...

...Which is why you might not understand the rationale behind Fedora Unity respin effort. I disagree that the solution is to slow down the update process. The solution is to optimize a process whereby an updated respin is easy to do. I and others have already demonstrated this is closer than you may realize. And, given the previous statements about patches, the support / certification / QA arguments about respins go out the window. Just leave the "gold" media as the only officially certified, make it easy to do updated respins, and make sure people who use them understand they do so on their own.

It is already pretty easy to redo on your own. You can run livecd-creator using whichever combo of repositories you like with a kickstart file (and a number of samples of these exist) to build a live cd or dvd. You can install off the live dvd.

Indeed...!

I'm still playing around with this, but my first pass seems to have minted a nice, updated F10 Live CD. And it was impressively simple to do.

Only limitations I'm seeing so far are that you can only create ISOs for the platform you are currently working on. Perhaps combining this with mock could overcome that.

And since you can do this using most any reasonable kickstart file, it should also be just as easy to create updated, custom spins for your own purposes.

Add an adaptation of the Live USB Creator GUI as a front-end to all of this (or add this as an extension to the Live USB Creator), and you come up with a "requested feature complete" tool capable of creating custom or updated spins suitable for CD, DVD, or USB use.

Where do I go to submit the Bugzilla Feature Enhancement request...? :)

Cheers,

Chris

-- ========================================= "In theory there is no difference between theory and practice. In practice there is."

--Yogi Berra

Jesse Keating-3 wrote:

The Fedora Project, that you're not asking to do any extra work? Ok.

Based on the information posted earlier in this thread, and after doing a little reading, I thought I would try my hand at building a new updated iso for the i386 DVD install for F10 to see how much work it really involves....

This is what I have done this evening in a newly installed F10 on an old laptop to create a new spin using mock/pungi:

Made sure mock, spin-kickstarts and pungi are installed.

As root: 1) gpasswd -a mike mock to add mike to the mock group. All the remaining commands can be done as normal user.

2) Then as user mike I did mock -r fedora-10-i386 --init

This takes a while - seems to do lots of stuff - then clearly creates files somewhere! In fact I found they are in /var/lib/mock when outside the chrooted environment.

The original mock files are in /etc/mock

3) Need to install spin-kickstarts in the chroot so

mock -r fedora-10-i386 --install spin-kickstarts

also will need vim so do the same replacing vim for spin-kickstarts in the above command.

4) Now install pungi into the chroot: mock -r fedora-10-i386 --install pungi

It takes a while and no output!

5) Now get a shell within the chroot mock -r fedora-10-i386 --shell

This gives a mock-chroot> prompt to indicate we are in the shell

6) Note that the files created within the chroot are accessible from outside the chroot at /var/lib/mock/

7) Edit the appropriate kickstart file as needed - I cp the appropriate file from /usr/share/spin-kickstarts into the same directory within the chroot then edit the new file to suit my needs. I made the new file fedora-install-mikespin.ks in the same dir.

Changed the mirror lines.

repo --name=f10 --baseurl=http://path-to-mirror/fedora/linux/releases/10/Everything/$basearch/os/ repo --name=f10-updates baseurl=http://path-to-mirror/fedora/linux/updates/10/$basearch/

Also removed all the language support except for british-support as I don't need the others - this can be configured as needed by anyone doing a similar build.

You could add or subtract stuff as necessary from the kickstart file to personalise it - the above are the only changes I made.

8) Can cleanup doing mock-chroot> rm -f /var/lib/rpm/__db.00* This is not strictly necessary if building for the same arch - in my case running i386 and building i386 I did not do it as not vital if composing for same arch.

9) Now we can run the build...

mock-chroot> pungi -c /usr/share/spin-kickstarts/fedora-install-mikespin.ks --de stdir=/compose --nosplitmedia --nosource

This will likely take a long time - currently it is gathering rpms - hopefully it will then do the build and create the iso. I'll go get a long coffee/head to bed/read Thomas Hardy novel/stare out of the window for some time - or even post what I did to Fedora List!

So if this all works then this should be doable by most moderately experienced Fedora users.

Once done I will check the compose directory in /var/lib/mock/fedora-10-i386/root/compose from outside the chroot to check if the new DVD iso containing up to date rpms, and netinsall.iso have been created - and then copy them out and test install. Of course this will not build the course RPMS but in this case I am only running this as a test and not for external publication. Someone could of course re-produce/improve this and make isos for Fedora Unity I guess?

I imagine guidance in this post could be followed relatively easily. Of course this is only using mock/pungi in the CLI, and details for using revisor were posted earlier in the thread if someone wants to rebuild using a GUI facility.

Maybe this will help others who wish to create updated isos for install to avoid some of the problems that came with the original release iso for particular hardware such as scsi disks and particular graphics cards?

Of course anyone creating an iso this way takes their own responsibility if it fails! I am just saying what I did for my own use.

Best wishes

Mike

Horst H. von Brand wrote:

Creating the image is rather easy; checking that it doesn't break badly or has any other undesired side effects, repeating the above for all supported architectures, shipping them out to mirrors (and getting mirrors to agree on carrying more large files) is where the real work is. Plus the risk of

Accepted - but I was doing a private re-spin for my own use.

giving Fedora a bad name with a busted respin. Just check how long it takes to move from the first images to the images finally shipped on release. Sure, for a respin the work would be somewhat less (much less brand-new contents), but still.

Of course - but as I said it was/is a private respin - if someone does this and it breaks their system then Fedora is not responsible. However I do know of some people who installed the release iso for F10 on a machine with real scsi disks and this left them with an unbootable system until an install from the DVD physical media was done in a different way.

Doing a private iso with updated mkinitrd/kernel/nash that were issued as updates since release might have helped in that case.

Besides, there is Fedora Unity... why do a job others have already volunteered to do?

At the present time I have not seen a re-spin available from Fedora Unity for the DVD install iso? SO making a private one is for me under this scenario the only option!

Once upon a time, Lawrence E. Graves lgraves@risingstarmbc.com said:

There's no need to be nasty, I very new at this and had no idea what's involve (as I mentioned before) in the making of an ISO.

I wasn't trying to be nasty, just trying to explain why it wasn't feasible to do what you said. Making the ISO is just one part of the problem; actually distributing it is a lot of work as well. I run a Fedora mirror, and a lot goes on behind the scenes to make it (relatively anyway) easy to access Fedora.

One day if I keep at it I will be as good as you profess to be.

No need to be rude. I certainly don't have all the answers.

The only way I think something like this could be feasible (from a "getting the bits out there" point of view anyway) would be to update only the jigdo files (and still maybe only for the binary DVDs). That doesn't remove the work required to generate the release (because the DVDs still have to be generated to generate the jigdo files), and doesn't solve the problem of debugging random installs though.

Years ago, when Red Hat Linux was still one CD (RHL 4.x days?), I had a private mirror that did regenerate the CD image after downloading updates each day. Even with such limited use, I occasionally ran into install issues that went away if I installed from a "pristine" CD and loaded updates.