Created attachment 165940 [details] [review]
Adds LFS support to System-tools-backends. (NOTE: Incomplete, does not have ifname support yet)

Well, it turns out that system-tools-backends needs to change. I've attached a patch that adds LFS support, but it's incomplete, as I diddn't change the ifnames support. Of note:

 * LFS initscripts are in /etc/rc.d/init.d. The way the initscript system works is that there are symlinks to the scripts in /etc/rc.d/init.d for each runlevel, in this format: {S,K}startnumberinitscript.
 * Network scripts and devices are in /etc/sysconfig/network-devices
 * Interface names are fully spelt out, like ifconfig.eth0 for eth0, and it belongs in /etc/sysconfig/network-devices.

Thanks for the work! As I can't test how Linux From Scratch works, I can only trust you if you say it's right. So when you think it's done, please attach a patch and I'll commit it for sure. Of course I can help if you have problems with the way the backends work.

(In reply to comment #2)
> Thanks for the work! As I can't test how Linux From Scratch works, I can only
> trust you if you say it's right. So when you think it's done, please attach a
> patch and I'll commit it for sure. Of course I can help if you have problems
> with the way the backends work.

Thing is, I do need some help with how the backends work. If you could tell me, that would be really helpful, before I hack more on the backends.

Just tell me what areas you think you need help on, and I'll try to explain you how they work.

From your comment #1:
- Init scripts work as other SysV platforms, so have a look at get_sysv_paths(), where you can add a new platform with the correct paths.
- About network interfaces, I can't really help because that's an area I've never worked on. I think you should take example on a distribution that is similar to LFS, copy/paste all functions, and adapt them to what you see.

(In reply to comment #4)
> From your comment #1:
> - Init scripts work as other SysV platforms, so have a look at
> get_sysv_paths(), where you can add a new platform with the correct paths.
I know about that, since I added a entry for LFS. Look in the patch.
> - About network interfaces, I can't really help because that's an area I've
> never worked on. I think you should take example on a distribution that is
> similar to LFS, copy/paste all functions, and adapt them to what you see.
I've began working on it. Hopefully, once I have a LFS system to test it on, I'll see if it's working. A new patch will come really soon.

Created attachment 167663 [details] [review]
Updated version of the LFS/CLFS patch, that adds network interface support and correctly dectets LFS/CLFS systems.

I did say that I'll have a new patch ready soon. And this one now has network interface support as well as correctly detecting LFS and CLFS systems. (Since Cross-LFS and LFS are very similar, I've make CLFS use the LFS rules.)

I think this patch is ready to commit, but first I want this tested. What you should do is:

 1. Build a LFS system using JHALFS and the latest SVN version.
 2. Next, build a minimal Gnome desktop, but make sure all of the deps are installed, and it's best to build Lynx, GPM, Wget, a DHCP client or PPP, and the tools required to build the book (Libxml2 with the python module, Libxslt, Tidy, and Subversion) before rebooting and building X.org and GNOME.
 3. Next, install system-tools-backends with my patch for LFS support.
 4. Then, install the system tools and it's deps.
 5. And finally, try launching the system tools applications.

I hope that this patch works, if it dosen't, tell me. Also, try to look for typos, and fix them before commiting.

Great! Looking at the patch, there doesn't seem to be anything wrong, but I won't be able to test it, sorry. I really appreciate your work, but I don't have the time (the the disk space FWIW) to install LFS to check if it works.

It could be nice to find people using LFS that would be OK to apply your patch and test, since it doesn't require compiling anything. But if you apply a strict testing procedure yourself, it might be enough.

So if you tell me you're reasonably confident with your code, I can commit it for you. Anyway, it won't be worse than no support at all, and I don't think there could be anything dangerous at stake (removing files, granting permissions...).

(In reply to comment #7)
> Great! Looking at the patch, there doesn't seem to be anything wrong, but I
> won't be able to test it, sorry. I really appreciate your work, but I don't
> have the time (the the disk space FWIW) to install LFS to check if it works.
> 
> It could be nice to find people using LFS that would be OK to apply your patch
> and test, since it doesn't require compiling anything. But if you apply a
> strict testing procedure yourself, it might be enough.
> 
> So if you tell me you're reasonably confident with your code, I can commit it
> for you. Anyway, it won't be worse than no support at all, and I don't think
> there could be anything dangerous at stake (removing files, granting
> permissions...).
I have a good feeling that the patch might work, but I need someone to test it over at LFS first. I think I'll ask Wayne (one of the BLFS editors who is working on upgrading GNOME) on testing my patch with the system tools.

Well, I ended up emailing Wayne's wrong address (his lfs one instead of his personal one), and I'll have to wait some more for a response from Wayne.

No problem - just tell me when testing is OK, and I'll commit the patch, and roll up a tarball not too long after that.

(In reply to comment #10)
> No problem - just tell me when testing is OK, and I'll commit the patch, and
> roll up a tarball not too long after that.

I think I'm ready for it to be commited, but I'd also like it to be comitted to the 2.9.* series as well as the 2.10.* series. You got that? I think this patch is ready to be submitted.

Great! Would you be kind enough to fix a few details before I commit the patch? * I'd like all => in distribution lists to be aligned, meaning you should add a few spaces to all existing lines when "linuxfromscratch" is too long. Or just call it "lfs". ;-)

* In sub get_sysv_paths(), you added one line but didn't end it with ','. Merely for style consistency reasons, it would be better to add it.

When it's ready, please use 'git commit' and 'git format-patch' to create a patch with a one-line summary of the change, and a quick description of LFS's specifics (anything that might help somebody to understand your code later). That way, I'll push the changes ASAP, and release 2.10.2 with LFS support.

Note it doesn't make sense to apply the change to the 2.9.x series: it's not a parallel series at all, it was the unstable series leading to 2.10.x, and was never intended to be shipped by any stable distribution (I know, Ubuntu 10.04 is shipping it but that's a big mistake). 2.9.x is dead now.

(In reply to comment #12)
> Great! Would you be kind enough to fix a few details before I commit the patch?
> * I'd like all => in distribution lists to be aligned, meaning you should add a
> few spaces to all existing lines when "linuxfromscratch" is too long. Or just
> call it "lfs". ;-)
Will do that.
> * In sub get_sysv_paths(), you added one line but didn't end it with ','.
> Merely for style consistency reasons, it would be better to add it.
Again, I'll do that.
> When it's ready, please use 'git commit' and 'git format-patch' to create a
> patch with a one-line summary of the change, and a quick description of LFS's
> specifics (anything that might help somebody to understand your code later).
> That way, I'll push the changes ASAP, and release 2.10.2 with LFS support.
Good. I'll try to make a git-formatted version of the patch soon.
> Note it doesn't make sense to apply the change to the 2.9.x series: it's not a
> parallel series at all, it was the unstable series leading to 2.10.x, and was
> never intended to be shipped by any stable distribution (I know, Ubuntu 10.04
> is shipping it but that's a big mistake). 2.9.x is dead now.
Yep, it is a very big mistake, as BLFS is using that series too. I knew that Wayne was not using a stable version.

Created attachment 169309 [details] [review]
Git-formatted version of the patch. Ready for primetime!

I did say that I'll come with a git-formated patch very soon. And so I did.

The patch is ready to commit. I'll announce the release over at BLFS.

Just remember to use <will.immendorf@gmail.com> as the email address, not <william@william-laptop.(none)>

Created attachment 169335 [details] [review]
Add Linux From Scratch support

Linux From Scratch (LFS) is an guide that allows you to build your
own Linux system, from scratch. Beyond Linux From Scratch (BLFS)
allows for expanding what you can build on your LFS system.
Cross-LFS (CLFS) is basically the same as LFS, but with support
for cross-compiling.

Here's a version where I fixed a few spacing issues. But I'm more concerned with two syntax errors I found in Network/Ifaces.pm: they should have prevented your code from working. So I think you should test interfaces support more carefully, because there may be corner cases you missed. Else, you'd have seen compilation errors.

These errors are:
--- a/Network/Ifaces.pm
+++ b/Network/Ifaces.pm
@@ -1613,7 +1613,7 @@ sub delete_lfs_interface
 
   if ($login)
   {
-    &remove_pap_entry ("/etc/ppp/pap-secrets", $login;
+    &remove_pap_entry ("/etc/ppp/pap-secrets", $login);
   }

@@ -2764,6 +2764,7 @@ sub get_interface_parse_table
-    "linuxfromscratch" >=
-       {
+
+    "linuxfromscratch" =>
+    {
      iface_set    => \&activate_interface,
      iface_delete => \&delete_lfs_interface,
      fn =>

Also, I'd like the description of the commit to explain a little how LFS supports is different from, say, redhat-6.2, or where it's just the same. This can help people that don't use LFS (like me) to work on the code one day. Thanks again!

To apply my version of the patch, just do:
git reset --hard origin (to get rid of your local change, beware you don't have something valuable)
git am $PATH_TO_PATCH (once you have saved the attached file)
[apply your changes]
git commit -a --amend

The thing is, I really don't know how to implement IFNames support in LFS. I mean, unlike other distros like Redhat/Fedora, instead of /etc/sysconfig/network-devices/ifconfig.eth0 (for example) being a text file, it instead is a directory that contains text files for configuring the specified interface, like: pppoe for PPP over Ethernet (aka: DSL), ipv4 for static IP address, and dhclient/dhcpcd for DHCP setup, depending on whenever you are using ISC DHCP or DHCPCD. So, yea, this is more complicated than I relized.

Can you help me with this?

Ah, OK. Shouldn't be too hard to implement, we should try to fix this. Do you know what files we are likely to find in a directory configuring an interface? And the settings they may contain?

I've never worked on Network/Ifaces.pm before, but it seems to me that you can specify several files for an interface - and you seem to have started using this mechanism already. Just replace "IFCFG" with a set of files, and pass them to the parameters listed in "table" depending on where they are stored. So, for a silly example, here's the entry you could have, only using 3 files (PPPOE, IPV4, DHCP), and a few options to make my point:
    "linuxfromscratch" =>
    {
     iface_set    => \&activate_interface,
     iface_delete => \&delete_lfs_interface,
     fn =>
     {
       PPPOE  => "/etc/sysconfig/network-devices/ifconfig-#iface#/pppoe",
       IPV4  => "/etc/sysconfig/network-devices/ifconfig-#iface#/ipv4",
       DHCP  => "/etc/sysconfig/network-devices/ifconfig-#iface#/dhcp",
       CHAT   => "/etc/ppp/%ppp_type%.chat",
       IFACE  => "#iface#",
       IFACE_TYPE => "#type#",
       TYPE   => "%ppp_type%",
     },
     table =>
     [
      [ "bootproto",          \&Utils::Replace::set_sh,            DHCP,  BOOTPROTO ],
      [ "address",            \&Utils::Replace::set_sh,      IPV4,  IPADDR ],
      [ "serial_port",        \&Utils::Replace::set_sh,      PPPOE, MODEMPORT ],
      [ "serial_speed",       \&Utils::Replace::set_sh,      PPPOE, LINESPEED ],
      [ "ppp_options",        \&Utils::Replace::set_sh,      PPPOE, PPPOPTIONS 
   },

But I don't really understand where options are supposed to be found. E.g., the IP address may be obtained using DHCP, or specified statically via IPv4. How does that work? If some options are complex and would need a special treatment, you can provide your custom function instead of \&Utils::Replace::set_sh. I think you can pass as arguments two files if needed, by adding them to the list after the function name. Then you could check the values in the function, and decide what value to return.

But that's very rough and theoretical. If you need help on some options, please tell me how this precisely works, and I'll see what I can do.

Nice idea. But, so that you can see what the actual service files look like, here are some example ones:

Static IP (ipv4)
ONBOOT=yes
SERVICE=ipv4-static
IP=192.168.1.1
GATEWAY=192.168.1.2
PREFIX=24
BROADCAST=192.168.1.255

PPP over Ethernet (pppoe)
ONBOOT="yes"
SERVICE="pppoe"
PPP_OPTS="user jdoe remotename adsl"

ISC DHCP (dhclient) or Dhcpcd (dhcpcd), as both are basically the same except for the default options (and the name):
ONBOOT="yes"
SERVICE="(either dhclient or dhcpcd)"
DHCP_START="(For dhclient, -q is added here. dhcpcd has nothing) <And additional options can be added>"
DHCP_STOP="(For dhcpcd, -k is added here. For dhclient, -q and -r are added) <Again, additional options can be added>"

# Set PRINTIP="yes" to have the script print
# the DHCP assigned IP address
PRINTIP="no"

# Set PRINTALL="yes" to print the DHCP assigned values for
# IP, SM, DG, and 1st NS. This requires PRINTIP="yes".
PRINTALL="no"

This brings up a way to configure which network service starts: instead of using BOOTPROTO, use the ONBOOT varable to control which network service is used.

For example, let's say that ISC DHCP is being used. In that case, you would set that services's ONBOOT to "yes", and set the other scripts to "no", so that they are ignored on boot. This might require quite a few changes to the Ifnames module, and maybe even the system tools themselves if needed.

Additionally, we could also do an if-else check to see if either ISC DHCP or Dhcpcd is installed by checking for their service files (which should be created when the user installs the appropriate package), and set the DHCP variable to point at the appropriate one. So Milan, I'd now like an implementation of my ideas on how to get the ifnames support working and ready (for the commit).

OK. I think you should go over the list of settings that are used in Ifaces.pm, and see for each of them how you can handle it. Some are easy, like static IP. Others will be more tricky, like DHCP. Other options can be ignored, like PRINTIP. But I think it's important to build a list of them and see if everything seems to be OK, and then you'll be able to write code for this.

The DHCP support in LFS seems very raw to me: I'd have thought the tool that manages interfaces is able to detect what DHCLP clients are present, and act accordingly. Instead, it seems we even have to decide for the tool what kind of commands need to be run. This is not really hard to do, but certainly not so clean...

(In reply to comment #21)
> OK. I think you should go over the list of settings that are used in Ifaces.pm,
> and see for each of them how you can handle it. Some are easy, like static IP.
> Others will be more tricky, like DHCP. Other options can be ignored, like
> PRINTIP. But I think it's important to build a list of them and see if
> everything seems to be OK, and then you'll be able to write code for this.
Well, here is my list for options that we should use, and options that we should ignore:

Common:
ONBOOT: This determines if the associated network script should run to set up the interface. We can use this to control which script starts up at boot time, but may take a good bit of code to implement.
SERVICE: This just lists the script's name that is called in /etc/sysconfig/network-devices/services. This can be ignored.

Static IP:
IP: Lists the static IP to use. This is very easy to implement.
GATEWAY: Lists the IP to use as an gateway. Again, easy to implement.
PREFIX: Lists the subnet prefix to use, for example, PREFIX=24 yields a subnet mask of 255.255.255.0.
BRODCAST: Lists the broadcast IP, easy to implement.

PPPoE:
PPP_OPTS: Lists the options for use with PPPoE. Normally, this would list the username and remotename for use. This should be implemted.

DHCP in general:
DHCP_START and DHCP_STOP: Lists the approiate start and stop options to use, it varies depending on the DHCP implemtation. I think we should implement this for people who want to change the default options.
PRINTIP and PRINTALL: On boot, the DHCP client will print the IP (if the PRINTIP version is set), or all of the tecinal info. This can be ignored, since these options are only for curious geeks.

This seems very good to me.
> The DHCP support in LFS seems very raw to me: I'd have thought the tool that
> manages interfaces is able to detect what DHCLP clients are present, and act
> accordingly. Instead, it seems we even have to decide for the tool what kind of
> commands need to be run. This is not really hard to do, but certainly not so
> clean...
Indeed, DHCP is tricky to implement due to the fact that there are diffrent clients that users can use. But what would make it easier would be to use one DHCP configuration file, named dhcp, and that would make it easier to implement, since both the service files for dhclient and dhcpcd are basically the same. But this will require some changes to the BLFS book (and to CLFS SVN, since this change will break support for that distro).

So how does this map to the option Ifaces.pm is using? The big part for you will be finding ways to translate those into options that can be written to the config files, possibly with a few custom fonctions.

First of all, I have created a BLFS ticket describing unifing the service configuration files for Dhclient and DHCPCD. It's located here:

http://wiki.linuxfromscratch.org/blfs/ticket/3145

Anyway, here is what I would map the variables to:

ONBOOT: Normally, this would be mapped to "auto", but in this case, due to LFS's modular script nature, I would use this as a way to determine which script to use, sora like BOOTPROTO. This would need it's own function.

IP: Map to "address"
GATEWAY: Straightforward, map to "gateway"
PREFIX: This is tricky. This needs it's own custom function, and some network knowledge. For example, a prefix of 24 yields a subnet of 255.255.255.0.
BROADCAST: Map to "broadcast".

PPP_OPTS: Well, this does list the username and remote name to use, this would require a custom function.

For the others, we can't map them.

(In reply to comment #24)
> First of all, I have created a BLFS ticket describing unifing the service
> configuration files for Dhclient and DHCPCD. It's located here:
> 
> http://wiki.linuxfromscratch.org/blfs/ticket/3145
Let's see what they say...

> Anyway, here is what I would map the variables to:
> 
> ONBOOT: Normally, this would be mapped to "auto", but in this case, due to
> LFS's modular script nature, I would use this as a way to determine which
> script to use, sora like BOOTPROTO. This would need it's own function.
I don't really get the idea. Does ONBOOT only decides whether an interface has to be set up at boot? What are the scripts we can choose to use?

> IP: Map to "address"
> GATEWAY: Straightforward, map to "gateway"
> PREFIX: This is tricky. This needs it's own custom function, and some network
> knowledge. For example, a prefix of 24 yields a subnet of 255.255.255.0.
Not that hard! I think you just need to use the "netmask" option.

> BROADCAST: Map to "broadcast".
> 
> PPP_OPTS: Well, this does list the username and remote name to use, this would
> require a custom function.
OK, just to concatenate a few PPP options. Quite straightforward. But what about all PPP options like serial_port, serial_speed, dial_command, stupid...?

> For the others, we can't map them.
There must be a way to map them. I can't think of options you don't want or can't support. Only options left:
- WiFi
- DNS server & gateway
- MTU & MRU

I'm not sure what happens to options you don't set. It seems that some platforms don't use some options, so there must be a fallback mechanism. We don't want the GUI to show silly values, and pretend you can change them while it's not the case. We need to check that, but first we can work on supported options. ;-)

(In reply to comment #25)
> I don't really get the idea. Does ONBOOT only decides whether an interface has
> to be set up at boot? What are the scripts we can choose to use?
Normally, it decides whenever a interface is brought up at boot time. But, due to LFS's modular network configuration system, ONBOOT can be used to control which network script is used to configure the interface. This can work on all scripts, and that's what makes my idea so good.
> > PREFIX: This is tricky. This needs it's own custom function, and some network
> > knowledge. For example, a prefix of 24 yields a subnet of 255.255.255.0.
> Not that hard! I think you just need to use the "netmask" option.
Oh. Thanks for the advice.
> > PPP_OPTS: Well, this does list the username and remote name to use, this would
> > require a custom function.
> OK, just to concatenate a few PPP options. Quite straightforward. But what
> about all PPP options like serial_port, serial_speed, dial_command, stupid...?
Yea. Forgot about those other options. Oops. But, the script is for PPPoE, and it's not really needed for that (but it can be used for regular PPP as well, if you feel like it)
Also, can we use DHCP_START and DHCP_STOP for settings? (if it's going to work)
> > For the others, we can't map them.
> There must be a way to map them. I can't think of options you don't want or
> can't support. Only options left:
> - WiFi
There is a hint detailing Wifi support, but it's kinda old.
> - DNS server & gateway
I don't think there is a special network script for that...
> - MTU & MRU
And I don't really know what those are.
> I'm not sure what happens to options you don't set. It seems that some
> platforms don't use some options, so there must be a fallback mechanism. We
> don't want the GUI to show silly values, and pretend you can change them while
> it's not the case. We need to check that, but first we can work on supported
> options. ;-)
Agreed. Also, I made a typo. It's ifconfig.#iface#, NOT ifconfig-#iface#.

(In reply to comment #26)
> (In reply to comment #25)
> > I don't really get the idea. Does ONBOOT only decides whether an interface has
> > to be set up at boot? What are the scripts we can choose to use?
> Normally, it decides whenever a interface is brought up at boot time. But, due
> to LFS's modular network configuration system, ONBOOT can be used to control
> which network script is used to configure the interface. This can work on all
> scripts, and that's what makes my idea so good.
What do you mean by "network scripts"? You have one script for each type of interface?

> > > PPP_OPTS: Well, this does list the username and remote name to use, this would
> > > require a custom function.
> > OK, just to concatenate a few PPP options. Quite straightforward. But what
> > about all PPP options like serial_port, serial_speed, dial_command, stupid...?
> Yea. Forgot about those other options. Oops. But, the script is for PPPoE, and
> it's not really needed for that (but it can be used for regular PPP as well, if
> you feel like it)
I don't "feel like it", but, well, that could be useful.. ;-) The main concern is that things that seem to work but don't are not helping users. So "LFS support" would be better if there aren't missing features. Else, PPP connexions will accept settings, but won't save them to the system.

> Also, can we use DHCP_START and DHCP_STOP for settings? (if it's going to work)
For what? PPP? I don't think mixing two different protocols like that is a good idea, and that won't be easy anyway...

> > > For the others, we can't map them.
> > There must be a way to map them. I can't think of options you don't want or
> > can't support. Only options left:
> > - WiFi
> There is a hint detailing Wifi support, but it's kinda old.
Would be good to have, but if you don't add support for this, wireless interfaces won't be shown (or shown as Ethernet interfaces, which could be misleading).

> > - DNS server & gateway
> I don't think there is a special network script for that...
Sorry, these DNS options are actually only used for PPP. "update_dns" is used to specify whether DNS servers list should be updated with information obtained while connection; "set_default_gateway" decides whether interface should become the default gateway when connected. I confused them with global DNS parameters, but they are set using HostsConfig, and they are generic for Linux systems (/etc/resolv.conf).

We still have to handle the "gateway" option, which is valid for every interface.

> > - MTU & MRU
> And I don't really know what those are.
These are PPP parameters, meaning Maximum Transmission Unit and  Maximum Receive Unit. But they seem to be commented out for other platforms, so let's skip them too.

(In reply to comment #27)
> What do you mean by "network scripts"? You have one script for each type of
> interface?
Network scripts are scripts that are used to set up a connection on the network adapter, like ipv4, dhcp, pppoe, etc. Like, in this case, we can control what method to set the connection up by altering the ONBOOT varable.
> I don't "feel like it", but, well, that could be useful.. ;-) The main concern
> is that things that seem to work but don't are not helping users. So "LFS
> support" would be better if there aren't missing features. Else, PPP connexions
> will accept settings, but won't save them to the system.
Will do. Thanks!
> > Also, can we use DHCP_START and DHCP_STOP for settings? (if it's going to work)
> For what? PPP? I don't think mixing two different protocols like that is a good
> idea, and that won't be easy anyway...
Not for PPP, DHCP.
> > There is a hint detailing Wifi support, but it's kinda old.
> Would be good to have, but if you don't add support for this, wireless
> interfaces won't be shown (or shown as Ethernet interfaces, which could be
> misleading).
The hint in question is located here:

http://www.linuxfromscratch.org/hints/downloads/files/wpa-service.txt

It acually has to do with WPA, but you get the idea.
> > > - DNS server & gateway
> > I don't think there is a special network script for that...
> Sorry, these DNS options are actually only used for PPP. "update_dns" is used
> to specify whether DNS servers list should be updated with information obtained
> while connection; "set_default_gateway" decides whether interface should become
> the default gateway when connected. I confused them with global DNS parameters,
> but they are set using HostsConfig, and they are generic for Linux systems
> (/etc/resolv.conf).
Let's not bother then.
> We still have to handle the "gateway" option, which is valid for every
> interface.
I've got that covered.
> > > - MTU & MRU
> > And I don't really know what those are.
> These are PPP parameters, meaning Maximum Transmission Unit and  Maximum
> Receive Unit. But they seem to be commented out for other platforms, so let's
> skip them too.
Aggreed. Let's not bother.

Well, there has been a big hiatus on this ticket, so it means that I'll quickly fix the networking support (but leaving out Wifi, since LFS currently dosen't really have a script so set the ESSID, and my method for controlling which script is used with the ONBOOT varable). Sooner or later, I'll have a patch ready, the only thing is that the networking will be a little broken, but hey, LFS is targeted towards power users who have a great knowlidge of Linux, and they can easily change the network script files, right?

Can you cook a patch that at least works for most modules without messing too much with network? In the worst case, you can create dummy methods that report no network interface and don't apply changes. It would be silly to lose support for other tools just because of network...

According to its developer(s), gnome-system-tools is not under active development anymore. Functionality has been mostly integrated into GNOME Control Center / "[System] Settings".

It is unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel
free to reopen this bug report in the future if anyone takes the responsibility
for active development again.