Merge lp://staging/~jmarsden/ubiquity/lp775124 into lp://staging/ubiquity

This really ought to be done by having the Xubuntu and Lubuntu images
preseed a specific debconf template, rather than by checking for the
existence of preseed files at run-time.

I thought there should be a better way, but I didn't get as far as figuring out what it was! Also, I was looking for a small quick fix, something that might be simple enough to validate that it could get accepted even though we are already in beta :) Sounds like you would prefer I "do it right"... OK.

I think you are saying that there should be a debconf variable ubiquity/minfreespace (or some such name), defined in the debian/templates file in the ubiquity package, and if that variable exists, then ubi-prepare.py would use that value as the offset to filesystem.size to compute the minimum disk space needed, rather than my 600MB hardcoded constant. Otherwise, default to filesystem.size*2 as now, strange though that *2 is.

That makes sense, but I'm not sure I know quite how to do that in Python, and I was looking for a small quick fix that might be simple enough to validate that it could get accepted during beta :)

I'll see what I can come up with using debconf. Oh... once I code this, how can I test it? Is there a way to edit a local copy of lubuntu.seed to include a line setting this new debconf variable, and then say "build me an ISO" using this seed, on my local machine? I understand the build process enough to know what a seed file does and how to edit it to set a debconf variable with a d-i line, but not enough to know how to cause an ISO build to happen locally using a local repository mirror. Pointers appreciated.

Thanks,

Jonathan

Hi, I just noticed this merge proposal in my e-mails :)

Last week I update ubi-prepare a bit so that it now has an hardcoded maximum disk space variable, currently set to 8GB.

That's, if filesystem.size*2 is higher than 8GB and filesystem.size*2 + 20% still fit in 8GB, the installer is only going to ask for 8GB (instead of around 14GB in the case of Edubuntu).

I guess that doesn't help much flavours using CDs, but if we want to make something preseedable, I'd suggest that variable be the right candidate.

Stéphane: I thought that was new when I saw it, but I didn't check the bzr history of it.

To me, that code looks like a workaround for another side-effect of the *2 problem. Basically *2 is not really the correct "fudge factor" for many Ubuntu flavours, IMO.

If we make the preseeded variable the total disk space to ask for, as you suggest, then every time the size of a default install changes, we might need to edit the seed file. If instead we make the preseeded variable the offset from the filesystem.size, that is, the minimum amount of free space needed in addition to the file size being installed, then the total size requirement will 'automatically' change as the size of the stuff in the default install changes, and the seed file only needs a manual update when the amount of free space needed by the installer changes.

My guess is that the size of the default install could change a lot more often than the amount of extra space needed by the installer to work in. On that basis, it seems more useful to me to preseed the offset, the "extra space" needed, rather than the total space requirement.

Based on Colin's suggestion, I have played with using debconf info from Python in test programs, and they work fine if the program is called as debconf ./mytestprogram.py -- but I don't yet know how to access the debconf database correctly/safely from inside a ubiquity plugin. Will the debconf database have already been opened somewhere when the plugin code is called, so there is an existing (global?) db object the plugin can use to do something like

  db.get('ubiquity/minfreediskspace')

with? Or do I need to do the

  import debconf
  db = debconf.Debconf()

inside ubi-prepare.py itself?

Is there documentation somewhere detailing the environment that ubiquity plugins such as ubi-prepare.py run in, and what things ubiquity has already done "above" them which they can make use of? Or do I just have to read all the code :)

Thanks,

Jonathan

Jonathan,

We try to split the code that touches debconf from the UI code as much as possible. In the case of plugins such as ubi-prepare, code that reads from debconf should be located in the Page class, under the prepare function in your case. That should then call self.ui.some_function_to_set_the_ui_appropriately, making sure to either implement it in an interface-neutral way, or account for the KDE frontend either by implementing a function in PageKde as well as PageGtk, or by stubbing out a default function in PageBase or PageKde.

Hope that helps!

I don't know why I didn't make this comment earlier, but I do not believe we should be special casing Ubuntu flavors here at all.

For what it's worth, the fudge factor is there not as a workaround, but because we do not want users creating an Ubuntu installation that is only just big enough to contain the system files. We should ensure they have enough room to be able to use the operating system, including storing documents, music, and downloads, for the life of the installation.

Ideally the iso image would self declare the desired minimal install sizes (e.g. similar to the .disk/info file) and then it would be used in the installer, else use the default fudge factor.

The development of ubiquity has moved to git, still hosted on launchpad. If this merge proposal is still relevant, please resubmit it against the git branches found at https://code.launchpad.net/ubiquity

Sorry for any inconvenience caused.