Revision 14 Release Notes

Today, I'm releasing LFScript 4 revision 14 (UNSTABLE) and an accompanying Live CD.

The reason for the "UNSTABLE" mark is, that it does not include scripts for many popular applications, including any graphical environment.

If you want to build a graphical system, use revision 12.

Changelog

For this revision I focused on proper Live CD creation. The changes listed here improve the Live CD creation process and improve the look of Live CD's that are branded with the 'fsos' script.

• LFScript now reloads /etc/profile, if it is created in a script.
• Removed all unchecked scripts, which includes most BLFS scripts. If you want to build a graphical system, use revision 12.
• Removed the scripts for previous LFS version.
• Merged 'init.sh' with the 'buildiso' script.
• Made several improvements in the 'buildiso' and 'livekernel' scripts.
• Renamed 'fsos2' to just 'fsos'. The version number of fsos will from now on be the same as the LFScript revision that was used to create it.
• Added a script to the 'fsos' directory that merges Live CD's of different architectures into a single image.
• Updated and created the fsos kernel configurations for i386 and x86_64 systems.
• Added the source SVG for the 'fsos_boot.png' isolinux splash screen.
• Updated the 'fsos2' script and renamed it 'fsos-nox' (as it contains 'no X11'). Added a script 'fsos-nox-32' which adds software which only compiles on 32-bit systems (memtest86+).
• Updated the documentation to reflect the current version.

New Live CD

As a result of all the changes, I've been able to build a new Live CD. From now on Live CD's will carry the same version number as the LFScript revision that was used to create it. So, this new CD is "fsos4r14".

Note that because revision 14 does not have scripts for X11, Gnome and KDE (revision 12 does), this Live CD is also without a graphical environment.

Starting with this release, the same Live CD can be used to boot i686 (32-bit) systems and x86_64 (64-bit) systems

This new Live CD is now the recommended host system to use when building LFScript 4.

Revision 13 Release Notes

I'm about to release LFScript 4 revision 13 (unstable). Several important changes have been made, and will be made in the upcomming revisions. Therefore it is important to read the following release notes:

Weekly Release Cycle

Revision 13 is the first in a new weekly release cycle. Revision 14 will be released no later than the 20th of November.

Rev. 13's (and also the next few revisions) main reason for being is to commit several big behind-the-scenes enhancements that were made over the last few months. I'll mark these revisions as "unstable" because they have not been tested thoroughly.

A new incarnation of ScriptFactory has been incorporated in LFClass which will allow me to keep up to date with recent versions of LFS, like I already did for BLFS up to a few months ago.

Change of License

Beginning with revision 13, LFScript and all it's parts are released under the MIT (expat) License, and no longer under the GNU GPL.

This change in Licence will not change anything in the way I'll be developing or distributing LFScript. If anything, you (the user) are getting more freedom in what you are allowed to do with my work.

Read the MIT-License on opensource.org for more information.

LFS-7.0

Rev. 13 includes scripts for a current development version of Linux From Scratch, which is slightly newer than LFS-7.0. These scripts are known to run without errors, but I have not yet tested an installed version of the system.

LFS-7.0 brings a few small changes in the LFS filesystem hierarchy, which possibly breaks compatibility with the LFS-6.8 scripts that were included in the previous revisions of LFScript. Nevertheless, I decided to keep the LFS-6.8 scripts in revision 13 because I have not yet been able to update the BLFS scripts to a current version. While most BLFS packages may compile on an LFS-7.0 system, I have not tested this.

With LFS-7.0, also the host system requirements have changed and unfortunately this means that you can not use any of the current LFScript Live CD's to build it. A new minimal Live CD is being prepared and will be released together with the revision of next week.

Breaking Script Compatibility

A recent blog post discussed a new script layout which I've decided to implement. I've also decided to merge the compilation() and installation() functions in the scripts. The LFS-7.0 scripts all include an empty compilation() function for now, to maintain compatibility with revision 12. But as soon as I've updated the BLFS scripts, these will be removed and compatibility will be lost, so you will then have to reorganize the contents of your custom scripts.

Other small changes

• When the MD5 checksum fails on a particular file, the file is automatically downloaded again from a mirror.
• A few aspects of the host system are checked before building a system, and a warning is issued if it is determined it is unlikely you will be able to complete a build without error. This does not replace the need to ensure that your system meets the host system requirements yourself.
• Some documentation files have been updated
• The scripts in the 'ScriptFactory' directory have been slightly modified and are expected to be replaced entirely in one of the next revisions.

In conclusion

If you want to be sure you'll be able to build and use a new system, you should not download revision 13 (unstable) but stick to revision 12 (stable) for now. If you want a bleeding edge system, get revision 13.

Revision 13: November 13

I'll be working on LFScript again next week; Finishing LFS-7.0 scripts, adding some features and integrating Thunder for the interactive configuration. If all goes well, I'll release revision 13 on the 13th of November.

Framebuffer fun

In addition to making the scripts for LFS-7.0 almost ready for release, this weekend I've been playing with the Linux framebuffer and making it available in Java.

As a result, I decided to make LFScript show a bitmap header (in stead of plain colored text) if you are running it on the Linux console and have a framebuffer:

Compared to the text version:

Combine compilation() and installation() in LFScript?

A new parser for the LFS XML sources (ScriptFactory) is almost finished. It's code is much cleaner than the current ScriptFactory implementation and contains almost no package specific rules (which made the old ScriptFactory a pain to maintain).

Checking the output scripts made me question if it is necessary to keep the compilation() and installation() functions separate. I always had them separated, because the commands in installation() are modified to install the package to a fake root directory.

However, because a small amount of packages use one installation command in between compilation commands, the order of commands is slightly distorted in those scripts. It's nothing serious, but I'm still wondering if combining the two functions would be a cleaner solution. It would break compatibility with earlier LFScript 4.0 scripts though.

No indentation in LFS-7.0

I've decided to change the layout of the scripts I'm preparing for LFS-7.0.

Until now, most commands in a script had an indentation of 2 or 4 spaces. However, this always presented a few problems, especially with the 'cat' command, which potentially could lead to bugs. To simplify things (and avoid unnecessary bugs) I decided to remove the indentation.

I then made some creative use of the '#' (comment) character to clearly mark the different sections of the script.

Here is a comparison, the left script is in the new layout (click to enlarge):

Personally, I believe the scripts look much better than before.

Et tu, Wuala?

As some of you may know, I've been a real fan of Wuala. Their free "trading space" functionality made it possible to keep a lot of GB in the cloud (including the LFScript LiveCD images). And because it's secure it was also perfect for my personal backups.

But in a year, that will be gone... By then, I'll only have 2 GB left, which is not enough to publish Live CD's (not even mentioning that my personal backups will be gone).

Wuala made the unfortunate decision to kill one of the two features which made me use it, and had me talking people into using it. They tell me that "trading storage" had to go, to make room for new (really not impressive) features, which loosely translates to "we are now owned by a corporation that expects us to make money, so now please buy that which used to be free".

And that is not the cynic in me talking, no! I learned about Wuala in a presentation that talked about this very feature being the very thing that defined Wuala. Trading storage equals Wuala.

There already have been a lot of people complaining about the issue, so let's hope they change their mind about this.

In the mean time, please recommend alternatives to me. Thanks.