[00:07] <Gavin__> Good morning!
[00:10] <psusi> rofl
[00:10] <psusi> good change log Keybuk, "Some idiot thought it'd be a good idea if device mapper didn't respond to "add" events, like those during boot.  Take their change out back and shoot it in the head."
[00:11] <Keybuk> at least someone thought it was funny ;-)
[00:33] <Laibsch> ArneGoetje: I'm glad to hear that Japan is perceived as an important market to Canonical.  I'm just not sure that replacing a font with one that looks worse is a good choice.
[00:33] <Laibsch> ArneGoetje:   I'll talk to Hideki this week since I believe he may be able to give me some insight.  If you have any further comments, I'd love to hear them as well.
[00:38] <persia> Laibsch: The font selection was done in communication and coordination with the Japanese team, on the basis that it was a better font for daily use.
[00:38] <Laibsch> I assume you're a part of that team?  Who else, if I may ask.
[00:39] <Laibsch> As I said initially (been a few days now), the font looks *much* worse here.
[00:39] <Laibsch> But I wonder if that isn't some config problem
[00:39] <Laibsch> Right now, I'm just trying to understand
[00:39] <persia> Laibsch: https://launchpad.net/~japaneseteam
[00:41] <Laibsch> persia: how does the font look for you?
[00:41] <Laibsch> comparable?
[00:42] <Laibsch> vl-pgothic (old standard) vs. the new IPA derived font
[00:42] <persia> Laibsch: Different, but neither is more or less readable to me.
[00:42] <Laibsch> I see
[00:42] <Laibsch> the new one is much thinner for me
[00:42] <persia> The new font seems to have more delicate strokes, which is nice for low-dpi situations.
[00:42] <Laibsch> it's certainly readablle
[00:43] <kees> pitti: we've written a lot of tests.  ;)
[00:46] <YokoZar> dssi-vst needs a simple rebuild after my new wine1.0 package goes in (configuration issue)
[00:54] <persia> YokoZar: Does it need a real rebuild, or just a retry?  Seems to be FTBFS on arches where it could work.
[00:54] <RoAkSoAx> could I still be able to file a FFe?
[00:55] <RoAkSoAx> to get new upstream of TestDrive into lucid?
[00:55] <persia> YokoZar: If just a retry, then there's a handy button on launchpad that you can click.
[00:57] <YokoZar> persia: a retry
[00:57] <YokoZar> persia: Can anyone click that button?
[00:57] <TheMuso> YokoZar: You should be able to.
[00:57] <YokoZar> TheMuso: I'd used the button for my PPAs before, but for some reason I was expecting the real archive version of the button to only be available to archive admins
[00:57] <persia> YokoZar: Anyone with upload rights to the relevant package, yes.
[01:12] <YokoZar> Proper versioning for programs without version numbers is 0.0-YYYYMMDD yes?
[01:14] <Keybuk> YokoZar: I tend to prefer 0~YYYYMMDD-n
[01:15]  * persia doesn't like 0~ because Soyuz gets confused sometimes
[01:15] <YokoZar> Keybuk: I guess that works better if they release a version "0" or 0.0 for some reason
[01:15] <Keybuk> persia: why would Soyuz get confused?
[01:15] <YokoZar> because it's less than 0?
[01:16] <persia> Keybuk: Dunno, and I haven't encountered it since intrepid.  At that point I had some sync & upload failures I worked around with 0.0.0+...
[01:16]  * persia happily hasn't encountered the situation since
[01:25] <Keybuk> actually
[01:25] <Keybuk> I'd probably just use YYYYMMDD if there was no version
[01:25] <Keybuk> you can always just add an epoch later
[01:28] <persia> Well, except that gets annoying if Debian later packages 0.2 without an epoch.
[01:30] <Keybuk> Debian Schmebian
[01:54] <psusi> anyone know how to get gdb to quite being a retard and kill all inferior processes?  kill just kills the currently selected thread
[01:54] <psusi> quit even, not quite
[02:09] <jdong> kirkland: hey congrats on manpages.ubuntu.com fixing the "terminates output on bad character" bug :)
[02:11] <jdong> kirkland: I submitted a particularly ironic snprintf(3) manpage to TheDailyWTF a few weeks ago :) The manpage abruptly ended at "followed by the null byte, [EOF]"
[02:11] <kirkland> jdong: i saw that :-)
[02:11] <jdong> hehe :)
[02:11] <kirkland> jdong: i mean, i saw your pointer
[02:12] <kirkland> jdong: i think i fixed that bug
[02:12] <kirkland> jdong: can you check?
[02:12] <jdong> yeah
[02:12] <jdong> http://manpages.ubuntu.com/manpages/lucid/en/man3/snprintf.3posix.html
[02:12] <jdong> it looks good now
[02:12] <jdong> (the old version was much more amusing though!)
[02:12] <kirkland> jdong: yeah :-)
[02:12] <kirkland> jdong: still has some unprintable chars
[02:12] <jdong> yeah, whatever that special <?> character is before the quotes.
[02:13] <jdong> yup
[02:13] <kirkland> �
[02:13] <jdong> yeah they are littered throughout that manpage
[02:13] <kirkland> jdong: probably a w3m bug
[02:13] <jdong> ah, it goes through w3m?
[02:13] <kirkland> jdong: hmm, it's just a paren (
[02:14] <jdong> other parens seem to do fine
[02:15] <kirkland> jdong: weird
[02:15] <kirkland> jdong: file a bug on it, if you like, and i'll have a deeper look some time
[02:15] <jdong> kirkland: where do bugs go?
[02:15] <kirkland> jdong: launchpad.net/ubuntu-manpage-repository
[02:15] <jdong> ok, will do :)
[02:15] <jdong> and ooooh OS X Terminal.app linkifies that http-less URL
[02:16] <jdong> does gnome-terminal do that too?
[02:16] <ajmitch> sadly not
[02:16] <jdong> awww
[02:16] <ajmitch> at least not on this jaunty desktop :)
[02:16] <jdong> *tosses around a Google-Apple conspiracy theory to break Linux*
[02:16] <temugen> no, but special rxvt regexing can
[02:16]  * ajmitch should probably upgrade at some point
[02:17] <jdong> temugen: you mean special/regexing.that'll also match that?
[02:17] <jdong> ;-)
[02:17] <temugen>  .net/.com/blah blah
[02:18] <jdong> ah, one of those enormous regexes
[02:18] <temugen> How else does OS X do it?
[02:18] <jdong> like the one for valid emails.
[02:18] <temugen> I assume they use magic
[02:18] <jdong> temugen: natural language parsing?
[02:18] <jdong> temugen: same way they pick dates and telephone numbers and addresses out of emails.
[02:18] <jdong> (I'd assume)
[02:19] <jdong> I HOPE with their 200 billion USD marketcap or whatnot they're not using a switch/case of regexes ;-)
[02:19] <ajmitch> you hope for a lot
[02:20] <jdong> ajmitch: hey one can be an optimist, right? ;-)
[02:20] <ajmitch> like with running experimental crack? sure... :)
[02:21] <persia> ajmitch: Do remember your counterparty in this conversation :)
[02:21] <ajmitch> persia: my point
[02:23] <revcompgeek> I am unable to get graphics acceleration with my Radeon 9200 card, and I used to be able to
[02:28] <revcompgeek> running "compiz --replace" tells me that it detected a software rasterizer, but i don't know how to make it use the graphics card
[04:18] <boringwall> Right now I'm currently messing around with mprotect. I'm having it generate SIGSEGVs when I try to read/write into protected memory. I've got a handler for the SIGSEGVs and am wondering how its possible to tell if when it is invoked whether I am trying to request a read or write
[05:55] <pitti> Good moring
[05:56] <ajmitch> morning pitti
[05:56] <pitti> YokoZar: wine removal> no, didn't know I was supposed to; removed now
[05:57] <YokoZar> pitti: Cool, thanks.
[05:58] <RAOF> Um, has lvm2 broken boot for anyone else?
[05:59] <pitti> kees: there's a 115 MB mysql database and a 100 MB "qatest.tar.bz" in libvirt (presumably a packed image?)
[05:59] <pitti> hello ajmitch
[05:59] <pitti> RAOF: uh, how?
[05:59] <RAOF> Well, I'm not sure that it's the recent lvm2 upgrade, but that's my first guess.
[06:00] <RAOF> As in: enter the passphrase for your dm_crypt partition, get dumped to a recovery shell with the helpful message “CONTROL-D will teminate his shell and reboot the system”
[06:00] <RAOF> And I know there was a recent lvm2 change…
[06:03] <RAOF> I'm installing the previous version of lvm2 to see if that is in fact the problem.
[06:14] <RAOF> Looks like it was actually mountall.
[06:18] <pitti> RAOF: moutnall and plymouth were also updated yesterday
[06:19] <wgrant> RAOF: So I don't want to upgrade mountall and reboot if I use LUKS filesystems?
[06:20] <RAOF> Well… downgrading to mountall 2.13 gets me a mostly-working boot, it seems.
[06:20] <RAOF> By “mostly working” I mean that a recovery shell gets started, but the boot continues & I'm able to log in.
[06:21] <RAOF> wgrant: You know how to bring up a working system by hand, right?  You should be fine! :)
[06:21] <wgrant> RAOF: Heh, I haven't had to do it in the new world yet.
[06:22] <RAOF> The trick is “service start dbus” - after that, everything's mostly up :)
[06:24] <slangasek> RAOF: bug #570289?
[06:24] <slangasek> RAOF: if so, I need a backtrace on this sucker
[06:26] <RAOF> slangasek: That looks like the symptoms - how do I get a backtrace?
[06:29] <slangasek> RAOF: edit /etc/init/mountall cleverly, to spawn gdb with a non-interactive script and output redirected to somewhere useful under /dev
[06:29] <slangasek> RAOF: you will need to drop the 'expect daemon' line from mountall to accomplish this
[06:30] <pitti> would it be possible to enable apport and add a "started apport" condition?
[06:31] <slangasek> RAOF: you'll want to put a gdb batch script on the root filesystem somewhere, containing the commands 'run\nbt full' and launch gdb -x /path/to/script -batch mountall
[06:31] <slangasek> pitti: no, that would be a dependency loop
[06:31] <slangasek> but depending on how the filesystem is laid out, you might be able to call 'start apport' in the pre-start script of mountall
[06:32] <pitti> RAOF: or, if that fails, just add this: echo "|/usr/share/apport/apport %p %s %c" > /proc/sys/kernel/core_pattern
[06:32] <pitti> ah, I guess it'd fail anyway, since it needs a writable /var/crash/
[06:32] <pitti> so, hand-crafted gdb is it then
[06:36] <RAOF> Let's give that a whirl
[06:36] <Keybuk> slangasek: my hunch on hat one
[06:36] <Keybuk> the process_pending_events processes whatever is in the list you're while looping on
[06:36] <Keybuk> which matches the assertion
[06:37] <Keybuk> so I thought the two functions in the loop migh just need to be swapped
[06:37] <slangasek> Keybuk: I wouldn't expect process_pending_events() to process outgoing requests, which is the only way I can see this causing that failure?
[06:38] <slangasek> since we loop while (ply_list_get_length (client->requests_to_send) > 0)
[06:38] <Keybuk> if the event is the closing of the file descriptor ?
[06:38] <slangasek> we certainly can't reverse the order of those calls, because that brings back the deadlock where both ends are trying to write at the same time
[06:38] <Keybuk> I might clear the pending events from the lis
[06:38] <slangasek> hmm
[06:40] <Keybuk> that was my guess
[06:40] <Keybuk> but I didn't want to go swapping the order around, since I was sure you had a very good reason for the functions being in that order
[06:40] <RAOF> Gah!
[06:40] <slangasek> that might explain it; I'll have to go code-digging to see
[06:40] <slangasek> RAOF: ?
[06:41] <RAOF> The screen gets cleared just after mountall gets called, so I can't see any output, and / is still read-only, so I can't pipe output anywhere
[06:41] <slangasek> Keybuk: yeah, the reason not to swap them is bug #554737 :)
[06:41] <slangasek> RAOF: no, output it to /dev
[06:42] <slangasek> (I think I said this :)
[06:42] <RAOF> You did, I just didn't pay enough attention :)
[06:45] <Keybuk> and now you go hungry
[06:48] <Keybuk> ah, I thought I had just eaten too much mexican food and couldn't type
[06:48] <Keybuk> instead it turns out that the 't' key was falling off
[06:51] <slangasek> bryceh: have you learned anything more about bug #553708?
[06:52] <slangasek> RAOF: is that working better?
[06:53] <Keybuk> the "S&M message" ?
[06:53] <RAOF> Ok.  Now it is redirecting to /dev, just an empty file!  The mountall script now has “exec gdb -x /gdbscript -batch mountall > /dev/mountall.log” in the obvious place, and /gdbscript has “run\nbt full” (with \n expanded into a real newline).
[06:53] <Keybuk> ah, I'd forgotten that one
[06:53] <Keybuk> Unable to mount your filesystem.
[06:53] <Keybuk> Say the safe word to abort.
[06:53] <RAOF> Ahem. :)
[06:54] <slangasek> RAOF: maybe add a 2>&1 as well?
[06:54] <slangasek> (not sure why that would be needed, but)
[06:55] <RAOF> Yeah - gdb should be on stdout, surely.  Anyway… added.  Let's give *that* a whirl.
[06:55] <RAOF> Nope.  Empty again.
[06:55] <slangasek> hmm
[06:56] <RAOF> Hm.  It also has changed the behaviour somewhat.  Rather than waiting for me to unlock the dmcrypt device, it's now failing without prompting for the passphrase.
[06:57] <slangasek> er - mountall really shouldn't affect that
[06:57] <slangasek> can you post your full /etc/init/mountall.conf?
[06:58] <slangasek> well, though I guess if mountall is failing before even emitting virtual-filesystems, udev won't start either
[07:01] <Keybuk> jono!!!!
[07:01] <jono> oi oi Keybuk :)
[07:09] <RAOF> slangasek: http://pastebin.com/4fMG50Ze
[07:09] <RAOF> (Sorry about the delay; it's a bit hard to get things off the laptop :)
[07:12] <RAOF> And http://pastebin.com/qGP2WgeP is /gdbscript
[07:20] <Damascene> I want to create personal page on ubuntu wiki, were should I ask?
[07:22] <RAOF> AHA!  gdb looks like it wants to be able to write to /
[07:22] <slangasek> RAOF: 2>&1 has to go after > /dev/mountall.log
[07:22] <slangasek> oh?
[07:22]  * RAOF never gets shell redirections right the first time :(
[07:23] <RAOF> If I remount / rw before calling gdb, I get some output in /dev/mountall.log.
[07:23] <slangasek> RAOF: "2>&1" == "make fd 2 point to the same place that fd 1 currently points"
[07:24] <slangasek> RAOF: interesting, ok
[07:25]  * micahg could see how that could be confusing, if you use tee, the redirection is before the pipe
[07:25] <RAOF> However, that output in /dev/mountall.log doesn't include a backtrace, and is just mountall saying “yup, your drive doesn't need to be fsck'd”
[07:26] <Keybuk> micahg: that's because a pipe is a different part of shell language
[07:26] <slangasek> RAOF: ah; you may have to trap SIGABRT explicitly
[07:26] <Keybuk> |, like &&, ||, ;, etc. separates distinct commands
[07:26] <Keybuk> so the redirect has to go on the left of the pipe, otherwise it applies to the command after the pipe rather than the command before
[07:26] <micahg> Keybuk: yeah, I understand, but I took a double take when I saw that since I'm used to doing 2>&1 | tee /tmp/foo
[07:26] <slangasek> RAOF: hmm, no - gdb handles SIGABRT by default
[07:27] <RAOF> I thought it did, yeah.
[07:27] <Keybuk> micahg: it makes a kooky sense
[07:27] <micahg> Keybuk: it makes great sense if everything is in perspective, slangasek described it well
[07:27] <slangasek> RAOF: do you still get the abort message somewhere?
[07:27] <Keybuk> micahg: 2>&1 | there means "make fd 2 point to the same place that fd 1 currently points" still - the pipe means that fd 1 is always connected to the next process, rather than stdout
[07:28] <Keybuk> whereas >log 2>&1 vs. 2>&1 >log now make sense as different
[07:29]  * micahg has a lot to learn still
[07:30] <Keybuk> more fun .. what does  ...   cmd >log 2>&1 | less  do? :p
[07:31] <Keybuk> and to make your brain really hurt, try that in zsh ;-)
[07:31] <ion> Depends on the shell. In dash, less gets nothing. In zsh, it gets the output from cmd.
[07:31] <Keybuk> zsh's pipeline handling is based largely on a dare
[07:31] <ion> Just like echo foo >bar >baz works in zsh.
[07:32] <Keybuk> I like <(...)
[07:32] <RAOF> Accursed thing!  What's preventing keyboard input?
[07:33] <Keybuk> e.g.  diff -u <(sort file1) <(sort file2)
[07:33] <ion> Yes, <(...) is nice. I use it frequently in xargs -a <(find ... or dpkg -L ... or something) -d'\n' cmd ... where i want cmd’s stdin to be the terminal.
[07:34] <ion> For instance, xargs -a (ls | shuf) -d'\n' mplayer to play the videos from cwd in random order.
[07:34] <ion> <(
[07:34] <RAOF> There's a lot of craziness here - if I don't unlock the dmcrypt partition in break=mount it seems that the recovery shell and the cryptsetup unlock dialog fight for input, and neither gets any.
[07:35] <slangasek> 'dmcrypt'?  Is that using cryptsetup, or not?
[07:35] <slangasek> oh, you say that it is
[07:36] <RAOF> Well, to unlock it I run “cryptsetup luksOpen ...”, so I presume that's using cryptsetup :)
[07:36] <slangasek> RAOF: try commenting out 'console output' in /etc/init/cryptdisks-udev.conf
[07:36] <ion> Glob expansion in zsh is especially nice. echo foo/**/a*(.) (equivalent to find foo -type f -name 'a*' -print0 | xargs -0 echo)
[07:37] <Keybuk> ion: indeed; though we're kinda getting in the way of debugging here, so I'm going to shut up P:
[07:37] <ion> Hehe
[07:37] <RAOF> Eh, not that much in the way :)
[07:40] <RAOF> slangasek: /etc/init/cryptdisks-udev.conf doesn't *have* a “console output” stanza.
[07:41] <slangasek> really?
[07:41] <RAOF> http://pastebin.com/JBvmKQ74 is the full output of mountall.log, with stderr redirected appropriately.
[07:41] <slangasek> oh, I guess I have a modified version of that file then :P
[07:42] <RAOF> But that output is after manually unlocking the crypted disc, which doesn't have the same behaviour.
[07:44] <slangasek> Keybuk: ^^ maybe you can interpret that pastebinned output?  gdb seems to be unhappy with being launched from upstart or something
[07:44]  * slangasek runs to grab breakfast
[07:44] <Keybuk> you can't launch gdb from upstart
[07:45] <Keybuk> not without taking out the "expect ..." bit
[07:45] <RAOF> Keybuk: You mean the “expect daemon” bit?  That's commented out.
[07:45] <Keybuk> oh, dunno then
[07:48]  * RAOF comments out random “console output” stanzas
[07:48] <Keybuk> try "console owner"?
[07:49] <Keybuk> maybe the ioctl is inappropriate unless it's married?
[07:49] <RAOF> That should totally be a technical term!
[07:50] <Keybuk> "how do you like your ioctls?  raw or cooked?"
[07:55] <RAOF> Hey!  Since I've already remounted / read-write I can just write the gdb log somewhere permanent!
[07:57] <pitti> RAOF: I set up a test system with cryptsetup-LUKS LVM now, in case you need more testing for something
[08:05] <RAOF> So, “console owner” seems to have cleared up those inappropriate ioctl messages, but there's still no backtrace.
[08:07] <RAOF> slangasek: Shall we just go on a printf debugging spree?
[08:07] <dholbach> good morning
[08:22] <slangasek> RAOF: cjwatson's suggestion just now was to adjust the mountall job to call chdir /dev and set 'ulimit -c unlimited', so that you can get a core file there - rather than trying to get gdb to work under upstart
[08:23] <slangasek> then we can postprocess at leisure
[08:25] <RAOF> Seems reasonable; doing so ow.
[08:25] <RAOF> *now
[08:30] <Keybuk> chdir /
[08:30] <Keybuk> limit core unlimited unlimited
[08:30] <Keybuk> ;-)
[08:30] <Keybuk> (can go directly in the conf file)
[08:30] <slangasek> heh, ok
[08:32] <RAOF> We have a core, and a backtrace.
[08:32] <RAOF> ...and maybe I need to install a bunch of dbgsym packages.
[08:32]  * slangasek nods :)
[08:32]  * slangasek afks again to run across the river
[08:32]  * RAOF will install dbgsym and generate a better trace.
[08:33] <Keybuk> slangasek: I know the Thames has a reputation for being polluted, but it's totally unfounded - and besides, at the point of the hotel and office, it's completely tidal anyway
[08:33] <Keybuk> attempting to run directly across it will only result in drowning
[08:50] <slangasek> Keybuk: I seem to have made it ok
[08:51] <slangasek> perfectly dry, too
[08:53] <bryceh> slangasek, no, I got busy with other stuff and just worked around it
[08:54] <Keybuk> RAOF: any further on that better trace?
[08:56] <RAOF> Keybuk: got a better one, then rebuilt everything with DEB_BUILD_OPTIONS=noopt,nostrip and installed further dbgsym packages.
[08:56] <cjwatson> persia: 0~FOO is fine in Soyuz - the only problem is that sync-source won't work out of the box because I think it still compares to 0, but that's OK, we can easily work around that
[08:57] <RAOF> Yay!  Got *all* the stack this time
[08:59] <Keybuk> RAOF: may I see?
[08:59] <RAOF> Keybuk: http://paste.ubuntu.com/423232/
[09:02] <Keybuk> right, pretty straight forward
[09:03] <Keybuk> just to confirm sanity
[09:03] <Keybuk> if you up a couple of frames and
[09:04] <Keybuk> p client->requests_to_send
[09:04] <Keybuk> do you get 0
[09:04] <Keybuk> ?
[09:05] <RAOF> I presume you meant p *client->requests_to_send?
[09:05] <RAOF> $2 = {first_node = 0x0, last_node = 0x0, number_of_nodes = 0}
[09:05] <Keybuk> right
[09:05] <Keybuk> ok
[09:05] <Keybuk> so pretty straight forward
[09:06] <Keybuk> when it flushes the plymouth fd, there are requests to send
[09:06] <Keybuk> the first call is to process_pending_events ()
[09:06] <Keybuk> this can clearly send events (it polls on write)
[09:06] <Keybuk> so it writes out the queue
[09:07] <Keybuk> there are now no events to flush
[09:07] <Keybuk> so process_pending_requests will assert
[09:07] <Keybuk>   while (ply_list_get_length (client->requests_to_send) > 0)
[09:07] <Keybuk>     {
[09:07] <Keybuk>       ply_event_loop_process_pending_events (client->loop);
[09:07] <Keybuk>       ply_boot_client_process_pending_requests (client);
[09:07] <Keybuk>     }
[09:07] <Keybuk> ...
[09:07] <Keybuk> slangasek: since ply_event_loop_process_pending_events () will *call* ply_boot_client_process_pending_requests () if the fd is writable
[09:07] <Keybuk> isn't that loop wrong?
[09:07] <Keybuk> should it not simply be
[09:08] <Keybuk>   while (ply_list_get_length (client->requests_to_send) > 0)
[09:08] <Keybuk>     ply_event_loop_process_pending_events (client->loop);
 does it call it?  I don't think it does
