[00:05] and cjwatson had a commit for the fix to bug 524169 on the tree ready to go too [00:05] Launchpad bug 524169 in ubiquity "Ubiquity installer partitioner crashed, main installer enters endless loop" [High,Fix committed] https://launchpad.net/bugs/524169 [00:07] superm1: ok, that sounds like a set worth uploading then [00:07] superm1: please go ahead [00:07] alrighty, thanks [00:10] so something is sending a quit signal to x's controlling tty when some people press enter after first boot ( http://paste.ubuntu.com/382615/ shows it coming from the tty layer) when plymouth is used. suse seems to be getting around it with http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch anyone familiar enough with plymouth to dig into it more? i noticed one place where it could be resetting the ISIG flag o [00:10] n plymouths tty (in src/libplybootsplash/ply-terminal.c) so the enter key (0x1c) becomes Control-\ (0x1c) if the same VT is used for X but its a bit over my head. [00:23] pitti, bryceh: what's the status of hal removal now? I see it included on daily desktop ISOs, which seems to put the lie to what was written in the A2 tech overview :) [00:23] slangasek, afaik we no longer use it for anything [00:24] slangasek, so if you spot something X-ish which does, let me know as it's a bug [00:24] it's in main because of libvirt-bin, but that doesn't explain it being on the CD; will dig [00:25] ah, it's pitivi [00:25] lol [00:25] heh [00:25] seb128, robert_ancell: does pitivi need this Recommends: hal? [00:26] slangasek, not sure, seb128 do you know? [00:26] slangasek, thanks for your help with plymouth+upstart. It's driving me insane :) [00:26] slangasek, yes [00:26] seb128: waah - why? :) [00:26] slangasek, it needs to be ported to python-gudev [00:26] robert_ancell: is it /still/ driving you insane? :/ [00:27] slangasek, because it uses it... [00:27] slangasek, yeah. I already knew about the /proc issue (I've tried mounting it before running plymouthd and modifying plymouthd to not require it) [00:27] seb128: is that likely to happen in lucid? I guess the daemon is no longer started by default so it's not a huge problem, right? [00:27] slangasek, the problem I find is it's really hard to tell why it doesn't boot up [00:27] slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=605920 [00:27] Gnome bug 605920 in general "Switch to (g)udev for device detection/support (deprecation of HAL)" [Normal,New] [00:28] robert_ancell: even after fixing plymouthd to not mind if /proc is missing? [00:28] slangasek, would be nice for lucid, and correct for the start [00:28] slangasek, yeah, did that ages ago. [00:28] seb128, is gudev an official GNOME dependency? [00:28] robert_ancell: mmk; is there some way I can get my hands on a running environment of what you're working on, to poke at directly? [00:28] robert_ancell, yes, there was no python bindings though [00:28] (not that I'll have time until Friday, but) [00:29] robert_ancell, pitti get that solved now [00:29] seb128, that's what I was going to ask pitti - is the halsectomy an ubuntu goal and/or a GNOME goal? [00:29] both I guess [00:30] not an official GNOME goal that I know [00:30] but they work toward deprecating it too [00:30] bryceh: is this note about not having wacom support obsolete in a3? I see xserver-xorg-input-wacom is in now [00:30] slangasek, that's correct, wacom is good to go [00:30] \o/ [00:33] well usb wacom support at least, serial digitizers still need an xserver change thats in git [00:34] why is there a distribution upgrade available? I'm running lucid alpha 2. [00:35] Kai_: Probably as part of the testing for the upcoming Alpha-3: you might get a more detailed answer in #ubuntu+1 [00:35] next xserver upload will have it, most tablet pc's need that [00:35] okay, thanks === nhandler_ is now known as nhandler [00:52] is there a known issue with lucid that when you do autologin it doesn't seem to change to the X server [00:53] i see the xcursor but not the rest of X [00:54] 16.5s boot from upgraded lucid (not clean install by any stretch) not bad at all :) [00:54] it just doesn't show X properly for some reason :-\ === bladernr_ is now known as bladernr|away [01:04] hmm it worked after trying again [01:04] seems to not be completely stable for me for some reason [01:09] mdeslaur, zul: where did /etc/network/if-up.d/samba go in samba 2:3.4.5~dfsg-2ubuntu1 ? this should have been kept until the conversion to upstart could be done (bug #526659) [01:09] Launchpad bug 526659 in samba "nmbd fails to start at boot time" [Undecided,New] https://launchpad.net/bugs/526659 [01:09] ccheney: bug #521175; would love it if you could figure out *why* autologin is different [01:09] Launchpad bug 521175 in plymouth "Plymouth AND Automatic Login enabled system freezes" [Undecided,Incomplete] https://launchpad.net/bugs/521175 [01:09] slangasek: looking now [01:11] mdeslaur: if it's broken anyway, I'm inclined to just upload for bug #523868, I'm just surprised to see this regression [01:11] Launchpad bug 523868 in samba "FFe request: samba upstartification" [Low,New] https://launchpad.net/bugs/523868 [01:11] slangasek: it didn't actually freeze for me, some of the times the xcursor showed up but not the rest of the desktop, other times it came up all the way but then x would crash after a short time, but would respawn ok [01:11] on intel x4500 [01:12] ccheney: all the same thing. Does gdm come up ok when *not* using autologin? [01:12] slangasek: yea [01:13] slangasek: and even when x didn't come up all the way i could still switch vt's [01:13] ccheney: yep. So somewhere in the gdm logic to interface with plymouth, there's a bug when autologin is used; but I couldn't find it when I tried to trace the gdm code [01:13] can someone accept nomination for lucid for https://bugs.launchpad.net/ubuntu/+source/euca2ools/+bug/526697 [01:13] oh ok [01:13] Launchpad bug 526697 in euca2ools "euca-describe-images has incorrect order of ramdisk and kernel" [High,Confirmed] [01:14] on the times i booted up and xcursor was all that showed it played the login music with just the black screen, one time i switched vt's and the desktop showed up, iirc it crashed soon afterward though [01:14] so maybe some kind of bug with the vt switching in plymouth/gdm, but not really sure [01:19] every time that's happened to me ureadahead was reprofiling, could just be a coincidence though. [01:20] there very definitely seems to be something different in gdm's interaction with plymouth when using autologin [01:21] if someone can figure out what, that's probably the bug [01:21] (and knowing what it is might help me fix other plymouth bugs, fwiw) [01:26] slangasek: looks like the samba in lucid never got the if-up.d file added to debian/samba.files [01:26] zul: ^ [01:27] mdeslaur: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/462169/comments/64 [01:27] Launchpad bug 462169 in samba "nmbd dies on startup when network interfaces are not up yet" [High,Fix released] [01:28] mdeslaur: i remember putting it in lucid its in lucid-updates as well [01:28] zul: you forgot to add it to debian/samba.files [01:28] zul: http://launchpadlibrarian.net/38098612/samba_2%3A3.4.3-2ubuntu1_2%3A3.4.3-2ubuntu2.diff.gz [01:28] frig... [01:28] my bad [01:29] huh, ok :) [01:29] * mdeslaur votes for the upstart job :) [01:29] as do i :) === nhandler_ is now known as nhandler [01:45] anybody use dvbcut? i get an error message saying "the chosen file *** contaqins no video" anybody come across the before? [01:46] !support | homebrewcider [01:46] homebrewcider: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only. [01:47] oops sorry [01:47] clicked the wrong room [01:47] happens to everyone once :) === nhandler_ is now known as nhandler === Kai_ is now known as Kaj_ [02:55] Some much more frequently than that. === Kaj_ is now known as Kai_ [03:40] o/ [03:40] /usr/lib/claws-mail/plugins/notification_plugin.so: undefined symbol: menu_create_items [03:40] i'm having issues with 2 plugins in claws-mail [03:41] notification and att_remover [03:41] is that here that i should adress or to maintainer ? [03:53] mohaa: best to file a bug on launchpa [03:53] d [03:53] ubuntu-bug claws-mail [03:54] doing it [03:54] likely, it's too complicated :D [03:54] awesome, thank you. [03:54] * mohaa mad at maintainers not using their builds :P [03:55] we're not being mean and trying to send you to the proverbial RT, just the bug tracker is the best way of getting the attention of those who care, so to speak. [03:55] actually in this case CLAWS-MAIL has been upgraded and not the plugins -_- [03:56] so we have fresh client and plugins compiled for an older version of claws :-\ [03:56] is this on karmic or lucid? [03:56] :o [03:56] 9.04 [03:56] groan... yikes. [03:57] i don't use this system much so.... [03:57] ugh *rant mode* plugin packagers should properly depend on the version of the parent program they need.... [03:57] :D [03:57] *end rant* :) [03:57] IIRC the one Ubuntu dev I know of that uses claws mail wasn't that active during Jaunty development. [03:57] jdong: It probably just needs a rebuild. [03:57] i see it [03:57] why am I getting a deja vu moment. [03:57] it's still on 3.6 series :-\ [03:58] * ScottK used to need to care about claws when it has clamav plugin. [03:58] ScottK_san it still has it ;) [03:59] mohaa: you probably could check this ppa https://launchpad.net/~claws-mail/+archive/ppa [03:59] nigelb thx :) [04:00] i'm using a quite old buntu so... [04:02] hey, didnt Alpha 3 drop today? [04:03] Thursday [04:03] I could have sworn the timeline said today [04:04] February 25th [04:04] Must have confused it with the rebuild test [04:04] I think a 3-day pushback. [04:04] Ok, so I'm NOT nuts [04:04] just got the freeze announcement this morning [04:04] which mentioned a schedule delay :) [04:05] so no, you probably correctly marked your calendar [04:08] jdong: https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/526831 ;) [04:08] Launchpad bug 526831 in claws-mail "Claws-mail : plugins built against different parent program" [Undecided,New] [04:15] jdong: Milestone releases are always on Thursdays. [04:15] ah, gotcha [04:16] Freeze on Tuesday and release on Thursdays for Alphas. [04:59] hello everyone: I'm trying to compile with gcc a program and I need the -lsocket library, I installed "happycoders-libsocket-dev" but I still get an error that says "/usr/bin/ld: cannot find -lsocket" any ideas ? [04:59] bye you guys [04:59] o/ [05:24] Is it known if Lucid will ship with Mono 2.6 ? [05:25] It is currently using 2.4, and 2.6 was released in December and contains many bug fixes [05:27] det: it will probably be 2.4 as that's an LTS [05:28] det: 2.6 will most likely be in lucid +1 [05:28] That is very unfortunate, but thanks for the info [05:29] det: it would be more unfortunate to have an unsupported version of mono in an LTS :) [05:29] What do you mean by unspported ? [05:30] det: mono only supports branches for certain amounts of time, so if we ship a short support branch in a long term release, then we'll have a period of time w/out upstream fixes/patches [05:31] Do you happen to know that Mono 2.4 is a long term support branch, while 2.6 not? [05:31] det: http://www.mono-project.com/Roadmap [05:32] I understand now, thanks. [05:33] det: np :), LTS's aren't the place for latest and greatest anyways..people want stability more than features in tehm [05:33] Perhaps some of the bug fixes I am interested in from 2.6 are backported into the 2.4.3 release [05:33] det: maybe and if they're not, maybe it can be requested [05:34] I will test out the Lucid alpha-2 [05:34] det: alpha 3 is coming thursday [05:35] Well, I am interested in testing mono 2.4.3, which I think alpha-2 has [05:36] I tried 2.6 from a suse live cd, and it solved some problems in an application [06:52] Good morning [06:52] Hi pitti! [06:54] bryceh, slangasek: so the two remaining use cases of hal in lucid are: (1) pitivi, and (2) gnome-power-manager uses hal to change the backlight on devices which don't have XBACKLIGHT support (which is still the majority) [06:54] slangasek, bryceh: hal was switched to d-bus activation, i. e. it does not start up on systems with xbacklight support on boot [06:54] slangasek: I'm afraid we are stuck with that in lucid [06:55] pitti: I guess pitivi uses hal for hardware notifications? [06:55] yes [06:55] finding cameras, etc. [06:55] Bleh [06:55] pitti, is the xbacklight issue already known upstream? [06:55] However, g-p-m is the much harder one to kill :-/ [06:56] bryceh: yes, for a long time [06:56] brb, gotta help put kiddo to bed [06:56] bryceh: it's a matter of getting driver support for it [06:57] argh! a dist-upgrade here wants to install chromium now, WTH? [06:59] Wow, what's pulling that in ... [06:59] pitti, any work arounds? Can whatever hal does be extracted into something more standalone? [06:59] argh, nevermind [07:00] pitti: False alarm? [07:00] bryceh: in theory yes, but in practice it'd be better to add xrandr support to drivers; otherwise you keep having two things which are responsible for the backlight control [07:03] pitti, hmm, well waiting for stuff to get added to drivers (X drivers at least) can take a while... [07:03] right [07:03] but I think there's no way we can make even a workaround happen in lucid [07:07] good morning [07:11] pitti: ok, makes sense [07:40] is something wrong with the repo main server? it is extremely slow [07:50] Mamarok: yep. same here [07:54] to much tv [08:30] aah, I tracked down the reason for the major udisks boot time increase \o/ [08:30] geez, our armel images exploded in size ... darn openoffice [08:31] ogra: when? which version of rhythmbox-ubuntuone-music-store do you have? [08:31] pitti, did we inherit the new langs from you guys ? [08:31] ogra: today's netbook images exploded by 40 MB, due to a wrong dependency in above [08:31] pitti, the image from 22 is 540 vs 690 today :) [08:31] * ogra check RB [08:31] ogra: we dropped most languages from our seeds [08:32] *checks even [08:32] +rhythmbox-ubuntuone-music-store 0.0.2-0ubuntu2 [08:32] that's it [08:32] http://paste.ubuntu.com/382809/ is the manifest diff [08:32] ogra: you can substract 40 MB once 0.0.2-0ubuntu3 [08:32] is published [08:32] ah, cool [08:33] still bloated :) [08:33] 540MB was so convenient :) [08:33] +default-jre 1.6-34 [08:33] there you go [08:33] don't do that [08:33] i think that came in with oo.o [08:33] we didnt change our seeds at all, we only use what you guys use for netbook now [08:33] ogra: don't seed oo.o-base [08:34] It's the *same* seed. [08:34] it will go again once the online office spec is fully implemented [08:34] until then we'll live with oo.o i guess ... its not oversized yet [08:34] hm [08:34] -base is not seeded [08:35] and 40MB less gets us back to 650 at least [08:35] so some wrong dependency pulls it back in [08:35] it's not on the i386/amd64 ones [08:35] strange [08:35] the seeds are identical, as persia stated abov [08:35] e [08:36] ogra: we recently had that problem on i386/amd64 as well [08:36] what was the issue ? [08:36] some oo.o translation package depended on language-support-writing-en | openoffice.org [08:36] something like that [08:36] but that got fixed during the sprint [08:36] weird, there shouldnt be any armel specific deps [08:36] it's definitively not a seed problem [08:37] +openoffice.org-report-builder-bin 1:3.2.0~rc4-1ubuntu1 [08:37] nobody ever seeded stuff like that [08:37] Reverse Depends: [08:37] openoffice.org-report-builder [08:37] openoffice.org [08:38] hmm, the same on x86 [08:40] ogra: perhaps some package is out of date on armel? === yofel_ is now known as yofel [09:19] pitti: in my laptops dmesg [09:19] pitti: actually, I lie [09:20] I was sshed into a linode ;P ignore that [09:20] hm, I'm pretty sure we disabled it in karmic [09:20] heh [09:20] I do see udev spam on boot [09:20] probably stale rules or something [09:20] lifeless: I see them from calibre [09:20] but I'm sure there's plenty of other broken/obsolete rules in packages out there :/ [09:21] * pitti will fix calibre soono [09:21] s/o$// [09:21] calibre? free californians? [09:21] heh [09:21] lifeless: e-book organizer/converter/creator [09:22] nice [09:22] I was trolling :> [09:23] * pitti remembers to stop taking you seriously from now on :) [09:23] lifeless: how's your Klingon these days? [09:23] pitti: you should, when I'm not serious [09:23] pitti: terrible, I don't know it [09:23] pitti: I only set it up for you guys :> [09:30] pitti: however, FF has a klingon pack too, now. === tkamppeter_ is now known as tkamppeter [10:50] cjwatson: any ideas as to why "DEB_SHLIBDEPS_INCLUDE_$(PKG_driver) := debian/$(PKG_driver)/$(DRIDIR)/fglrx/:/$(DRIDIR)/" doesn't work with cdbs in this case? http://pastebin.ubuntu.com/382879/ [10:50] I don't really know cdbs ...? [10:51] oh [10:51] maybe try 'export DH_VERBOSE=1' and run the relevant commands by hand to dig into it? [10:52] cjwatson: ok, but you know debhelper. Basically what's happening here is that a binary depends on a library shipped by the same package [10:52] ok [10:52] by hand? [10:53] tseliot: Since debian/control is not supposed to change at build-time, can't you just hardcode the dependency for that library into debian/control? [10:53] at a shell prompt [10:54] persia: the binary and the library it depends on are in the same package [10:55] tseliot: The same source package or the same binary package? [10:55] persia: both things [10:56] tseliot: Then why do you care about shlib:Depends there? You know it's provided. Just ship a symbols file for things that build against it. [11:02] tseliot: If you're working around debug packages, you may want to request debhelper >= 6.0.3, but as long as you have debhlper >= 6.0.0 you shouldn't need -l anyway (which is what DEB_SHLIBDEPS_INCLUDE sets) [11:03] hi there! i try to cross compile with arm-linux-gcc a sqlclient to arm720t and i need lib mysqlclient. Must i compile it from soucre? How? it would give me great pleasure for some tip. [11:03] persia: it's a proprietary library and it can get even messier. I've found out that my cdbs option works if I create a link (libfglrx_gamma.so.1) to libfglrx_gamma.so.1.0 (the actual library) [11:04] persia: as the error was dpkg-shlibdeps: error: couldn't find library libfglrx_gamma.so.1 [11:04] tseliot: Ugh. That's just messy. [11:04] persia: welcome to the world of fglrx ;) [11:05] Noisi: #ubuntu-arm might be a better forum. There are precompiled binaries that might or might not work properly in a primarily cross-compiled environment. [11:06] persia: Thanks :-) [11:07] persia: with that link I don't even need DEB_SHLIBDEPS_INCLUDE_ [11:07] tseliot: So, you're operating with binary blobs? I suspect a gap between filenames and information presented from introspection (nm might let you confirm). Drop the -l, add the symlink, and generate a symbols file just to verify stuff. [11:07] tseliot: Well, if you use debhelper 5 you'd still need it :) The fix is with debhelper 6. What's debian/compat? [11:08] persia: 7 [11:08] Yeah, then you very much don't need DEB_SHLIBDEPS_INCLUDE [11:09] cjwatson, persia: ok, thanks for your help [11:14] If we would like to get bug #506125 fixed we'd have to sync Nautilus Actions, because the fix is in 2.29.4. Otherwise I'd remove nautilus-actions since it now just doesn't work. Will nautilus-actions be synced to 2.30 in time for the Lucid release? [11:14] Launchpad bug 506125 in nautilus-actions "nautilus-actions-config-tool assert failure: NA-nact:ERROR:nact-ibackground-tab.c:381:get_folders_treeview: assertion failed: (GTK_IS_TREE_VIEW( treeview ))" [Medium,Triaged] https://launchpad.net/bugs/506125 [11:16] Noisi: you might also like to look into dpkg-cross [11:16] (requires some setup) [11:18] Keybuk: Mind if I bother you for a sec? In VMBuilder, I routinely mkfs some devmapper devices. Immediately afterwards, I use blkid to extract the uuid. Occasionally, blkid fails (exit code 2). [11:18] Keybuk: I tried adding a "udevadm settle" in between the two, but it still happens every once in a while. [11:18] It's rare, so I thought the "udevadm settle" fixed it, but it just happened again, so now I'm back to square 1. [11:18] soren: the mkfs will cause udev to run blkid itself, and rearrange symlinks [11:19] which way do you run blkid? [11:19] with -p or without? [11:19] if you run without, it's possible the cache is out of date [11:19] without. [11:19] Right. [11:19] right, run with -p [11:19] Hm. I thought that was frowned upon. [11:19] you shouldn't need the settle [11:19] -p is a physical probe of the block device [11:19] I thought the idea was that only udev would need to do that. [11:19] I understand. [11:19] without means "whatever was in the cache" [11:19] yeah [11:19] but you need to wait for udev to do that [11:20] you can steal the wait-for-root code out of initramfs-tools if you like [11:20] that has the logic to wait properly [11:20] if you use that, you can just call blkid [11:21] * soren looks at that [11:22] Can you explain why -p is needed? I thought that when mkfs let go of the device node, it would trigger an inotify event upon which udev would react, and that "udevadm settle" wouldn't return until udev was done processing this event (and thus, calling blkid -p and updating the blkid cache). [11:22] Which part is mistaken? [11:24] Keybuk: ^ [11:26] that "udevadm settle" knows what you meant to wait for [11:26] Keybuk: Could it be that my "udevadm settle" occurs before udev even sees the inotify event and thus does not think there are any unprocessed events? [11:26] udevadm settle simply waits for udev to be idle [11:27] events could be still somewhere en-route to udev [11:27] when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle [11:27] on the assumption that any file close instantly resulted in the entry being added to the inotify queue [11:28] but inotify has been entirely rewritten since then (replaced in-kernel with fsnotify) [11:28] so that may no longer be true [11:28] it might be possible for there to be a gap between the mkfs call, and the inotify event being queued for udev to receive [11:29] Right, ok. [11:29] it would be worth reading some kernel code to find out whether or not that's changed [11:30] Keybuk: You said "when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle"... Does it not attempt to drain this queue anymore? (Yes, I understand that the event might not be in the queue at all yet, this is just a side-question) [11:30] soren: udevd does, yes [11:30] Ok. [11:31] *inotify*, in the kernel, has been completely rewritten [11:31] so it's possible that the act of mkfs closing the device node does queuey things in the kernel [11:31] that no longer guarantees that udevd's inotify socket polls for reading *by the time close() returns* [11:31] if that bit has gone async in the kernel, you'd have a race where after mkfs exits, udevd may not yet have received the inotify event for the block device [11:32] *nod* [11:33] that'd be worth some investigation [11:39] Keybuk: udev still uses the inotify /interface/, right? [11:40] yes [11:40] alright [11:42] Keybuk: so yesterday I started converting console-setup to upstart in order to fix its interaction with plymouth, which is a little bit involved due to how it glues into the installer. Am I duplicating work you've already done and should I stop? :-) [11:42] (I didn't get very far as it was at the end of the day - just wrote initial job sketches) [11:44] Keybuk: ugh, too much *notify's and fa*'s ;P [11:44] starting to get really confusing :) [11:44] cjwatson: no, you're doing work I felt was far too scary for me ;P [11:44] I couldn't work out when we'd actually run console-setup [11:44] since plymouth is *always* running from startup through to power off [11:44] I thought we might need to use ConsoleKit to run console-setup when switching away from X [11:44] inotify, dnotify, fanotify, fam... [11:44] which ones am I forgetting? :P [11:45] fsnotify [11:45] Chipzz: fam is not a kernel interface [11:45] Chipzz: and all those you mentioned are the same in-kernel code [11:45] just different user-space interfaces for the underlying fanotify code [11:45] or is it fsnotify [11:45] Keybuk: I know, but all these technologies fall into the same "realm" [11:45] Chipzz: they're all the same technology from the kernel POV [11:45] just different iterations :P [11:45] the difference between inotify, dnotify and fanotify is the difference between open(), creat() and socket() [11:46] no, not even iterations [11:46] *the same code* [11:46] Keybuk: I was thinking of running it 'on starting plymouth-splash' [11:46] roughly [11:46] wasn't dnotify replaced by inotify? [11:46] s/replaced/obsoleted/ [11:47] Chipzz: Yes. [11:47] Chipzz: dnotify was implemented using inotify [11:47] Chipzz: And then inotify was replaced by fsnotify. [11:47] cjwatson: right, that's about the only point we can do it [11:47] the problem then is racing gdm [11:47] you could be doing console-setup and hold up plymouth --show-splash [11:47] meanwhile gdm starrs [11:47] and starts X [11:48] this would suck less if the kernel sucked less [11:48] it's ridiculous that we need an active text-mode console in order to set the console font [11:49] agree [11:49] it would suck less if upstart sucked less too [11:50] using consolekit would sort of work, but wouldn't be effective on server-type installations [11:50] since ttx filed the bug in question ... :-) [11:50] (well, one instance of it) [11:50] well, on server plymouth does exit at the end of rc2 [11:50] so that's one obvious place to run console-setup [11:50] yeah, true [11:51] we used to do that for usplash [11:51] could shove it in plymouth's stop script [11:51] it's desktop that's tricky, because getting to a console is really only by C-A-F1 [11:51] cjwatson: on stopping plymouth plz :p [11:51] fair enough :) [11:51] shoving other things into upstart scripts is not the upstart way ;) [11:52] ok, so I'm happy to make this my problem if I'm not stepping on your toes and you don't mind occasional requests for criticism [11:52] sure [11:52] I'm happy for it to be your problem [11:52] gives me more time for plymouth itself to be my problem [11:52] maybe I should just fix the damn kernel [11:52] Jim Leib tried that [11:52] he died [11:53] * cjwatson is not Jim Lieb [11:53] :-) [11:53] * ogra grins [11:53] no, indeed; you're unlikely to have to learn ANSI C just to read the kernel source [12:01] * sebner has faith in our mighty cjwatson :D [12:02] well, this is something that's defeated me in the past, so we'll see [12:02] the basic problem (AFAICR) is that vgacon stores the font only in video memory [12:10] we're not using vgacon anymore though, right? [12:10] we're always using fbcon [12:13] Keybuk: for a kernel bug report, I'd want to cover all possibilities [12:13] *kernel patch [12:14] Keybuk: and that's the basic reason why there's a != KD_TEXT guard in console-impl-independent code [12:14] yeah, I recall [12:14]