[09:39] <ara> cjwatson, morning
[10:31] <lool> Wow, is it on purpose that /boot is formatted as ext2 with d-i?
[10:32]  * persia likes non-journaling /boot
[10:32] <lool> Why?
[10:33] <persia> Because it doesn't change often and I'm still suspicious of filesystems that construct my files from logs at request time.
[10:33] <persia> I've become convinced they are OK for some stuff, but I like my kernels to try to be contiguous (helps to have /boot be far too large and keep few kernels for this).
[10:34] <lool> I dont think there are significant differences in the layout of the files between ext2 and ext3/ext4 once the writes are complete
[10:35] <lool> Especially in the case of a relatively empty partition that you describe
[10:35] <persia> You may be right.  I tend to be overconservative on these matters.
[10:36] <persia> I know that for partman-uboot NCommander wanted to change from ext2 to ext3 for lucid (but there's another bug in partman-uboot that needs fixing first).
[10:36] <lool> In my eyes, the journal helps in the cases of incomplete transactions which is a bonus over ext2, but you still have as much access to the data by remounting the fs as ext2
[10:36] <persia> I've not looked as closely at other bits of partman.
[10:37] <lool> Apparently it's on purpose
[10:37] <lool> I think it's recipes/atomic in partman-auto:
[10:37] <lool>         filesystem{ ext2 }
[10:37] <lool>         mountpoint{ /boot } .
[10:39] <persia> Hrm.  Either that ought be shifted, or partman-uboot shouldn't prefer ext3
[10:43] <lool> I filed LP #527667, but it might all be on purpose, I'm not sure
[10:43] <persia> Let's hope for a speedy wontfix or fix
[11:28] <ara> ev, good morning
[11:30] <cjwatson> lool: I'm not keen to change this
[11:30] <cjwatson> for /boot, a lot of people seem to like to be conservative.
[11:31] <cjwatson> that said using a separate /boot in this case does seem slightly odd
[11:32] <persia> Is it just a leftover from when grub (!2) couldn't understand LVM volumes?
[11:32] <ara> cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/527641
[11:32] <cjwatson> persia: possibly
[11:32] <cjwatson> ara: ok, queued
[11:33] <ara> cjwatson, ok
[11:33] <ev> ara: good morning
[11:33] <CIA-3> ubiquity: cjwatson * r3844 ubiquity/debian/changelog: typo
[11:34] <ara> ev, do you know any reason why lang packs do not get installed? despite having internet connection
[11:35] <ev> ara: not offhand.  Odd, I could've sworn my install test with Spanish selected turned out okay.
[11:35]  * ev digs
[11:35] <ara> ev, I filed a bug with logs
[11:35] <ara> ev, let me find it
[11:35] <ev> ah, cool
[11:35] <CIA-3> ubiquity: cjwatson * r3845 ubiquity/ (debian/changelog ubiquity/frontend/kde_components/PartMan.py):
[11:35] <CIA-3> ubiquity: * KDE frontend:
[11:35] <CIA-3> ubiquity:  - Fix partman component for use_as signature change (LP: #527468).
[11:36] <ara> ev, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/527706
[11:36] <ev> cjwatson: nice, thanks for that
[11:38] <CIA-3> ubiquity: cjwatson * r3846 ubiquity/ (2 files in 2 dirs): on_partitionResized needs a self argument (LP: #527457).
[11:39] <cjwatson> ara: BTW in future it's easier if you can attach logs separately rather than as a tarball
[11:39] <ara> cjwatson, noted
[11:39] <cjwatson> separately => click in browser; tarball => download, fiddle about in vim
[11:40] <ara> if only lp interface allowed attaching more than one file in one server post...
[11:50] <cjwatson> I think it works if you use ubuntu-bug ...
[11:56] <cjwatson> it sort of looks as if install_extras isn't working
[11:57] <cjwatson> (re 527641)
[11:58] <cjwatson> and yet no errors, it just isn't doing anything useful, such as installing the oem-config-gtk package
[12:08] <ev> hrm, I'm indeed getting language-pack-es
[12:13] <cjwatson> do you get a cdrom entry in /etc/apt/sources.list?
[12:13] <cjwatson> my suspicion is that you don't...
[12:13] <cjwatson> it might work for language packs that are in the livefs, because they can just not be removed
[12:13] <cjwatson> except language-pack-es probably isn't is it?
[12:18] <ev> indeed I do not
[12:21] <ev> and language-pack-es is in the livefs
[12:30] <cjwatson> ah, well
[12:31] <cjwatson> that explains it then, you might see the bug with a different language; and then again you might not, since the network is enabled for language pack installation
[12:32] <CIA-3> ubiquity: jriddell * r3847 trunk/ (debian/changelog ubiquity/frontend/kde_ui.py):
[12:32] <CIA-3> ubiquity: kde_ui.py: Always show progressDialog during the install stage (LP:
[12:32] <CIA-3> ubiquity: #527448)
[12:41] <CIA-3> ubiquity: cjwatson * r3848 ubiquity/debian/changelog: releasing version 2.1.28
[12:52] <CIA-3> ubiquity: evand * r3849 ubiquity/ (debian/changelog gui/gtk/stepUserInfo.ui):
[12:52] <CIA-3> ubiquity: Align description labels to the top left on the user-setup page and get
[12:52] <CIA-3> ubiquity: rid of the width request (LP: #524827).
[12:55] <persia> Spreading kudos from #ubuntu-server: Jeeves_> compliments on the Lucid server installer. To whom it may concern :)
[12:57] <cjwatson> cool
[13:55] <dpm> cjwatson, sorry for the delay in replying, just came back some minutes ago. Re: bug 518718 , if the official name is "Ubuntu Netbook" and that's what the code uses, that's just fine. I just wasn't sure at the time.
[13:57] <dpm> regarding the question on whether to update strings, yes, I think it would be good if it's not too much work to update the strings you can as well, and leave the other ones as fuzzy. I can give a heads up to translators to check out that string once it's done
[14:23] <ogra> in oem-config-firstboot i see RET="$(echo GET oem-config/remove | debconf-communicate)"
[14:24] <ogra> what sets that debconf value ?
[14:24] <cjwatson> it's available for preseeding
[14:24] <cjwatson> Description: for internal use; can be preseeded
[14:24] <cjwatson>  Remove oem-config on successful completion
[14:24] <cjwatson> defaults to true
[14:24] <ogra> ah, its ture by default
[14:25] <ogra> yeah, just found that
[14:25] <ogra> thanks
[14:25]  * ogra wonders about the usecase to keep it :)
[14:25] <cjwatson> keep?  it was added as part of a lucid specification
[14:26] <ogra> keeping oem-config instealled i mean
[14:26] <cjwatson> oh, keep oem-config you mean
[14:26] <ogra> yeah
[14:26] <cjwatson> useful for debugging sometimes
[14:26] <ogra> ah
[14:26] <cjwatson> inconvenient when it crashes, you want to run it again, and realise you have to reinstall
[14:26] <ogra> well, oem-config-firstboot should catch that, no ?
[14:27] <ogra> (crashes)
[14:27] <ogra> at least the shell code looks like it would
[14:28] <cjwatson> sort of - usually :)
[14:28] <ogra> heh
[15:12] <NCommander> cjwatson: I was curious on your thoughts for enabling d-i (and ubiquity) to support installation to mtd devices for the 10.10 cycle; I know its been discussed before and upstream, but I was curious if you could shed some light on it (I'd like to propose it as a UDS/M spec)
[15:13] <cjwatson> the only thing I remember about it is that it's viciously hard, and requires parted extensions
[15:13] <cjwatson> best talk with whoever it was was doing it in d-i upstream; Per somebody
[15:14] <ara> cjwatson, I am seeing a strange issue with LVM, can I explain it to you?
[15:16] <ogra> cjwatson, NCommander, it likely requires even a specific design ... like rootfs images to dump there or some such, depending on the device
[15:16] <cjwatson> ara: sure ...
[15:17] <cjwatson> mtd> the different device semantics meant that it involved quite a lot of deep and difficult changes in partman
[15:17] <ara> cjwatson, I installed Ubuntu alt with LVM with encryption; passphrase, let say "pass1"
[15:17] <ara> cjwatson, when done, in the same HD, I installed kubuntu OEM Full disk
[15:17] <ara> when I reboot it asks for the old LVM password, and it reboots in the old Ubuntu system
[15:18] <cjwatson> (nitpick: not an LVM password)
[15:18] <cjwatson> had you believed you'd erased the old system?
[15:19] <ara> yes, full disk, for me, is full disk
[15:19] <ara> is not?
[15:19] <cjwatson> sure, I was just asking
[15:20] <cjwatson> well, evidently it didn't - perhaps it reuses the old volume group, I'm not sure?  it will be difficult to guess without logs
[15:20] <cjwatson> (and I have about five other things on my list right now :-( )
[15:22] <charlie-tca> cjwatson: was able to reproduce the exit code 141 on install again. Am running with debug to get the logs. It seems to be when I have no internet connection
[15:52] <charlie-tca> bug 527848
[15:52] <charlie-tca> I think I got it right this time
[16:27] <cjwatson> charlie-tca: blah, thought I'd fixed that
[16:27] <cjwatson> it's basically what seb128 was seeing, and I fixed it for him, but you're running a version that should contain that fix
[16:32] <cjwatson> oh, something to do with the last partition to be updated being free space
[16:32] <cjwatson> what a mess
[16:43] <charlie-tca> Yeah, it looks like if I don't delete all existing partitions, it fails
[16:43] <charlie-tca> But at least I got the logs this time. Did I get enough information ?
[16:44] <cjwatson> yeah, you did, thanks
[16:45] <cjwatson> I think the fix should be something like http://paste.ubuntu.com/383785/, but of course I'll have to test that
[16:45] <charlie-tca> Okay. thanks
[18:16] <HiHo> LINUX_VERSION_CODE bombs out on Custom Vanilla build. Why Now? Suggestions ...
[20:56] <superm1> cjwatson, 87038c2d5bda2418fda8b1456a0ae81cc3ff5bd8 and 7d13af3279985f554784a45cc961f706dbcdbdd1 are the two commits you might be needing for full 4k stack support from the kernel.  they're GPT related, so i'm not sure you'll be able to develop a sane test case without a machine using uEFI
[20:57] <cjwatson> GPT isn't bound to uEFI, whatever the manufacturers might like you to think ;-)
[20:58] <cjwatson> or EFI for that matter
[20:58] <superm1> true..
[20:58] <cjwatson> but thanks - could you send those to kernel-team@lists.ubuntu.com maybe?
[20:58] <superm1> sure
[20:59] <cjwatson> looks plausible to me, though non-512-byte sector sizes aren't limited to GPTof course
[20:59] <cjwatson> maybe the others don't have that problem
[21:00] <cjwatson> Colin King has a uEFI system lying around, I think
[21:00] <superm1> as i understand, the servers that will be launching with these types of drives will likely be using uEFI also
[21:01] <cjwatson> right.  there are some existing machines as well, notably netbooks with certain SSDs I think
[21:01] <cjwatson> multiple concerns :-/
[21:01] <cjwatson> but yeah, definitely ought to fix this kind of issue in the kernel
[21:02] <cjwatson> oh, yay, slangasek granted my parted FFe request
[21:02] <cjwatson> so I'll start pushing that in after a3, subject to a check that ubiquity still works
[21:02] <cjwatson> and then will probably have to figure out how to actually make use of the new alignment functions in partman
[21:03] <superm1> great!