[00:07] Good morning! [00:10] rofl [00:10] 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] at least someone thought it was funny ;-) === mrcurrington is now known as mcurrington === dendrobates is now known as dendro-afk [00:33] 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] 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. === dendro-afk is now known as dendrobates [00:38] 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] I assume you're a part of that team? Who else, if I may ask. [00:39] As I said initially (been a few days now), the font looks *much* worse here. [00:39] But I wonder if that isn't some config problem [00:39] Right now, I'm just trying to understand [00:39] Laibsch: https://launchpad.net/~japaneseteam [00:41] persia: how does the font look for you? [00:41] comparable? [00:42] vl-pgothic (old standard) vs. the new IPA derived font [00:42] Laibsch: Different, but neither is more or less readable to me. [00:42] I see [00:42] the new one is much thinner for me [00:42] The new font seems to have more delicate strokes, which is nice for low-dpi situations. [00:42] it's certainly readablle [00:43] pitti: we've written a lot of tests. ;) [00:46] dssi-vst needs a simple rebuild after my new wine1.0 package goes in (configuration issue) [00:54] YokoZar: Does it need a real rebuild, or just a retry? Seems to be FTBFS on arches where it could work. [00:54] could I still be able to file a FFe? [00:55] to get new upstream of TestDrive into lucid? [00:55] YokoZar: If just a retry, then there's a handy button on launchpad that you can click. [00:57] persia: a retry [00:57] persia: Can anyone click that button? [00:57] YokoZar: You should be able to. [00:57] 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] YokoZar: Anyone with upload rights to the relevant package, yes. [01:12] Proper versioning for programs without version numbers is 0.0-YYYYMMDD yes? [01:14] YokoZar: I tend to prefer 0~YYYYMMDD-n [01:15] * persia doesn't like 0~ because Soyuz gets confused sometimes [01:15] Keybuk: I guess that works better if they release a version "0" or 0.0 for some reason [01:15] persia: why would Soyuz get confused? [01:15] because it's less than 0? [01:16] 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] actually [01:25] I'd probably just use YYYYMMDD if there was no version [01:25] you can always just add an epoch later [01:28] Well, except that gets annoying if Debian later packages 0.2 without an epoch. [01:30] Debian Schmebian [01:54] 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] quit even, not quite [02:09] kirkland: hey congrats on manpages.ubuntu.com fixing the "terminates output on bad character" bug :) [02:11] 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] jdong: i saw that :-) [02:11] hehe :) [02:11] jdong: i mean, i saw your pointer [02:12] jdong: i think i fixed that bug [02:12] jdong: can you check? [02:12] yeah [02:12] http://manpages.ubuntu.com/manpages/lucid/en/man3/snprintf.3posix.html [02:12] it looks good now [02:12] (the old version was much more amusing though!) [02:12] jdong: yeah :-) [02:12] jdong: still has some unprintable chars [02:12] yeah, whatever that special character is before the quotes. [02:13] yup [02:13] � [02:13] yeah they are littered throughout that manpage [02:13] jdong: probably a w3m bug [02:13] ah, it goes through w3m? [02:13] jdong: hmm, it's just a paren ( [02:14] other parens seem to do fine [02:15] jdong: weird [02:15] jdong: file a bug on it, if you like, and i'll have a deeper look some time [02:15] kirkland: where do bugs go? [02:15] jdong: launchpad.net/ubuntu-manpage-repository [02:15] ok, will do :) [02:15] and ooooh OS X Terminal.app linkifies that http-less URL [02:16] does gnome-terminal do that too? [02:16] sadly not [02:16] awww [02:16] at least not on this jaunty desktop :) [02:16] *tosses around a Google-Apple conspiracy theory to break Linux* [02:16] no, but special rxvt regexing can [02:16] * ajmitch should probably upgrade at some point [02:17] temugen: you mean special/regexing.that'll also match that? [02:17] ;-) [02:17] .net/.com/blah blah [02:18] ah, one of those enormous regexes [02:18] How else does OS X do it? [02:18] like the one for valid emails. [02:18] I assume they use magic [02:18] temugen: natural language parsing? [02:18] temugen: same way they pick dates and telephone numbers and addresses out of emails. [02:18] (I'd assume) [02:19] I HOPE with their 200 billion USD marketcap or whatnot they're not using a switch/case of regexes ;-) [02:19] you hope for a lot [02:20] ajmitch: hey one can be an optimist, right? ;-) [02:20] like with running experimental crack? sure... :) [02:21] ajmitch: Do remember your counterparty in this conversation :) [02:21] persia: my point [02:23] I am unable to get graphics acceleration with my Radeon 9200 card, and I used to be able to [02:28] running "compiz --replace" tells me that it detected a software rasterizer, but i don't know how to make it use the graphics card === lifeless_ is now known as lifeless [04:18] 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] Good moring [05:56] morning pitti [05:56] YokoZar: wine removal> no, didn't know I was supposed to; removed now [05:57] pitti: Cool, thanks. [05:58] Um, has lvm2 broken boot for anyone else? [05:59] kees: there's a 115 MB mysql database and a 100 MB "qatest.tar.bz" in libvirt (presumably a packed image?) [05:59] hello ajmitch [05:59] RAOF: uh, how? [05:59] Well, I'm not sure that it's the recent lvm2 upgrade, but that's my first guess. [06:00] 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] And I know there was a recent lvm2 change… [06:03] I'm installing the previous version of lvm2 to see if that is in fact the problem. [06:14] Looks like it was actually mountall. [06:18] RAOF: moutnall and plymouth were also updated yesterday [06:19] RAOF: So I don't want to upgrade mountall and reboot if I use LUKS filesystems? [06:20] Well… downgrading to mountall 2.13 gets me a mostly-working boot, it seems. [06:20] By “mostly working” I mean that a recovery shell gets started, but the boot continues & I'm able to log in. [06:21] wgrant: You know how to bring up a working system by hand, right? You should be fine! :) [06:21] RAOF: Heh, I haven't had to do it in the new world yet. [06:22] The trick is “service start dbus” - after that, everything's mostly up :) [06:24] RAOF: bug #570289? [06:24] Launchpad bug 570289 in plymouth "mountall assertion failure breaks boot process" [High,Incomplete] https://launchpad.net/bugs/570289 [06:24] RAOF: if so, I need a backtrace on this sucker [06:26] slangasek: That looks like the symptoms - how do I get a backtrace? [06:29] RAOF: edit /etc/init/mountall cleverly, to spawn gdb with a non-interactive script and output redirected to somewhere useful under /dev [06:29] RAOF: you will need to drop the 'expect daemon' line from mountall to accomplish this [06:30] would it be possible to enable apport and add a "started apport" condition? [06:31] 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] pitti: no, that would be a dependency loop [06:31] 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] RAOF: or, if that fails, just add this: echo "|/usr/share/apport/apport %p %s %c" > /proc/sys/kernel/core_pattern [06:32] ah, I guess it'd fail anyway, since it needs a writable /var/crash/ [06:32] so, hand-crafted gdb is it then [06:36] Let's give that a whirl [06:36] slangasek: my hunch on hat one [06:36] the process_pending_events processes whatever is in the list you're while looping on [06:36] which matches the assertion [06:37] so I thought the two functions in the loop migh just need to be swapped [06:37] 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] since we loop while (ply_list_get_length (client->requests_to_send) > 0) [06:38] if the event is the closing of the file descriptor ? [06:38] 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] I might clear the pending events from the lis [06:38] hmm [06:40] that was my guess [06:40] 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] Gah! [06:40] that might explain it; I'll have to go code-digging to see [06:40] RAOF: ? [06:41] 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] Keybuk: yeah, the reason not to swap them is bug #554737 :) [06:41] Launchpad bug 554737 in plymouth "ply_boot_client_flush() does not read replies (plymouth stuck during/after filesystem check or error)" [High,Fix released] https://launchpad.net/bugs/554737 [06:41] RAOF: no, output it to /dev [06:42] (I think I said this :) [06:42] You did, I just didn't pay enough attention :) [06:45] and now you go hungry [06:48] ah, I thought I had just eaten too much mexican food and couldn't type [06:48] instead it turns out that the 't' key was falling off [06:51] bryceh: have you learned anything more about bug #553708? [06:51] Launchpad bug 553708 in plymouth "ubuntu-logo theme: Mount error message is overlayed with the S&M message" [Medium,Triaged] https://launchpad.net/bugs/553708 [06:52] RAOF: is that working better? [06:53] the "S&M message" ? [06:53] 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] ah, I'd forgotten that one [06:53] Unable to mount your filesystem. [06:53] Say the safe word to abort. [06:53] Ahem. :) [06:54] RAOF: maybe add a 2>&1 as well? [06:54] (not sure why that would be needed, but) [06:55] Yeah - gdb should be on stdout, surely. Anyway… added. Let's give *that* a whirl. [06:55] Nope. Empty again. [06:55] hmm [06:56] 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] er - mountall really shouldn't affect that [06:57] can you post your full /etc/init/mountall.conf? [06:58] well, though I guess if mountall is failing before even emitting virtual-filesystems, udev won't start either [07:01] jono!!!! [07:01] oi oi Keybuk :) [07:09] slangasek: http://pastebin.com/4fMG50Ze [07:09] (Sorry about the delay; it's a bit hard to get things off the laptop :) === jamesh_ is now known as jamesh [07:12] And http://pastebin.com/qGP2WgeP is /gdbscript [07:20] I want to create personal page on ubuntu wiki, were should I ask? [07:22] AHA! gdb looks like it wants to be able to write to / [07:22] RAOF: 2>&1 has to go after > /dev/mountall.log [07:22] oh? [07:22] * RAOF never gets shell redirections right the first time :( [07:23] If I remount / rw before calling gdb, I get some output in /dev/mountall.log. [07:23] RAOF: "2>&1" == "make fd 2 point to the same place that fd 1 currently points" [07:24] 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] 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] micahg: that's because a pipe is a different part of shell language [07:26] RAOF: ah; you may have to trap SIGABRT explicitly [07:26] |, like &&, ||, ;, etc. separates distinct commands [07:26] 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] 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] RAOF: hmm, no - gdb handles SIGABRT by default [07:27] I thought it did, yeah. [07:27] micahg: it makes a kooky sense [07:27] Keybuk: it makes great sense if everything is in perspective, slangasek described it well [07:27] RAOF: do you still get the abort message somewhere? [07:27] 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] whereas >log 2>&1 vs. 2>&1 >log now make sense as different [07:29] * micahg has a lot to learn still [07:30] more fun .. what does ... cmd >log 2>&1 | less do? :p [07:31] and to make your brain really hurt, try that in zsh ;-) [07:31] Depends on the shell. In dash, less gets nothing. In zsh, it gets the output from cmd. [07:31] zsh's pipeline handling is based largely on a dare [07:31] Just like echo foo >bar >baz works in zsh. [07:32] I like <(...) [07:32] Accursed thing! What's preventing keyboard input? [07:33] e.g. diff -u <(sort file1) <(sort file2) [07:33] 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] For instance, xargs -a (ls | shuf) -d'\n' mplayer to play the videos from cwd in random order. [07:34] <( [07:34] 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] 'dmcrypt'? Is that using cryptsetup, or not? [07:35] oh, you say that it is [07:36] Well, to unlock it I run “cryptsetup luksOpen ...”, so I presume that's using cryptsetup :) [07:36] RAOF: try commenting out 'console output' in /etc/init/cryptdisks-udev.conf [07:36] Glob expansion in zsh is especially nice. echo foo/**/a*(.) (equivalent to find foo -type f -name 'a*' -print0 | xargs -0 echo) [07:37] ion: indeed; though we're kinda getting in the way of debugging here, so I'm going to shut up P: [07:37] Hehe [07:37] Eh, not that much in the way :) [07:40] slangasek: /etc/init/cryptdisks-udev.conf doesn't *have* a “console output” stanza. [07:41] really? [07:41] http://pastebin.com/JBvmKQ74 is the full output of mountall.log, with stderr redirected appropriately. [07:41] oh, I guess I have a modified version of that file then :P [07:42] But that output is after manually unlocking the crypted disc, which doesn't have the same behaviour. [07:44] 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] you can't launch gdb from upstart [07:45] not without taking out the "expect ..." bit [07:45] Keybuk: You mean the “expect daemon” bit? That's commented out. [07:45] oh, dunno then [07:48] * RAOF comments out random “console output” stanzas [07:48] try "console owner"? [07:49] maybe the ioctl is inappropriate unless it's married? [07:49] That should totally be a technical term! [07:50] "how do you like your ioctls? raw or cooked?" [07:55] Hey! Since I've already remounted / read-write I can just write the gdb log somewhere permanent! [07:57] RAOF: I set up a test system with cryptsetup-LUKS LVM now, in case you need more testing for something [08:05] So, “console owner” seems to have cleared up those inappropriate ioctl messages, but there's still no backtrace. [08:07] slangasek: Shall we just go on a printf debugging spree? [08:07] good morning [08:22] 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] then we can postprocess at leisure [08:25] Seems reasonable; doing so ow. [08:25] *now === radoe_ is now known as radoe [08:30] chdir / [08:30] limit core unlimited unlimited [08:30] ;-) [08:30] (can go directly in the conf file) [08:30] heh, ok [08:32] We have a core, and a backtrace. [08:32] ...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] 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] attempting to run directly across it will only result in drowning [08:50] Keybuk: I seem to have made it ok [08:51] perfectly dry, too [08:53] slangasek, no, I got busy with other stuff and just worked around it [08:54] RAOF: any further on that better trace? [08:56] Keybuk: got a better one, then rebuilt everything with DEB_BUILD_OPTIONS=noopt,nostrip and installed further dbgsym packages. [08:56] 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] Yay! Got *all* the stack this time [08:59] RAOF: may I see? [08:59] Keybuk: http://paste.ubuntu.com/423232/ [09:02] right, pretty straight forward [09:03] just to confirm sanity [09:03] if you up a couple of frames and [09:04] p client->requests_to_send [09:04] do you get 0 [09:04] ? [09:05] I presume you meant p *client->requests_to_send? [09:05] $2 = {first_node = 0x0, last_node = 0x0, number_of_nodes = 0} [09:05] right [09:05] ok [09:05] so pretty straight forward [09:06] when it flushes the plymouth fd, there are requests to send [09:06] the first call is to process_pending_events () [09:06] this can clearly send events (it polls on write) [09:06] so it writes out the queue [09:07] there are now no events to flush [09:07] so process_pending_requests will assert [09:07] while (ply_list_get_length (client->requests_to_send) > 0) [09:07] { [09:07] ply_event_loop_process_pending_events (client->loop); [09:07] ply_boot_client_process_pending_requests (client); [09:07] } [09:07] ... [09:07] slangasek: since ply_event_loop_process_pending_events () will *call* ply_boot_client_process_pending_requests () if the fd is writable [09:07] isn't that loop wrong? [09:07] should it not simply be [09:08] while (ply_list_get_length (client->requests_to_send) > 0) [09:08] ply_event_loop_process_pending_events (client->loop); [09:08] does it call it? I don't think it does [09:09] it definitely definitely definitely does [09:09] that's the whole purpose of that function [09:09] to be called from inside ply_event_loop [09:09] look at ply_boot_client_queue_request === almaisan-away is now known as al-maisan [09:10] 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] right [09:10] so all the time that client->requests_to_send is *not* 0, that function will be called whenever the fd is writable [09:10] OK. So why isn't this asserting for everybody? [09:10] and in the bottom of the function itself, it clears its own watch once the list is empty again [09:11] I guess for most people, the epoll says the fd isn't writable [09:11] and then it blocks in the second function [09:11] but for RAOF, the epoll says it's writable [09:11] so that assert [09:11] very fast machines assert maybe? [09:11] or machines with oodles of memory (big socket buffs) [09:12] yes, that could make sense. In that case it isn't particularly configuration-specific and I think we ought to respin [09:12] it'll also only assert if you manage to completely *drain* the request list inside that first call to epoll [09:12] so pretty racy [09:12] and the request list when fsck is concerned is pretty long, so hard to drain [09:13] so yeah, the assert pattern would look something like [09:13] - there are requests when flush() is called [09:13] - the fd polls for writing (write will not block) [09:14] - all of the requests are able to be written before write would block [09:14] - thus by the next call, there are no longer any requests [09:15] ok, my work here is done [09:15] * Keybuk hands over to the day shift [09:15] I can not log gives me a black screen and reboot ... how to help me reinstall [09:29] 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] what's the current process to upload a one-liner bugfix for a universe package? [09:37] lucas: upload it and make sure that the changelogaand linked bug properly document the change [09:38] pitti: thanks [09:38] pitti: a fake sync from debian is fine, too? [09:39] lucas: same criteria: depends on whether the debdiff is 100% obvious and regression proof [09:39] ok [09:40] lucas: aside from that, a big concern is that builds must be completed soon, to avoid having pending build records at release [09:40] lucas: for most (i. e. relatively small) packages that's not a problem [09:40] it might be for things the size of linux/OO.o/openjdk [09:41] pitti: ok, will upload ASAP [09:41] lucas: merci === ttx_ is now known as ttx [09:43] tseliot, could you please have a look at 565407, another fglrx issue when installing the ubuntu package over the ati installer [09:44] tseliot, the fglrx preinst script removes /etc/ati _before_ running ati's uninstallation script. [09:44] bug #565407 [09:44] Launchpad bug 565407 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1 - inst_path_default or inst_path_override does not exist in /etc/ati wh..." [Medium,Triaged] https://launchpad.net/bugs/565407 [09:44] tseliot, fglrx-uninstall.sh fails when installing the ubuntu package over the ATI driver because its /etc/ati disappeared === tkamppeter_ is now known as tkamppeter [09:51] ogra, can you tell me the bug nr for the mount with a broken clock ? [09:51] good morning all [09:52] joaopinto, bug 563618/ [09:52] Launchpad bug 563618 in initramfs-tools "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Fix released] https://launchpad.net/bugs/563618 [09:52] hrm [09:52] tks [09:52] * ogra wonders where that slash came from [09:53] there is a fix released ? [09:53] a workaround [09:53] the actual fix has to happen upstream [09:58] 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] slangasek: ^^ [10:06] ogasawara_: bug 570542 (iso-testing) looks like a straightforward fix - maybe SRU? [10:06] Launchpad bug 570542 in linux "linux-image-virtual does not include ahci module, prevents virtualbox from booting minimal vm install" [Undecided,New] https://launchpad.net/bugs/570542 [10:08] tseliot, not really because once you've tried to install the ubuntu package you cannot uninstall the ati driver anymore. [10:08] cjwatson: ack, thanks [10:08] tseliot, shouldn't we detect the presence of the ati driver before attempting to remove any of its files ? [10:09] 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] 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] tseliot, indeed [10:13] slangasek, pitti: do you agree to include this trivial fix in the final release (for the sake of dist-upgrades)? [10:13] tseliot: upgrades can easily be fixed as SRUs, too [10:14] pitti: sure but we would break a lot of dist-upgrades in the mean time... [10:14] tseliot: at this point I defer to slangasek and cjwatson, they are coordinating the current rebuild ATM [10:14] ok, thanks [10:14] update-manager workarounds can be done outisde of that as well, right? [10:14] tseliot: trivial fix - no, the deadline for those was Sunday [10:14] tseliot: we can't afford to further delay ISO mastering [10:15] tseliot: please get it uploaded to lucid-proposed now [10:15] slangasek: too bad, well, I tried. I'll do as pitti suggests [10:15] ajmitch: do you have anything particular in mind? [10:15] 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] mvo: nothing particular, just seeing the discussion from tseliot & jibel about the ati driver [10:16] that would be a good compromise [10:23] 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] slangasek: plymouth -ubuntu2 boots my system correctly. Thought you might like some confirmation ;) [11:10] RAOF: great, thanks for confirming :) [11:12] pitti, ping [11:13] hey deryck [11:14] 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] 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] the actual bug report is still open, of course [11:15] pitti, ah, ok, that makes sense. Sorry missed the comment. [11:30] is firefox supposed to have an offline startpage? [11:30] seb128: I think you only see it when you're offline. [11:31] right, that's what I meant, should I get a startpage or an errorpage when starting offline? [11:31] I think you should get a startpage :) [11:32] ok, I don't [11:32] fta: micahg: any input? [11:32] that's on the live image though [11:32] if that makes any difference [11:32] Ought be the same. === MacSlow is now known as MacSlow|lunch [12:55] smoser: hi, we need a UEC/EC2 respin to pick up the latest plymouth change; can you take care of that this morning? === mdomsch is now known as mdomsch_BOS === MacSlow|lunch is now known as MacSlow [13:29] kirkland: people.canoncial.com has tons of space these days [13:31] smoser: n/m, have triggered it here [13:31] * didrocks starts to upload every daily for history then ;) [13:37] elmo: any chance those images were backed up somewhere? [13:38] slangasek, sorry i missed you. you're all set? [13:39] smoser: yep, we're good - thanks [13:39] as a simple "build it" i use: sudo -u vmbuilder ~vmbuilder/bin/cronrun build-daily lucid server [13:39] yeah, I grabbed it from the cronjob [13:44] doko_: you've seeded texinfo-doc-nonfree without an MIR? [13:47] 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:47] Launchpad bug 390677 in hundredpapercuts "Hidden line during install wizard" [Undecided,Confirmed] https://launchpad.net/bugs/390677 [13:48] yeah, the window is smaller than it could be [13:48] its the same size in both variants for me [13:48] it just doesnt show the last line [13:49] and there is no scrollbar [13:49] (note i'm doing only-ubiquity since thats the default on omap) === ogra_ is now known as ogra [14:27] 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] we haven't discussed them being in universe (i. e. consider them free) === doko_ is now known as doko [14:28]