[00:00] <Keybuk> slangasek: tell me about it
[00:01] <Keybuk> status should exit non-zero if the job isn't running
[00:02] <Keybuk> I think my notes say that it should even exit non-zero if job is starting or stopping - but different non-zero to "not running at all"
[00:02] <Caesar> Keybuk: excellent, you've saved me an email
[00:03] <Caesar> Can you fix it for Lucid?
[00:03] <Keybuk> huh
[00:03] <Keybuk> if slangasek lets me ;P
[00:04] <Keybuk> oh, I see - it got lost in the move to using D-Bus Properties
[00:05] <Caesar> Keybuk: I thought service had a few exit 0's in places as well
[00:06] <slangasek> Keybuk: perfectly fine
[00:06] <slangasek> Keybuk: now, can you tell me why plymouth now falls on its face in the initramfs looking for /proc/cmdline, when it didn't before? :)
[00:10] <slangasek> hmm; maybe that's not the reason it's falling over
[00:10] <slangasek> apparently break=bottom is too late to test, because /proc has already been unmounted again by that point :P
[00:11] <jbebel> cjwatson, using the previous installer (the one that actually supports hard drives), we're now failing to set up encryption when the crypto partman method is used.  Is that known?  I don't find a bug for it.
[00:12] <jbebel> Partitions get created, but there's no LUKS header.
[00:12] <slangasek> jbebel: is that the bug that was in the beta1 release notes about LVM+encryption?
[00:13] <jbebel> That's a different bug, I think.  We were seeing that one, and this is substantially different.
[00:13] <slangasek> Keybuk: aha, got it - --attach-to-session doesn't work without /dev/pts :P
[00:14] <jbebel> with the release notes bug, partitioning, LUKS, LVM, and the root filesystem were setup, just swap wasn't created.  now, we aren't even making it past LUKS.
[00:14] <slangasek> hmm, ok
[00:18] <Keybuk> slangasek: which is why I patched initramfs-tools to mount it ;-)
[00:18] <slangasek> Keybuk: ah, but without a versioned dep
[00:18] <Keybuk> it doesn't break it
[00:18] <slangasek> right, I'll grab that then
[00:18] <Keybuk> it just means you get console splurge
[00:18] <snow_> hm
[00:19] <Keybuk> (the parent exits 69, but it seems that the child carries on regardless)
[00:19] <snow_> quickly can be used for C/C++ ?
[00:19] <slangasek> Keybuk: actually, after plymouth fails to start in the initramfs, it *also* fails to start in the root fs; haven't diagnosed that yet to see if it's the same cause
[00:20] <slangasek> and since I was testing post-initramfs passphrase prompting at the time, I had a right mess
[00:22] <slangasek> the post-initramfs failures may just be unhappiness with my /usr-as-separate-partition
[01:12] <slangasek> Keybuk: ah, and after upgrading initramfs-tools, can't reproduce the failure of the plymouth job post-initramfs. <shrug>
[01:12] <slangasek> so I guess things are working :)
[01:23] <Keybuk> http://news.opensuse.org/2010/03/25/opensuse-11-3-milestone-4-release/
[01:23] <Keybuk> THE APOCALYPSE HAS COME! :D
[01:31] <slangasek> Keybuk: congratulations, your vga16fb renderer has been reported as a bug. :-)
[01:31] <Keybuk> "My $1,000 nVidia card should be able to do more than 16 colors" ?
[01:32] <slangasek> yep
[01:33] <slangasek> though it would be nice to have a crisper logo on vga16fb, that's certainly not the renderer's fault
[01:33] <Keybuk> right, Design were supposed to have furnished us with one long ago
[01:33] <Keybuk> we made them aware of the need for it from the very beginning
[02:09] <jjardon> Hello, could be automake 1.11 upgraded to 1.11.1 ? Automake 1.11 are known to be suffering from critical security issues
[02:09] <jjardon> https://bugs.launchpad.net/ubuntu/+source/automake1.11/+bug/526035
[02:10] <jjardon> the request is for karmic, lucid already have the 1.11.1 version
[02:10] <jjardon> should I file a new bug?
[02:14] <slangasek> jjardon: given that the justification for an update in karmic is a security issue, you should talk to the Ubuntu Security Team, who are already subscribed to the bug; I've added a new bug task for karmic on that bug
[02:15] <jjardon> slangasek, thanks a lot
[02:30] <ion> Le sigh, an apparmor update broke the system again.
[04:05] <ls_a> hi
[07:19] <_minerva> anyone who would be interested in mentoring "truely system wide proxy" for gsoc
[07:26] <_minerva> anyone who would be interested in mentoring "truely system wide proxy" project for gsoc !!
[07:33] <RAOF> _minerva: It's either Friday evening or Saturday for everyone now; it's not a good time for finding people online :)
[07:40] <_minerva> RAOF: k thanks anyway
[11:11] <jdstrand> ion: can you file a bug?
[11:23] <ion> jdstrand: Bug #458299
[11:23] <jdstrand> ion: thanks
[13:29] <dholbach> ArneGoetje: what's going to happen to the branches in Bug #46318 - I'll try to get them from the sponsors' list
[13:42] <yofel> hey, are there any amd64 builds of UNR planned for lucid? (or lucid+1)
[13:42] <sistpoty> gilir: just looking at bug #523433. how about deferring that to lucid + 1 and then making a backport for lucid?
[13:43] <Kalidarn> yeah it'd be good if were amd64 builds because the new N450 atom processor is 64bit
[13:44] <Kalidarn> it's in the MSI Wind series atm http://www.msi.com/index.php?func=prodpage2&maincat_no=135&cat2_no=582 other vendors will follow
[13:44] <kklimonda> what are the benefits of amd64 on netbooks anyway?
[13:45] <Kalidarn> i would have figured it was worthwhile if the chip supported it.
[13:46] <Kalidarn> http://ark.intel.com/Product.aspx?id=42503 :P
[13:54] <tjaalton> slangasek: plymouth-set-default-theme went missing in the last plymouth upload, was that intentional?
[13:54] <tjaalton> *latest
[13:55] <Tm_T> there seems to be plenty of mess with plymouth nowadays
[13:56] <gilir> sistpoty, there is incompatible changes in pcmanfm2, if you use a backport version, you need also changes in others packages
[13:57] <gilir> sistpoty, it will also be less easy to switch for v1 to v2, as the backport will override the previous one automaticly if you are using backports
[14:09] <tjaalton> slangasek: nevermind, seems like some theme packages have not migrated
[14:13] <sistpoty> gilir: what needs to be changed in other packages? why would the backport override the previous one?
[14:30] <ari-tczew> can anybody review SRU? bug 421684
[14:54] <otro_viajero7> hello, how do I specify in my Makefile an "Input file with spaces.c" in gnu make?
[15:00] <sistpoty> otro_viajero7: escape the space with \   ... not too sure how well make handles spaces though (I think I read that there are limitations, but can't find it right now)
[15:01] <otro_viajero7> I tried that, but it does recognize it as two files
[15:03] <sistpoty> otro_viajero7: that works for me: http://paste.ubuntu.com/402439/
[15:04] <sistpoty> otro_viajero7: however you won't be able to use $^ then, obviously
[15:11] <otro_viajero7> thanks sistpoty ;)
[15:11] <sistpoty> yw
[15:12] <gilir> sistpoty, because for lucid +1, it will stay as pcmanfm, there is no need to keep a pcmanfm2 after lucid
[15:13] <sistpoty> gilir: ah, I see, thanks
[15:51] <pecisk> kenvandine, ping?
[15:53] <MaximLevitsky> I need to know exactly how compiz is started on ubuntu
[17:23] <bens_> Ahoi.  Already talked to #virt about this, and no ideas.  Ubuntu 10.04 Beta or 9.10, most recent kvm/libvirt available for either.  Linux guests get ~20MBps disk throughput, windows xp guests get <3MBps at best.  Tested both guests with all possible img types, preallocated.
[17:24] <bens_> I can push >40MBps to the linux guests dev/shm, but only 20MB to disk.  the host disk is capable of 170MBps
[17:24] <bens_> the host disk is ext4 on lvm, on top of mdraid5 10 disks.
[17:24] <bens_> When I put the  guest image in /dev/shm instead, I get proper performance.
[17:25] <bens_> Can't find any reference to this problem on the intarwebs.
[17:25] <bens_> Ideas?
[17:26] <bens_> (p.s. install time for a tinyxp guest (<300MB) was >10 hours with the guest image on the raid.  <5  minutes on shm.
[18:13] <ari-tczew> should do we update-maintainer in SRU?
[18:21] <ScottK> ari-tczew: No.  Minimal diff.
[18:21] <ari-tczew> thanks
[19:19] <psusi> cjwatson, I am working on that libparted code and I'm not sure if it is throwing the correct type of warning because gparted seems to happily ignore it
[19:24] <geser> ScottK: so we (Ubuntu) need to update the Maintainer when modifying packages in the development release, but can "skip" it in SRUs?
[19:25] <ScottK> geser: That's my understanding.  SRU is supposed to be a minimal diff.  Changing maintainer isn't actually needed for the SRU, so I'd call it not minimal.
[19:25] <ScottK> I could certainly be wrong.
[19:27] <geser> I would have excepted that we need to update the maintainer in SRUs too (especially as it is risk-free). But I could be wrong too.
[19:28] <geser> I remember that we didn't do it for SRUs in some older release before we started to systematically update the Maintainer field.
[19:32] <ari-tczew> men, please specify a consensus
[19:35] <cjwatson> I must say, I
[19:35] <cjwatson> 've generally updated Maintainer in SRUs
[19:36] <cjwatson> but I can see the argument for not doing so; I don
[19:36] <cjwatson> 't think it matters either way
[19:36] <ScottK> Clearly don't do it for a Dapper SRU.
[19:36] <ScottK> I'm not sure either.  I'm also not on the SRU team.
[19:37] <cjwatson> (sorry, ' is symbol-shift-m on the N900, while ctrl-m of course generates CR, and I keep missing)
[19:39] <ari-tczew> okay, but if I made update-maintainer on lucid for package from lucid-1 and older is it OK?
[19:42] <ari-tczew> men, please answer, I don't have a lot of time
[19:42]  * sistpoty thinks a change of the maintainer value doesn't effect the value of an SRU, so it's safe to do it
[19:43] <ari-tczew> sistpoty: but not necessary right?
[19:43] <sistpoty> ari-tczew: if anything else is fine, changing maintainer or not can be done by the uploader, whatever the best practice is.
[19:43] <cjwatson> ari-tczew: nobody will argue if you omit the change; people might argue if you include the change
[19:43] <cjwatson> so it seems clear that if you are in doubt then there is a safe option
[19:44] <ari-tczew> ok
[19:44] <cjwatson> ari-tczew: also, "men" sounds weird as a way to address a group like this (even leaving aside questions of sexism); I'd suggest not using that form
[19:45] <sistpoty> (might be lost in translation... good movie btw :))
[19:45] <psusi> cjwatson, so have you any idea why gparted seems to happily ignore libparted warnings when it can't sync the partition table?  from your comments on bug #540940 I got the feeling you are more familiar with it than I
[19:46] <ari-tczew> cjwatson: okay, so s/men/dear developers
[19:46] <cjwatson> psusi: can't look today - but it could well just be catching the exception and ignoring it?
[19:47] <cjwatson> psusi: can't look today - but it could well just be catching the exception and ignoring it?
[19:47] <cjwatson> psusi: gparted didn't inspire much confidence in me when I last looked at it, though at least most of the partitioning logic is still left to libparted
[19:47] <psusi> cjwatson, that's what it seems to do... but I'm wondering why... it seems it ignores the warning, then judges that everything seems ok, and continues
[19:48] <cjwatson> I stopped using it in ubiquity for several good reasons :)
[19:48] <cjwatson> anyway, got to put my daughter to bed, later
[19:48] <psusi> I'm also confused about extended partition handling... I swear that if you had primary slot 4 used for the extended partition, the kernel did not make a /dev/sda4, it just skipped straight to 5 and on for any logical partitions in the extended
[19:49] <psusi> but now it seems it makes /dev/sda4 with a size of 2... it maps the pseudo mbr and the next sector for some reason
[19:53] <ogra_cmpc> cjwatson, n900 ?
[19:53] <ogra_cmpc> welcome to the club :)
[19:56] <sistpoty> psusi: yes, that's what I recall for extended partitions
[19:57] <sistpoty> psusi: actuall it still seems to be true for me with 2.6.32-16-generic #25
[19:58] <sistpoty> +y
[19:58] <sistpoty> (amd64)
[20:05] <psusi> sistpoty, you sure?  because for me I get a dev node for the extended partition of size 2
[20:09] <sistpoty> psusi: that's what I get: http://paste.ubuntu.com/402553/
[20:12] <sistpoty> psusi: so indeed, there seem to be devices for extended partions (not sure if that changed though), which contain the header as expected
[20:13] <cjwatson> psusi: it's certainly what I remember, although I don't know whether it's always been that way.  It seems moderately useful for things like installing a boot loader to the EBR
[20:14] <sistpoty> psusi: /dev/sda3 doesn't have size 2 though: http://paste.ubuntu.com/402556/
[20:14] <cjwatson> not maybe the most useful thing ever, but not useless either
[20:15] <cjwatson> ogra_cmpc: yeah, it's a pretty nice device
[20:16] <cjwatson> been meaning to blog first impressions
[20:16] <ogra_cmpc> yep, i'm in love with it since i got mine
[20:16] <sistpoty> yep, makes inspecting a partion easier (and yes, I did write a program to look for partition header once, since I was an idiot who deleted a partition)
[20:16] <cjwatson> getting a bit late possibly :)
[20:17] <cjwatson> the keyboard isn't quite perfect, and there are a few annoying bugs, but it beats the hell out of S60
[20:17] <cjwatson> and it seems competitive with Android - haven't any direct iPhone experience so can't say there
[20:17] <ogra_cmpc> definately, to sad that maemo is dead though, imho it was a bad decision to drop it
[20:17] <cjwatson> mm
[20:18] <ogra_cmpc> meego simply will take a while to get into such a state
[20:18] <cjwatson> I'm sort of reserving judgement until I see how meego turns out, though dropping the .deb format is a shame
[20:18] <ogra_cmpc> yeah
[20:18] <cjwatson> yeah, switching technologies is going to suck
[20:19] <ogra_cmpc> well, we have omap images since today ... people can start proting to it ;)
[20:19] <ogra_cmpc> *porting
[20:19] <cjwatson> but at least meego will work (to some extent) on the n900, so we won't have to get new devices
[20:20] <cjwatson> I need to start developing for it in some way
[20:20] <cjwatson> at the very least fix the annoying xterm enter bug
[20:20] <cjwatson> anyway, OT I suppose :)
[20:20] <ogra_cmpc> oh, btw, ppc d-i didnt find anna after my upload it seems (/me didnt have time to debug that yet)
[20:20] <cjwatson> grr, that might be a recurring buildd bug
[20:20] <cjwatson> lamont fixed that ...
[20:21] <cjwatson> is there a permission error on sources.list in the log?
[20:21] <ogra_cmpc> i'll ping him on monday and will give it back (if no other upload happened)
[20:22] <ogra_cmpc> hmm, i didnt notice one but i scrolled directly to the error msg
[20:22] <cjwatson> if so, don't just give it back, it needs a launchpad-buildd (re)fix
[20:22] <cjwatson> it was a consequence of upgrading the powerpc buildds to karmic
[20:22] <ogra_cmpc> ah
[20:24] <lamont> cjwatson: which buildd?
[20:24] <lamont> cjwatson: monday I plan to roll a new lp-buildd, there's some dogfood testing first, then we'll blat it to the world
[20:26] <cjwatson> lamont: adare
[20:26] <kusum> cjwatson: Hello
[20:27] <kusum> cjwatson: Doest the code keep changing from new releases of Ubuntu ?
[20:27] <lamont> cjwatson: best way to find the umask of a running process?
[20:27] <cjwatson> kusum: of course; which code in particular?
[20:28] <lamont> GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH
[20:28] <lamont> fixored
[20:28] <kusum> i am sorry
[20:28] <lamont> when one edits the init.d, one should restart the service.
[20:28] <cjwatson> lamont: um, not sure, suppose it's somewhere in /proc but I can't check right now
[20:28] <cjwatson> lamont: ah :) thanks
[20:28] <kusum> i forgot to mention partman-auto-loop code
[20:28] <lamont> no worries - process older than init.d
[20:28] <lamont> so adare is fixed
[20:28] <lamont> giveback left as an exercise
[20:29] <cjwatson> kusum: hasn't changed a huge amount, but sure, it's changed
[20:29] <kusum> cjwatson: what are .nsh files ?
[20:29] <kusum> i did not really find useful info about them
[20:30] <cjwatson> something windowsy.  I don't write Windows code so I don't know
[20:30] <kusum> ok
[20:30] <kusum> cjwatson: it is for ui code in windows ?
[20:31] <sistpoty> lamont: btw, did you reschedule ghc6 on armel? I'm a bit worried if it does make any process, though Laney is certainly  more competent to tell this
[20:32] <sistpoty> lamont: (it seems to not progress since a few days, but as I wrote, Laney is the better person to ask)
[20:32] <cjwatson> kusum: I said I don't know :)
[20:34] <lamont> sistpoty: the jaboticaba build? yeah, I'm ignoring that on the grounds that it'll be interesting to see if it finishes before release
[20:34] <lamont> it's known/expected to not make progress.
[20:34] <lamont> OTOH, armel is keeping up just fine these days, so tying up jaboticaba to find out isn't really hurting anything.  ergo, meh.
[20:34] <kusum> cjwatson:  thanks for the information
[20:37] <cjwatson> kusum: did you try googling for "windows nsh"?  links related to nsis should be relevant
[20:37]  * lamont wanders off to break networking
[20:38] <kusum> cjwatson: i finally understood when i googled "compile nsh files"
[20:38] <kusum> i was thinking nsis was wrong link
[20:38] <kusum> got it now :)
[20:41] <exobuzz> hi
[20:41] <slangasek> tjaalton: yes, it's intentional that it's gone missing, theme packages need to use update-alternatives now instead
[20:41] <exobuzz> i have made a useful bash script I call "ubuntu experience". you can run it from within gnome, to add that unique ubuntu touch to your desktop windows. http://pastebin.com/DafZTLuk
[20:44] <exobuzz> (Yes its a joke, forgive me. i couldnt help myself).
[20:50] <kusum> cjwatson: thank you
[20:57] <cjwatson> kusum: you're welcome
[21:08] <psusi> sistpoty, what does cat /sys/block/sda/sda3/size say?
[21:09] <ari-tczew> please review SRU bug 262235
[21:11] <sistpoty> psusi: 2
[21:12] <sistpoty> psusi: is that in blocks? then 2 would make perfect sense for an extended partition, I guess
[21:12] <psusi> sistpoty, yea... I think so... what's it map the second sector for?
[21:13] <psusi> I and I swear the kernel used to just not map them.... if you only had a extended partition you got sda5 and that was it... no 1-4... seems odd to map the extended container
[21:15] <sistpoty> psusi: not too sure, I admit that I don't recall the format for an extended header, but I think that I recall that it was two blocks (which you really shouldn't take for granted)
[21:15] <psusi> sistpoty, I noticed this because I had an error while testing my fix to parted... tried to create a logical partition starting at the start address of the extended+1... parted thinks it should work and tries, and the kernel rejects the addpart since it overlaps the second sector mapped by the extended partition
[21:15] <psusi> sistpoty, I thought it was just another pseudo mbr so should only be 1 block
[21:16] <sistpoty> psusi: there must be documentation somewhere to prove that speculation (both yours and mine :))
[21:18] <psusi> hrm... seems fdisk doesn't want to start the logical partition for 63 sectors into the extended
[21:19] <sistpoty> psusi: crap, thought that I might help you but reading the wiki article shows that I really don't recall any details, sorry (http://en.wikipedia.org/wiki/Extended_partition)
[21:20] <psusi> oh weird... if I turn off the dos compat flag, fdisk won't start the logical until sector 2111
[21:24] <psusi> hrm... yea, it should only be one sector
[21:24] <psusi> though due to customary cylinder alignment, typically has 62 unused sectors following it before the logical partition
[21:24] <arand> psusi: When I dd my extended partition, I only get 1024b.
[21:25] <arand> psusi: If it remember right.
[21:25] <psusi> arand, right... 2 sectors
[21:25] <psusi> I'm wondering first, why the extended has a dev node at all, I swear this did not used to be the case, and secondly, why it is 2 sectors long
[21:26] <psusi> when you put parted in sector mode it seems to think you can create the logical partition on the very next sector, but the kernel doesn't like it
[21:26] <arand> psusi: I'm quite happy it has, since my main bootrecord is on there :)
[21:26] <psusi> what do you mean?
[21:27] <psusi> extended boot records are not bootable
[21:28] <arand> psusi: I have my main mbr (vbr) residing in that 1024 space, yes.
[21:29] <psusi> arand, that doesn't make sense... by definition the mbr is sector 0
[21:29] <arand> psusi: Well, actually my proper mbr picks up which start key I press and delegate to either sda1 or sda4.
[21:30] <psusi> and sda4 is an extended partition?  weird... what boot loader is this?
[21:34] <arand> psusi: The one on the mbr-proper is some Dell mediadirect thingy ref. http://digiwanderlust.blogspot.com/2008/04/dual-boot-boot-linux-using-dell-media.html, on the extended vbr I have a 466b grub bit I dd:d over from a logical partitions vbr (since grub2 wasn't happy about installing to the extended's bootrecord).
[21:35] <psusi> hrm.... yea, and when I use parted to create several logical partitions, they start on the sector immediately following the ebr.... no second sector unused...
[21:37] <psusi> arand, ack... so you're using blocklists ;)
[21:41] <stgraber> join #hackus
[21:41] <stgraber> oops
[21:44] <psusi> damnit.... hw_sector_size and optimal_io_size in /sys/block/sdd/queue are not writable....
[21:53] <psusi> nice to see that the kernel does not respect the hidden flag on gpt partitions
[22:06] <cjwatson> psusi: imo, none of this extended partition stuff should block your patch; if it's a problem, it isn't a new one
[22:15] <psusi> cjohnston, agreed... just cleaning it up now... think I have it working pretty good now
[22:31] <jbebel> When might I expect linux 2.6.32-18.27 to get built/uploaded?
[22:33] <jbebel> assuming it allows us to test Lucid installs again.
[22:36] <jbebel> Also, I suppose a new d-i will need to be built too.
[22:42] <geser> jbebel: the new linux debs are in the NEW queue and waiting on an archive admin looking at them. if they don't get a special treatment on this weekend, they should get accepted during the week (probably on monday)
[22:48] <rawkasaur> When 10.04 is released, is it recommended to do a fresh install, or will updating be enough?
[22:49] <ScottK> Upgrading should be fine.
[22:51] <rawkasaur> Alright, thanks.
[22:54] <cjwatson> jbebel: um, didn't this morning's d-i build fix the missing modules already?
[22:54] <jbebel> cjwatson, it doesn't appear to have.
[22:55] <cjwatson> well, can't look now ...
[22:55] <jbebel> it's still using -17 and doesn't have sata modules.
[22:55] <jbebel> I was going to take a closer look at why drive encryption was failing, but without drives that's a bit more difficult.
[22:56] <cjwatson> oh, for goodness' sake, I didn't realise they were going to bump abi and obviously ogra didn't check ...
[22:56] <ogra_cmpc> no, i didnt
[22:57]  * cjwatson pulls out the laptop then
[22:57] <ogra_cmpc> i would have noticed if the meta had hit ml laptop during the upgrade this morning but thats obviously still in new
[22:57] <ogra_cmpc> s/ml/my/
[22:57] <slangasek> ups, sorry; smb had mentioned there'd be NEW processing, didn't realize that hadn't been communicated
[22:57] <ogra_cmpc> sorry for that
[22:58] <cjwatson> oh well, I'll sort it out now
[22:58] <cjwatson> jbebel: thanks for the note
[22:59] <jbebel> cjwatson, np
[23:00] <Sarvatt> how about having a plymouth-i-want-a-pretty-boot package that forces plymouth into the initrd? :)
[23:00] <cjwatson> I'll just upload d-i in advance, it can dep-wait or whatever if it likes
[23:01] <jbebel> cjwatson, do you think this new d-i and/or kernel has any chance of fixing drive encryption?  I haven't gotten far figuring out what's wrong yet.
[23:01] <cjwatson> no.
[23:01] <cjwatson> well probably not
[23:01] <cjwatson> d-i's just the core, the initrd doesn't contain partitioning code
[23:01] <jbebel> I filed a bug with partman-auto-crypto, but I'm thinking that was the wrong place.
[23:02] <slangasek> Sarvatt: does it need to be a package?  It's a one-line change to /etc/initramfs-tools/conf.d/
[23:02] <cjwatson> jbebel: it'll do
[23:03] <cjwatson> jbebel: I prefer not to waste time reassigning between packages until I've actually analysed it; any vaguely plausible installer package is fien
[23:03] <cjwatson> *fine
[23:03] <jbebel> fair enough.
[23:04] <Sarvatt> just thinking about user friendlyness for that change even though it is easy to do and it is a common complaint :) guess it'd be more appropriate for something like ubuntu-tweak
[23:05] <cjwatson> jbebel: the race with swap creation is top of my list right now; if that doesn't turn out to fix your problem too, I'll look at it after that
[23:05] <jbebel> Right now we're not even making it to the swap creation step though.  I suspect you'll find the same thing.
[23:05] <cjwatson> I just mean that I want to debug one thing at a time. :-)
[23:06] <jbebel> Sure. :)
[23:06] <cjwatson> races in this sort of area sometimes have multiple consequences, so we'll see
[23:06] <cjwatson> I kind of doubt that this is specific to swap creation, but I haven't narrowed it down yet
[23:06] <Sarvatt> just worked through a problem where someone wasnt getting a splash for almost 30 seconds into the boot with this fstab setup - http://pastebin.com/tYgACis9 would adding nobootwait to one of those partitions fix that?
[23:06] <jbebel> I can't even set up encrypted partitions manually anymore.
[23:07] <cjwatson> Sarvatt: many perfectly normal situations in lucid result in not having a splash for that sort of length of time; it may not be fixed for lucid
[23:07] <cjwatson> I wouldn't advise mucking with fstab to try to influence that
[23:08] <cjwatson> the problem is a conflict between boot performance and boot experience, that needs non-trivial work to resolve
[23:09] <cjwatson> on hard disks, the most efficient way to boot is to run ureadahead to load everything, *and do nothing else while it's running*
[23:09] <Sarvatt> yeah thats why I was suggesting maybe we should have a package people can install that puts plymouth in the initrd with OPTION=FRAMEBUFFER=Y without requiring manual editing
[23:09] <cjwatson> any disk activity at all will spoil its seek pattern and ultimately slow things dodwn
[23:09] <cjwatson> down
[23:09] <cjwatson> but it turns out that getting the splash up before that involves bottlenecking on waiting for the graphics drivers to initialise
[23:10] <cjwatson> Sarvatt: I assumed you didn't understand the problem because you were talking about fiddling with fstab :-)
[23:10] <cjwatson> therefore I thought an explanation might be worthwhile
[23:11] <cjwatson> though you were talking about efifb the other day so I assume you've looked into it ...
[23:12] <ogra_cmpc> Sarvatt, did you actually make that user create a bootchart ?
[23:12] <ogra_cmpc> might be an issue with dmraid or some such
[23:16] <Sarvatt> ah ok, it looked like it was waiting for everything in this guys custom fstab to be ready before continuing because / was ready pretty early into the boot which is why I asked that. it wasn't loading gpu modules until after everything was mounted because they weren't in the initrd and packing in plymouth fixed that
[23:18] <cjwatson> I might be wrong, but I don't think it should wait for filesystems to be up
[23:19] <cjwatson> plymouth starts on starting mountall, and plymouth-splash starts on started plymouth and (your primary graphics device appeared, or other stuff)
[23:20] <slangasek> right
[23:21] <cjwatson> I'm not actually sure what forces ureadahead to be serialised ahead of that, although my understanding is that it is
[23:23] <slangasek> the usual problems we see are 1) ureadahead takes so long that the user is sitting at a blank screen for 30s or more before mountall actually starts mounting anything, or 2) the single-partition SSD install is so fast that gdm is ready to start as soon as udev has announced the video device
[23:23] <slangasek> cjwatson: actually, I don't think anything *does* force it to be serialized; I think we may have just found a bug
[23:24] <slangasek> it may be a bug we don't currently hit because upstart always walks /etc/init in the same order
[23:24] <slangasek> but I don't think we're meant to rely on that
[23:28] <cjwatson> reverse alphabetical order? :)
[23:30] <jbebel> cjwatson, I could be wrong, but I think the end-of-disk gap for md is what broke crypto somehow.
[23:31] <cjwatson> jbebel: seems odd, why would that make any difference?
[23:31] <cjwatson> it gets a fractionally smaller container, that's all, surely?
[23:32] <jbebel> I agree, but it stopped working for us just about with that release of partman-base
[23:32] <cjwatson> I think I'd rather analyse first
[23:32] <jbebel> Sure
[23:34] <jbebel> oh... Hmm.  It might have been something else in 139.  I forgot that our mirrors got a bit behind.
[23:34] <cjwatson> it would be good if you could attach syslog as well as partman
[23:35] <cjwatson> jbebel: I fixed the bit about /boot landing at the end of the disk, BTW, I just haven't uploaded that yet
[23:35] <jbebel> Ah.  Excellent!
[23:35] <slangasek> cjwatson: actually, since ureadahead itself doesn't block, /alphabetical/ order would be the one that gives better performance by starting plymouthd first instead of starting it while ureadahead is in the middle of running :)
[23:36] <cjwatson> partman-auto-lvm 33ubuntu3 will clear that up
[23:36] <cjwatson> slangasek: right, but I mean right now doesn't upstart block due to the 'expect fork' trick in ureadahead before it gets round to starting plymouth?
[23:37] <slangasek> cjwatson: oh, I don't know - I was going by the comment in the job, which says "Forks into the background both when reading from disk and [...]"
[23:38] <slangasek> maybe this all works the way it's supposed to, but if so it's sorely underdocumented :)
[23:38] <cjwatson> nih_dir_walk_scan sorts the list of filenames
[23:39] <cjwatson> I imagine it then inserts them into a linked list such that the last one ends up run first, or something
[23:39] <cjwatson> but haven't bothered to check that
[23:39]  * slangasek wonders if someone can decipher what's really going on in bug #541700, given that the submitter's statements are not credible :/ (aubergine screen with no ubuntu theme installed)
[23:40] <jbebel> We did get bitten by suddenly needing to include partman/confirm_nooverwrite in the preseed after 139.  That should probably be added to the example-preseed in the installation guide.
[23:40] <cjwatson> oh, yeah, I meant to do that
[23:41] <cjwatson> kickseed too
[23:41] <cjwatson> I thought about that and everything and forgot.  Sorry
[23:41] <jbebel> It's fine for us. I figured it out. :)
[23:42] <jbebel> I can file a bug to add it to the manual if that would help.
[23:43] <cjwatson> no need, already committed a fix
[23:44] <cjwatson> and upstream
[23:45] <cjwatson> partman-base 139ubuntu1 is even less likely to have caused this; the core changes there were minimal compared to 138ubuntu4
[23:45] <cjwatson> 138ubuntu3 and 138ubuntu4 were big changes
[23:46] <cjwatson> in fact all the 138ubuntu* series
[23:48] <jbebel> Maybe our mirrors were more behind than I thought.