[00:00] <slangasek> cjwatson: well, at least we now have a mountall+plymouth publishing that *work* together, so users won't wind up with breakage after a normal dist-upgrade
[00:00] <peitschie> hello everyone :)
[00:00] <cjwatson> slangasek: ah yes, ok
[00:00] <slangasek> so I'm less worried about timing of the Breaks: arriving
[00:00] <cjwatson> I'll leave the publisher alone then
[00:01] <slangasek> my current manual run is going to clip the next scheduled run, regardless :)
[00:01] <peitschie> i was wondering if anyone knows who is best to talk to about getting a patch into the python launchpad integration source?
[00:02] <ScottK> File a bug and attach the patch.
[00:05] <peitschie> ScottK: I've done that about a week ago already :)   just seeing if there was a way I could get it looked at any sooner :)
[00:05] <ScottK> If you can make it into a debdiff ready for upload then you can subscribe ubuntu-main-sponsors.
[00:05] <slangasek> Keybuk: I wonder - shouldn't the mountall failure due to missing libs have triggered mountall-shell.conf?
[00:07] <peitschie> ScottK: I'll look into that :).  Thanks heaps :)
[00:07] <Keybuk> slangasek: no, because mountall never ran
[00:07] <Keybuk> I assume it was an exec() failure rather than an exit code?
[00:07] <slangasek> hmm, does that get reported as an exec() failure?
[00:08] <Keybuk> yes
[00:08] <slangasek> ok
[00:08] <Keybuk> upstart holds a close-on-exec fd open to its children
[00:08] <Keybuk> if it closes, then the exec succeeded
[00:08]  * slangasek nods
[00:08] <Keybuk> if it gets data, then the exec failed and the data is the errno
[00:09] <Keybuk> so it can distinguish between child failure and the actual processes own exit codes
[00:10] <slangasek> right, all part of upstart's "No Child Left Behind" policy
[00:14] <robbiew> Keybuk: slangasek: what if someone did? how can they fix that?
[00:14] <robbiew> re: mountall/libplymouth2
[00:15] <slangasek> robbiew: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/538292/comments/3
[00:15] <Keybuk> slangasek: well, more as part of Upstart's "I look after my children, and looking after my children includes killing them myself" policy
[00:15] <slangasek> Keybuk: I prefer my allusions to the Bush Administration's education policies
[00:16] <robbiew> slangasek: ack
[00:16] <Keybuk> slangasek: I don't know anything about that
[00:16] <Keybuk> but I'm good at mass-murder
[00:16]  * cjwatson finds the blkid hang
[00:17] <slangasek> afk for a few
[00:30] <Nafallo> heh. doesn't seem like I need to report the mountall can't find libplybootclient.so.2 then? ;-)
[00:31] <jdong> hahaha
[00:32] <nixternal> slangasek: note that the fix you listed in the bug report is only good for i386 users right now
[00:34] <Nafallo> oh well. was a nice exercise :-)
[00:34] <Nafallo> long time since I had to break into my initramfs ;-)
[00:37] <crimsun> nixternal: it's good for amd64, too.
[00:38]  * directhex is scared to shut down & go to sleep
[00:40] <jpds> directhex: Nah, updates are on the archive.
[00:40] <directhex> which version is doom?
[00:40] <directhex> "the" archive != mirror.ox
[00:41] <slangasek> directhex: the one in the topic
[00:41] <directhex> oh, topic. fancy
[00:41] <jpds> directhex: That mirror going to become a push mirror in future I believe. ;)
[00:42] <directhex> 0.8.0~-12 is safe?
[00:42] <slangasek> yes
[00:42] <slangasek> and 0.8.0~-14 is safe
[00:43] <directhex> i can sleep then. woo!
[00:47]  * Nafallo upgrades mountall and reverts his copied lib :-)
[00:48]  * sistpoty wishes he could upgrade to a new bios containing a sane mac after some flashrom accident :P
[00:50] <nixternal> crimsun: no amd64 here yet for mountall 2.8
[00:51] <jpds> nixternal: Which mirror?
[00:51] <nixternal> figures, as soon as I say that amd64 is there :)
[01:04] <kees> Keybuk: do you have knowledge about default readahead values for devices?  is 256 right?
[01:04] <Keybuk> no
[01:04] <Keybuk> 128 KB
[01:05] <kees> 256 * 512 == 128KB, so yes
[01:05] <kees> I have seen raw performance graphs that imply 4096 is the right block readahead, but that seems like a lot
[01:06] <Keybuk> probably depends wildly on the disk
[01:06]  * kees nods
[01:08] <kees> mathiaz: who does server install testing?  I'm curious about 525425 -- would be nice to get it fixed for this beta.
[01:08] <mathiaz> bug 525425
[01:09] <kees> mathiaz: and I know kirkland has a lot on his plate at the moment, so I'm trying to find someone with cycles.  :)
[01:10]  * mathiaz tries to remember last time he had free cycles....
[01:10] <kees> heh
[01:11] <mathiaz> kees: well - I don't really know what I can do on this one
[01:11] <mathiaz> kees: yes it's a bug
[01:11] <mathiaz> kees: I'm not sure *I* will have time to look into it
[01:12]  * kees nods
[01:12] <kees> yeah.  I just wanted to make sure it stays on the radar.  It seems like a high priority issue -- the server ISO is uninstallable for a majority of users (who installs a server without raid?)
[01:13] <mathiaz> kees: cloud instances? vms?
[01:13] <cjwatson> I've put it on my list for Monday
[01:13] <mathiaz> kees: but yes - I agree
[01:13] <kees> cjwatson: ah! okay
[01:13] <mathiaz> kees: RAID is an important use case
[01:14] <bryceh> kees, hey question on maintaining project packaging using bzr if you're around
[01:14] <cjwatson> unless somebody else can do it faster, but given it's Monday and nobody else really knows grub2?
[01:14] <kees> bryceh: I may be the wrong person, but go ahead.  :)
[01:14] <bryceh> kees, I've got an upstream project foo, and I want to maintain its debian packaging stuff in bzr
[01:14] <cjwatson> s/Monday/Friday/ argh
[01:15] <bryceh> so like have trunk be an import of foo, and branch that to add debian/ and such atop
[01:15]  * kees nods
[01:15] <bryceh> should I register foo as a project in launchpad, and then upload its code to that project's bzr?
[01:15] <kees> bryceh: that's how apparmor's bzr branches are done
[01:15] <bryceh> or is there a better way to do it that doesn't require creating a project?
[01:15] <Keybuk> bryceh: if you upload, james_w's importer will make a lp:ubuntu/foo branch for it
[01:15] <Keybuk> then just push --overwrite your own branch over the top
[01:15] <Keybuk> then use that
[01:16] <kees> bryceh: what Keybuk said or create a project, those are the only two I've ever done.
[01:16] <cjwatson> creating a project: it depends how much of an independent existence you want the upstream to have
[01:16] <mathiaz> bryceh: is your project already packaged in ubuntu?
[01:16] <Nafallo> kees: job-1 installed servers without raid... they used the second hard drive to do rsync backups in cron.daily...
[01:16] <bryceh> mathiaz, no I'm doing the packaging for it from scratch
[01:16] <cjwatson> logically, upstream => project, even though it isn't always worth bothering
[01:17] <bryceh> mathiaz, it's an existing upstream project by a university, hosted in a random git repo somewhere
[01:17] <bryceh> cjwatson, ok
[01:17] <slangasek> is the git repo public?
[01:18] <slangasek> if so, I have a nice recipe that I'm in the process of refining for bzr git-import + bzr-builddeb
[01:18] <cjwatson> or you can use launchpad's automatic git imports
[01:18] <mathiaz> slangasek: ^^ I was about to ask about that
[01:18] <bryceh> slangasek, I don't think it is accessible publically; I think they have an application to get one from fdo though
[01:19] <slangasek> (git-import -> launchpad project; otherwise, you can import *just* the master branch and go the lp:ubuntu/$pkg route)
[01:19] <slangasek> cjwatson: does launchpad do full-repo imports?
[01:19] <cjwatson> just master, I think
[01:19] <slangasek> right
[01:19] <bryceh> ok, I'll make a lp project and shove it in there
[01:19] <cjwatson> though, well, I think you can do multiple imports if they're different series
[01:19] <cjwatson> e.g. grub
[01:22] <slangasek> bryceh: http://www.advogato.org/person/robertc/diary/130.html for lifeless's howto for initial Debianization w/ builddeb
[01:24] <bryceh> slangasek, sweet thanks
[01:24] <slangasek> bryceh: N.B.: when he says 'bzr revert', he actually means "rm -rf debian" :)
[01:25] <bryceh> slangasek, that makes more sense, I was about to ??
[01:25] <bryceh> any conventions for naming of the packaging branch?  'packaging'?  'debian'? 'ubuntu'?
[01:25] <Keybuk> slangasek: what a wonderful command
[01:26] <slangasek> bryceh: well, when you push it to LP, it'll be called "lucid"
[01:26] <bryceh> ok, wfm
[01:27] <bryceh> presto, it lives: https://code.edge.launchpad.net/multitouchd
[01:29] <slangasek> here we go, testing update-manager's upgrading of plymouth+mountall
[01:31] <slangasek> success, good
[01:35] <psusi> jesus, I got my SSD today and had lvm migrate the root over to it, then I rebooted... 5 seconds to initial X startup, which then crashes and has to be restarted, hehe... guess it's too fast.. must be a race condition somewhere...
[01:35] <slangasek> psusi: what version of plymouth?
[01:37] <psusi> what IS this plymouth thing everyone is talking about?  looks like... ohh, boot graphic eh?  version 0.8.0~-13
[01:37] <bryceh> next question with maintaining packaging in bzr...  I would like to just apply changes directly, and not use quilt and debian/patches/* stuff.  Am I insane for wanting to do it this way?  Should I stick with quilt?
[01:37] <Keybuk> nvidia card?
[01:37] <psusi> ati
[01:37] <Keybuk> bryceh: I do it that way
[01:37] <psusi> 4850 hd
[01:37] <Keybuk> psusi: do you see a graphical logo or "Ubuntu 10.04" ?
[01:38] <psusi> no... tty7 looks like it switches modes, but just sits there with a blinking text cursor in the top left and a mouse cursor in the middle of the screen
[01:38] <slangasek> bryceh: not insane; I would recommend a separate topic branch for each logical upstream change, + an integration branch, though I don't know any recipes for this yet
[01:38] <slangasek> psusi: at boot time, which do you see: a graphical logo, or "Ubuntu 10.04"?
[01:38] <psusi> logs show gnome session is up at 5 seconds into the boot, then crashes, and gets respawned on tty8
[01:38] <slangasek> bryceh: (bzr looms might also be relevant here)
[01:38] <bryceh> slangasek, ok
[01:39] <psusi> slangasek, neither
[01:39] <bryceh> slangasek, probably overkill for this project but noted.
[01:39] <slangasek> bryceh: overkill> that just makes this a good project to practice it on :)
[01:39] <bryceh> true :-)
[01:39] <slangasek> psusi: interesting
[01:40] <psusi> log says the X server gets a SIGQUIT
[01:40] <psusi> and it dumps a stack trace
[01:40] <slangasek> psusi: gdm, kdm, or xdm?
[01:40] <Keybuk> psusi: err, you're *sure* you have -13 there/
[01:40] <psusi> after it has initalized everything by the looks of it
[01:40] <psusi> gdm
[01:41] <psusi> ohh, no... it's ~12
[01:41] <slangasek> ah, heh
[01:41] <Keybuk> thanks
[01:41] <Keybuk> because what nearly happened there was that I nearly gave up entirely
[01:41] <Keybuk> broke down
[01:41] <slangasek> yeah, upgrade to -14 :)
[01:41] <Keybuk> and got carried away by men in white coats
[01:41] <psusi> lol, so I guess I'll try updating and see what happens
[01:42] <Keybuk> screaming "BUT I CHANGED ALMOST EVER LINE OF CODE IN THE TRANSITION!!!!  HOW CAN IT STILL DO THAT?"
[01:42] <psusi> or maybe I just disable it... don't really need a boot progress screen when you're able to login after 5 seconds ;)
[01:42] <slangasek> "disable it" - not supported, not an option
[01:42] <Keybuk> psusi: you need plymouth to deal with the cases where the boot doesn't progress
[01:42] <psusi> ohh?
[01:42] <Keybuk> otherwise the first time you have filesystem issues, you'll be up fuck alley without any lube
[01:42] <psusi> how so?
[01:43] <slangasek> plymouth isn't "splash screen pretty"; it's "boot-time I/O arbitration"
[01:43] <Keybuk> "hai psusi, bit of problem with your filesystem, want me to try fixing it?"
[01:43] <Keybuk> type questions
[01:43] <psusi> I don't need that ;)
[01:43]  * ScottK considers the BOFH archives.
[01:43] <slangasek> Keybuk: apparently he's not a fan of lube
[01:44] <Keybuk> psusi: I will remember you saying this when you're in here weeping that you lost your root filesystem
[01:44] <Keybuk> and I will laugh
[01:44] <Keybuk> like this
[01:44] <Keybuk> BWAHAHAHAHA
[01:44] <Keybuk> ;-)
[01:44] <psusi> when I got a problem with my filesystem, I don't want anything trying to automagically jigger with it... I'll boot to single user mode or just the initramfs and diagnose and repair from there ;)
[01:45] <psusi> I've had to do that plenty of times over the years because of my dmraid... when I first got this computer and tried Ubuntu I spend 3 weeks trying to get it to recognize the raid and install and boot up, hehe... had to hex edit partition tables and such a few times
[01:46] <psusi> that was what?  breezy?
[01:46]  * ScottK is really reminded of the BOFH archives.
[01:46] <psusi> hehe... "I need more disk space, I only have 10 megs quota, and it's used up"
[01:46] <psusi> "there you go, you now have 10 megs free"
[01:46] <psusi> "oh wow, 10 megs used, 10 megs free, 20 meg quote... nice!"
[01:47] <psusi> "no, you just have 10 megs free".
[01:47] <bryceh> "let me help you with your bandwidth next..."
[01:47] <psusi> hehehe
[01:48] <psusi> now I still need to figure out why grub is still using the config file on the old hd even though I reinstalled it on the ssd and set the bios to boot from it...
[01:48]  * ScottK was thinking more about the ones where the end user claimed to know better, but whatever.
[01:56] <psusi> wow... bootchart stops at 15 seconds now... 7 seconds of that looks like it was the time it took me to type my password and log in... heh.
[01:56] <psusi> so... what else does plymouth do other than pretty boot candy?
[01:59] <psusi> ohh, it DOES have a man page
[02:09] <Keybuk> heh, the manpage is probably all wrong
[02:11] <psusi> I must say, migrating the root filesystem of the running system over to the new disk on the fly was pretty cool... though the Logical Volume Manager gui locked up during the process... now if only I could have hot plugged the drive.... hrm...
[02:11] <psusi> I'm still surprised that lvm worked on top of dmraid these days
[02:14] <psusi> yea, the man page just describes plymouth-set-default
[02:16] <walters> Keybuk: while you're around, can you fix the FAQ for "Will Upstart replace D-Bus?"; you say "The mechanism for doing this is to send a nonsense message to the service, so D-Bus starts the service (in theory to handle your message).", but actually you can just call StartServiceByName if you want to start a service by side effect
[02:17] <walters> Keybuk: also, is there a way in upstart right now to do something on inotify watches?
[02:18] <walters> Keybuk: we also tossed around the idea of having it handle ACPI events like shutdown, rather than having acpid
[02:19] <Keybuk> there isn't a way right _now_, but there will be
[02:19] <walters> that's for the inotify question?
[02:19] <Keybuk> for both
[02:19] <walters> ah, great
[02:20] <walters> it came out that X used to listen for ACPI events, but no longer does
[02:21] <Keybuk> are there many interesting ones left?
[02:22] <walters> i don't think so but haven't checked
[02:24] <Keybuk> the probable pattern is you'd have something connect to the socket, and make upstart events for them
[02:24] <Keybuk> where we have acpi-support now
[02:25] <psusi> I thought I heard we got rid of hald?
[02:25] <Keybuk> for most things
[02:27] <slangasek> there are a handful of ACPI events still not handled as input-events - ac adapter, battery, power button, I think
[02:32] <psusi> hrm... I'm getting unreleased mem pools running update-grub... looks like os-prober
[02:35] <Keybuk> probably because you haven't got plymouth
[02:36] <psusi> I do
[02:40] <psusi> ohh, THAT logo... ;)
[02:45] <Keybuk> which ?
[02:54]  * Keybuk makes a psusi logo out of the font
[02:57] <psusi> ohh, the ubuntu logo from plymouth
[02:58] <Keybuk> right
[03:00] <psusi> wow... I got lm-sensors fancontrol to stop the fans because the cpu is cool, and told hdparm to spin down the hard drives... that's some peace and quiet... though I still can't get grub to load the .cfg from the ssd automatically ( it still goes to the hd and I have to tell it to switch )
[05:57] <yannick> hello :-) how can i upload a file from my pc to my server?
[05:58] <persia> yannick: I strongly suspect that you would do better to ask that question in #ubuntu
[06:16] <ccheney> persia: heh :)
[06:17] <ccheney> asking any question devel related or not at this time of day on a fri/sat won't get much response
[06:18] <persia> Well, most days.  I happened to be sick this morning, so cancelled my other plans and am around.
[06:18] <persia> I suspect that for most classes of interesting developer question, statistically someone would be around at this hour most weeks.
[06:19] <ccheney> ah
[06:19] <persia> But lots of questions on this channel remain unanswered anyway, as there are few people who know the answers.
[06:19] <ccheney> i figured at Sat 6:20 UTC people would either be asleep or out at a bar
[06:19] <ccheney> except for eastern europe and asia of course
[06:20] <persia> You forget this side of the world, where one has to be farily dedicated to head to a bar at this hour.
[06:20] <ccheney> not a lot of those people in this channel though afaik :)
[06:20] <persia> Yeah, well.  I suspect there's some correspondance between the common assumption that there aren't any and that there aren't any.
[06:21] <ccheney> persia: 3pm is a great time to go to a bar :)
[06:21] <persia> Plus, you forget antipodeans (although I suspect it's a good time for the pub there anyway)
[06:21] <persia> If you're dedicated, sure :)
[06:21]  * persia goes back to trying to saturate the links to the DC
[06:22] <ccheney> i thought antipodean's were classified as being part of asia
[06:24] <persia> Different crustal plate.
[06:24] <ccheney> ah ok
[06:26] <ccheney> i think i got confused by thinking autralasia was just more specific for asia, heh :)
[06:26] <ccheney> its actually appears to be the area southeast of asia
[06:26] <ccheney> s/its/it/
[06:30] <slangasek> I think it's sad that we label these people because of their opposition to iPods
[06:31] <wgrant> We all keep a box of crushed iPods with us at all times to show our true alignment.
[06:32] <ccheney> heh :)
[11:40] <pitti> lucas: hm, I read it as "ruby is GPL or ruby license" and readline is "GPL", so that seemed fine; ruby's copyright file does not restrict the version of the GPL
[11:40] <pitti> ah, I see that was extensively discussed
[11:42] <persia> "GPL" is unfortunately losing independent semantic value with increasing use of "GPLv2" and "GPLv3"
[11:42] <pitti> cjwatson: yeah, seems to be (yay license stupidity); I only looked at debian/copyright, sorry
[13:10] <sivang> hi all
[13:48] <lucas> pitti: I fixed debian/copyright in pkg-ruby's svn ;)
[14:51] <pitti> lucas: thanks
[14:52] <sebner> pitti: is it safe to upgrade to latest udisks (does not happen automatically here) and remove devkit-disks?
[14:52] <pitti> sebner: the udisks upgrade doesn't work because of a libparted problem; yes, it's safe to updated
[14:53] <sebner> great :)
[18:24] <kees> Keybuk: so... how exactly did we go from 18.43s to 10.43s?
[18:25] <sebner> kees: that's certainly black evil magic!
[18:25] <kees> yeaaaa.
[18:28] <cjwatson> kees: see -release from this morning; something to do with a bug causing the switch to vt7 to happen, and compiz is insanely faster at doing its drawing offscreen
[18:28] <cjwatson> er.  NOT to happen
[18:29] <kees> "off screen"? oh, you mean since it's drawing X on vt1 while we're looking at vt7?
[18:29]  * kees goes to read
[18:30] <crimsun> hmm, is -release not logged?
[18:30] <cjwatson> other way round, drawing X on vt7 while we're looking at vt1, I think
[18:30] <cjwatson> this is second-hand though
[18:31] <kees> this cements my opinion that compiz is to blame for everything.  ;)
[18:53] <ScottK> crimsun: It's not.  I have pretty complete logs though if you need someting.
[18:53] <ScottK> ting/thing
[18:53] <crimsun> ScottK: was just interested in the discussion above to which colin referred
[18:56] <ScottK> crimsun: http://paste.debian.net/63969/ is I think it.
[18:59] <cjwatson> yup, that's what I meant.
[19:02] <crimsun> ScottK: thanks
[19:17] <danyR> hi there. has anyone read about possibly steam coming to linux?
[20:36] <YokoZar> Anyone else getting "unable to connect to crash database" with ubuntu-bug ?  It's been broken for a couple days for me now.
[20:38] <geser> bug 538097
[21:37] <jarlath> I'd like to contribute to the bug-triaging effort. Are there any low-hanging-fruit, like following up on old and inactive reports to see if they can be closed?
[21:38] <jpds> jarlath: The BugSquad might be able to help you out, try #ubuntu-bugs.
[21:39] <jarlath> ah yes. Thanks jpds