We shipped FC6 with a set size of 685, could we make this the default in splittree?
Jesse Keating wrote:
We shipped FC6 with a set size of 685, could we make this the default in splittree?
Why do you still hard-code the size? IMV it should be a parameter (maybe with a default value). Some people like to create their own with bigger images, and if I'm never going to burn it to any media, the larger the better.
On Saturday 20 January 2007 15:03, John Summerfield wrote:
Why do you still hard-code the size? IMV it should be a parameter (maybe with a default value). Some people like to create their own with bigger images, and if I'm never going to burn it to any media, the larger the better.
It has to be coded somewhere (: One can pass a variable or set a variable when using splittree, I just thought that the default should reflect what we've used for Fedora 6. In pungi, I plan on making it a (semi hidden) configurable parameter.
Jesse Keating wrote:
On Saturday 20 January 2007 15:03, John Summerfield wrote:
Why do you still hard-code the size? IMV it should be a parameter (maybe with a default value). Some people like to create their own with bigger images, and if I'm never going to burn it to any media, the larger the better.
It has to be coded somewhere (: One can pass a variable or set a variable when using splittree, I just thought that the default should reflect what we've used for Fedora 6. In pungi, I plan on making it a (semi hidden) configurable parameter.
I'm looking at splittree in FC6; it's hard-coded to 640*1024.0*1024, and I don't see a way to override it.
I contend it should be specifiable from the commandline, and the default value be set in a configuration file for the distro. The config file might also specify the product name (RHEL, FC, Clark Connect etc) and release.
And all this info should go into the first ISO image so folk can easily see how to recreate it, create modified versions etc etc. Of course, this is all beyond the scope of changing CD size....
On Saturday 20 January 2007 21:38, John Summerfield wrote:
I'm looking at splittree in FC6; it's hard-coded to 640*1024.0*1024, and I don't see a way to override it.
I contend it should be specifiable from the commandline, and the default value be set in a configuration file for the distro. The config file might also specify the product name (RHEL, FC, Clark Connect etc) and release.
And all this info should go into the first ISO image so folk can easily see how to recreate it, create modified versions etc etc. Of course, this is all beyond the scope of changing CD size....
In the compose tools we use, we don't call splittree directly, rather we import splittree as a module and set some variables that way, then call splittree.timber().
The particular compose tool I'm working on, pungi, will have the configurable items in a config file, to allow for easy reproduction. I don't necessarily think they belong on the CD itself, as much of the config will be specific to the compose environment, which may not necessarily match what is external (repo locations, compose destination, etc..).
Jesse Keating wrote:
On Saturday 20 January 2007 21:38, John Summerfield wrote:
I'm looking at splittree in FC6; it's hard-coded to 640*1024.0*1024, and I don't see a way to override it.
I contend it should be specifiable from the commandline, and the default value be set in a configuration file for the distro. The config file might also specify the product name (RHEL, FC, Clark Connect etc) and release.
And all this info should go into the first ISO image so folk can easily see how to recreate it, create modified versions etc etc. Of course, this is all beyond the scope of changing CD size....
In the compose tools we use, we don't call splittree directly, rather we import splittree as a module and set some variables that way, then call splittree.timber().
The particular compose tool I'm working on, pungi, will have the configurable items in a config file, to allow for easy reproduction. I don't necessarily think they belong on the CD itself, as much of the config will be specific to the compose environment, which may not necessarily match what is external (repo locations, compose destination, etc..).
One of the big problems folk have had wrt Anaconda for years has been lack of documentation.
I will admit right now that I haven't gone looking for official documentation recently, it's a while since I found the need to remaster a {RHL,RHEL,Fedora} ISO, and it may have improved. I'm guessing it hasn't though, these things tend to get left until later by many, including JS.
Some folk here will remember Tony Nugent who became famous for writing the best document for remastering RHL back in the time of RHL 7.x.
I think the position could be alleviated greatly, if RH included a script that could be run by users to take a source tree of built RPMs and create one or more ISO images ready to burn.
The script would need to be parameterised, perhaps as simply as setting some values (probably those used by RH), and then sourcing a file in {$PWD,$HOME}, so as to account for different users' setups: we may store the tree differently, we may store source packages in a completely different location.
Oh, this does not prevent RH from using its own private tools; the script should be produced by those tools (and maybe in time those tools could be extended to generate the script and then use it).
Why should RH do this? Well, obviously to extend its niceness:-)
It's nice that this is in Fedora Core 6: [summer@ns ~]$ head -20 /misc/fc6/GPL ***************************************************************************** The following copyright applies to the Red Hat Linux compilation and any portions of Red Hat Linux it does not conflict with. Whenever this policy does conflict with the copyright of any individual portion of Red Hat Linux, it does not apply.
*****************************************************************************
It would be nicer still if RH bound itself to the terms of the GPL and provided scripts to "to control compilation and installation of the executable."
On Monday 22 January 2007 08:40, John Summerfield wrote:
It would be nicer still if RH bound itself to the terms of the GPL and provided scripts to "to control compilation and installation of the executable."
http://hosted.fedoraproject.org/projects/pungi
This is the tool that will be building Fedora releases from F7 on (until it is replaced by something better)
Jesse Keating wrote:
On Monday 22 January 2007 08:40, John Summerfield wrote:
It would be nicer still if RH bound itself to the terms of the GPL and provided scripts to "to control compilation and installation of the executable."
Kill the webmaster for me:-) I went straight to a shonky website with a shonky certificate. Does it really require https?
This is the tool that will be building Fedora releases from F7 on (until it is replaced by something better)
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
Please do not reply off-list
On Tuesday 23 January 2007 07:44, John Summerfield wrote:
Kill the webmaster for me:-) I went straight to a shonky website with a shonky certificate. Does it really require https?
For now yes, as the website can do a login, and we want that login encrypted. The cert is just a temp cert, as this is the trial run of the Fedora Hosted Projects. If you're not giving over any information, it shouldn't matter if the certificate is "shonky".
anaconda-devel@lists.stg.fedoraproject.org