Here's a diff to the livecd config that makes the i386 livecd fit in brief testing. The biggest reason why the desktop one keeps flowing over is because it tries to include support for all languages, including input method.
What these changes do is:
- don't include groups where upstream gnome is < 50% translated - don't include fonts that are only referenced in %fonts and those groups - remove ekiga, just because it drags in so much other stuff
Comments?
Bill
Bill Nottingham (notting@redhat.com) said:
Here's a diff to the livecd config that makes the i386 livecd fit in brief testing. The biggest reason why the desktop one keeps flowing over is because it tries to include support for all languages, including input method.
What these changes do is:
- don't include groups where upstream gnome is < 50% translated
- don't include fonts that are only referenced in %fonts and those groups
- remove ekiga, just because it drags in so much other stuff
Comments?
... and, the diff.
Bill
On Mon, 2008-01-28 at 22:54 -0500, Bill Nottingham wrote:
Bill Nottingham (notting@redhat.com) said:
Here's a diff to the livecd config that makes the i386 livecd fit in brief testing. The biggest reason why the desktop one keeps flowing over is because it tries to include support for all languages, including input method.
What these changes do is:
- don't include groups where upstream gnome is < 50% translated
- don't include fonts that are only referenced in %fonts and those groups
- remove ekiga, just because it drags in so much other stuff
Comments?
In the past, any attempts to go to a subset of language have always met with strong resistance. Just kicking out some fonts/input methods, but leaving the "unsupported" translations in the packages may send a somewhat mixed message, but is probably the only thing we can do since noone knows how to make %_install_langs work.
Anyway, if we go with this approach, there should be at least a comment in the kickstart file explaining how the excluded font groups have been determined.
Matthias Clasen (mclasen@redhat.com) said:
- don't include groups where upstream gnome is < 50% translated
- don't include fonts that are only referenced in %fonts and those groups
- remove ekiga, just because it drags in so much other stuff
Comments?
In the past, any attempts to go to a subset of language have always met with strong resistance. Just kicking out some fonts/input methods, but leaving the "unsupported" translations in the packages may send a somewhat mixed message, but is probably the only thing we can do since noone knows how to make %_install_langs work.
Yeah, I'm just wondering if it's worth it installing fonts for a language that's only 10% translated in the desktop (for example.)
Anyway, if we go with this approach, there should be at least a comment in the kickstart file explaining how the excluded font groups have been determined.
The alternative is to still kick out ekiga (sorry, it's pretty large), and find the rest of the space somewhere else.
Bill
On Tue, 2008-01-29 at 11:59 -0500, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
- don't include groups where upstream gnome is < 50% translated
- don't include fonts that are only referenced in %fonts and those groups
- remove ekiga, just because it drags in so much other stuff
Comments?
In the past, any attempts to go to a subset of language have always met with strong resistance. Just kicking out some fonts/input methods, but leaving the "unsupported" translations in the packages may send a somewhat mixed message, but is probably the only thing we can do since noone knows how to make %_install_langs work.
Yeah, I'm just wondering if it's worth it installing fonts for a language that's only 10% translated in the desktop (for example.)
Anyway, if we go with this approach, there should be at least a comment in the kickstart file explaining how the excluded font groups have been determined.
The alternative is to still kick out ekiga (sorry, it's pretty large), and find the rest of the space somewhere else.
Kicking the debuginfo out of mono-core should give us on the order of 15M, I think:
https://bugzilla.redhat.com/show_bug.cgi?id=430500
But I am not opposed to do the font pruning. All I'm asking is that you add a comment explaining the rationale and where the data came from.
On Tue, 2008-01-29 at 12:07 -0500, Matthias Clasen wrote:
On Tue, 2008-01-29 at 11:59 -0500, Bill Nottingham wrote:
Yeah, I'm just wondering if it's worth it installing fonts for a language that's only 10% translated in the desktop (for example.)
Anyway, if we go with this approach, there should be at least a comment in the kickstart file explaining how the excluded font groups have been determined.
But I am not opposed to do the font pruning. All I'm asking is that you add a comment explaining the rationale and where the data came from.
Seems sane (both removing the fonts and the comment). Thanks for tracking some stuff down Bill
Jeremy
On Jan 28, 2008 7:07 PM, Matthias Clasen mclasen@redhat.com wrote:
In the past, any attempts to go to a subset of language have always met with strong resistance.
Here's the paradoxical reality of the situation.
1)The CD image is championed because DVD drives are not commonplace in some parts of the world yet (ie not US/Western Europe).
plus
2)Holding all languages in the CD image makes it more difficult to include useful applcations for everybody.
equals
3)The very people who need the CD image, are the people who also most likely need the additional language support.
Here's is what I think we need to actual do. We need to build a process by which different language groups are encouraged to build and host their own CD spins, instead of continuing to shove everything into one CD image. How do we do this? How do we provide the correct balance of infrastructure and services such that community members will step up and produce and consume the localized CD spins? How much of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
I don't have any answers to these questions, but I'm pretty sure these are the right questions to be asking instead of asking how do we fit multiple locales onto a single CD spin.
-jef
Jeff Spaleta wrote:
On Jan 28, 2008 7:07 PM, Matthias Clasen mclasen@redhat.com wrote:
In the past, any attempts to go to a subset of language have always met with strong resistance.
Here's the paradoxical reality of the situation.
1)The CD image is championed because DVD drives are not commonplace in some parts of the world yet (ie not US/Western Europe).
plus
2)Holding all languages in the CD image makes it more difficult to include useful applcations for everybody.
equals
3)The very people who need the CD image, are the people who also most likely need the additional language support.
Here's is what I think we need to actual do. We need to build a process by which different language groups are encouraged to build and host their own CD spins, instead of continuing to shove everything into one CD image. How do we do this? How do we provide the correct balance of infrastructure and services such that community members will step up and produce and consume the localized CD spins?
How much
of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
A: All of it.
-dmc
I don't have any answers to these questions, but I'm pretty sure these are the right questions to be asking instead of asking how do we fit multiple locales onto a single CD spin.
-jef
Douglas McClendon (dmc.fedora@filteredperception.org) said:
How much
of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
A: All of it.
Not necessarily. Localized spins may want a different app set due to their localization status.
Bill
Bill Nottingham wrote:
Douglas McClendon (dmc.fedora@filteredperception.org) said:
How much
of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
A: All of it.
Not necessarily. Localized spins may want a different app set due to their localization status.
Sure, I was just pointing out that you could easily script a first pass. Though my quick response was woefully disregarding the issue mirrors and hosting. Though if bittorrent is enough...
-dmc
Maybe im ill be taking this discussion on another direction, but its my opinion. I've used Ubuntu and so its LiveCD installation. There you can select your language during the installation process and if you language isnt english then an aditiona step is added in the installation which is the 'downloading language support' or something like that.
As ive also seen fedora's DVD installation method, i can see that you can manage some extra packages that are not included in the iso image so during the installation those packages are downloaded from the repositories.
Isnt it possible to add a similar feature to LiveCD?, like adding the 'Select your language' step and use the repositories to download the language support if its not english?
On Tue, 2008-01-29 at 15:37 -0600, Douglas McClendon wrote:
Jeff Spaleta wrote:
On Jan 28, 2008 7:07 PM, Matthias Clasen mclasen@redhat.com wrote:
In the past, any attempts to go to a subset of language have always met with strong resistance.
Here's the paradoxical reality of the situation.
1)The CD image is championed because DVD drives are not commonplace in some parts of the world yet (ie not US/Western Europe).
plus
2)Holding all languages in the CD image makes it more difficult to include useful applcations for everybody.
equals
3)The very people who need the CD image, are the people who also most likely need the additional language support.
Here's is what I think we need to actual do. We need to build a process by which different language groups are encouraged to build and host their own CD spins, instead of continuing to shove everything into one CD image. How do we do this? How do we provide the correct balance of infrastructure and services such that community members will step up and produce and consume the localized CD spins?
How much
of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
A: All of it.
-dmc
I don't have any answers to these questions, but I'm pretty sure these are the right questions to be asking instead of asking how do we fit multiple locales onto a single CD spin.
-jef
Luis Alfredo Prada (juankprada@gmail.com) said:
Maybe im ill be taking this discussion on another direction, but its my opinion. I've used Ubuntu and so its LiveCD installation. There you can select your language during the installation process and if you language isnt english then an aditiona step is added in the installation which is the 'downloading language support' or something like that.
As ive also seen fedora's DVD installation method, i can see that you can manage some extra packages that are not included in the iso image so during the installation those packages are downloaded from the repositories.
Isnt it possible to add a similar feature to LiveCD?, like adding the 'Select your language' step and use the repositories to download the language support if its not english?
That's sort of orthogonal to having the livecd actually *come up* in the user's requested language - they'll still need to be able to process whatever language the live CD is in just to get to this point.
Bill
On Tue, 2008-01-29 at 17:55 -0500, Bill Nottingham wrote:
Luis Alfredo Prada (juankprada@gmail.com) said:
Maybe im ill be taking this discussion on another direction, but its my opinion. I've used Ubuntu and so its LiveCD installation. There you can select your language during the installation process and if you language isnt english then an aditiona step is added in the installation which is the 'downloading language support' or something like that.
As ive also seen fedora's DVD installation method, i can see that you can manage some extra packages that are not included in the iso image so during the installation those packages are downloaded from the repositories.
Isnt it possible to add a similar feature to LiveCD?, like adding the 'Select your language' step and use the repositories to download the language support if its not english?
That's sort of orthogonal to having the livecd actually *come up* in the user's requested language - they'll still need to be able to process whatever language the live CD is in just to get to this point.
Bill
The thing is, we should assume that a user able to download the LiveCD and who is willing to install fedora on his computer might have a little knowledge of English (if that is not true then the user might not be able to install any distro at all, not even fedora DVD iso as it starts in english). And so if the option to choose the language appears as the first step the user could just obvious that it is for language selection (as almost all installers set the first step to choose the installation language), then we could add a "small language support" to the liveCD so the installer can change its language as selected by the user (and only the installer).
On Tue, 2008-01-29 at 10:24 -0900, Jeff Spaleta wrote:
Here's is what I think we need to actual do. We need to build a process by which different language groups are encouraged to build and host their own CD spins, instead of continuing to shove everything into one CD image. How do we do this? How do we provide the correct balance of infrastructure and services such that community members will step up and produce and consume the localized CD spins? How much of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
The testing[1], hosting, and distribution of these is really the hard part. :-/
Jeremy
[1] Testing is the global pain, isn't it?
On Jan 29, 2008 8:24 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Jan 28, 2008 7:07 PM, Matthias Clasen mclasen@redhat.com wrote:
In the past, any attempts to go to a subset of language have always met with strong resistance.
Here's the paradoxical reality of the situation.
1)The CD image is championed because DVD drives are not commonplace in some parts of the world yet (ie not US/Western Europe).
plus
2)Holding all languages in the CD image makes it more difficult to include useful applcations for everybody.
equals
3)The very people who need the CD image, are the people who also most likely need the additional language support.
Here's is what I think we need to actual do. We need to build a process by which different language groups are encouraged to build and host their own CD spins, instead of continuing to shove everything into one CD image. How do we do this? How do we provide the correct balance of infrastructure and services such that community members will step up and produce and consume the localized CD spins? How much of the work can be automated with scripts which do nothing but pull one language group out and stick another one in so that localized versions of the same thing can be autogenerated?
I don't have any answers to these questions, but I'm pretty sure these are the right questions to be asking instead of asking how do we fit multiple locales onto a single CD spin.
-jef
I have some lame questions: 1. What kind of compression fedora uses? Any? None? I know that Knoppix makes a big deal how they put a l lot more stuff on CD by doing strong compression.
2. I know I'll get flame for this, but here it goes: make one spin without selinux but include OOo and call it "General Destop". Rename current spin without OOo and with selinux to "Secure desktop"
3. of removing selinux is out of question rename current spin to "Basic Desktop spin" and create a "Full desktop spin" with Ooo and much more other apps and make it a DVD spin, or maybe, maybe 2 CD spin.
Hope this helps, Valent.
On Wed, 2008-01-30 at 00:36 +0100, Valent Turkovic wrote:
- What kind of compression fedora uses? Any? None? I know that
Knoppix makes a big deal how they put a l lot more stuff on CD by doing strong compression.
We use squashfs which gives us pretty comparable compression to knoppix.
- of removing selinux is out of question rename current spin to
"Basic Desktop spin" and create a "Full desktop spin" with Ooo and much more other apps and make it a DVD spin, or maybe, maybe 2 CD spin.
This then means another image to build, test, host, mirror, ... across n architectures.
Not to mention increased user confusion as to which is the "best" for them to download.
Jeremy
On Tue, 2008-01-29 at 19:59 -0500, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
Not to mention increased user confusion as to which is the "best" for them to download.
Also, the overhead of SELinux is nowhere near enough to get you to enough space for OO.o + OO.o localization.
If everything including OOo's core apps would fit with *no translations* on a CD. It suggests the old idea I guess, of zoned/regional live-cds with OOo on them (like Ubuntu's and OpenSuse's do) where the language support per-cd is broken down to sommat like EMEA, Asia, Big 12 instead of a one global LiveCD.
C.
On Jan 30, 2008 9:08 AM, Caolan McNamara caolanm@redhat.com wrote:
On Tue, 2008-01-29 at 19:59 -0500, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
Not to mention increased user confusion as to which is the "best" for them to download.
Also, the overhead of SELinux is nowhere near enough to get you to enough space for OO.o + OO.o localization.
If everything including OOo's core apps would fit with *no translations* on a CD. It suggests the old idea I guess, of zoned/regional live-cds with OOo on them (like Ubuntu's and OpenSuse's do) where the language support per-cd is broken down to sommat like EMEA, Asia, Big 12 instead of a one global LiveCD.
C.
Could we do something different? Can there be an base install with OOo and language pack CD as an addon?
Valent.
On Jan 30, 2008 6:02 PM, Bill Nottingham notting@redhat.com wrote:
Valent Turkovic (valent.turkovic@gmail.com) said:
Could we do something different? Can there be an base install with OOo and language pack CD as an addon?
I don't see how 'please swap in the other CD to run openoffice' is practical, or doable.
Bill
I was thinking something different. If you leave everything by default you get Fedora 9 live cd installed with english and OOo in english.
In Live CD installer you choose your country and/or language of your choice and then you are presented with two options to load language packs for gnome and Ooo from CD2 or download them if you are online. And then everything else is still installed from CD1. Yes it is a messy idea... but still maybe somebody has a better one...
2008/1/31, Valent Turkovic valent.turkovic@gmail.com:
On Jan 30, 2008 6:02 PM, Bill Nottingham notting@redhat.com wrote:
Valent Turkovic (valent.turkovic@gmail.com) said:
Could we do something different? Can there be an base install with OOo and language pack CD as an
addon?
I don't see how 'please swap in the other CD to run openoffice' is
practical,
or doable.
Bill
I was thinking something different. If you leave everything by default you get Fedora 9 live cd installed with english and OOo in english.
In Live CD installer you choose your country and/or language of your choice and then you are presented with two options to load language packs for gnome and Ooo from CD2 or download them if you are online. And then everything else is still installed from CD1. Yes it is a messy idea... but still maybe somebody has a better one...
+1
Thats pretty much what i proposed, i think is a good idea to let the user choose its language and if it doesnt fit on the liveCD then it could be downloaded from the internet. Someway or another non-english-speakers will have to deal with english during his FOSS experience, and leaving English as the default language isnt going to change that much (remember that DVD iso's default language is english and it change ass soon as you select another language). so we could add the translation just for the Anaconda installer and leave the rest of the LiveCD with its default language, and if needed, the other languages could be downloaded from the internet.
--
http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic
--
Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Thu, 2008-01-31 at 10:05 -0500, Juan Camilo Prada Ojeda wrote:
Thats pretty much what i proposed, i think is a good idea to let the user choose its language and if it doesnt fit on the liveCD then it could be downloaded from the internet. Someway or another non-english-speakers will have to deal with english during his FOSS experience, and leaving English as the default language isnt going to change that much (remember that DVD iso's default language is english and it change ass soon as you select another language). so we could add the translation just for the Anaconda installer and leave the rest of the LiveCD with its default language, and if needed, the other languages could be downloaded from the internet.
See my message earlier in this thread on %_install_langs
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out the big guys into -docs subpackages.
The largest documentation directories being:
5.1M ./bash-3.2 6.8M ./cups-1.3.5 8.1M ./ghostscript-8.61 9.4M ./selinux-policy-3.2.5
luke
Luke Macken (lmacken@redhat.com) said:
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out the big guys into -docs subpackages.
The largest documentation directories being:
5.1M ./bash-3.2 6.8M ./cups-1.3.5 8.1M ./ghostscript-8.61 9.4M ./selinux-policy-3.2.5
While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
Bill
On Tue, 2008-01-29 at 13:52 -0500, Bill Nottingham wrote:
Luke Macken (lmacken@redhat.com) said:
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out the big guys into -docs subpackages.
The largest documentation directories being:
5.1M ./bash-3.2 6.8M ./cups-1.3.5 8.1M ./ghostscript-8.61 9.4M ./selinux-policy-3.2.5While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
Jeremy
On Jan 30, 2008 12:31 AM, Jeremy Katz katzj@redhat.com wrote:
On Tue, 2008-01-29 at 13:52 -0500, Bill Nottingham wrote:
Luke Macken (lmacken@redhat.com) said:
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out the big guys into -docs subpackages.
The largest documentation directories being:
5.1M ./bash-3.2 6.8M ./cups-1.3.5 8.1M ./ghostscript-8.61 9.4M ./selinux-policy-3.2.5While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
Jeremy
I tested 7zip with ultra settings and got this as a result:
7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on selinux-policy-3.0.8.7z selinux-policy-3.0.8
ls -lh selinux-policy-3.0.8.7z 199K 2008-01-30 00:46 selinux-policy-3.0.8.7z
could 7zip compression be of any help?
On Jan 30, 2008 12:49 AM, Valent Turkovic valent.turkovic@gmail.com wrote:
On Jan 30, 2008 12:31 AM, Jeremy Katz katzj@redhat.com wrote:
On Tue, 2008-01-29 at 13:52 -0500, Bill Nottingham wrote:
Luke Macken (lmacken@redhat.com) said:
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out the big guys into -docs subpackages.
The largest documentation directories being:
5.1M ./bash-3.2 6.8M ./cups-1.3.5 8.1M ./ghostscript-8.61 9.4M ./selinux-policy-3.2.5While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
Jeremy
I tested 7zip with ultra settings and got this as a result:
7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on selinux-policy-3.0.8.7z selinux-policy-3.0.8
ls -lh selinux-policy-3.0.8.7z 199K 2008-01-30 00:46 selinux-policy-3.0.8.7z
could 7zip compression be of any help?
Ignore that, I now get it. It is 3.5MB compressed.
Jeremy Katz (katzj@redhat.com) said:
While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
But is it interesting to ship for the real case, or should it be in a separate package? For example, I'm not sure that /usr/share/doc/ghostscript-8.61/Humor.htm is really relevant in all cases.
Bill
On Tue, 2008-01-29 at 20:01 -0500, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
But is it interesting to ship for the real case, or should it be in a separate package? For example, I'm not sure that /usr/share/doc/ghostscript-8.61/Humor.htm is really relevant in all cases.
Another argument in relation to docs and languages is that a lot of the documentation we ship is only available in a handful of languages anyway (in practice, only English), so it will not really help the people for whose benefit we include all those languages anyway...
On Tue, 2008-01-29 at 20:01 -0500, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
While that's 30MB on disk, using bzip2 as an approximation, that would only save about 3.5MB of CD space. Still may be worth doing.
I've been pretty vocally opposed to removing documentation in the past. Because if the documentation is interesting to ship for the real case, then it's also interesting for being on the live images. Especially as they're installable. And especially as we start looking at things like deltarpm where having those bits on the disk to begin with matters
But is it interesting to ship for the real case, or should it be in a separate package? For example, I'm not sure that /usr/share/doc/ghostscript-8.61/Humor.htm is really relevant in all cases.
Or should we not ship it at all? Sticking it in a separate package just leads to the other problems of bloated metadata, etc. And that's a really _dumb_ file :-)
Jeremy
On Jan 29, 2008 7:30 PM, Luke Macken lmacken@redhat.com wrote:
/usr/share/doc is 141mb, but I'm not sure how viable it would be to remove it (everything except the release notes). We could possibly split out
Just to mention if you have missed my my bz entry, but reelase notes are missing on F8 live CD. If you click in the installed of live cd on "Release notes" you get an message saying "file missing".
https://bugzilla.redhat.com/show_bug.cgi?id=429672
desktop@lists.stg.fedoraproject.org
-
Bill Nottingham -
Caolán McNamara -
Douglas McClendon -
Jef Spaleta -
Jeremy Katz -
Juan Camilo Prada -
Luke Macken -
Matthias Clasen -
Valent Turkovic