The meeting had reports on lmza and issues with liveusb building. The haskell and moblin spin proposals were discussed and some questions generated, but voting was deferred.
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20... Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20... Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20...
Hi All,
On Mon, Dec 28, 2009 at 10:13 PM, Bruno Wolff III bruno@wolff.to wrote:
The meeting had reports on lmza and issues with liveusb building. The haskell and moblin spin proposals were discussed and some questions generated, but voting was deferred.
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20... Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20... Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-28/fedora-meeting.20...
Sorry I missed the meeting, I'm travelling at the moment so its hard to be near computers and convenient times, I should be able to make the next one.
To answer in bullet point and to allow for further discussion on the list in the meeting logs so it can at least be discussed here prior to the next meeting.
1) The reason for the new fedora-mini*.ks files is to slim down the build. The difference between that and using a standard desktop one is about 150 meg on a live CD the last time I tested it and when the Moblin livecd is currently 400 meg that's quite a difference. I've been working to and planning to work further to get the changes merged in upstream. There are a number of bugs filed already and in Jan when I have some more time I'll be following it up with other stuff.
2) The mesa-dri-drivers-experimental is needed for 3D on ATI based cards otherwise the Moblin interace is unusable with those devices (15 seconds + to activate a menu) but with luck that should be obsolete for F-13
3) ssmtp is only included as its small and cronie currently requires an MTA. Its not enabled. If one isn't specifically set it pulls in exim which in turn pulls in perl adding 50+ meg to the liveCD. Similar issues with sendmail and postfix. There is a separate NoMTA feature being proposed for F-13 with RHBZ bug 548843 being the only blocker to having no MTA at all. Other option is to remove cronie.
4) most of the rest of the stuff is documented in the kick start files and its mostly to remove things that would never/rarely be used in a netbook or other small device. This includes printing related things (cups/drivers/ etc), corporate and server stuff (FCA and other server firmwares, nfs/cifs/iscsi/fcoe), services (yp/nis/dns/smtp), and other non sensical stuff that isn't generally used on MID/Netbook and other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
Cheers, Peter
On Mon, Dec 28, 2009 at 22:58:23 +0000, Peter Robinson pbrobinson@gmail.com wrote:
- The reason for the new fedora-mini*.ks files is to slim down the
build. The difference between that and using a standard desktop one is about 150 meg on a live CD the last time I tested it and when the Moblin livecd is currently 400 meg that's quite a difference. I've been working to and planning to work further to get the changes merged in upstream. There are a number of bugs filed already and in Jan when I have some more time I'll be following it up with other stuff.
Do you think it might be better to remove more stuff from live-base and add it back in to live-desktop where needed? And remove the need for a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable, to base it over of live-base instead of starting from scratch. This would probably help with maintenance down the road.
- The mesa-dri-drivers-experimental is needed for 3D on ATI based
cards otherwise the Moblin interace is unusable with those devices (15 seconds + to activate a menu) but with luck that should be obsolete for F-13
That's pretty much what we figured, but there should probably be a deadline where if the graphics supoort is ready, the official spin gets pushed to F14 instead of F13.
other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.
On Mon, Dec 28, 2009 at 11:08 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Dec 28, 2009 at 22:58:23 +0000, Peter Robinson pbrobinson@gmail.com wrote:
- The reason for the new fedora-mini*.ks files is to slim down the
build. The difference between that and using a standard desktop one is about 150 meg on a live CD the last time I tested it and when the Moblin livecd is currently 400 meg that's quite a difference. I've been working to and planning to work further to get the changes merged in upstream. There are a number of bugs filed already and in Jan when I have some more time I'll be following it up with other stuff.
Do you think it might be better to remove more stuff from live-base and add it back in to live-desktop where needed? And remove the need for a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable, to base it over of live-base instead of starting from scratch. This would probably help with maintenance down the road.
I think its 6 to one, half a dozen to the other. I think the desire is still there. By slimming the base and moving it out to the individual desktop .ks files you could be adding duplication and complexity unnecessarily there. I think in the short term from the rather big investigation it will be easier to have a separate one.
Ultimately the work has to be done somewhere. Sometimes by trying to merge it all together you just end up with more of a mess and creating more issues and more work for more people than by having two separate ones and comparing them on occasion. In the not too distant future I suspect there will be more than just Netbooks. At the very least there will be a sugar one as its covers a lot of the ground that Moblin does. There's likely also to be a MID one and support for secondary arch devices too. There's nothing to say it can't disappear in the future.
- The mesa-dri-drivers-experimental is needed for 3D on ATI based
cards otherwise the Moblin interace is unusable with those devices (15 seconds + to activate a menu) but with luck that should be obsolete for F-13
That's pretty much what we figured, but there should probably be a deadline where if the graphics supoort is ready, the official spin gets pushed to F14 instead of F13.
Well that would be a question for the X guys not a mere user environment guy like me :-)
other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.
On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.
Regards, Peter
On Mon, Dec 28, 2009 at 23:23:52 +0000, Peter Robinson pbrobinson@gmail.com wrote:
On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.
Other spins besides yours might be using it in the future. The normal rule is that live spins are based off live-base or live-desktop. Making an exception is possible. But I think it is worth thinking about is the exception going to be just for moblin or will other official spins be able to base off it as well. If the latter, support becomes more of a concern.
On 12/29/2009 12:23 AM, Peter Robinson wrote:
On Mon, Dec 28, 2009 at 11:08 PM, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Dec 28, 2009 at 22:58:23 +0000, Peter Robinson pbrobinson@gmail.com wrote:
- The reason for the new fedora-mini*.ks files is to slim down the
build. The difference between that and using a standard desktop one is about 150 meg on a live CD the last time I tested it and when the Moblin livecd is currently 400 meg that's quite a difference. I've been working to and planning to work further to get the changes merged in upstream. There are a number of bugs filed already and in Jan when I have some more time I'll be following it up with other stuff.
Do you think it might be better to remove more stuff from live-base and add it back in to live-desktop where needed? And remove the need for a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable, to base it over of live-base instead of starting from scratch. This would probably help with maintenance down the road.
I think its 6 to one, half a dozen to the other. I think the desire is still there. By slimming the base and moving it out to the individual desktop .ks files you could be adding duplication and complexity unnecessarily there. I think in the short term from the rather big investigation it will be easier to have a separate one.
As far as the desire of stripping down the bare minimums of what a livecd contains goes, here's my take on the problem;
If fedora-live-base.ks would just be the bare minimum of packages and settings and scripts to make a LiveCD as such work (along with it's features), then there would be no need to strip anything off.
Should there be a set of packages that any desktop/foo/bar oriented spin requires, well, then enter fedora-live-desktop.ks or fedora-live-foo.ks.
We should always remember though, that even though collaboration on fedora-live-base.ks is a very beautiful thing, in the end it is about the spins.
The maintainers should have ultimate control over the contents of the spin and so if fedora-live-base.ks puts stuff on there we don't need, then maybe it has to go (even if that means 5 other spins need to add a package to their list).
Should something be removed from a group however, it's up to us to forward such to the people maintaining comps.xml (which is all of us).
Ultimately the work has to be done somewhere. Sometimes by trying to merge it all together you just end up with more of a mess and creating more issues and more work for more people than by having two separate ones and comparing them on occasion. In the not too distant future I suspect there will be more than just Netbooks. At the very least there will be a sugar one as its covers a lot of the ground that Moblin does. There's likely also to be a MID one and support for secondary arch devices too. There's nothing to say it can't disappear in the future.
- The mesa-dri-drivers-experimental is needed for 3D on ATI based
cards otherwise the Moblin interace is unusable with those devices (15 seconds + to activate a menu) but with luck that should be obsolete for F-13
That's pretty much what we figured, but there should probably be a deadline where if the graphics supoort is ready, the official spin gets pushed to F14 instead of F13.
Well that would be a question for the X guys not a mere user environment guy like me :-)
List references to the issue as your dependencies, so that people can help you track it, and other people can make noise about it at meetings where show-stoppers for various things are addressed (blocker bugs, etc.).
other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.
On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.
We would like to make sure that issues that make or break a LiveCD in general are fixed in one location only. Maybe that means splitting up fedora-live-base.ks, maybe there's another way.
-- Jeroen
I think its 6 to one, half a dozen to the other. I think the desire is still there. By slimming the base and moving it out to the individual desktop .ks files you could be adding duplication and complexity unnecessarily there. I think in the short term from the rather big investigation it will be easier to have a separate one.
As far as the desire of stripping down the bare minimums of what a livecd contains goes, here's my take on the problem;
If fedora-live-base.ks would just be the bare minimum of packages and settings and scripts to make a LiveCD as such work (along with it's features), then there would be no need to strip anything off.
Should there be a set of packages that any desktop/foo/bar oriented spin requires, well, then enter fedora-live-desktop.ks or fedora-live-foo.ks.
We should always remember though, that even though collaboration on fedora-live-base.ks is a very beautiful thing, in the end it is about the spins.
The maintainers should have ultimate control over the contents of the spin and so if fedora-live-base.ks puts stuff on there we don't need, then maybe it has to go (even if that means 5 other spins need to add a package to their list).
Should something be removed from a group however, it's up to us to forward such to the people maintaining comps.xml (which is all of us).
All of the above sounds reasonable. I have had it on my list for Jan already to go through it all and see what can be merged, changed, fixed etc (I think I mentioned this to you at FUDCon, but possibly not) so with luck most of the issues might just go away. Unfortunately December has been manic and it hasn't got high enough on the ToDo list yet.
Well that would be a question for the X guys not a mere user environment guy like me :-)
List references to the issue as your dependencies, so that people can help you track it, and other people can make noise about it at meetings where show-stoppers for various things are addressed (blocker bugs, etc.).
I need to dig deeper on this one and do more testing and find out what the plan is for it from a mainline desktop perspective.
other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.
On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.
We would like to make sure that issues that make or break a LiveCD in general are fixed in one location only. Maybe that means splitting up fedora-live-base.ks, maybe there's another way.
OK, cool. As mentioned above its on my todo list to review. Having looked at it all quite extensively before i know how most of the deps are and other issues, I just need to update and see what changes there are and file bugs with patches or requests.
Peter
Sorry for the lateness of my reply but I have been slow to catch up on my email reading....
I definitely think that other spins could benefit from a more slimmed down base.ks definition, specificity thincrust and ovirtnode which are doing similar things to what Peter's fedora-mini*.ks sounds like.
On 12/28/2009 06:50 PM, Peter Robinson wrote:
I think its 6 to one, half a dozen to the other. I think the desire is still there. By slimming the base and moving it out to the individual desktop .ks files you could be adding duplication and complexity unnecessarily there. I think in the short term from the rather big investigation it will be easier to have a separate one.
As far as the desire of stripping down the bare minimums of what a livecd contains goes, here's my take on the problem;
If fedora-live-base.ks would just be the bare minimum of packages and settings and scripts to make a LiveCD as such work (along with it's features), then there would be no need to strip anything off.
Agreed, fedora-live-base.ks only included what is needed to produce a bare minimal working livecd image.
Should there be a set of packages that any desktop/foo/bar oriented spin requires, well, then enter fedora-live-desktop.ks or fedora-live-foo.ks.
We should always remember though, that even though collaboration on fedora-live-base.ks is a very beautiful thing, in the end it is about the spins.
The maintainers should have ultimate control over the contents of the spin and so if fedora-live-base.ks puts stuff on there we don't need, then maybe it has to go (even if that means 5 other spins need to add a package to their list).
Should something be removed from a group however, it's up to us to forward such to the people maintaining comps.xml (which is all of us).
All of the above sounds reasonable. I have had it on my list for Jan already to go through it all and see what can be merged, changed, fixed etc (I think I mentioned this to you at FUDCon, but possibly not) so with luck most of the issues might just go away. Unfortunately December has been manic and it hasn't got high enough on the ToDo list yet.
Well that would be a question for the X guys not a mere user environment guy like me :-)
List references to the issue as your dependencies, so that people can help you track it, and other people can make noise about it at meetings where show-stoppers for various things are addressed (blocker bugs, etc.).
I need to dig deeper on this one and do more testing and find out what the plan is for it from a mainline desktop perspective.
other small devices such as scanners, perl, etc. I originally started with a fedora-desktop-base file and had about 4 or 5 pages of -blah so I figured it was going to be easier and neater to start with nothing and then add what I needed. I've had quite a bit of interest in it from various areas.
The issue with that approach is that if some change is made to add a feature to live-base it isn't going to get included in the mini ks. It might be safer to maintain a long subtraction list.
On the flip side of that argument its quite likely also that a feature is added that we don't want and we then have to strip it out in other .ks files adding more work possibly across multiple .ks files or multiple levels of ks files. I'm not sure what the allergic reaction to another -base.ks file is that I'm quite happy to maintain and get rid of if necessary.
We would like to make sure that issues that make or break a LiveCD in general are fixed in one location only. Maybe that means splitting up fedora-live-base.ks, maybe there's another way.
I do not know if there is another way, but I have always envisioned having another layer below fedora-live-base. Weather its called "fedora-min" whatever, but if fedora-live-base extended this it would 1) not break existing spins, and 2)other smaller spins or spins that may not even be livecd's can use this minimal ks as a starting point. This was one of the initial ideas behind the AOS.
In upstream ovirt we take it even further and have snippets for base-install.ks, base-pkgs.ks, and base-post.ks.
Introducing *all* of this extra abstraction may not be necessary, however it would defiantly be nice to have a minimal package set definition to produce a small foot print fedora image.
-D
-
Bruno Wolff III -
David Huff -
Jeroen van Meeuwen -
Peter Robinson