[00:19] <CynthiaG> looks like the latest librsvg2-2 introduced a regression, I see bad rendering in my Lucid VM
[00:21] <CynthiaG> http://img.photobucket.com/albums/v390/Looce/img-launchpad/ubuntu1004-badrendering.png
[08:54] <apachelogger> LucidFox: seems like a likely enough thing to happen ^^
[13:41] <ikorm> I would like to know if anyone is up to date with ati drivers on ubuntu. Proprietary ones
[13:41] <ikorm> They keep freezing my laptop, and a lot of people have troubles with them on ubuntu.
[13:41] <ikorm> Where should I adress this, here or do I need to take it to Ati website?
[13:45] <Gryllida> ikorm: !ATI <ubottu> https://help.ubuntu.com/community/BinaryDriverHowto This guide and its subpages describe how to install the proprietary binary/restricted drivers provided by video card manufacturers.
[13:45] <Gryllida> ikorm: I think take to ATI support, not to here.
[13:46] <Gryllida> ikorm: unless it is a request to update a driver in the repo
[13:49] <rlameiro> anyone in here worked with python-apt?
[13:50] <rlameiro> i needex to know how to add a ppa with it
[14:34] <froud> Hi everyone. where is the file that holds the setting for session type GNOME | BLACKBOX. I want to be able to edit this setting via bash shell script, not via the login screen session drop list.
[15:08] <Q-FUNK> doko: could you check something with gas?
[15:09] <Q-FUNK> doko:  https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/587186
[15:19] <geser> rlameiro: you could look how apt-add-repository does it.
[15:24] <rlameiro> thanks geser, i will
[15:53] <fmuellner> my apologies if this is not the appropriate channel for these kinds of questions
[15:54] <fmuellner> i'm looking for the most graceful manner to disable app-indicators in order to resolve https://bugzilla.gnome.org/show_bug.cgi?id=621382
[15:54] <fmuellner> killing seems like a pretty rude solution - i'm not using ubuntu myself, so any help would be very much appreciated
[16:42] <kklimonda> fmuellner: killing indicator-application-service
[16:42] <kklimonda> should be enough
[16:42] <fmuellner> kklimonda: thanks!
[16:43] <fmuellner> kklimonda: would that process be restarted with gnome-panel?
[16:44] <kklimonda> fmuellner: hmm.. let me see.
[16:45] <kklimonda> fmuellner: yes, killing gnome-panel, then killing indicator-application-service and starting gnome-panel again does restart indicator-application-service itself.
[16:45] <fmuellner> kklimonda: cool, thanks a lot!
[17:32] <BlackZ> pitti: are you working to the cdbs merge?
[19:53] <jdong> Hmph. I wish there existed a timezone aware ssh hack :)
[19:53] <jdong> e.g. Based on source IP geolocation set the timezone in the session
[21:13] <un214> it's time for plymouth to go.
[21:14] <un214> it can't even do its job without specific drivers anymore
[21:14] <hyperair> o rly?
[21:14] <un214> https://bugs.launchpad.net/bugs/593408
[21:15] <un214> fbcon has always been broke on this system so don't get any bright ideas
[21:16] <hyperair> so get it fixed.
[21:16] <hyperair> fbcon isn't a "specific driver"
[21:16] <hyperair> it's a generic one.
[21:17] <hyperair> fyi, i'm not using nouveau on my desktop, and it displays the terrible looking lowres splash, but still works.
[21:17] <un214> I got tired of the crashes
[21:18] <un214> fbcon-vesa is misaligned
[21:18] <CynthiaG> fbcon-vesa is probably displaying at 640x480
[21:18] <hyperair> how about filing a real bug report about that? i'm sure the nouveau people will like more information.
[21:18] <CynthiaG> which you can perform a (separate) monitor auto-adjustment for
[21:18] <un214> monitor auto-adjust isn't going to work in this case
[21:19] <hyperair> what you're saying is that "X technology doesn't work without Y technology, which should work for everyone, but due to a few bugs can't work for me. so let's remove X technology instead of fixing Y technology"
[21:19] <hyperair> i'm sure you understand what's wrong with what i just highlighted.
[21:19] <CynthiaG> nouveau is in active development yes, and they need hardware dumps
[21:19] <jdong_> hyperair: I think "plymouth uses fbcon which is more than the old bootsys that just needed a VGA text console, which causes regressions" is fairly valid of a complaint.
[21:20] <jdong_> of course, "we should remove plymouth" isn't a solution
[21:20] <un214> well since the hardware is actually bad
[21:20] <un214> nouveau isn't going to be able to fix it
[21:20] <CynthiaG> Does Nouveau work while in X/GNOME/whatever?
[21:20] <un214> it's unstable
[21:21] <CynthiaG> If the hardware is bad... what are the Nouveau guys to do about it, in software?
[21:21] <CynthiaG> *boggles*
[21:21] <hyperair> jdong_: oh how i wish we can take such an outlook on everything new on ubuntu that causese regressions. but yes i agree.
[21:21] <un214> the motherboard designers put two devices on the same address and wrote special windows drivers to make it work
[21:22] <hyperair> jdong_: in particular, i'm annoyed that plymouth doesn't give me my usual verbose initialization messages.
[21:22] <CynthiaG> the nouveau project can implement that split too, even if not right now
[21:22] <un214> I can't afford to wait
[21:23] <un214> seriously I have so few services that I don't need the parallel boot sequence
[21:23] <un214> how hard would it be to check [ -x /sbin/plymouthd] || run each boot service attached to the console in turn
[21:24]  * CynthiaG thinks she misunderstands Plymouth versus Upstart, or that you do
[21:24] <CynthiaG> Plymouth is just the splash screen that messages get written onto, and Upstart handles the parallel booting... at least Upstart did that in Karmic
[21:24] <un214> CynthiaG: In karmic that was right
[21:24] <un214> in lucid it doesn't seem to be
[21:25] <hyperair> can't you apt-get purge plymouth, though?
[21:25] <un214> I tried.
[21:25] <un214> it wants to remove e2fsprogs
[21:26] <hyperair> huh
[21:26] <CynthiaG> e2fsprogs depends on plymouth? :|
[21:26] <CynthiaG> sounds like a very ugly kludge
[21:27] <hyperair> e2fsprogs doesn't depend on plymouth
[21:27] <hyperair> however, mountall does
[21:27] <CynthiaG> Ah
[21:27] <un214> e2fsprogs depends on sysvinit-tools which depends on upstart which depends on plymouth
[21:27] <hyperair> so the bug should be on mountall.
[21:28] <hyperair> er no
[21:28] <hyperair> upstart doesn't depend on plymouth
[21:28] <CynthiaG> Confusing dependency chain is confusing? :(
[21:28] <hyperair> upstart depends on mountall
[21:29] <hyperair> mountall depends on plymouth
[21:29] <hyperair> mountall is the buggy one
[21:29] <hyperair> it should function without plymouth
[21:29] <hyperair> so file a bug
[21:29] <CynthiaG> hyperair @ un214 or me?
[21:29] <hyperair> whoever
[21:29]  * hyperair isn't really interested in the issue.
[21:30] <hyperair> whoever's interested, file a bug.
[21:30] <CynthiaG> I wouldn't be such a great source of information on the issue because I'm not having it :\
[21:30] <hyperair> heh
[21:30] <un214> CynthiaG: you can force the issue by adding alias fbcon off to /etc/modprobe.conf
[21:31] <hyperair> or blacklist fbcon
[21:31] <CynthiaG> un214: even in a VM, you think?
[21:31] <CynthiaG> a VM of the LiveCD
[21:31] <un214> hyperair: I have another bug for blacklist fbcon doesn't work
[21:31] <hyperair> huh
[21:31] <un214> believe me I tried that one
[21:31] <hyperair> weird.
[21:33] <CynthiaG> actually, never mind, I've just created a virtual hard drive and will try what you say
[21:43] <un214> I was talking to some others earlier and they say the dependency is reall -- w/o plymouth no boot program can talk to the console
[21:50] <un214> I really wish they had bolted the parallel init on top of sysvinit -- it'd make it a lot easier for me to find out what scripts run at boot time in what order
[21:52] <jdong_> what order... in a parallel init system? :)
[21:53] <psusi> that statement hurts my head
[21:54] <un214> I need to know the critical ones bucause if you can't fix this I get to replace all the bootscripts
[21:54] <psusi> like saying I want different process contexts, but they all share the same memory
[21:55] <un214> besides, there exists a partial order (http://en.wikipedia.org/wiki/Topsort)
[21:55] <psusi> the only ordering is between jobs that depend on each other... which you can see in the init script
[21:56] <CynthiaG> un214: creating /etc/modprobe.conf with the line "alias fbcon off" in it does absolutely nothing
[21:56] <un214> oh that's right they moved it
[21:56] <CynthiaG> create a file in /etc/modprobe.d instead?
[21:56] <un214> I actually ended up adding it to /etc/modprobe.d/blacklist.conf
[21:56] <jdong_> psusi: don't say depend on each other or keybuk is gonna come in here screaming at you ;-)
[21:56] <psusi> jdong, hey... care to sponsor the defrag package? ;)
[21:57] <jdong_> psusi: whoa, where's this defrag package??
[21:57] <un214> jdond_: there is such a thing as co-depends
[21:57] <psusi> lol... it may not be 100% accurate, but still a useful generalization concept ;)
[21:57] <jdong_> un214: I'm not arguing with that, it's not proper terminology for Upstart :)
[21:57] <jdong_> but yes, you can do a topological sort by Upstart events :)
[21:58] <psusi> jdong, didn't see my post the other day to the motu mailing list?  launchpad.net/e2defrag is the project.... has link to bzr repo and source tarball for the release I made the other day... binary build in my ppa
[21:58] <jdong_> I used to have a script that did that
[21:58] <jdong_> psusi: neeeeat; no unfortunately I've been swamped with work lately
[21:58] <psusi> and I've even tested it on up to 2tb disks
[21:58] <jdong_> sweet
[21:58] <psusi> made some changes to allow that without needing 6gb of ram
[21:59] <CynthiaG> un214: /etc/modprobe.d/blacklist.conf +alias fbcon off still does absolutely nothing for me, in the VM
[21:59] <un214> CynthiaG: did you run update-initramfs afterwords
[21:59] <psusi> and in the process ran into a kernel bug... I was trying to go over 2tb and found that lvm snapshots silently wrap around at 2tb
[21:59] <CynthiaG> un214: oh, no I didn't
[21:59] <CynthiaG> I'll do that
[22:00] <psusi> you can use snapshots of a zero target to create a virtual disk of huge size with a smaller backing store... was going to use that to try making a 4tb disk to defrag, but it's all hosed up because of the wraparound
[22:02] <CynthiaG> aha un214, now it did something! the boot screen was green, and I can see absolutely nothing instead of the login screen
[22:02] <un214> ok you hit the situation but not the bug
[22:02] <psusi> that reminds me... I need to poke Keybuck about merging my ureadahead changes
[22:02] <un214> hit Alt-F1 to get login
[22:02] <CynthiaG> I heard the drum-like thing that serves as the login ready indication
[22:02] <CynthiaG> Ubuntu 10.04 LTS abra tty1 || abra login:
[22:02] <un214> somehow I got that green screen broken
[22:02] <psusi> and I still haven't heard from Ted about my e2fsck patch....
[22:03] <CynthiaG> that's what virtual terminal 1 says
[22:03] <un214> CynthiaG: my bug is somehow I'm no longer getting the green screen
[22:03] <CynthiaG> hmm
[22:04] <CynthiaG> What are you getting instead?
[22:04] <un214> blackness until login prompt
[22:04] <CynthiaG> well, in any case, it's not the Ubuntu logo and the five circles
[22:04] <CynthiaG> which is to be expected since blacklisting fbcon
[22:05] <un214> I'll bet that if I got fsck to ask me any questions during boot it hangs forever
[22:05] <CynthiaG> However, I only get a login prompt for GNOME (vt7) after I do like you said and switch to vt1
[22:05] <un214> I run KDE and don't have the problem
[22:06] <un214> (*dm login not working)
[22:06] <CynthiaG> it would probably hang forever if fsck needed to ask you anything, yes
[22:06] <CynthiaG> but I think the on-boot fsck is non-interactive
[22:06] <CynthiaG> until it needs to boot you to a maintenance shell, that is. And then I don't know what it does, but it should switch to a sane terminal
[22:07] <un214> CynthiaG: last I checked maintenance boot doesn't use plymouth
[22:08] <CynthiaG> I don't mean a maintenance boot (single-user), I mean fsck having unrecoverable errors and throwing you into a maintenance shell from a normal boot :)
[22:08] <un214> who knows what that's gonna do
[22:08] <CynthiaG> Errors such as "mount time in the future" from Karmic
[22:08] <un214> My money's on wrong console acrtive
[22:09] <CynthiaG> Those threw me to a maintenance shell during the alphas
[22:09] <un214> that shouldn't be an error -- it means the system clock is off until it can sync to network
[22:09] <CynthiaG> I know, but they were still considered unrecoverable in Karmic
[22:10] <un214> ewww
[22:10] <CynthiaG> Aye
[22:13] <CynthiaG> Off-topic fun fact: Apparently a Lucid install needs to read 157 MB of data between boot and the GNOME desktop.
[22:15] <un214> I'm gonna play a hunch and see if I get usable feedback with chmod -x plymouth
[22:16] <un214> test will take awhile
[22:19] <jdong_> what does marking plymouth non-executable do?
[22:20] <CynthiaG> prevents it from being run, without necessarily removing the package
[22:20] <CynthiaG> because removing plymouth the package would also delete e2fsprogs because of a dependency
[22:22] <jdong_> and how will that help him see messages that otherwise plymouth is unable to print??
[22:23] <CynthiaG> s/he is testing a bug that is making plymouth unable to print things anyway
[22:23] <CynthiaG> https://bugs.launchpad.net/bugs/593408
[22:24] <CynthiaG> and with fbcon enabled, it's apparently misaligned enough that still nothing is visible, or something
[22:24] <jdong_> well not allowing plymouth to run isn't gonna cause the boot system to print anything either
[22:25] <CynthiaG> *boggles* :)
[22:25] <CynthiaG> I wonder what that person wants to achieve now
[22:26] <un214> well chmod -x /sbin/plymouthd resulted in the boot feedback showing up again
[22:27] <CynthiaG> In a console?
[22:27] <CynthiaG> Er. Text console.
[22:27] <un214> yup, right on tty1
[22:27] <jdong_> I was unaware of such a fallback except for init scripts
[22:27] <CynthiaG> So that's what you wanted to achieve.
[22:27] <un214> not quite
[22:27] <jdong_> stuff like mountall IIRC directly called plymouth APIs to output
[22:28] <un214> I've got to go find the options being used to call fsck and change them
[22:28] <psusi> CynthiaG, sounds about right... that's why I've been working on using defrag to pack all that data in order at the start of the disk so it gets pulled in faster ;)
[22:28] <CynthiaG> psusi: So e2defrag is also a boot-sequence optimiser?
[22:28] <jdong_> CynthiaG: psusi is combining it with ureadahead to make it such :)
[22:28] <psusi> if you don't want a gui boot console, just pass "text" on the kernel command line and it will remain in 25 line mode
[22:29] <CynthiaG> Oho! That sounds awesome
[22:29] <un214> jdong: looks like I get to go break mountall then
[22:29] <un214> I'll bet he's the one calling fsck anyway
[22:29] <jdong_> or probably just find the 9.04 version anyway :)
[22:29] <psusi> CynthiaG, not exactly... but you can give it a list of files that should be given priority when packing... such as a list pulled from the ureadahead pack file ;)
[22:29] <un214> psusi: tried that doesn't work
[22:30] <CynthiaG> psusi: Sounds even more awesome :D
[22:42] <un214> ugh goodbye mountall
[22:43] <un214> replacing it with fsck -a && mount -a
[22:43] <psusi> you mean fsck -p
[22:43] <un214> no actually I mean fsck -A
[22:44] <psusi> boot time fsck is run in prone mode... not to mention that the rest of the system won't boot without mountall
[22:44] <psusi> s/prone/prune
[22:44] <un214> preen
[22:44] <psusi> err, yea, that one ;)
[22:44] <psusi> shit... I'm getting old.
[22:44] <un214> you want to fix mountall to not depend on plymouth?
[22:45] <psusi> no
[22:45] <un214> remember, plymouth is broken for me
[22:46] <psusi> you should probably fix it then
[22:47] <un214> can't determine why its broken
[22:47]  * psusi watches defrag do its thing
[22:50] <lifeless>  \o/
[22:57] <un214> anyway reading the plymouth source made the problem obvious
[22:58] <un214> /bin/plymouth was damaged
[23:00] <un214> I'm still probably gonna make a mountall-noplymouth as this thing's bloody stupid
[23:05] <psusi> cjwatson, have you seen my e2fsck patch in bug #556621?  Wondering if you had any thoughts on it.
[23:10] <psusi> cjwatson,  also could you possibly help move bug #568050 along by uploading the fix to lucid-proposed?  This was a serious regression that prevents installation for effected users so I'd like to see it make it in for the 10.04.1 respin