Hi All,
Slightly off topic for this list but a tool that ultimately the spins depend strongly on. I'm wondering whether without a upstream maintainer getting some of the patches (see links below) into upstream tool might not be a possible project for FES?
Getting some of these things fixed would be very useful for the Sugar on a Stick spin, and slightly less so, but to the moblin and no doubt other spins.
Peter
http://lists.fedoraproject.org/pipermail/livecd/2010-May/005797.html https://bugzilla.redhat.com/show_bug.cgi?id=587411 http://lists.fedoraproject.org/pipermail/livecd/2010-April/005764.html Next two are related to post above https://bugzilla.redhat.com/show_bug.cgi?id=448030 https://bugzilla.redhat.com/show_bug.cgi?id=582051 http://lists.fedoraproject.org/pipermail/livecd/2010-April/005765.html https://bugzilla.redhat.com/show_bug.cgi?id=583658 http://lists.fedoraproject.org/pipermail/livecd/2010-March/005762.html http://lists.fedoraproject.org/pipermail/livecd/2010-March/005714.html (partially related to the syslinux perl issue I mentioned before) http://lists.fedoraproject.org/pipermail/livecd/2010-April/005768.html https://bugzilla.redhat.com/show_bug.cgi?id=588622 https://bugzilla.redhat.com/show_bug.cgi?id=530308
On Wed, May 05, 2010 at 23:43:15 +0100, Peter Robinson pbrobinson@gmail.com wrote:
Hi All,
Slightly off topic for this list but a tool that ultimately the spins depend strongly on. I'm wondering whether without a upstream maintainer getting some of the patches (see links below) into upstream tool might not be a possible project for FES?
Getting some of these things fixed would be very useful for the Sugar on a Stick spin, and slightly less so, but to the moblin and no doubt other spins.
Well it seems inefficient to put extra middle men in place when the FES people may not know stuff as well as the people submitting patches and may not have access to update the source either.
I'd rather see the people willing to do the work (evidenced by submitting patches) just get the access needed to do the updates.
Bruno Wolff III wrote:
On Wed, May 05, 2010 at 23:43:15 +0100, Peter Robinson pbrobinson@gmail.com wrote:
Hi All,
Slightly off topic for this list but a tool that ultimately the spins depend strongly on. I'm wondering whether without a upstream maintainer getting some of the patches (see links below) into upstream tool might not be a possible project for FES?
Getting some of these things fixed would be very useful for the Sugar on a Stick spin, and slightly less so, but to the moblin and no doubt other spins.
Well it seems inefficient to put extra middle men in place when the FES people may not know stuff as well as the people submitting patches and may not have access to update the source either.
I'd rather see the people willing to do the work (evidenced by submitting patches) just get the access needed to do the updates.
I'm sorry (and apologizing) for the fact that I'm not an admin for this group (re: commit access). By consensus of the community, with everything that's going on, you would have my vote +1.
-- Jeroen
On Wed, May 05, 2010 at 05:59:34PM -0500, Bruno Wolff III wrote:
On Wed, May 05, 2010 at 23:43:15 +0100, Peter Robinson pbrobinson@gmail.com wrote:
Hi All,
Slightly off topic for this list but a tool that ultimately the spins depend strongly on. I'm wondering whether without a upstream maintainer getting some of the patches (see links below) into upstream tool might not be a possible project for FES?
Getting some of these things fixed would be very useful for the Sugar on a Stick spin, and slightly less so, but to the moblin and no doubt other spins.
Well it seems inefficient to put extra middle men in place when the FES people may not know stuff as well as the people submitting patches and may not have access to update the source either.
I'd rather see the people willing to do the work (evidenced by submitting patches) just get the access needed to do the updates.
I agree with Bruno. The tool's upstream is in Fedora Hosted, correct?
On 05/06/2010 05:27 PM, Paul W. Frields wrote:
On Wed, May 05, 2010 at 05:59:34PM -0500, Bruno Wolff III wrote:
On Wed, May 05, 2010 at 23:43:15 +0100, Peter Robinsonpbrobinson@gmail.com wrote:
Hi All,
Slightly off topic for this list but a tool that ultimately the spins depend strongly on. I'm wondering whether without a upstream maintainer getting some of the patches (see links below) into upstream tool might not be a possible project for FES?
Getting some of these things fixed would be very useful for the Sugar on a Stick spin, and slightly less so, but to the moblin and no doubt other spins.
Well it seems inefficient to put extra middle men in place when the FES people may not know stuff as well as the people submitting patches and may not have access to update the source either.
I'd rather see the people willing to do the work (evidenced by submitting patches) just get the access needed to do the updates.
I agree with Bruno. The tool's upstream is in Fedora Hosted, correct?
All,
I am going to try and take a more active role with the livecd project.
Peter I have take your list and will try and work them into livecd-tools upstream in the next couple of days.
For the rest of you, feel free to bug me if I miss something or something has been sitting too long.
-D
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am building to Fedora spins, Kiosk and MLS. I want to use the fedora-desktop as the base for thise spins, but I want to manage the users within my own kickstart file.
Basically this patch separates the liveuser creation into a separate script /etc/init.d/livesys-adduser. It also changes livesys to execute this script if it exists.
This allows me to remove the livesys-adduser script in my kiosk.ks (attached). And only have the xguest user account.
NOTE: I have sent this email to spins list at least three times, and it was rejected, because I was not subscribed. So if it eventually comes through multiple times, I appologize.
On Fri, May 07, 2010 at 08:22:13 -0400, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am building to Fedora spins, Kiosk and MLS. I want to use the fedora-desktop as the base for thise spins, but I want to manage the users within my own kickstart file.
Basically this patch separates the liveuser creation into a separate script /etc/init.d/livesys-adduser. It also changes livesys to execute this script if it exists.
This allows me to remove the livesys-adduser script in my kiosk.ks (attached). And only have the xguest user account.
Is this something for f14? We haven't made an f13 branch yet, and it's a bit late for a change to f13.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/2010 09:40 AM, Bruno Wolff III wrote:
On Fri, May 07, 2010 at 08:22:13 -0400, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am building to Fedora spins, Kiosk and MLS. I want to use the fedora-desktop as the base for thise spins, but I want to manage the users within my own kickstart file.
Basically this patch separates the liveuser creation into a separate script /etc/init.d/livesys-adduser. It also changes livesys to execute this script if it exists.
This allows me to remove the livesys-adduser script in my kiosk.ks (attached). And only have the xguest user account.
Is this something for f14? We haven't made an f13 branch yet, and it's a bit late for a change to f13.
I would like to see it go into F13, but definitely F14.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One of the things I had done was write a patch for livecd to create a livecd that is "Non-Interuptable" My goal was for kiosk type environments to allow a machine without an operating system to only be able to boot a livecd with root account disabled and no way to boot it in single user mode or disable SELinux etc.
The patch I submitted allowed a ks file to use TOTALTIMEOUT=1. On a syslinux boot system this flag tells the system to boot withing .1 seconds and the user can not stop it.
The patch was rejected by Jeremy Katz (Probably Rightly so) for a couple of reasons.
1. It was syslinux specific. It would not work for efi boots. 2. It changed the syntax of kickstart, so packages like anaconda would have to start supporting it.
I was thinking of adding a flag to livecd-iso-to * to setup uninterruptable boots. I think this could be done using the TOTALTIMEOUT flag above for syslinux and by setting up a passwd in grub.conf that can not be reached by MD5 for efi boot environments.
Is this interesting to any one else? Do you think this is the proper way to go? Am I asking on the wrong list?
On Fri, May 07, 2010 at 11:54:54 -0400, Daniel J Walsh dwalsh@redhat.com wrote:
Is this something for f14? We haven't made an f13 branch yet, and it's a bit late for a change to f13.
I would like to see it go into F13, but definitely F14.
My personal opinion is that it is too late to change the initial live base ks file for F13. That is going to affect several spins and there isn't a lot of time to do QA before the release.
I think typically the spin-kickstarts package doesn't get updated during the life of a release because the intention is to save what was used to build the release spins. Though I am not sure that this view is accurate.
My personal opinion is that updating spin-kickstarts during the release should be doable. I'd like to hear some other people's take on that.
So what I think makes sense is that once the git branch is made for F13, that this patch get applied to master and get some testing. Then I think a bit after F13 is released and the patch doesn't seem to break anything, that it get applied to the F13 branch, get a bit more testing and then it gets into an update of the spin-kickstarts package for F13. (Somewhere in theer it should also get into the F14 package.)
I'd like to get an ack or two, that this is reasonable plan?
On Fri, 7 May 2010 11:41:54 -0500 Bruno Wolff III bruno@wolff.to wrote:
On Fri, May 07, 2010 at 11:54:54 -0400, Daniel J Walsh dwalsh@redhat.com wrote:
Is this something for f14? We haven't made an f13 branch yet, and it's a bit late for a change to f13.
I would like to see it go into F13, but definitely F14.
My personal opinion is that it is too late to change the initial live base ks file for F13. That is going to affect several spins and there isn't a lot of time to do QA before the release.
Yes. it's way to late IMHO. RC2 is being spun up now. Now is the time for only critical blockers.
I think typically the spin-kickstarts package doesn't get updated during the life of a release because the intention is to save what was used to build the release spins. Though I am not sure that this view is accurate.
Yeah, that was my understanding as well.
My personal opinion is that updating spin-kickstarts during the release should be doable. I'd like to hear some other people's take on that.
So what I think makes sense is that once the git branch is made for F13, that this patch get applied to master and get some testing. Then I think a bit after F13 is released and the patch doesn't seem to break anything, that it get applied to the F13 branch, get a bit more testing and then it gets into an update of the spin-kickstarts package for F13. (Somewhere in theer it should also get into the F14 package.)
I'd like to get an ack or two, that this is reasonable plan?
I'd prefer to just see this work done in F14. I suppose if it's tested there we could update spins-kickstarts for folks to build their own images, I don't feel too strongly either way on that.
kevin
On Fri, May 07, 2010 at 15:33:42 -0600, Kevin Fenzi kevin@scrye.com wrote:
I'd prefer to just see this work done in F14. I suppose if it's tested there we could update spins-kickstarts for folks to build their own images, I don't feel too strongly either way on that.
That's where I was going with this.
Daniel J Walsh wrote, On 05/07/2010 02:22 PM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am building to Fedora spins, Kiosk and MLS. I want to use the fedora-desktop as the base for thise spins, but I want to manage the users within my own kickstart file.
Basically this patch separates the liveuser creation into a separate script /etc/init.d/livesys-adduser. It also changes livesys to execute this script if it exists.
Is that proper use of init.d? AFAIK that folder it is intended for sysv "main" scripts, not for helper scripts.
But I assume that a proper long-term solution (as long as we are using sysv init) is to split the huge ks-generated shell script up in several normal init scripts. This is a step in that direction.
However, we should probably use the canonical /etc/rc.d/init.d/ instead of the /etc/init.d/ symlink.
This allows me to remove the livesys-adduser script in my kiosk.ks (attached). And only have the xguest user account.
It could be nice to have spins with this technology available for f13.
Perhaps kiosk.ks for f13 could inline (the modified) fedora-live-base.ks instead of indirectly including it. That would reduce the risk of applying that patch in f13 fedora-kickstarts. Alternatively it could be placed in the xguest package, either in docs/ or in spin-kickstarts/.
/Mads
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/09/2010 03:44 PM, Mads Kiilerich wrote:
Daniel J Walsh wrote, On 05/07/2010 02:22 PM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am building to Fedora spins, Kiosk and MLS. I want to use the fedora-desktop as the base for thise spins, but I want to manage the users within my own kickstart file.
Basically this patch separates the liveuser creation into a separate script /etc/init.d/livesys-adduser. It also changes livesys to execute this script if it exists.
Is that proper use of init.d? AFAIK that folder it is intended for sysv "main" scripts, not for helper scripts.
But I assume that a proper long-term solution (as long as we are using sysv init) is to split the huge ks-generated shell script up in several normal init scripts. This is a step in that direction.
However, we should probably use the canonical /etc/rc.d/init.d/ instead of the /etc/init.d/ symlink.
This allows me to remove the livesys-adduser script in my kiosk.ks (attached). And only have the xguest user account.
It could be nice to have spins with this technology available for f13.
Perhaps kiosk.ks for f13 could inline (the modified) fedora-live-base.ks instead of indirectly including it. That would reduce the risk of applying that patch in f13 fedora-kickstarts. Alternatively it could be placed in the xguest package, either in docs/ or in spin-kickstarts/.
/Mads
Yes I could do this, but it prevents the kiosk.ks from taking advantage of any fixes in the desktop/base livecd.
On Thu, May 06, 2010 at 17:46:12 -0400, David Huff dhuff@redhat.com wrote:
All,
I am going to try and take a more active role with the livecd project.
Thanks for stepping up and taking ownership of this!
-
Bruno Wolff III -
Daniel J Walsh -
David Huff -
Jeroen van Meeuwen -
Kevin Fenzi -
Mads Kiilerich -
Paul W. Frields -
Peter Robinson