[09:09] <Keybuk> it definitely definitely definitely does
[09:09] <Keybuk> that's the whole purpose of that function
[09:09] <Keybuk> to be called from inside ply_event_loop
[09:09] <Keybuk> look at ply_boot_client_queue_request
[09:10] <Keybuk> when a request is queued, if client->requests_to_send is 0 then it sets up an fd watch that calls ply_boot_client_process_pending_requests() whenever the fd is writable, then queues the request to send
[09:10] <cjwatson> right
[09:10] <Keybuk> so all the time that client->requests_to_send is *not* 0, that function will be called whenever the fd is writable
[09:10] <cjwatson> OK.  So why isn't this asserting for everybody?
[09:10] <Keybuk> and in the bottom of the function itself, it clears its own watch once the list is empty again
[09:11] <Keybuk> I guess for most people, the epoll says the fd isn't writable
[09:11] <Keybuk> and then it blocks in the second function
[09:11] <Keybuk> but for RAOF, the epoll says it's writable
[09:11] <Keybuk> so that assert
[09:11] <Keybuk> very fast machines assert maybe?
[09:11] <Keybuk> or machines with oodles of memory (big socket buffs)
[09:12] <cjwatson> yes, that could make sense.  In that case it isn't particularly configuration-specific and I think we ought to respin
[09:12] <Keybuk> it'll also only assert if you manage to completely *drain* the request list inside that first call to epoll
[09:12] <cjwatson> so pretty racy
[09:12] <Keybuk> and the request list when fsck is concerned is pretty long, so hard to drain
[09:13] <Keybuk> so yeah, the assert pattern would look something like
[09:13] <Keybuk> - there are requests when flush() is called
[09:13] <Keybuk> - the fd polls for writing (write will not block)
[09:14] <Keybuk> - all of the requests are able to be written before write would block
[09:14] <Keybuk> - thus by the next call, there are no longer any requests
[09:15] <Keybuk> ok, my work here is done
[09:15]  * Keybuk hands over to the day shift
[09:15] <SuN__> I can not log gives me a black screen and reboot ... how to help me reinstall
[09:29] <kees> pitti: yeah, part of the downside to lots of tests is lots of test data :)  that said, if you want to extract a single test, scripts/make* to build test tarballs
[09:36] <lucas> what's the current process to upload a one-liner bugfix for a universe package?
[09:37] <pitti> lucas: upload it and make sure that the changelogaand linked bug properly document the change
[09:38] <lucas> pitti: thanks
[09:38] <lucas> pitti: a fake sync from debian is fine, too?
[09:39] <pitti> lucas: same criteria: depends on whether the debdiff is 100% obvious and regression proof
[09:39] <lucas> ok
[09:40] <pitti> lucas: aside from that, a big concern is that builds must be completed soon, to avoid having pending build records at release
[09:40] <pitti> lucas: for most (i. e. relatively small) packages that's not a problem
[09:40] <pitti> it might be for things the size of linux/OO.o/openjdk
[09:41] <lucas> pitti: ok, will upload ASAP
[09:41] <pitti> lucas: merci
[09:43] <jibel> tseliot, could you please have a look at 565407, another fglrx issue when installing the ubuntu package over the ati installer
[09:44] <jibel> tseliot, the fglrx preinst script removes /etc/ati _before_ running ati's uninstallation script.
[09:44] <tseliot> bug #565407
[09:44] <jibel> tseliot, fglrx-uninstall.sh fails when installing the ubuntu package over the ATI driver because its /etc/ati disappeared
[09:51] <joaopinto> ogra, can you tell me the bug nr for the mount with a broken clock ?
[09:51] <joaopinto> good morning all
[09:52] <ogra> joaopinto, bug 563618/
[09:52] <ogra> hrm
[09:52] <joaopinto> tks
[09:52]  * ogra wonders where that slash came from
[09:53] <joaopinto> there is a fix released ?
[09:53] <ogra> a workaround
[09:53] <ogra> the actual fix has to happen upstream
[09:58] <tseliot> jibel: that sounds like a bug in the ati installer to me but still I can see how badly it can affect dist-upgrades.
[09:58] <tseliot> slangasek: ^^
[10:06] <cjwatson> ogasawara_: bug 570542 (iso-testing) looks like a straightforward fix - maybe SRU?
[10:08] <jibel> tseliot, not really because once you've tried to install the ubuntu package you cannot uninstall the ati driver anymore.
[10:08] <ogasawara_> cjwatson: ack, thanks
[10:08] <jibel> tseliot, shouldn't we detect the presence of the ati driver before attempting to remove any of its files ?
[10:09] <tseliot> jibel: what I meant to say is that deb packages should uninstall cleanly without having to look up some random file to see what it has installed
[10:11] <tseliot> jibel: I know that we call /usr/share/ati/fglrx-uninstall.sh in the preinst so removing /etc/ati/after that should solve the problem
[10:11] <jibel> tseliot, indeed
[10:13] <tseliot> slangasek, pitti: do you agree to include this trivial fix in the final release (for the sake of dist-upgrades)?
[10:13] <pitti> tseliot: upgrades can easily be fixed as SRUs, too
[10:14] <tseliot> pitti: sure but we would break a lot of dist-upgrades in the mean time...
[10:14] <pitti> tseliot: at this point I defer to slangasek and cjwatson, they are coordinating the current rebuild ATM
[10:14] <tseliot> ok, thanks
[10:14] <ajmitch> update-manager workarounds can be done outisde of that as well, right?
[10:14] <slangasek> tseliot: trivial fix - no, the deadline for those was Sunday
[10:14] <slangasek> tseliot: we can't afford to further delay ISO mastering
[10:15] <pitti> tseliot: please get it uploaded to lucid-proposed now
[10:15] <tseliot> slangasek: too bad, well, I tried. I'll do as pitti suggests
[10:15] <mvo> ajmitch: do you have anything particular in mind?
[10:15] <pitti> tseliot: they'll be accepted immediately after the release, and as long as they get positive confirmation/testing, I'm also happy to shorten the 7 day delay
[10:15] <ajmitch> mvo: nothing particular, just seeing the discussion from tseliot & jibel about the ati driver
[10:16] <tseliot> that would be a good compromise
[10:23] <persia> cjwatson: Thanks for the clarification.  I remembered something broke, but it's nice that it's just a helper script that ought become obsolete sometime during the maverick cycle.]
[10:49] <RAOF> slangasek: plymouth -ubuntu2 boots my system correctly.  Thought you might like some confirmation ;)
[11:10] <slangasek> RAOF: great, thanks for confirming :)
[11:12] <deryck> pitti, ping
[11:13] <pitti> hey deryck
[11:14] <deryck> pitti, hey!  What is the significance of the "set next expectations" item being dropped from the blueprint?  Is that just because its in progress but close to next UDS?  Or less important now?
[11:15] <pitti> deryck: I added a comment to the whiteboard; it's not a WI of the desktop team, thus I dropped it from the desktop team's work list for lucid (just to clean up, while checking which lucid WIs were still outstanding)
[11:15] <pitti> the actual bug report is still open, of course
[11:15] <deryck> pitti, ah, ok, that makes sense.  Sorry missed the comment.
[11:30] <seb128> is firefox supposed to have an offline startpage?
[11:30] <persia> seb128: I think you only see it when you're offline.
[11:31] <seb128> right, that's what I meant, should I get a startpage or an errorpage when starting offline?
[11:31] <persia> I think you should get a startpage :)
[11:32] <seb128> ok, I don't
[11:32] <persia> fta: micahg: any input?
[11:32] <seb128> that's on the live image though
[11:32] <seb128> if that makes any difference
[11:32] <persia> Ought be the same.
[12:55] <slangasek> smoser: hi, we need a UEC/EC2 respin to pick up the latest plymouth change; can you take care of that this morning?
[13:29] <elmo> kirkland: people.canoncial.com has tons of space these days
[13:31] <slangasek> smoser: n/m, have triggered it here
[13:31]  * didrocks starts to upload every daily for history then ;)
[13:37] <kirkland> elmo: any chance those images were backed up somewhere?
[13:38] <smoser> slangasek, sorry i missed you. you're all set?
[13:39] <slangasek> smoser: yep, we're good - thanks
[13:39] <smoser> as a simple "build it" i use: sudo -u vmbuilder ~vmbuilder/bin/cronrun build-daily lucid server
[13:39] <slangasek> yeah, I grabbed it from the cronjob
[13:44] <slangasek> doko_: you've seeded texinfo-doc-nonfree without an MIR?
[13:47] <ogra> pitti, i just noticed Bug 390677 too on an omap install, the intresting piece here is that it seems to appear if i do the same install in english locale (and there is enough space in the window in both cases (usign 1280x720 here))
[13:48] <pitti> yeah, the window is smaller than it could be
[13:48] <ogra> its the same size in both variants for me
[13:48] <ogra> it just doesnt show the last line
[13:49] <ogra> and there is no scrollbar
[13:49] <ogra> (note i'm doing only-ubiquity since thats the default on omap)
[14:27] <doko_> slangasek: yes, afaict we never did require MIR's for GFDL'd docs that Debian does see as non-free. pitti?
[14:28]  * persia thinks they ought get wave-through MIRs for records-keeping purposes anyway
[14:28] <pitti> we haven't discussed them being in universe (i. e. consider them free)
[14:28] <pitti> but MIRing them right now, two days before the release, when it has happily stayed in universe since dapper certainly does warrant a MIR IMHO
[14:28] <persia> pitti: Hrm?  I was sure I saw a statement that GFDL was considered Ubuntu-free previously.  Are you sure it's undiscussed?
[14:29] <pitti> persia: sorry; I mean not re-discussed for every package instance
[14:29] <persia> Ah, all is now clear :)
[14:29] <pitti> we have a general agreement that GFDL is Ubuntu-free-enough
[14:52] <slangasek> dpm: do we have translation stats that you want included in the release announcement?
[14:54] <doko> pitti: subscribed the MIR team to #75253
[14:58] <dpm> slangasek, I'm still working on them. When is the deadline (if it isn't too late already)?
[14:59] <slangasek> dpm: tomorrow - do you want me to use the same boiler plate as last time, and we'll fill in the numbers when you have them?
[14:59] <slangasek> (so that I can send the draft for review)
[14:59] <dpm> slangasek, that'd be perfect, thanks!
[15:14] <kirkland> slangasek: asac: cjwatson: is anyone looking at netcf for Maverick in a blueprint?
[15:15] <cjwatson> first I've heard of it
[15:15] <cjwatson> oh for god's sake why do people keep perpetuating XML configuration files
[15:15] <cjwatson> (netcf)
[15:15] <cjwatson> or actually a library API involving XML strings!  nuts
[15:16] <cjwatson> can't say I'm wildly enthused, but whatever
[15:17] <kirkland> cjwatson: just curious;  the kvm/libvirt community is talking a lot about netcf right now
[15:18] <cjwatson> this isn't a veto, it's just a lack of enthusiasm/interest
[15:18] <kirkland> cjwatson: as a command line replacement for networkmanager, and useful for packages to setup networking consistently
[15:18] <kirkland> cjwatson: no problem;  i'm just asking, really
[15:18] <cwillu_at_work> cjwatson, can I interest you in a json configuration database? :p
[15:18] <kirkland> cjwatson: i doubt the server team will have the bandwidth or clout to drive this into Maverick
[15:18] <cjwatson> I would certainly like a command-line NetworkManager equivalent or frontend; there appear to be several possibilities for that
[15:18] <cjwatson> cwillu_at_work: no :-)
[15:18] <kirkland> cjwatson: conman?  (or what else)?
[15:19] <slangasek> network manager itself doesn't need a GUI frontend to do its job
[15:19] <cjwatson> no, I've seen at least one actually based on NM
[15:19] <cjwatson> connman is entirely separate
[15:19] <slangasek> you can store all the configs under /etc/NetworkManager
[15:19] <cjwatson> right, you then just need something command-line to talk dbus to it
[15:19]  * slangasek nods
[15:19] <cwillu_at_work> people who put capital letters into pathnames should be shot
[15:19] <cjwatson> was it cnetworkmanager?  something like that
[15:19] <jcastro> cjwatson: yeah
[15:20] <jcastro> I tried it once, it wasn't very finished
[15:20] <cjwatson> I think there were a couple of versions with the same name
[15:20] <cjwatson> anyway, I'd rather stick with the same underlying network configuration layer, rather than creating a new one
[15:20] <slangasek> quite
[15:20] <cjwatson> if nothing else, it is occasionally useful to be able to interact with NM from the command line on desktop systems too
[15:21] <cjwatson> "X died, and I need to search the web to find out how to fix it"
[15:24] <Riddell> tkamppeter: are you still editing DesktopTeam/Meeting/2010-04-27?
[15:25] <persia> What should such an nm-tool do?  list, connect, disconnect?  Is it acceptable to expect users to configure manually?
[15:26] <cjwatson> I don't want to try to design it now, though knock yourself out if you do :)
[15:27] <persia> Just wanted to understand requirements.  I want to use it, and don't mind fiddling a little to be able to do so.
[15:28]  * persia will try to write something up for potential discussion in a couple weeks
[15:31] <slangasek> mr_pouit: will there be a Xubuntu release announcement at http://xubuntu.org/news/10.04-release for linkage in the release announcement mail?
[15:32] <slangasek> superm1: http://mythbuntu.org/10.04/release - is that the right URL for you guys?
[15:32] <superm1> slangasek, Yup
[15:33] <slangasek> TheMuso, persia: is luisbg still involved in ubuntustudio?  he doesn't seem to have been on IRC for a month
[15:34] <cjwatson> persia: my only thought is that it would be nice if it could optionally fish existing configuration out of gconf, although that clearly isn't always appropriate
[15:34] <slangasek> TheMuso, persia: looking for confirmation on whether an UbuntuStudio release announcement is in progress, perhaps for posting to https://wiki.ubuntu.com/UbuntuStudio/10.04release_notes ?
[15:35] <persia> slangasek: He's become fairly absent.  I'd recomment grabbing ScottL: I'see ll if I can get him to join -release
[15:35] <tkamppeter> Riddell, no.
[15:35] <slangasek> persia: oh, he's already there
[15:35] <persia> Ah, good.  I think he was working on release notes.  Dunno if he's done.
[15:36] <persia> cjwatson: I think it'd need to do that in some ways, but I'll have to also look at the KDE implementation to see if I can find something that's generally freindly.
[16:08] <cjwatson> pitti: bug 548891: SKIP actually is meant to be valid - it's a magic value defined by me in console-setup a while back, meaning "just leave the kernel keymap alone and don't change it".  I have a vague memory that X has a reasonable default keymap it could use, doesn't it?
[16:09] <cjwatson> pitti: I could make the value be something different if that's easier, but actually I'm inclined to suggest that since SKIP has been there way back to hardy, whatever's failing to interpret it on the desktop side should be fixed instead.  What would the correct package be to reassign this to?
[16:18] <Riddell> pitti: we need SRU bug 535199 moved to -updates before release
[16:27] <pitti> cjwatson: ah, so if it's supposed to be in /e/d/console-setup, then this can be reassigned to xserver-xorg-input-evdev; I'll care about it then
[16:28] <pitti> cjwatson: the only sensible change would be to leave it empty (which I take isn't appropriate?), so let's keep it like it is
[16:28] <pitti> Riddell: did someone do a test upgrade with that? I didn't see a followup
[16:29] <Riddell> pitti: I'm doing one now although it should be someone other than me I would think
[16:29] <pitti> Riddell: oh, that's fine; as long as it's the actual .debs from -proposed
[16:30] <pitti> Riddell: (yes, in general it's better to have it tested by someone else, but since it's urgent..)
[16:30] <Riddell> pitti: ok then yes it works good
[16:30] <Riddell> can't comment on the bug, am in the middle of an upgrade now
[16:30] <pitti> Riddell: can you please say so on the bug, for the records?
[16:30] <pitti> ah
[16:30] <Riddell> pitti: I'll go to the other room and do it, one sec
[16:31] <pitti> Riddell: ain't networking great? :-)
[16:31] <cjwatson> pitti: I don't remember why I didn't leave it empty, although it may be that that would cause other problems and there's still the upgrade issue anyway
[16:32] <cjwatson> pitti: I'll reassign, thanks; shall I assign to you?
[16:32] <pitti> cjwatson: please do, yes
[16:32] <cjwatson> pitti: this has the advantage that it seems SRUable, so we could automatically fix people in this situation
[16:32] <pitti> cjwatson: sounds like an easy SRU (well, I need to test what X does if you don't specify a keyboard layout)
[16:32] <Riddell> done
[16:33] <pitti> cjwatson: but as long as X behaves without any keyboard layout set (like, default to US), then it's a trivial udev rule change
[16:33] <cjwatson> right
[16:33] <pitti> cjwatson: ok, thanks for following up; it originally seemed to me that "SKIP" was a debconf-only magic value which somehow slipped into the config file
[16:33] <slangasek> kirkland: I see you already have a handle on bug #570732 - are you doing any other tests to see if it's reproducible?
[16:34] <kirkland> slangasek: no, i haven't....  i just switched it to the right package, and bumped its priority
[16:38] <cjwatson> kirkland: if I can get a recipe for reproducing this in a kvm, I will fix it
[16:39] <kirkland> cjwatson: i'm most alarmed by the severe installer performance regression
[16:40] <kirkland> cjwatson: i'm at 12 minutes in this install, and i'm still "Installing the base system"
[16:40] <kirkland> cjwatson: i benchmarked a complete CLC/WC/SC/CC install at under 9 minutes, at beta2
[16:40] <pitti> kirkland: please note that the dpkg fsync introduces a times-5 overhead; that's likely the cause?
[16:40] <pitti> oh, beta2
[16:41] <kirkland> cjwatson: was the only way i was able to conduct the full installation and live demo of UEC in a 45 minute presentation slot
[16:41] <kirkland> pitti: ie, beta2 worked fine;  these GA candidates are taking much longer to install
[16:42] <pitti> ah, it was re-enabled after beta-2 indeed
[16:42] <kirkland> pitti: what's this, in a nutshell?
[16:42] <pitti> kirkland: I just overheard your last couple of comments; did you already identify something else as the cause? or are you talking about dpkg
[16:43] <kirkland> pitti: i'm suspect of dpkg, as it's the installation steps of the server installer that are really, really slow
[16:43] <pitti> kirkland: during unpack, dpkg now calls fsync() a few times, to ensure data integrity (it previously caused a lot of 0-byte files on power failures, etc.)
[16:44] <ogra> pitti, only during unpack ?
[16:44] <pitti> kirkland: see dpkg 1.15.5.6ubuntu4 changelog
[16:44] <kirkland> pitti: yeah, i have two levels of UPSes here, won't be any powerfailures on my end... how do i make it go-fast again?
[16:44] <ogra> really smells like the cause for bug 532733 which we are unable to debug properly
[16:44] <pitti> ogra: well, I checked the unpack and configure times of openoffice.org-common
[16:44] <slangasek> kirkland: install on ext3 instead of ext4
[16:44] <ttx> pitti: that would match my experience. dpkg cycles appearing to hang at various points
[16:45] <kirkland> :-/
[16:45] <slangasek> kirkland: if that makes it faster, then this is what it is
[16:45] <kirkland> slangasek: oh, okay
[16:45] <kirkland> slangasek: i'll do that next UEC machine
[16:46] <ion> Two levels of UPSes? Sounds like worse power efficiency with little benefit over a single UPS to me. :-)
[16:46] <kirkland> ion: it's a laptop, with a battery, plugged into a UPS
[16:48] <cjwatson> yeah, OK, so the fsync thing would match up
[16:48] <cjwatson> but that is not going to be changed now for lucid
[16:49] <cjwatson> I'm very unhappy about ext4's behaviour here.  dpkg really has no good option
[16:49] <cjwatson> it gets to lose data or be slow
[16:49] <cjwatson> but the ext4 developers are famously unsympathetic; this has been discussed at nauseating length
[16:50] <cjwatson> (the general issue, not this particular case)
[16:50] <ogra> kirkland, if ext3 is supposed to fix it then its not 532733 :( rootstock uses ext3 by default (even used ext2 before)
[16:50] <cjwatson> kirkland: back to grub2; is there a recipe?
[16:50] <cjwatson> ogra: the dpkg fsync thing would not have caused hangs
[16:50] <kirkland> cjwatson: there is no recipe; i can halt UEC testing to go and try to reproduce that
[16:51] <ogra> cjwatson, oh. ok i thought that was the general opinion
[16:51] <pitti> mdke, chrisccoulson: back in the old days I got a local start page when opening firefox and having no network connection; was that dropped deliberately?
[16:51] <pitti> (it tries http://start.ubuntu.com/10.04//Google/
[16:51] <cjwatson> ogra: no, it's a slowdown, not a hang
[16:51] <pitti> / -> sic
[16:51] <chrisccoulson> pitti - it wasn't, that should work
[16:51] <chrisccoulson> seb128 already mentioned an issue to me
[16:51] <pitti> chrisccoulson: trying on the current live system, it doesn't
[16:52] <ogra> cjwatson, ah, k, we surely see a solid hang
[16:52] <chrisccoulson> pitti - there is an issue currently where it only displays a non-localised offline page without any layout
[16:52] <chrisccoulson> but i don't know why it's still trying to access http://start.ubuntu.com/10.04//Google/ with no network connection
[16:53] <chrisccoulson> pitti - network manager is indicating that the network connection is disconnected?
[16:54] <pitti> chrisccoulson: yes; I didn't give it a wpa password
[16:54] <chrisccoulson> pitti - ok, i'm slightly confused then. i'll have a think about that ;)
[16:54] <pitti> chrisccoulson: you don't get that on the live system?
[16:54] <chrisccoulson> pitti - tbh, i've only tried it on my installed system
[16:55] <chrisccoulson> pitti - bug 531882 is an issue anyway
[16:55] <pitti> chrisccoulson: or in a guest session?
[16:55] <chrisccoulson> pitti - ok, i'll try with guest session
[16:55] <chrisccoulson> bbiab, have to disconnect ;)
[16:56]  * pitti -> gdm testing, bbl
[17:02] <kirkland> slangasek: that's it exactly ... the same server install, from the same USB stick, on the same hardware.... 19:20 on ext4 and 9:08 on ext3
[17:02]  * slangasek nods
[17:03] <ion> Why does fsync cause such a performance difference on ext4?
[17:03] <chrisccoulson> pitti - ok, confirmed from a guest session, but only on the first attempt
[17:03] <kirkland> ion: apps are required to call fsync on ext4
[17:09] <joaopinto> I had to add barriers=0 to make ext4 usable for sbuilds
[17:12] <cjwatson> ion: fsync is considerably more than what dpkg actually needs
[17:12] <cjwatson> ion: dpkg requires that either old or new file is on disk, not somewhere in between
[17:12] <cjwatson> ion: ext4's requirement to fsync then rename means that it has to stop and wait for the new file to land
[17:13] <cjwatson> this is fundamentally bound to be slower
[17:13] <cjwatson> it is a filesystem misdesign caused by the filesystem designers optimising for theoretical benchmarks rather than for real-world applications
[17:14] <cjwatson> and this is just a demonstration of why the recommendations made repeatedly and loudly by the filesystem designers cause poor performance
[17:15] <ion> I mean, wouldn’t the added fsync calls cause a similar slowdown on ext3, too?
[17:16] <cjwatson> empirically, the added fsync calls are within experimental error on ext3
[17:16] <cjwatson> I do not know why
[17:16] <ion> Also, would it help if dpkg only used fdatasync?
[17:17] <kirkland> cjwatson: would it be possible to disable the fsync calls when dpkg is run from d-i ?
[17:17] <cjwatson> kirkland: not for lucid.
[17:17] <cjwatson> this WILL NOT CHANGE FOR LUCID.  excuse me for shouting.
[17:17] <cjwatson> far too risky
[17:18] <kirkland> cjwatson: necessarily, if there's a power loss during installation, you're starting over from scratch anyway
[17:18] <kirkland> cjwatson: that's very, very, very unfortunate
[17:18] <cjwatson> I've discussed this briefly with dpkg upstream, and one possibility is to add an option for it
[17:18] <cjwatson> kirkland: *shrug*
[17:18] <cjwatson> use ext3
[17:18] <cjwatson> it doesn't suck
[17:18] <kirkland> cjwatson: great; let's switch ubuntu server default install to use ext3 then
[17:18] <cjwatson> let's release-note it.
[17:19] <pitti> OOI, does anyone happen to know if btrfs will handle this any better?
[17:19] <cjwatson> ion: maybe, I'm not sure
[17:21] <cjwatson> look, I'm not especially happy about the slower performance, but I don't think it's release-critical compared to data-loss bugs
[17:21] <cjwatson> and I don't think that it justifies the risk of making non-trivial changes at this point
[17:23] <ion> I don’t find ten more minutes of install time too big a problem. It’s how much out of the total runtime the installation is going have in its lifetime? :-)
[17:23] <kirkland> ion: ten minutes sucks, considering i'm in the middle of approximately 40 installations today
[17:24] <pitti> well, but integrity >> speed at this point, especially for installing updates in a production system
[17:24] <elmo> just to add to an alternative voice to this
[17:24] <elmo> it's not ten minutes on real server hardware
[17:24] <elmo> and in my workflow, I don't care how long installs take
[17:24] <elmo> but i care *very much* that they're consistent and correct
[17:25] <Keybuk> and to add a voice with a different POV
[17:25] <elmo> (how long installs take + within reason)
[17:25] <elmo> (and believe me, I've done a lot of ubuntu server installs this week too)
[17:26] <elmo> (except they were hardy, but whatever ;-)
[17:26] <Keybuk> one of the problems with calling fsync() all the time is that in filesystems which do delayed allocation, have extents, etc. like XFS, ext4 and btrfs, is that it will lay down the files at every fsync
[17:26] <Keybuk> which will increase the likelihood of fragmentation
[17:26] <ion> keybuk: Yes, the filesystem sucks indeed. :-)
[17:26] <cjwatson> right, and FAOD I think the whole "must call fsync before rename" thing is stupid and wrong
[17:26] <cjwatson> but rock, hard place
[17:27] <kirkland> pitti: i wholeheartedly agree on the update scenario; but i wholeheartedly disagree on the base install scenario
[17:27] <cjwatson> look, there certainly are problems that would merit a respin at this point; but ones that require fairly deep modifications to the package manager aren't, imo, among them
[17:27] <elmo> kirkland: I, for one, like my base installs to have integrity :-P
[17:28] <kirkland> elmo: one fsync at the end takes care of that
[17:28] <pitti> kirkland: right, I agree to installs; but too late now :/
[17:28] <cjwatson> fsync is per-file-descriptor, FYI
[17:28] <cjwatson> YM sync
[17:28] <kirkland> pitti: cjwatson: is this something that can be fixed in 10.04.1 ?
[17:28] <joaopinto> the ext4 choice for servers as other implications depending on the server role, e.g. mysql may get a major performance hit
[17:28] <cjwatson> and I agree that there are better ways that the installer could deal with this, just not for 10.04
[17:28] <kirkland> since 10.04 has shipped?
[17:28] <cjwatson> kirkland: potentially yes
[17:28] <ion> Yeah, a more intelligent filesystem might as well only flush what’s needed and keep other allocations delayed.
[17:28] <cjwatson> I'd like to agree something with dpkg upstream
[17:29] <Keybuk> cjwatson: in at least ext4, fsync is per filesystem
[17:29] <cjwatson> Keybuk: sure, but the API is per-file
[17:29] <cjwatson> dpkg is not entitled to make that assumption
[17:29] <Keybuk> cjwatson: yes, but then if you're being paranoid, dpkg needs to also open the directory file descriptor and fsync() that
[17:29] <Keybuk> which it doesn't
[17:29] <cjwatson> true
[17:30] <pitti> Riddell: packagekit released to -updates; thanks for testing!
[17:30] <cjwatson> and no doubt we'll pay the price for forgetting that in terms of bug reports
[17:31] <Riddell> pitti: great
[17:34] <jcastro> lucas: I've scheduled the debian session for Tuesday morning.
[17:34] <joaopinto> kirkland, if you can somehow remount with barriers=0 before install you should get an ext3 similar performance
[17:35] <cjwatson> I don't believe the installer offers an interface for that
[17:35] <ion> Ah, one using barriers and one not doing so would probably explain the major difference performance between the filesystems.
[17:36] <cjwatson> FTR this affects alternate install CDs much more than servers; I'm not picking on server here
[17:36] <cjwatson> (but fortunately it doesn't particularly affect desktop since ubiquity operates differently)
[17:51] <pitti> cjwatson: as for the SKIP bug, can that only happen with MODEL, or for LAYOUT etc., too?
[17:52] <cjwatson> just model
[17:55] <smoser> congrats ara
[17:55] <ara> smoser, thanks!
[18:56] <Caesar> Does anyone know if KDE has any plans to use gconf?
[18:56] <cody-somerville> cjwatson, persia, geser, nixternal, stgraber: Do we mention declines in meeting report or just approvals?
[18:56] <nixternal> Caesar: why would KDE us gconf?
[18:56] <JontheEchidna> Caesar: I can pretty safely say that will never happen.
[18:57] <Caesar> Jeff Bailey was saying he thought they were going to start using it
[18:57] <nixternal> cody-somerville: good question...I would say just approvals from what i can remember...if you look through previous reports, i can't remember declines in them
[18:57] <Caesar> What is KDE's equivalent?
[18:58] <JontheEchidna> Caesar: KDE uses flat files in ~/.kde/share/config, accessed by a KConfig C++ class
[18:58] <cody-somerville> nixternal, But what if there is related action items? :S
[18:58] <seb128> Caesar, gconf is being deprecated next cycle so would be a bad choice
[18:59] <Caesar> Whoa
[18:59] <Caesar> seb128: more info?
[18:59] <seb128> on?
[18:59] <Caesar> gconf being deprecated
[18:59] <Caesar> like a link, what it's being replaced with, etc etc
[18:59] <seb128> dconf being worked for over a year
[19:00] <seb128> google for dconf and GNOME I guess
[19:00] <Caesar> Thanks
[19:00] <seb128> it's a GNOME3 goal
[19:00] <seb128> the techs required mostly landed in glib previous cycle and now
[19:01] <seb128> it will depends on no other GNOME lib than glib I think
[19:01] <seb128> could be a good freedesktop choice I guess
[19:01] <geser> cody-somerville: I'd mention both; for documentation and for completeness
[19:02] <geser> cody-somerville: and to be able to find the meeting again when re-applying to be able to re-read the meeting log
[19:03] <Damascene> I keep getting I can't report a problem with the kernel because it's a not a genuine ubuntu package
[19:03] <Damascene> I'm on lucid, updated
[19:03] <cody-somerville> geser, Yea, I Agree with you.
[19:04] <maco> Damascene: what's your "uname -a" say?
[19:04] <Damascene> Linux tester01-laptop 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 i686 GNU/Linux
[19:06] <Damascene> so?
[19:20] <Damascene> is there any of apport guys?
[19:27] <ccheney> anyone know if there is a bug yet on update-manager being too large to fit on 800x600 screen (and thus netbook 1024x600 also)?
[19:27] <ccheney> er update-manager when running upgrade between dists at least
[19:27] <ccheney> if you click on details it goes way off the bottom of the screen
[19:32] <cody-somerville> geser, Do you think I should include it in the meeting minutes mailed out to ubuntu-devel-announce?
[19:32] <cody-somerville> geser, I'm thinking no
[19:36] <geser> cody-somerville: I'm thinking yes, the minutes are for those who want to stay informed but can't/won't attend the meetings, so the minutes should be complete
[19:39] <geser> as the meeting was public and logged (so those results are also logged), we shouldn't hide those results from the minutes
[20:00] <lucas> jcastro: tuesday? are you sure zack will be there?
[20:01] <jcastro> he mentioned he would be there for tuesday
[20:02] <lucas> ok, he mentioned he'd do thursday+friday, but that was probably before
[20:04] <jcastro> I'll doublecheck with him
[20:11] <lucas> jcastro: the wiki page says 2010-05-12 20:00 as arrival time for him
[20:13] <jcastro> lucas: so thursday it is
[20:17] <lucas> jcastro: perfect, thanks
[20:26] <bdrung> mako: it's hard to find the source for http://selectricity.org/
[20:27] <mako> bdrung: huh, i thought the "copyleft" text in the bottom linked to the source
[20:27] <mako> bdrung: but i see now it links to the blog
[20:27] <mako> bdrung: i'll fix that. thanks for pointing it out
[20:27] <bdrung> thanks
[20:28] <mako> bdrung: but you did find it, i hope?
[20:28] <bdrung> mako: through the debian-devel mailing list ;)
[20:28]  * mako winces :)
[20:31] <bdrung> mako: http://lists.debian.org/debian-devel/2010/04/msg00478.html and a offlist answer "Look at http://projects.mako.cc/source/selectricity/README (google "+selectricity source"), there it says:[...]"
[20:33] <mako> bdrung: i'll follow up to the list after fixing it
[20:36] <bdrung> mako: one suggestion: instead of "This program is free software. Please see the COPYING file for details.", you should add either the GPL header or at least one sentence with the license "It's licensed under AGPL-3. Please see the COPYING file for more details."
[20:41] <mdke> pitti: hopefully a firefox issue rather than ubuntu-docs issue...
[20:42] <pitti> mdke: right, I just included you to know whether the local start page was abolished for some reason
[20:42] <pitti> good night everyone
[20:43] <mdke> pitti: fine. Personally I don't think it's a big issue - if the user is disconnected, it's probably helpful that firefox says so. but that's something I'll discuss for the next release...
[20:44] <kees> jcastro: from http://ubuntudevelopers.blip.tv/file/3544126/ "all the specs in your queue" where is my queue?
[20:46] <jbebel> Why would launchpad tell me that my debdiff attachment to a bug does not look like a patch?
[20:50] <bdrung> jbebel: maybe a bug?
[20:50] <jcastro> kees: they show up here: https://blueprints.launchpad.net/sprints/uds-m
[20:51] <kees> jcastro: but that's _all_ of them, right?
[20:51] <jcastro> kees: page 2
[20:51] <jcastro> yeah
[20:51] <kees> jcastro: so there's no "show me all uds-m specs that have me as approver" list?
[20:52] <jcastro> kees: you need to put "security" in the "show only blueprints containing" box
[20:52] <jcastro> afaik that's the only way
[20:53] <ajmitch> blueprints certainly needs some love in LP
[20:54] <micahg> ajmitch: file feature requests :)
[20:54] <ajmitch> micahg: it'd be quicker to submit merge proposals
[20:54] <jcastro> kees: aha! https://blueprints.edge.launchpad.net/~kees/+specs?role=approver
[20:54] <micahg> ajmitch: I'm sure they'd appreciate it :)
[20:55] <kees> magic!
[20:55] <kees> jcastro: thanks!
[21:10] <ccheney> do the new discs no longer allow cd test or memtest? or is there a special key you have to hit now?
[21:20] <bdrung> ccheney: hit a key and the previous menu will come up
[21:22] <ccheney> bdrung: ah ok, that must be what the hieroglyphics mean
[21:24] <bdrung> ccheney: are keyboards that old? ;)
[21:37] <kees> jcastro: how do I change track color?
[21:37] <kees> jcastro: and is there such a thing as the auto-scheduler any more?
[21:39] <ccheney> pitti: i see the SKIP issue, will test your ppa
[21:39] <jcastro> kees: the lack of color is a bug, but you also need to set the "uds-m security" in each session in django. I am on a phone, when I am off I'll walk you through it
[21:40] <kees> jcastro: okay
[21:40] <Daviey> jcastro: is that another bug?!
[21:40] <kees> jcastro: there also seems to be an issue with the room capacities; they don't match the hotel's recommendations (i.e. Amarenta vs Bois Dentelle)
[22:37] <kees> asac: hm, yeah, I guess it should be "Discussion" or "New".  one of the "how-to" videos confused me. :)
[22:47] <kirkland> cjwatson: i was not able to reproduce https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/570732 in a VM, set up as identically to the reporter's as possible
[22:47] <kirkland> cjwatson: i'll cobble together a couple of disks in a machine here shortly and try to reproduce it on real hardware
[22:49] <jcastro> kees: I'll doublecheck the room capactities tomorrow with marianna. Where are you seeing the information from the hotel on the room capacity?
[22:49] <jcole> i create customized livedvds of ubuntu within my company.. i usually use the "guest" user for "livecd simulation" but it seems to be "broke" in lucid (i get a blank screen instead of a gnome-screensaver password dialog after logging out of the "guest" user)
[22:49] <jcole> im wondering how a i can debug this (or is the guest user being broke a know issue?)
[22:50] <jcole> perhaps a bug in gdm switching
[22:57] <kees> jcastro: http://www.dolce-la-hulpe-brussels-hotel.com/meetings/floorplans.asp -> http://www.dolce-la-hulpe-brussels-hotel.com/egallery/upload/Dolce%20International/Dolce%20-%20La%20Hulpe%20Brussels/Files/Dolce%20LA%20HULPE%20FR-ANG%20TABLEAU.pdf
[23:02] <shan3> hi all
[23:02] <shan3> Is it possible to use bash instead of sh for upstart jobs?
[23:21] <jcole> shan: change /bin/sh to link to /bin/bash
[23:22] <jcole> shan3: ^^
[23:23] <shan3> jcole: would that break something else?
[23:24] <kirkland> i have a system dist-upgrading, that's been stuck on "Setting up console-setup (1.34ubuntu15) ... " for about 4 hours
[23:28] <kirkland> root     27721 23437  0 17:21 pts/1    00:00:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/console-setup.postinst configure 1.34ubuntu14
[23:28] <kirkland> but I'm not seeing that debconf frontend
[23:28] <kirkland> ev: cjwatson: ^