It contains a few bugfixes, it makes the build of Gnome more stable and scripts for VLC media player and OpenJDK are now ready for use.
'TODO' overview
The short version of what is left to do is: Make sure that LFScript 4 contains
everything that was in LFScript 3.3 and a proper fsOS2 Live CD (or DVD) can be
produced for both 32-bit and 64-bit machines.
The rest of this blog post will explain what is exactly on my 'TODO' list before I will declare LFScript 4 as "stable" and it will get version number 1.0 (it is now version 0.7). Note that I may release a few more revisions before this happens.
Numbers in this article (like #766168) refer to bug entries in Launchpad
(https://bugs.launchpad.net/lfscript). It is there that you can check the status
for each item on this list. When all bugs have been fixed, 1.0 will be released.
Make sure everything in Gnome works perfectly
At this moment (revision 10) Gnome will compile without problems, but at run time there are still some minor problems:
- GDM will not allow you to login (it does not display a list of users or user/password text fields), nor will it allow you to reboot or shutdown, making it pretty useless (#792918).
- If GDM is run at boot (as the default display manager), it will block the initialization of text mode logins, making it impossible to login in any way (#792919).
- The Gnome menu editor will not work if PyGTK is not installed. PyGTK is currently not a dependency of any Gnome script (#792920).
Some additional software should also be included, in particular Gnome-Media (to allow volume control in Gnome) and GParted (partitioning software) (#792921).
Other issues
There are also still some minor problems with non-gnome scripts;
- Firefox does not link to the Java plugin if OpenJDK is installed (#792925).
- Firefox does not have an entry in the Gnome applications menu (#792927).
- A live CD should be ejected before shutdown or reboot (#792928).
- The live CD should start with the console linked to a framebuffer device (this will allow Tux to present itself at boot and provide better color support for text-mode applications). The script 'init.sh' does not create a framebuffer device file (#792930).
Add remaining scripts from LFScript 3.3 (#766168)
Scripts which were available in LFScript 3.3, but still need to be updated for use in LFScript 4:
- Xfce additional software (beyond xfce-core)
- KDE additional software (beyond kdebase)
- Gnome runtime requirements (consolekit, pygtk)
- Gnome additional software (a few have already been included in LFScript 4, but not all)
- Thunderbird
- A nice theme (I used 'candido' in LFScript 3, but maybe fsos2 should have something new)
- Extra fonts
Written documentation (#792932)
Because LFScript 4 has had quite a few changes recently, I've deliberately neglected to keep the documentation up to date (with the exception of the video tutorials). After all, what's the point in writing extensive documentation for features that will change or be dropped shortly after. But now, I feel that it's time to write some complete and properly formatted (as in: not only in plain text, maybe in docbook) documentation.
Merge scripts into ScriptFactory (#792933)
My latest revisions have been about implementing scripts, and not about preserving the differences to be applied in later versions of LFS and BLFS. Most people do not use ScriptFactory at all (and may even think "What the hell is ScriptFactory?") so this is only a minor issue. But it is something that needs to be done for a 1.0 release.
Did I miss something?
It's possible I'll uncover some other minor issues in the time before I release 1.0, in which case I'll file a bug on it at Launchpad.
The bug reporting tool is open for everyone with Launchpad account (which you can get for free). So, if something is missing from this list and also not yet reported on Launchpad (see link at the top of this post) feel free to report it.
Hi, love LFScript.
ReplyDeleteRunning into problem though. I get a "syntax error near unexpected token `>' " when running the script. It seems that the current livecd does not unsderstand the '&>>' redirection command.
Okay, I'll look into it and open a bug about this on your behalf.
ReplyDeleteIn the mean time: The only commands using '&>>' are for installation logging, so if you open lfscript in a text editor and replace all occurrences with '&>' you can temporarily work around this problem.
Cool. It's working now. Thanx.
ReplyDeleteMarcel,
ReplyDeleteThanks for the great work. I found something on the LFS hints page that may be interesting to you. I have thought about trying to implement it myself but the going is slow.
http://www.linuxfromscratch.org/hints/downloads/files/dpkg.txt
@trishtren18 Yes, that is interesting. I plan to have an option in LFScript 5 that enables you to select package managing alternatives. When I get to that, dpkg is probably the first thing that I will try as I already use it all the time in Ubuntu :).
ReplyDeleteI hate to keep bringing up the package managment thing but just found this:
ReplyDeletehttp://www.linuxfromscratch.org/pipermail/blfs-support/2005-May/054899.html
It's a little dated but having something like portage would stay true to the lfs and lfscript source based system.
@trishtren18 That was quite a discussion over there :). I personally have no experience with portage, but I guess it could work.
ReplyDeleteHowever, when I say I want to add package management alternatives, I mean that those managers should be configured to package and install the LFS system. I don't want to use them to fetch and install binaries from other distros, which is what the original poster of that message seems to want to do. If people don't like that, they are free to change it themselves of course.
@marcel I understand what your saying. If that's the case your more looking for package managers that only do source based installs of lfs packages or blfs?
ReplyDelete@trishtren18 I want to use a package manager to make it easier to manage a system built with LFScript, AFTER it has been built and installed.
ReplyDeleteMost people want to be able to install, remove or upgrade packages without reinstalling the entire system, which is something LFScript can not do right now. However, most package managers are designed to do just that. So if LFScript is able to generate packages in a PM format of choice (deb, rpm, tgz, pkg, whatever), you can use your favorite PM to manage the installed system, while LFScript can be used to generate the packages.
Source based package managers are probably not very effective in this scenario, because LFScript will do the building and packaging. The PM would only be used for install, remove and upgrade. So, portage probably won't be one of the options (unless it also has a package format of which I am unaware).
I think I'll write a package translator sometime soon, which will convert the LFScript packages (*.tgz) to something else (*.deb probably), so I can start experimenting with this set up.