[00:30] <bdmurray> evand: quitting a only ubiquity install takes me to a full desktop is that expected?
[01:49] <evand> bdmurray: if you quit the installer, you mean?
[01:49] <evand> err yeah, that's what you said :)
[01:49] <evand> yes, it's expected
[01:54] <bdmurray> evand: 'kay, thanks
[09:33] <soren> cjwatson: lp:~soren/tasksel/limit-section You like?
[09:36] <CIA-50> tasksel: cjwatson * r1377 ubuntu/ (debian/changelog tasksel.pl): merge from lp:~soren/tasksel/limit-section
[09:37] <cjwatson> soren: WFM
[09:37] <cjwatson> thanks
[09:38] <soren> Great. Thank *you*.
[10:08] <CIA-50> oem-config: cjwatson * r534 oem-config/ (debian/changelog oem-config-firstboot): Log messages from update-rc.d rather than throwing them away.
[10:58] <davmor2> xivulon: wubi still has no backdrops for Xubuntu or Kubuntu during install was that something that couldn't be fixed?
[11:00] <xivulon> avmor2 haven't tested kubuntu yet
[11:01] <davmor2> np's
[11:01] <xivulon> more importantly I had a chat with cjwatson yesterday, and he submitted a patch reverting the umountfs changes
[11:02] <xivulon> would be good if you could test those changes as I will be able to do so only tonight
[11:02] <davmor2> cool so it should unmount cleanly now?
[11:02] <davmor2> cjwatson: did that fix get into the re-re-re-rolled cds from yesterday?
[11:02] <cjwatson> no
[11:02] <xivulon> don't think they are in the ISO yet, you will probably have to patch /etc/init.d/umountfs manually
[11:03] <cjwatson> I just sent them to xivulon by mail
[11:03] <xivulon> cjwatson a paste would do I guess
[11:03] <cjwatson> http://paste.ubuntu.com/53150/
[11:03] <xivulon> davmor2 all yours :)
[11:04] <davmor2> right so in time for rc then or the day after beta is released :)
[11:05] <xivulon> I did test similar changes (my version offline) and it worked well, should be almost identical to the above but did not have a chance to compare/test yet
[11:07] <cjwatson> day after beta if it works for somebody
[11:09] <davmor2> I has kubuntu wubi installing now what do I need to do?
[11:09] <davmor2> s/has/have
[11:12] <cjwatson> after it's installed, apply that patch to /etc/init.d/umountfs, then reboot and see if it's clean
[11:14] <davmor2> cjwatson: Right never applied a patch is it a magic command line thing or just swapping the file out?
[11:17] <cjwatson> wget -q -O- http://paste.ubuntu.com/53153/plain/ | sudo patch /etc/init.d/umountfs
[11:17] <davmor2> it's installed now just booting up
[11:17] <cjwatson> you'll need to install the patch package first
[11:17] <xivulon> cjwatson no chance to have the patch in for beta?
[11:17] <davmor2> cjwatson: thanks :)
[11:17] <cjwatson> no
[11:17] <cjwatson> xivulon: ^-
[11:17] <xivulon> :(
[11:17] <davmor2> xivulon: we will not re-test again ;)
[11:18] <xivulon> cjwatson I guess it will be okish if people will get it via updates
[11:22] <cjwatson> xivulon: there was no possible way you could have expected it to get into beta when it wasn't tested until the day of beta
[11:22] <davmor2> patched rebooting now
[11:23] <davmor2> bingo
[11:24] <davmor2> cjwatson: It' worked,  do you want it rebooting again just to be sure?
[11:25] <cjwatson> once is fine
[11:25] <cjwatson> I'll upload that, thanks
[11:26] <davmor2> okay
[11:26] <xivulon> thanks a lot
[11:26] <cjwatson> that doesn't mean it's in for beta - the beta CDs have already been rolled
[11:27] <davmor2> :D
[11:27] <xivulon> cjwatson I assume that if it is in the archive people will get it on first update, correct?
[11:27] <cjwatson> xivulon: once it's built, yes
[11:27] <xivulon> this should minimize tickets
[11:27]  * davmor2 scurries off to write down patch info 
[11:28] <xivulon> Can we edit the release note caveats and suggest people to update?
[11:31] <cjwatson> feel free
[11:31] <cjwatson> I assume they're on the wiki, haven't looked yet
[11:31] <cjwatson> but really, people running the beta will be upgrading anyway
[11:32] <xivulon> yep should be fine
[11:32] <xivulon> thanks a lot
[11:45] <xivulon> superm1 will test the preseed tonight
[11:47] <xivulon> davmor2 can you remind me of the backdrop bug #?
[11:50] <davmor2> https://bugs.launchpad.net/wubi/+bug/208818
[11:50] <davmor2> only now both xubuntu and Kubuntu have no backdrop whereas Ubuntu does
[11:53] <xivulon> davmor2 not sure that one is in wubi domain
[12:11] <xivulon> davmor2, when you tested ntfs syncio, was that booting from a normal intrepid installation
[12:13] <davmor2> yes I did an install along side of xp and tested
[12:13] <davmor2> I think let me double check
[12:15] <davmor2> xivulon: no I did it on both wubi and an install if memory serves but definitely an intrepid install I used it to check m-a
[12:18] <davmor2> xivulon: Why?
[12:35] <xivulon> cking asked
[12:36] <xivulon> I guess he was checking whether it was a loop issue rather than an ntfs one
[13:54] <davmor2> cjwatson: why is the default hostname ubuntu on alternate even on a kubuntu and Xubuntu installs?  is it just a individual package that is used across all the desktops, he guesses wildly hoping to be right.
[13:55] <cjwatson> the latter, and because it's not especially clear to me that it's worth changing
[13:55] <cjwatson> bug 120087
[13:56] <cjwatson> I'd do it if the Kubuntu or Xubuntu developers (respectively) came to me and asked for it
[13:56] <davmor2> Okay cool I just wondered I never normally look at it
[13:56] <davmor2> just hit enter
[13:56] <cjwatson> I don't want to do it unilaterally
[14:10] <CIA-50> debian-installer: cjwatson * r968 ubuntu/ (14 files in 3 dirs): Move ports architectures to 2.6.25-2 kernels.
[14:14] <StevenK> cjwatson: Does that mean I can NBS out 2.6.25-1?
[14:16] <cjwatson> no
[14:16] <cjwatson> please wait until (a) after beta (b) linux-ports-meta is done
[14:16] <StevenK> Certainly
[14:17] <StevenK> cjwatson: d-i is one of the steps, and is usually done after -meta, so I thought I'd ask
[14:17] <cjwatson> StevenK: note that I have not uploaded the above change
[14:17] <cjwatson> I was just sticking it into bzr while I remembered
[14:18] <StevenK> Mmmmm, point
[14:30]  * cjwatson goes argh at bug 274219
[14:30] <cjwatson> I think I want a stretch to do nothing else but fix all our LVM and RAID bugs
[14:47] <CIA-50> partman-base: cjwatson * r108 ubuntu/ (choose_partition/partition_tree/do_option debian/changelog):
[14:47] <CIA-50> partman-base: Disable backup while displaying device/partition locked errors; it makes
[14:47] <CIA-50> partman-base: no sense and it can cause us to exit without closing the FIFO to
[14:47] <CIA-50> partman-base: parted_server (LP: #274219).
[16:23] <mathiaz> Hi - when defining a partition recipe, what's the order of the limits ? min_size max_size priority ?
[16:24] <cjwatson> see doc/devel/partman-auto-recipe.txt in debian-installer
:=<minimal size>_<priority>_<maximal size>_<parted fs>
[16:24] <mathiaz> cjwatson: right - however the preseed example in https://help.ubuntu.com/8.04/installation-guide/amd64/preseed-contents.html seems to be different
[16:24] <mathiaz> cjwatson: in the section about partitioning raid
[16:25] <mathiaz> cjwatson: 1000 5000 4000 raid
[16:27] <mathiaz> cjwatson: hm - it seems that only this line is odd - all the other examples in expert_recipe makes sense.
[16:29] <cjwatson> priority isn't necessarily <max
[16:29] <cjwatson> it's a bit weird
[16:29] <CIA-50> debian-installer: cjwatson * r969 ubuntu/ (3 files in 2 dirs): Move mainline architectures to 2.6.27-5 kernels.
[16:51] <kirkland> cjwatson: TheMuso: http://people.ubuntu.com/~kirkland/Screenshot-1.png
[16:52] <kirkland> cjwatson: looks like a bug against partman-base
[16:53] <cjwatson> kirkland: heh, looks like it
[16:53] <kirkland> cjwatson: i'm filing a bug now, will try to fix it
[16:56] <kirkland> cjwatson: another question...
[16:56] <kirkland> cjwatson: i tested an upgrade from hardy to intrepid, as I was curious what the default BOOT_DEGRADED value would be set to
[16:56] <kirkland> cjwatson: it was set to "true" which was unintended and unexpected
[16:57] <kirkland> cjwatson: I'm looking at mdadm.config and mdadm.postinst, where I have
[16:57] <kirkland>     db_get mdadm/boot_degraded
[16:57] <kirkland>     BOOT_DEGRADED="${RET:-false}"
[16:57] <kirkland> and i'd expect it to default to "false" if unset, but that's not happening, empirically
[16:58] <cjwatson> I think you need a DEBCONF_DEBUG=developer trace
[16:59] <cjwatson> trying to zen it will be a pain
[16:59] <kirkland> cjwatson: okay, so i'd like to simplify my test case
[16:59] <kirkland> cjwatson: intrepid install that doesn't actually have raid or mdadm installed
[16:59] <kirkland> cjwatson: so no BOOT_DEGRADED value
[17:00] <kirkland> cjwatson: and then install mdadm
[17:00] <kirkland> cjwatson: that should run the same exec path, right?
[17:00] <kirkland> cjwatson: rather than doing a full hardy -> intrepid upgrade, correct?
[17:00] <cjwatson> ... maybe
[17:01] <cjwatson> that's not obviously the same as a hardy system with mdadm installed
[17:01] <cjwatson> it depends on the maintainer scripts
[17:01] <cjwatson> you could take an intrepid install that doesn't have mdadm installed, install hardy's mdadm (if that works), and then upgrade
[17:01] <kirkland> cjwatson: okay, that sounds better
[17:05] <persia> There seems to be a piece I'm missing in lpia grub support, and I'm having trouble tracking it down.  Specifically, I'm failing with a DeconfError that grub-installer/bootdev doesn't exist.  While this isn't in the debconf DB, From my reading of the code, I'd expect to receive a return value of '', rather than an error.  Could someone point me at what I may be missing?
[17:09] <cjwatson> if it's not in the DB at all then you'll get an error
[17:09] <cjwatson> though I'm surprised it's not in the db
[17:11] <persia> I was a little surprised as well, given that ubiquity appears to have an extra hammer to force the setting: that's why I assumed I was supposed to skip it with a ''.
[17:11]  * persia looks at ubiquity again, harder
[17:12] <cjwatson> check /var/lib/dpkg/info/ubiquity.templates
[17:12] <cjwatson> and also try 'echo GET grub-installer/bootdev | sudo debconf-communicate' from a terminal on the live CD
[17:13] <persia> before or after a failed install?
[17:13] <cjwatson> either
[17:19] <kirkland> cjwatson: what do the :sl1: and :sl3: mean in the templates file?
[17:21] <kirkland> cjwatson: i notice that other text with embedded %s have :sl1: and seem to be working properly...  while partman/text/raid_device has :sl3:
[17:21] <cjwatson> they're translation categorisations from Debian
[17:21] <cjwatson> they have no significance to the installer itself
[17:21] <cjwatson> %s is handled manually with printf, not by anything in (c)debconf
[17:21] <kirkland> red herring then
[17:25] <kirkland> cjwatson: the odd thing is that the only way I can actually get a literal "RAID%s" printed to screen in the installer shell is to:
[17:25] <kirkland> printf "RAID%%s"
[17:25] <kirkland> or
[17:25] <kirkland> printf "RAID%s" %s
[17:25] <cjwatson> well, or anything that doesn't go through printf
[17:26] <kirkland> cjwatson: the relevant code is extracted here: http://pastebin.ubuntu.com/53228/
[17:26] <cjwatson> I can't even find that text
[17:27] <cjwatson> ah, right
[17:27] <kirkland> cjwatson: partman-base
[17:28] <cjwatson> kirkland: the 0 there is suspicious too
[17:29] <cjwatson> provisionally, bearing in mind I'm on the phone, I suspect buggered debconf protocol interaction
[17:32] <kirkland> cjwatson: is there a possibility that this code is duplicated elsewhere?
[17:33] <kirkland> cjwatson: partman-* is a bit of a maze to me, still
[17:33] <cjwatson> I don't *think* so
[17:33] <cjwatson> at the risk of being a broken record, DEBCONF_DEBUG=developer is your friend
[17:34] <persia> cjwatson: Thanks.  That was it precisely.
[17:34] <kirkland> cjwatson: :-)  sure
[17:36] <cjwatson> persia: hmm. what was it? :)
[17:36] <persia> cjwatson: Missing templates.
[17:37] <cjwatson> do you know why?
[17:37] <persia> No, but at least I know have a path I can follow.
[17:37] <persia> s/know/now/
[17:38] <cjwatson> ok
[17:52] <kirkland> cjwatson: the DEBCONF_DEBUG=developer goes on the kernel boot line?
[17:58] <cjwatson> yes
[18:21] <kirkland> cjwatson: http://pastebin.com/f2265a5d0  <- partman debconf debugged
[18:24] <kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
[18:24] <kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
[18:24] <kirkland> Oct  2 17:16:30 debconf: --> METAGET partman/text/raid_device description
[18:24] <kirkland> Oct  2 17:16:30 debconf: <-- 0 RAID%s device #%s
[18:24] <kirkland> that's from syslog
[18:24] <cjwatson> can I have the full syslog? context would be good
[18:25] <cjwatson> debconf debugging doesn't show up in /var/log/partman
[18:59] <kirkland> cjwatson: fwiw, Hardy does *not* suffer the same string formatting problem
[18:59] <kirkland> cjwatson: i debdiff hardy vs. intrepid partman-base, and didn't find a bloody glove
[19:00] <kirkland> cjwatson: i suppose I can check debconf hardy v intrepid, if you think that might be more productive
[19:01] <cjwatson> I don't think it's remotely likely that it's a debconf fault
[19:01] <cjwatson> could I have the full syslog?
[19:09] <kirkland> cjwatson: all attached to that bug
[19:09] <kirkland> cjwatson: https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/277153
[19:10] <persia> And now I even know why, and how to fix it.  While I'm at it, is there a reason partman-efi is built for amd64, except in ubiquity?
[19:21]  * persia looks for amd64 bugs against partman-efi, with the intention of turning it on
[19:44] <CarlFK> cjwatson: [   38.557201]  sdb: unknown partition table
[19:44] <CarlFK> different box/everything from that other box
[19:44] <CarlFK> should I open a new bug?
[19:45] <CarlFK> http://dev.personnelware.com/carl/a/dhcp91/sfdisk.txt
[19:45] <CarlFK> http://dev.personnelware.com/carl/a/dhcp91/fdisk.txt
[19:46] <CarlFK> maybe the boot=?
[19:50] <cjwatson> persia: no, that just sounds like a bug
[19:51] <cjwatson> CarlFK: that means that the kernel doesn't understand the partition table
[19:51] <cjwatson> (not the installer)
[19:51] <persia> cjwatson: Thanks for the confirmation.  I'll definitely fix it then, rather than continuing my search for previous bugs that would have disabled it.
[19:51] <cjwatson> CarlFK: and fdisk doesn't seem to think it's all that great either
[19:51]  * persia files a summary bug for tracking, and prepares a branch for pushing
[19:53] <CarlFK> cjwatson: it is similar to https://bugs.launchpad.net/ubuntu/+bug/273379 - wondering if I should append logs to it or open a new bug
[19:55] <cjwatson> CarlFK: I have no way to know
[19:55] <cjwatson> CarlFK: if in doubt, a new bug explicitly referencing the old bug is better
[19:55] <CarlFK> will do.
[19:55] <cjwatson> and saying that you don't know whether it's the same bug, to fend off triagers
[19:56] <cjwatson> it looks different, at first glance
[19:58] <CarlFK> another issue: same box, after picking the partitions on hdc:  [File system has an incompatible feature enabled.  Compatible features are has_journal, dir_index, filetype, sparse_super and large_file.  Use tune2fs or debugfs to remove features.]
[19:58] <CarlFK> logs: http://dev.personnelware.com/carl/temp/Oct02/b/dhcp91/
[19:59] <CarlFK> pretty sure this isn't my fault..
[20:00] <cjwatson> that's a well-known bug :-(
[20:01] <CarlFK> need more logs ?
[20:03] <cjwatson> hmm, or is it, I can't find a bug where it should be (partman-basicfilesystems)
[20:04] <cjwatson> oh, of course, bug 59620
[20:05] <cjwatson> CarlFK: could you attach that syslog and partman to bug 59620? this is a new manifestation (ext2 with some unusual feature enabled)
[20:06] <CarlFK> will do.
[20:06] <cjwatson> CarlFK: 'tune2fs -l /dev/sdc1' would be good too
[20:12] <CarlFK> cjwatson: should the first be against parted or linux?
[20:13] <cjwatson> CarlFK: linux
[20:18] <cjwatson> kirkland: note how most of the matches for "RAID%s" are closely followed by something where the substitution *did* work
[20:19] <cjwatson> kirkland: it's only right at the end where it went nuts
[20:19] <kirkland> cjwatson: well, i was more puzzled by the fact that that's the only screen that *doesn't* work
[20:20] <kirkland> cjwatson: lots and lot of RAID.*%s.* all over that interface that printed fine
[20:20] <cjwatson> kirkland: I diagnose debconf protocol getting out of step, perhaps due to random stuff echoed to stdout somewhere
[20:20] <kirkland> cjwatson: i know, because I've clicked through those screens _thousands_ of times this release cycle :-P
[20:20] <cjwatson> so the debconf protocol is command on stdin, response on stdout
[20:20] <cjwatson> if something else witters on stdout, it can get confused
[20:21] <kirkland> cjwatson: that seems, um, fragile?
[20:21] <cjwatson> it works :-)
[20:21] <kirkland> :-)
[20:21] <cjwatson> it's considered a bug, yes
[20:21] <cjwatson> but it's very very difficult to fix
[20:21] <cjwatson> it's been considered a bug almost as long as debconf has existed
[20:22] <cjwatson> for the most part, various workarounds take care of it - for example the standard debconf shell confmodule redirects stdout to stderr so that you can't hit it by accident that way
[20:22] <kirkland> yeah
[20:22] <cjwatson> but that's not altogether foolproof and accidents do happen
[20:22] <kirkland> cjwatson: so, i verified that we don't have this problem in hardy
[20:22] <kirkland> hardy.1 anyway
[20:23] <cjwatson> oh
[20:23] <cjwatson> I have a guess
[20:23] <cjwatson> let me verify it
[20:24] <cjwatson> hmm, bad guess, never mind :)
[20:24] <cjwatson> (I thought debconf-set-selections might write to stdout)
[20:24] <kirkland> :-(
[20:25] <cjwatson> it does seem to be right there where it screws up though
[20:26] <cjwatson> oh, of course
[20:26] <cjwatson> we pipe input to debconf-set-selections, which uses debconf ...
[20:26] <cjwatson> go to jail, go directly to jail, do not pass go, do not collect two hundred pounds
[20:27] <evand> haha
[20:28] <cjwatson> I think it might be easier to just duplicate debconf-set-selections' functionality
[20:29] <cjwatson> which in this case is just writing to the logfile
[20:30] <cjwatson> kirkland: try http://paste.ubuntu.com/53261/
[20:30] <kirkland> cjwatson: which source are you looking at?
[20:30] <kirkland> cjwatson: ah
[20:30] <cjwatson> mdadm
[20:30] <cjwatson> sorry, that was my fault, I should have known better
[20:31] <kirkland> cjwatson: okay, i'll give that a shot
[20:40] <CarlFK> can I create a .tar with the BusyBox tar ?
[20:40] <CarlFK> pretty sure I have been told no before
[20:41] <CarlFK> Usage: tar -[zxtvO] - assuming those are the same as http://www.busybox.net/downloads/BusyBox.html there is no -c
[20:43] <cjwatson> debian/config/config.udeb:# CONFIG_FEATURE_TAR_CREATE is not set
[20:43] <persia> Fix for bug 277225 about udebs for grub-installer/lpia and partman-efi/lpia+amd64 is in lp:~persia/ubiquity/lpia-grub
[20:43] <CarlFK> cjwatson: thanks.  I'll note that in my script for the next time I try to figure this out :)
[20:44] <cjwatson> persia: huh, I thought I added grub-installer/lpia already
[20:44] <cjwatson> oh, d-i/lists. bah
[20:44] <persia> cjwatson: Yeah.  I was sure the debian/ubiquity.install-lpia was the last bit, and then found this one.
[20:45] <cjwatson> thanks, I wrote that so should've known :)
[20:45] <persia> Anything else you can think of?
[20:45] <cjwatson> well, I didn't think of this
[20:45] <cjwatson> that *should* be it
[20:45] <persia> OK.  Let's hope this is good then :)
[20:45] <CIA-50> ubiquity: cjwatson * r2871 ubiquity/ (d-i/lists/lpia d-i/lists/amd64 debian/changelog): merge from lp:~persia/ubiquity/lpia-grub
[20:46] <cjwatson> the lp: short form is the finishing touch on this workflow for me
[20:47] <cjwatson> for some reason it makes a big difference
[20:47] <persia> Not having to type the entire string?
[20:47] <cjwatson> I guess so, though that seems trivial
[20:48] <persia> No, it's time consuming, and easy to get wrong.  Short is good.
[20:48] <cjwatson> maybe it's just that I get to use the keyboard rather than having to copy-and-paste with the mouse, and that feels better
[20:48] <persia> I must say, that for all I'm still unhappy with the few universe or multiverse packages that use bzr packaging that I occasionally encounter, working with bzr packaging on the installer has been incredibly pleasant.
[20:49] <persia> I find myself actually almost looking forward to proper source-package branches, although I still need to sort out performance issues.
[20:49] <cjwatson> I wonder what the difference is
[20:50] <cjwatson> I think it makes a big difference to be working on the same branches a lot; the worst slownesses are branching from scratch and pushing up new branches
[20:50] <cjwatson> (and the latter should be fixed once they get stacked branches working)
[20:51] <persia> It's also my special combination of high bandwidth and high latency.
[20:52] <persia> I can download 1GB over a well-served torrent in about 5 minutes.
[20:52] <persia> Anything where I can get a big TCP window, I can download fast, but the slow-start algorithm means I need a lot of bits to fill the pipe.
[20:52] <persia> bzr does lots of little transactions, which is particularly bad for me, especially at 150-200ms from LP.
[21:15] <CarlFK> cjwatson:  some how this: #3 primary   29.7 GB   K ntfs       /windows    (good)
[21:15] <CarlFK> caused Oct  2 19:36:25 kernel: [ 3492.564405] ReiserFS: sdc3: warning: unknown mount option "umask=007"
[21:16] <CarlFK> stuff: http://dev.personnelware.com/carl/temp/Oct02/c/dhcp91/
[21:21] <kirkland> cjwatson: \o/  that fixed it
[21:22] <kirkland> cjwatson: also, i've regression tested the default-BOOT_DEGRADED-to-false-on-upgrade change I made,
[21:22] <kirkland> cjwatson: both look good
[21:24] <cjwatson> cool
[21:25] <cjwatson> CarlFK: sorry, it's after 9pm and I have a headache, I'm not sure I can look at this now
[21:25] <CarlFK> no prob - uploadng stuff to lp
[21:25] <cjwatson> something asynchronous would be better, yes :)
[21:25] <CarlFK> package: installer?
[21:26] <cjwatson> no such package
[21:26] <cjwatson> debian-installer would be fine
[21:26] <CarlFK> thaks
[21:42] <xivulon> cjwatson can confirm that the umountfs patch works well
[22:05] <xivulon> evand, cjwatson, could you please have a quick look at cking comment on https://bugs.edge.launchpad.net/wubi/+bug/204133/comments/59 and let me know what you think is the best course of action about activating syncio in wubi?
[22:06] <xivulon> my 2c is that we should turn it on, since cking is concerned about data loss (although I did not have any such report in 8.04)
[22:07] <xivulon> the wubi delta is minimal, I only add it to the ROOTFLAGS in menu.lst if fs==ntfs, not sure about the actual impact in terms of performance
[22:08] <xivulon> in case we can remove lupin-sysctl hacks
[22:12] <xivulon> superm1, I see you have metalinks up :)
[22:12] <xivulon> on the dailys though the URL contains the builddate, which makes things tricky
[22:13] <xivulon> would it be possible to have a stable URL (redirect or server side symlink)?
[22:13] <xivulon> I would also need a link for what will be the final metalink URL
[22:15] <superm1> xivulon, can you let tgm4883 know?
[22:15] <superm1> he's the one who handled all the metalink stuff
[22:15] <xivulon> sure
[22:16] <superm1> xivulon, so about the no networking thing - it happens in the "install only" mode on the disk too (no live env)
[22:16] <superm1> is that the same case as the regular ubuntu too?  Is network manager wrecking havock?
[22:17] <xivulon> superm1 can you remind me about the networking issue?
[22:22] <superm1> xivulon, network manager doesnt' start up on it's own
[22:22] <superm1> when you go into only-ubiquity or automatic-ubiquity
[22:22] <superm1> i would guess this affects Ubuntu too, but I can't tell for sure since I can't switch VTs in only-ubiquity in a VM
[22:23] <xivulon> would not think that is an issue for wubi, except for updates
[22:24] <superm1> well it is for the mythbuntu installed wubi
[22:24] <superm1> because that means that you cant connect to your backend - which is critical for it to work
[22:24] <xivulon> ah of course
[22:25] <superm1> that's the exact issue you were seeing
[22:25] <superm1> i bet it's because the init script for ubiquity is set to start before network manager's and they don't run in parallel
[22:26] <superm1> bingo.  S29ubiquity and S30NetworkManager
[22:26] <superm1> evand, was there a good reason why you chose 29 for ubiquity's init script then?
[22:27] <xivulon> I am building a new version to try
[22:27] <xivulon> there is no i386 iso for today http://www.mythbuntu.org/devel/dailies/081001/
[22:27] <xivulon> or yesterday
[22:28] <xivulon> I'll use the 30th
[22:28] <xivulon> ps rsync on the server would be welcome :)
[22:30] <superm1> xivulon, http://uk.cdimages.mythbuntu.org/mythbuntu-8.10-beta-desktop-i386.iso
[22:30] <superm1> that's a later one
[22:30] <superm1> what should be syncing across servers right now
[22:30] <superm1> the daily build for i386 broke yesterday i believe
[22:34] <xivulon> downloading
[22:35] <persia> superm1: Which VM solution are you using?
[22:35] <superm1> persia, virtualbox
[22:36] <superm1> when i hit ctrl-alt-fX, it switches my VT of the host system even if the keyboard is grabbed
[22:36] <persia> Ah.  I have a solution for switching VTs in KVM, but not for vbox.
[22:36] <superm1> vmware grabs it fully too
[22:36] <superm1> but my box with vmware workstation is out of commission for now
[22:42] <xivulon> superm1 in vb it is Alt Gr + Fn
[22:43] <cjwatson> xivulon: umountfs> cool, thanks. apparently I uploaded it and forgot about it anyway :)
[22:43] <xivulon> cjwatson, well I tested the original patch, not the actual package
[22:44] <cjwatson> sure, but that's ok
[22:44] <cjwatson> xivulon: syncio> seems like it makes sense to activate it
[22:44] <xivulon> agreed
[22:44] <cjwatson> superm1: 29> it needs to go before gdm
[22:44] <xivulon> I am building a new version with mythbuntu too right now
[22:45] <cjwatson> superm1: NetworkManager probably needs to move a bit earlier in order to give us space for ubiquity without having to change the name :-)
[22:45] <xivulon> cjwatson in case we need to deactivate lupin-sysctl
[22:45] <cjwatson> superm1: uk.cdimages is a pretty confusing name
[22:45] <superm1> cjwatson, that's the main mirror that our images start at before they get spit out
[22:46] <cjwatson> is that United Kingdom or Ukraine? :-) (neither one has the ISO-3166 code UK)
[22:46] <superm1> cjwatson, and then we have a redirect URL that people use
[22:46] <cjwatson> the UK's code is GB
[22:46] <superm1> cjwatson, ah.  it should be united kingdom.
[22:47] <cjwatson> compare gb.archive.ubuntu.com
[22:47] <superm1> cjwatson, but our redirect URL detects where you're coming from and if you are united kingdom and the bandwidth is within limits for the month offer that mirror
[22:47] <superm1> ah i always assumed uk.archive.ubuntu.com was united kingdom too
[22:47] <cjwatson> only due to wildcard DNS
[22:48] <cjwatson> and the fact that the master is in the UK
[22:48] <superm1> ah
[22:49] <superm1> well Daviey, see the above ^.  You want to get that DNS corrected?
[22:52] <superm1> cjwatson, is the order of resolving init scripts case sensitive?  So if NetworkManager was brought down to 29, would it resolve before or after ubiquity?
[22:56] <cjwatson> it's C locale, in which N < u
[22:56] <cjwatson> though n < u anyway so case doesn't matter
[22:58] <xivulon> cjwatson have pushed rev111 for lupin disabling lupin-sysctl
[22:59] <cjwatson> ok, what happens to people upgrading from wubi beta installs if they upgrade to that version of lupin?
[23:11] <cjwatson> xivulon: I also changed it to 0.22 not 0.21ubuntu1 - might want to use dch -iU rather than dch -i for when you're changing packages maintained natively in Ubuntu
[23:12] <xivulon> made note
[23:13] <xivulon> cjwatson good point, as it is now I guess upgrading will be left with lupin-sysctl
[23:13] <cjwatson> that's probably as desired, since they won't get menu.lst changed ...
[23:14] <xivulon> correct
[23:14] <cjwatson> I was worried about lupin getting upgraded but menu.lst not having syncio yet
[23:14] <cjwatson> xivulon: could you add an explicit note about that to the changelog in case others don't follow the reasoning?
[23:14] <cjwatson> possibly as a comment in debian/rules too
[23:15] <xivulon> sure
[23:21] <Daviey> superm1, cjwatson: UK domain noted, will sort it.
[23:21] <cjwatson> thanks
[23:25] <kirkland> cjwatson: kees was about to sponsor my mdadm changes, fyi
[23:26] <kirkland> cjwatson: if you wanted to check them first
[23:26] <cjwatson> if it's basically just including the patch I suggested, I don't think I need to
[23:26] <kirkland> cjwatson: it does that, plus 2 more things....
[23:26] <kirkland> cjwatson: it solves the default-to-false on hardy->intrepid upgrades
[23:27] <cjwatson> ok, sure, I can have a look
[23:27] <kirkland> cjwatson: which is also a 2-liner
[23:27] <kirkland> cjwatson: and mathiaz really wanted to change the debconf text
[23:27] <kirkland> http://people.ubuntu.com/~kirkland/mdadm/mdadm.debdiff
[23:27] <kirkland> cjwatson: apologies, that debdiff contains all the po BS
[23:28] <cjwatson> kirkland: I think that makes sense, except that your changelog comment for the root_on_raid fix is incorrect
[23:29]  * kirkland looks
[23:29] <cjwatson> kirkland: the problem isn't writing to stdout (that was just a hypothesis I had), it's that we're causing debconf-set-selections to read from a pipe from echo rather than from the debconf input fd
[23:29] <cjwatson> so perhaps something like "do not pipe input to debconf-set-selections as that breaks debconf; write directly to the preseed log file instead" would be more accurate
[23:30] <kirkland> cjwatson: my bad
[23:30] <cjwatson> I'm all for pedagogical changelog entries :)
[23:31] <cjwatson> anyway, otherwise fine
[23:34] <xivulon> cjwatson rev 113
[23:34] <xivulon> superm1 can you please remind how to get the password for the backend
[23:35] <cjwatson> xivulon: ok, you didn't need the second changelog line :-) users will see it all at once
[23:35] <superm1> xivulon, as indicated in the gui, /etc/mythtv/mysql.txt :)
[23:35] <cjwatson> I removed it
[23:36] <cjwatson> xivulon: uploaded, thanks
[23:49] <xivulon> superm1, yep nm really needs to be started up upfront
[23:49] <superm1> xivulon, i filed a bug against network manager on it
[23:50] <superm1> xivulon, too bad, that's the only gating factor from wubi working with mythbuntu with that preseed that i see
[23:50] <xivulon> do you want also a backend role?
[23:50] <xivulon> or maybe leave the question unanswered?
[23:51] <superm1> xivulon, well that's a complicated question.  you can't preseed to setup multiple drives can you - both a loop mount and a real file system?
[23:51] <xivulon> by the way mounted with syncio started copying files 1m ago'
[23:53] <xivulon> is it? hmm I have ROOTFLAGS=syncio, but cannot see any trace in /proc/mounts...
[23:56] <xivulon> not sure how to check that
[23:57] <superm1> xivulon, because you'd have to mount the recordings partition to be on your NTFS filesystem and the install on the loop mount.  can you do that with a preseed right now?
[23:58] <xivulon> well the ntfs partition is going to be mounted as /host, so you can preseed /host/yourpath
[23:59] <superm1> is it always mounted as /host?
[23:59] <xivulon> yes
[23:59] <superm1> if we preseed a path that doesnt yet exist, like C:/ubuntu/mythtv, would that get made by the installer?