[09:24] <CIA-18> ubiquity: superm1 * r2162 mythbuntu-ubiquity/ubiquity/frontend/mythbuntu_ui.py: activate tv-out controls for all nvidia drivers
[09:47] <CIA-18> ubiquity: superm1 * r2163 mythbuntu-ubiquity/ (5 files in 4 dirs): allow adding/removing mythstream
[09:55] <superm1> evand, in my experiments this evening, i've been getting a lot of transient issues regarding getting stuck in install_extras.  Will literally work one boot and fail the next.  You guys been encountering anything similar when using install_extras to install language packages lately?
[09:56] <superm1> i narrowed it down to that function with a whole lot of print's around all the function calls of install.py
[10:04] <superm1> the odd thing is that all the extras get installed, and /sys, /proc get umounted.  just sits aimlessly otherwise
[12:06] <cjwatson> evand: did you know about http://www.groklaw.net/comment.php?mode=display&sid=20070921112733615&title=There%20is%20more%20to%20Linux%20than%20Ubuntu&type=article&order=&hideanonymous=0&pid=625102#c625432 ? (Mandriva to ship migration-assistant)
[01:35] <xivulon> cjwatson, is netboot a desirable add-on for wubi?
[01:38] <cjwatson> I can't really imagine it ...
[01:38] <xivulon> same as the debian one
[01:38] <cjwatson> the only case where that would make sense would be with a broken CD drive, and surely booting from an ISO on the hard disk covers that
[01:38] <cjwatson> does Debian win32-loader support netboot?
[01:38] <cjwatson> if so, I don't know what the rationale is
[01:38] <cjwatson> perhaps it can't boot from an ISO on the hard disk
[01:38] <xivulon> netboot is all win32 loader does
[01:38] <xivulon> exactly
[01:40] <xivulon> I strongly prefer the ISO approach since 1) you download from windows and do not expose the user to sorting out networking in a text envirnoment
[01:40] <xivulon> 2) you use ubiquity interface
[01:41] <xivulon> but... if you want to do a dedicated partition installation, using the iso you have to deal with one of the partitions being mounted
[01:42] <cjwatson> at some point, you should just use the normal installer :)
[01:42] <cjwatson> wubi doesn't have to support everything
[01:42] <xivulon> of course
[01:42] <xivulon> it does...
[01:42] <xivulon> we are running the normal installer
[01:42] <cjwatson> I mean just use the normal installer launched normally, not through wubi
[01:43] <xivulon> If people are familiar with ISOs and partitions, sure
[01:44] <cjwatson> when you start getting into more and more complicated scenarios, ultimately yes, people have to learn
[01:44] <xivulon> I always suggest people to do a normal installation if after using wubi they want something extra (usually more disk space or suspend)
[01:44] <cjwatson> the more options wubi has, the more complicated it is itself, and the harder it gets to use ...
[01:44] <xivulon> I agree there
[01:45] <cjwatson> I don't think netboot is particularly desirable for it
[01:46] <xivulon> I just mentioned because if you wanted netboot at a later stage we'd need to add lupin find_* and autopartition-loop to the alternate ISO
[01:46] <cjwatson> I understand, but we can cross that bridge if and when we come to it
[01:47] <xivulon> sure
[01:48] <cjwatson> (autopartition-loop is already on the alternate image; the lupin stuff will require changing the option name and probably significantly different code)
[01:48] <xivulon> cjwatson, as mentioned in the casper bug report I was thinking about a rewrite anyway
[01:49] <cjwatson> that wouldn't help here
[01:49] <cjwatson> this is one area where d-i and casper are likely to need separate code
[01:49] <cjwatson> the environments are too different to be able to share code at this point
[01:50] <xivulon> makes sense
[02:00] <xivulon> On a different topic, is it worth the trouble to support amd64?
[03:09] <evand> cjwatson: I found out through OSNews.  I'm kind of surprised that they didn't try to contact me.  I would've been very willing to explain things and help where possible.
[03:09] <evand> I can't complain though, I really wanted other distros to pick it up and this is a step in that direction.
[03:10] <cjwatson> I wonder if they're keeping the debconf use
[03:10] <cjwatson> I didn't know Mandriva supported that
[03:11] <evand> I image they're just using the m-a binaries (ma-search-users, ma-search-items, and ma-import)
[03:11] <evand> I'll investigate that tonight though as I'm curious if they modified the code at all.
[03:12] <evand> If they're keeping the debconf code, I hope they're following my branch closely, given the recent security issue.
[03:17] <evand> superm1: What function name?
[03:32] <superm1> evand,         under self.install_extras(), self.do_install(self.query_recorded_installed())
[03:32] <superm1> everything is getting installed, but it appears to be hanging through there
[03:34] <evand> Hrm, I haven't noticed any issues installing language packs.
[03:34] <evand> So it's not crashing, just taking a long time?
[03:35] <superm1> well i left it overnight in the VM
[03:35] <superm1> when i went to bed
[03:35] <superm1> and its still there
[03:35] <superm1> so yeah
[03:35] <evand> wow
[03:35] <superm1> so i'm at a bit of a loss of how to debug it now
[03:36] <evand> Python needs a set -x.  The rough equivalent in pdb is poor.
[03:38] <evand> superm1: I generally use a lot of print statements and --debug.
[03:38] <superm1> yeah i tried --debug and got nowhere regarding that.
[03:38] <evand> hrm
[03:39] <superm1> perhaps i'll have to keep tracing further into do_install then with the print statements
[03:40] <superm1> okay well my time this morning for debugging before class is already up, i'll try to continue later on then, thx :)
[03:40] <evand> that's what I ended up doing when working on the lang pack issue
[03:40] <xivulon> superm1 python logging is more convenient for that sort of tasks
[03:41] <evand> no problem, let me know if you need any help and I'll try to reproduce the bug
[03:41] <evand> xivulon: python logging?
[03:41] <xivulon> the logging module in python
[03:42] <xivulon> far better then using print statements
[03:42] <cjwatson> only if you want to leave them in place afterwards, which can clutter the code a lot for random debugging stuff and make it hard to read
[03:43] <evand> yeah, it seems like overkill for debugging
[03:43] <xivulon> cjwatson, let's say that if you "forget" them it's half damage most of the time...
[03:44] <xivulon> evand, once you define a proper debug level, then it's as easy as using print statements
[03:44] <xivulon> a matter of taste I suppose
[05:45] <superm1_> evand, I narrowed it down to the command that is causing issues in do_install
[05:45] <superm1_> cache.open(None)
[05:45] <superm1_> around line 1418 or so
[05:45] <superm1_> of install.py
[05:46] <evand> hrm
[05:46] <superm1_> what is that supposed to be doing exactly?
[05:46] <cjwatson> it reopens the cache to take account of the stuff that was just committed
[05:48] <superm1_> cjwatson, can you think of any reasons that would not be getting along then?
[05:48] <superm1_> perhaps related to bug 131294
[05:48] <cjwatson> I'd have to look at current python-apt code
[05:49] <cjwatson> the temporary workaround for 131294 ought to cover this too, if it's the same thing
[05:51] <cjwatson> perhaps mvo can shed light on why that might hang
[05:51] <evand> ohh, it completely slipped my mind that mythbuntu uses its own install.py
[05:51] <superm1_> evand, well but it inherits from install.py
[05:51] <superm1_> and uses install.py's functions then for things like this
[05:52] <superm1_> i'll be back in about 10 min, gotta run to my next building
[05:54] <evand> uhhh, shouldn't mythbuntu_install.py call Install.__init__()?
[05:54] <cjwatson> it doesn't define its own __init__ - does it need to call the superclass constructor explicitly?
[05:54] <cjwatson> I thought that was implicit
[05:55] <evand> I'm not sure, actually.
[05:55] <cjwatson> "If a base class has an __init__() method, the derived class's __init__() method, if any, must explicitly call it to ensure proper initialization of the base class part of the instance; for example: "BaseClass.__init__(self, [args...] )"."
[05:55] <evand> I'm from a C++ background where this kind of thing is simple ;)
[05:56] <cjwatson> I interpret "if any" as meaning that it's OK if the derived class doesn't have an __init__
[05:56] <evand> ahh
[05:56] <evand> ok
[05:58] <evand> indeed it does work that way
[06:07] <evand> speaking of apt_cache, the debconf python module should really throw a meaningful exception when the database is locked.  If no one beats me to that, I'll take care of it for Hardy.
[06:09] <superm1_> i'm surprised it doesnt already
[06:10] <cjwatson> it's tricky because it's not the confmodule that errors, it's the frontend
[06:11] <cjwatson> so it needs to spot the frontend failing and do something useful
[07:10] <superm1__> well i narrowed it down inside python-apt.  it is hanging on self._cache = apt_pkg.GetCache(progress)
[07:12] <cjwatson> need mvo really
[07:12] <superm1__> yeah
[10:22] <mathiaz> Hi. I'm trying to install an lvm system with the preseed using the ubuntu-server cd.
[10:22] <mathiaz> I've set the following line in the preseed : d-i partman-auto-lvm/disk string /dev/sda
[10:22] <mathiaz> and commented #d-i partman-auto/disk string /dev/sda
[10:23] <mathiaz> but I still end up with a system that is not lvm.
[10:25] <mathiaz> should I set something else in the preseed file ?
[10:26] <cjwatson> d-i partman-auto/method string lvm
[10:26] <cjwatson> partman-auto-lvm/disk doesn't exist; put that back to partman-auto/disk
[10:27] <cjwatson> you might want to set "d-i partman-auto-lvm/new_vg_name string <name>" too
[10:27] <cjwatson> (it'll default to the hostname)
[10:27] <cjwatson> (I think)
[10:27] <mathiaz> cjwatson: ok. I'll try that.
[10:32] <mathiaz> cjwatson: great ! it works. Thanks.
[10:33] <mathiaz> Where should I file a bug for this issue ?
[10:33] <mathiaz> I think it's in the installer guide.
[10:34] <cjwatson> the current version of the installation guide I have doesn't mention partman-auto-lvm/disk
[10:35] <cjwatson> it says:
[10:35] <cjwatson> # Alternatively, you can specify a disk to partition. The device name
[10:35] <cjwatson> # must be given in traditional non-devfs format.
[10:35] <cjwatson> # For example, to use the first SCSI hard disk:
[10:35] <cjwatson> d-i partman-auto/disk string /dev/sda
[10:35] <cjwatson> # In addition, you'll need to specify the method to use.
[10:35] <cjwatson> # The presently available methods are: "regular", "lvm" and "crypto"
[10:35] <cjwatson> d-i partman-auto/method string lvm
[10:35] <mathiaz> hum... I was looking at https://help.ubuntu.com/7.04/installation-guide/amd64/preseed-contents.html
[10:35] <evand> https://help.ubuntu.com/7.04/installation-guide/i386/preseed-contents.html#preseed-partman does
[10:35] <evand> whoops, beat me to it
[10:36] <mathiaz> it also asked me another question about writing the lvm data to the disk.
[10:37] <cjwatson> ah, the 7.04 documentation was out of date there
[10:37] <cjwatson> the 7.10 documentation will be correct in this regard
[10:37] <mathiaz> I guess I'll be able to find the write preseed configuration line with debconf-get-selections ?
[10:37] <cjwatson> bugs on the installation guide go on the installation-guide package
[10:39] <cjwatson> # If one of the disks that are going to be automatically partitioned
[10:39] <cjwatson> # contains an old LVM configuration, the user will normally receive a
[10:39] <cjwatson> # warning. This can be preseeded away...
[10:39] <cjwatson> d-i partman-auto/purge_lvm_from_device boolean true
[10:39] <cjwatson> # And the same goes for the confirmation to write the lvm partitions.
[10:39] <cjwatson> d-i partman-lvm/confirm boolean true
[10:39] <cjwatson> that?
[10:39] <cjwatson> I should get mdke to publish the 7.10 docs
[10:39] <mathiaz> cjwatson: great - thanks.
[10:42] <mathiaz> cjwatson: I think they're online at http://doc.ubuntu.com
[10:43] <cjwatson> mathiaz: I don't see the installation guide there
[10:43] <cjwatson> the doc team tend to conveniently forget things they didn't write :P
[10:44] <mathiaz> cjwatson: agreed. And I'm not sure it's gutsy documenation.
[10:44] <mathiaz> cjwatson: it says feisty in different places.
[11:04] <xivulon> hmm I am testing wubi and am stacked at creating ext3, even using full device zeroing
[11:04] <xivulon> everything is frozen solid
[11:05] <xivulon> I had top running and that looks fine
[11:08] <evand> yeah, that sounds like where we got stuck
[11:08] <evand> if it's anything like what I was experiencing you have a very short window where you could potentially get in there and strace mkfs.ext3
[11:12] <xivulon> weird
[11:12] <xivulon> can it be a unionfs thing? I still get weird messages when shutting down
[11:13] <xivulon> not that unionfs should be directly involved but...
[11:20] <evand> sorry about that
[11:20] <evand> most program crashes are boring, compiz at least makes things interesting
[11:21] <evand> with pretty flashing colors to keep you entertained while you hold down the power button
[11:23] <evand> it could be a unionfs issue, though I'm not sure.  There are apparently still isolated issues with unionfs as was reported in our team meeting this morning
[11:24] <evand> it could also be a ntfs-3g issue, I think, which I believe Colin suggested as a possibility
[11:27] <Knuta> is the 6.06.2 release still estimated for the beginning of october?
[11:28] <evand> mid-october, afaik
[11:28] <Knuta> :-|
[11:28] <evand> but best to ask in #ubuntu-devel
[11:28] <evand> as I am by no means an authority on such subjects
[11:29] <Knuta> okay, then I guess I'll try to hack the old initrd instead.
[11:30] <Knuta> 6.06.1 can't pxe boot on bnx2, and 6.06.2 will fix the issue. I was hoping I didn't have to mess with it on my own.