[00:02] slangasek: Do you still get lots of CPU usage with pulseaudio under jaunty when playing music, or is this in intrepid where youe xperience CPu load? [00:02] TheMuso: jaunty [00:03] slangasek: Right. What hda codec do you have? [00:04] is 12% for pulseaudio on a 2Ghz C2D when playing music in banshee "lots of CPU usage"? [00:04] Amaranth: Depending on pulse version, probably. [00:04] As far as I'm concerned, showing up in top is 'lots of CPU usage' [00:05] I've got 0.9.14 now and it's only using 4-6% so I dunno [00:05] Amaranth: Again, what hda codec do you have, if you have hda at all [00:05] Then again I'm watching a flash video, not playing music in banshee [00:05] TheMuso: remind me how to find the codec? [00:07] 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) [00:07] Subsystem: Apple Computer Inc. Device 00a1 [00:07] unless there is something else you're looking for? [00:07] slangasek: CHecking with aplay -l, or /proc/asound/card#/codec# I think it is [00:08] ah, *a*sound, right [00:08] so for me its /proc/asound/card0/codec#2 [00:08] TheMuso: Codec: Analog Devices AD1981 [00:08] $ cat /proc/asound/card0/codec#0 [00:08] Codec: Realtek ALC889A [00:08] * Amaranth cries [00:08] I already know I'm boned [00:08] Amaranth: Ok for you the high CPU is understandable, since glitch free doesn't work well if at all for realtek hda codecs, according to upstream. [00:09] slangasek: I need to check the driver broken list to see if analog devices codecs are known to not work with glitch free. [00:14] slangasek, Amaranth, one thing you could try when you have a chance is to edit /etc/pulse/default.pa and add "tsched=0" at the end of the line that loads module-hal-detect. [00:14] This turns off glitch free. [00:14] gah, between pulseaudio and banshee 25% of one of my cores is gone [00:14] slangasek: Your codec is not on the broken list, but this doesn't mean anything unfortunately. [00:15] TheMuso: er, I thought it was asserted last week that upstream's list of devices that didn't work with glitch-free was adequately comprehensive? [00:16] E: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the ALSA developers. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail_update() returned 0. [00:16] I get that about 5 times a second from pulseaudio [00:16] slangasek: It may have been, but I can't remember whether it was myself or someone else who said it, and if I said otherwise then, I certainly change it now, based on whats on the upstream wiki. [00:17] TheMuso: so if we don't know what devices are broken, that makes it hard to implement an appropriate blacklist for jaunty? [00:17] now pulseaudio is down to 2-4% CPU though [00:17] slangasek: Indeed it does. [00:17] Amaranth: After adding that flag? [00:17] yeah [00:17] Right. [00:18] I need to put my realtek codecs through a thorough test with pulseaudio from jaunty and my PPA to see where my cards stand. [00:18] I seem to always get broken hardware [00:18] well, pulse is only at 4% on my system before making this change - but as I said, this is comparable to what the media player itself takes, and the media player has to do real work [00:18] also don't most laptops use realtek codecs? [00:19] For what it's worth, pulseaudio 0.9.15 _still_ underruns at the barest hint of CPU usage on my hda-intel. [00:19] slangasek: what media player is that? obviously not one using gstreamer [00:19] Amaranth: Unfortunately realtek codecs are some of the most common, however I *BELIEVE* its an alsa driver issue. [00:19] Amaranth: er, it is one using gstreamer [00:19] perhaps I have a faster processor than you? [00:19] slangasek: You got a 2.8Ghz Core i7 or something? [00:20] hrm even the login sound has glitches in it for my notebook. [00:20] * TheMuso turns off glitch-free [00:20] Yeah; banshee and pulseaudio trade places at ~2% CPU regularly on this system. [00:20] I find it amusing that glitch-free _causes_ glitches [00:20] Also, banshee and rhythmbox both used 10% CPU on my slower computer as well [00:20] It seems as my CPU speed increases their use of the CPU does as well [00:20] clearly something was lost in translation, and it was meant to be called "free glitches" [00:21] Ok, turning that off helped the login sound, now time to test with rhythmbox and mp3s. [00:21] RAOF: What processor? [00:21] core 2 7400 or some such. [00:21] I'm seriously considering offering Lennart SSH access to a box to help debug this issue on a realtek device. [00:22] Amaranth: 7200 [00:22] RAOF: How about in real terms? 2.4Ghz? 2.2Ghz? :P [00:22] 2.0 GHz. [00:22] Cache matters but not for this [00:23] grr, that's what I have [00:24] Why is my pulseaudio and banshee using 5x as much CPU? [00:25] I've got the T7300 (2.0Ghz) [00:26] With 4MB cache :P [00:27] RAOF: Have you tried turning off glitch free? [00:27] Just have. [00:27] right [00:28] Is pulseaudio really not supposed to show up in top using CPU? [00:28] Adding tsched=0 seems to bump CPU usage up another couple of percent, but on the plus side it hasn't crackled like mad, either. [00:29] Amaranth: who are you asking? *I* consider it unacceptable for a software sound mixer to take up that much processor time... [00:29] I meant typically, not ideally [00:30] I know at one point rhythmbox was using 10% CPU and using pulseaudio made rhythmbox use less but combined with pulseaudio it was still 10% [00:30] But now with banshee it's using more CPU having pulseaudio then not [00:31] Here I have rhythmbox using 5% and pulse using 3% this is with glitch free. No crackling in sound, but not sure about logs. WIll check that in a sec. [00:34] Amaranth: I get the same message re no data to write although pulse was woken up, however I don't get any glitches in audio. However any sound played via canberra with glitch free turned on has glitches in it. [00:34] yep, definitely sounds like he meant "free glitches" [00:38] TheMuso: Are you also using pluse 0.9.15 in your PPA? Do you also find the 'flat volume' thing, or whatever it is that causes app volume changes to influence sink volume (and it seems, often mute it for no discernable reason) somewhat unintuitive? [00:39] RAOF: no still using 0.9.14 here atm, although will upgrade shortly. [00:47] is postgresql [00:47] lighter than mysql [00:49] Wow, pulseaudi 0.9.15~test1 turns on my notebook's digital out. [00:49] And uses that as the default sink. [00:50] This sounds unlikel to be what you want. [00:50] yep [00:50] * TheMuso clears home dir pulse files [00:50] And things work again [00:50] What really scares me with pulse is the fact that home dir files can cause pulse to break when one upgrades from one version to another. [00:52] Mmm. Turning off glitch-free seems to (a) make it stop glitching, and (b) make pulseaudio increadibly chatty about ALSA waking it up. [00:52] great [00:53] * TheMuso does that here to see what happens. [00:53] It appears to be generating that message at a rate of ~100Hz, given what the ratelimit warning is suggesting. [00:53] ouch [00:54] Well except for canberra, I don't get glitches with audio from rhythmbox. Time to try some wav files with aplay etc. [00:57] aplay works ok [01:21] RAOF: How you finding the new volume stuff in pulse? I am finding with rhythmbox it constantly changes volume when I change tracks. [01:21] TheMuso: I find that it seems to mute for no discernable reason. [01:22] Using Banshee it doesn't do anything strange on track change, but when I switch apps strange things happen, which usually results in the sound being muted. [01:22] Also it seems to override the volume-control-applet, which isn't my idea of a good time. [01:23] Oh, and that it'll be muted on startup without fail. [01:24] RAOF: Right, I may not have things set up correctly with configs etc however. [01:24] Pulseaudio IMO is getting more complex, but introducing more problems. I am seriously starting to question whether its worth keeping it around, at least for jaunty+1 and beyond. [01:24] You seem to turn off module-positional-sounds, or whatever, which apparently is broken, so that's right. [01:25] Pulseaudio _desperately_ needs an actual user-visible use-case. [01:25] RAOF: I agree, switching streams between devices is not common enough for users to want it yet. [01:26] I disagree. It's just a policy-daemon & UI away from being awesome. [01:26] I don't use pulse, because it introduces too much latency for speech. [01:26] I want to switch streams ALL the time; when I plug in my USB speakers, headset, unplug to move around, ... [01:26] RAOF: But there are so many stability/glitch issues with the underlying infrastructure, that some users would think dealing with alsa's annoyances is better than glitchy sound and fancy stream switching. [01:28] I suppose. But I'd like plugging in USB audio devices to work _properly_, and that's just not going to happen with ALSA, is it? [01:28] But if pulse isn't actually getting _better_ at doing just the sound bit, then... :( [01:29] I guess you can only live on "it'll get better, really" for so long. [01:29] RAOF: No, I agree, the plugging in devices etc is neat. [01:30] Anyway, I've offered Lennart ssh access for testing realtek glitch free issues so we will see what comes out of that. [01:32] * TheMuso is seeing lots of debian changelogs with git hashes in them, and IMO it looks ugly. [01:33] * RAOF thinks git could do with growing real revnos [01:33] I don't mind git hashes, but not parts of them in debian changelogs. [01:41] But revnos are somewhat incompatible with git's love of rewriting history [01:42] One should never rewrite history that has already been pushed. [01:43] is THAT what Git does? [01:44] I've been wondering why shortlog dates on git.kernel.org seem to jump back and forth; and I blamed it on my lack of sleep [01:44] Sure, if you add --force everywhere. :-P [01:45] As good an idea as using --force with any other program with an equivalent parameter. [01:45] * jdong will award one McDonald's chocolate chip cookie for the first person to invent the GUIID (The Globally Unique [strictly] Increasing Identifier) [01:45] you guys laugh now, but in 50 years I will be one cookie poorer :) [01:46] lool, ping. it looks like your debian maintainer of gnome-python-desktop. bug 223671 needs to get fixed now, but i would like to make sure that it's fixed in a way that you as debian maintainer can agree upon [01:46] Launchpad bug 223671 in ubiquity "wnck and rsvg should be provided in seperate packages not requiring gnome" [Undecided,New] https://launchpad.net/bugs/223671 [01:46] Simple. Just setup an official server with a simple protocol to request a new number. :-P [01:47] * jdong quickly trademarks Ubuntu LIVE (TM) Number (sm) [01:49] * bryce reserves GUIID 42 [01:52] heya TeTeT [01:53] hi bryce [02:01] jdong: nc heh.fi 56888 [02:02] ion_: lol can I have that code so I can run another one? [02:03] [02:03] ;-) [02:13] * jdong looks up and sees a fellow Linerva resident === mthaddon_ is now known as mthaddon [03:23] superm1, ping [03:35] mdomsch, contentless pong [03:36] hehe [03:36] xps m1330 headphone volume sucks [03:36] solution known? [03:37] mdomsch, not until IDT's equalizer support enters ALSA [03:37] boo [03:37] a lot of codecs are intentionally set lower than they can actually drive [03:38] yeah, but I can't even hear the audio with noise-canceling headphones on [03:38] i wasn't aware the 1330 was part of them, but it's not a surprise. if you drive it any higher, you'll hit some resonant frequencies [03:38] on the chasis [03:38] oh wait you said headphone volume. no this i wasnt aware of [03:39] make sure you are turning up "front" all the way? [03:39] as well as PCM and master and what not [03:39] mplayer -af volume=20 [03:39] is the only thing that helps [03:39] yeah [03:39] all lines maxed [03:40] perhaps your headphone jack is being detected as a line out rather than a HP [03:40] i've been seeing that on another platform. do both headphone jacks do this? [03:40] there are 3 jacks - only one (the one labeled microphone) outputs any audio at all [03:41] regardless of the 'line in as output' setting [03:41] so I think I"m getting "line out" levels instead of headphone levels [03:41] what kernel is this? [03:41] fedora 10 2.6.27.x [03:41] (my ubuntu load is horked, not your problem...) [03:42] can you double check with a git snapshot of alsa? if the problem persists, i can try to help out more tomorrow [03:42] I can't tonight, but no worry or rush - I just thought you might know already [03:42] I'm OoO rest of the week [03:42] rain! :-) [03:43] superm1, have a good week [03:43] yikes yeah!, time to get off the patio. well let me know if it persists with a snapshot when you get a chance and we'll go from there [03:44] and hail! [04:47] jpds: hmm intersting. i never knew there was such a thing as memoserv [04:48] jpds: it's fine =p i was just curious where you got it from. [05:44] slangasek, can you re-enable the daily cron job on mythbuntu disks? the alpha4 disks are not going to happen, but would like to be able to see that a few of the fixes for the problems at what would have been a4 are getting fixed still [05:46] good morning [05:47] morning ? already ? I should really go to bed then :) [05:48] man [05:48] it seems like dholbach's mornings keep getting earlier and earlier [05:49] yeah, it's not even 7am in europe :) [05:49] LaserJock: no no - I was up earlier yesterday :) === a|wen- is now known as a|wen [06:56] anybody here happen to know SQL? [06:57] LaserJock: just ask your question, lots of people here probably know SQL [07:00] I've got a postinst that's failing like: Failed to execute SQL: GRANT ALL PRIVILEGES ON moodle.* TO www-data@localhost IDENTIFIED BY [07:01] it seems to not like having a "-" i.e. www-data [07:01] is that a common problem? [07:02] you need to quote it, I suspect. [07:02] and you should create your own db user and use that instead of a shared one. [07:03] yeah, well, i didn't pick that [07:03] but the quoting I could maybe fix [07:17] Good morning [07:18] no it isn't. my new pc STILL isn't working [07:20] directhex: I have tried pitti/debian/patches/nosleep.patch for a while, but after some time the system became really unstable, so I reverted it [07:20] * StevenK waves to pitti [07:20] * pitti hugs StevenK [07:53] superm1: Until now we have been reluctant on the Debian side to split up modules as we don't have a mean to map modules to packages in our packaging arsenal [07:54] superm1: I don't really know how you could find a way to avoid splitting, or it would be complex just to please Debian === freeflyi1g is now known as freeflying [08:34] hey, I'm not sure if this is the correct place to ask, but asking the developer channel seems right [08:34] how come libdvdcss isn't included in restricted? I'm sure many people prefer VLC over mplayer [08:35] (or whatever totem is based off of) [08:36] it is not legal to distribute them in some parts of the world that are considered important to Ubuntu, unfortunately [08:36] oh [08:36] that sounds....quite reasonable actually [08:36] well luckily videolan maintains a /deb directory [08:36] I think the legal restrictions are incredibly unreasonable :) [08:36] well thank you, /parting now === apw`` is now known as apw [09:10] Keybuk: hello [09:11] Keybuk: got a minute to discuss some questions about readahead and bootspeed? [09:22] seb128: got my current bootcharts at http://people.ubuntu.com/~pitti/tmp/, BTW [09:22] hey pitti [09:22] seb128: I recreated /etc/readahead/boot to include the full desktop [09:23] and that dropped gdm->desktop from 35 to 18 seconds [09:23] with only adding about 1.5 to the grub->gdm time [09:24] that's good [09:24] is that on your laptop? [09:24] seb128: yes [09:24] seb128: I'm running vesa and metacity now, though [09:24] 18 seconds on a slow disk is good [09:24] (-intel is broken ATM) [09:25] seb128: it's not quite the 8 seconds I get on a hot cache (second login), but much better [09:25] gdm is taking a lot of time [09:25] seb128: be aware that this is not autologin [09:25] gdmgreeter to gnome-session is over 15 seconds on your chart [09:25] so there's a period of low cpu and I/O when I log in [09:25] so the two are neatly separated [09:26] ok, I guess the 3 seconds blue gdm bar is you typing your password [09:26] the 6 seconds between aplay and the gdm fork is the entering password time [09:27] that makes sense [09:27] hm, or that [09:27] there is not a lot of easy desktop targets now looking at the chart [09:27] I deliberately waited a couple of seconds to let everything else settle [09:28] seb128: you are looking on the -gnome or -default one? [09:28] default [09:28] the gnome one is cheating ;-) [09:28] well, "optimizing" :) [09:28] but yes, desktop startup is pretty tight now [09:29] well not something users will get [09:29] I wish we wouldn't need this seahorse thing [09:29] seb128: that's something I want to discuss with Keybuk (extend the readahead lists) [09:29] pitti: did you notice seahorse-daemon is not started now? [09:29] and we should get rid of this cpp and cc1 [09:29] pitti: you don't want the agent either? [09:29] seb128: right, daemon doesn't start [09:30] seb128: well, of course I'd like to keep the functionality [09:30] just unqualified wishful thinking :) [09:30] we need dbus activation on signals [09:30] it should get d-bus activated or so [09:30] well, neither gpg nor ssh support d-bus, they just check an env variable, don't they? [09:31] $GPG_AGENT_INFO and $SSH_AUTH_SOCK [09:31] right [09:31] SSH is gnome-keyring [09:31] I'm wondering if we need a gpg agent by default [09:31] or if that should be conditional on a gconf key too or something [09:31] I was just going to ask [09:32] seb128: at least we could convert it to an xdg autostart instead of an Xsession.d/ script [09:32] then it can start later, and in parallel [09:32] ah, no [09:33] there is no xsession script for this one [09:33] it needs to set that silly env var for all processes [09:34] there is also a gdmprefetch taking 1.6 seconds in your chart that we should comment [09:34] I think Keybuk said that was useless [09:35] martin 3975 0.0 0.6 19716 6536 ? Ss 10:16 0:00 /usr/bin/seahorse-agent --execute x-session-manager [09:36] hm, but that looks like an Xsession.d script... [09:36] /etc/X11/Xsession.d/60seahorse-plugins [09:39] do we install that by default? [09:39] or is that something you added? [09:40] it's a recommends so it's installed [09:41] oh, what's that apport thing doing there... [09:41] I've not it installed on this box ;-) [09:41] dunno [09:41] ah, it indeed caught a crash [09:41] I noticed apport on my charts too [09:41] it's tiny on the -gnome chart (no crash there) [09:41] but that's around the time where the desktop is loaded so that's not an issue [09:41] it's from update-notifier, I guess [09:42] we can probably delay evolution-alarm-notify too [09:42] seb128: seahorse Recommends: seahorse-plugins [09:42] I'm going to use this sleep workaround too I think ;-) [09:42] good idea [09:42] and isn't seahorse-plugins what provides the gpg agent? [09:43] that's it indeed [09:43] seb128: e-a-n isn't taking much resources, though [09:44] pitti: 18s? that is pretty impressive :) [09:44] it creates activity for aorund 3 seconds on your chart [09:44] seb128: oh, right, was looking at the readahead'ed one [09:45] Do I need to put something on my kernel command line to activate bootchart? [09:45] mvo: gdm to session, not grub to session :) [09:45] and trigger the e-d-s start I think which takes some 9-10 seconds [09:45] soren: no, just install it [09:45] soren: I removed /etc/rc2.d/S99stop-bootchart, so that I can run it until after GNOME started [09:45] oh, misread :) still a good improvement [09:45] seb128: is e-d-s really triggered by e-a-n, or rather by the panel? [09:45] hmm, gdm does not seem to allow one to configure automatic login to a specific user, but with the screen locked immediately [09:45] soren: Just restart and there should be a png in /var/log/bootchart/ . [09:45] seb128: or does the panel only start e-d-s once you try to open the calendar? [09:46] jpds, pitti: that's what I thought, but it didn't happen. Odd. [09:46] soren: hang on [09:46] soren: for me, it crashed with an exception [09:46] I had to do a "sudo ln -s headless xawt" to make it find a library [09:47] ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so is shipped by the package [09:47] but bootchart looks in ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/xawt/libmawt.so [09:47] it probably needs a rebuild, or so [09:48] pitti: I've got /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/xawt/libmawt.so [09:48] soren: well, kill the rc2.d symlink and start /etc/init.d/stop-bootchart by hand after login, then you should see [09:48] pitti: I need to check, I'm not sure [09:48] pitti: It's supposed to collect data in /var/run/bootchart, correct? [09:49] pitti: the clock applet should try to use it only when you click on it to display the calendar [09:49] "should" [09:49] seb128: I'll test it; I disable e-a-n and see when e-d-s gets started [09:49] ok [09:49] soren: not run, log [09:49] soren: yes, but moves them to /var/log/bootchart.tgz or os [09:49] s/os/so/ [09:50] Oh. I thought it collected data in /var/run and then turned that into a png in /var/log [09:50] soren: right [09:50] soren: I though you were asking where to look for the charts [09:51] seb128: I was at first :) [09:51] ..but since that failed.. :) [09:51] seb128: confirmed, that works [09:51] seb128: move e-d-s autostart .desktop -> ps ux|grep evo is empty [09:51] pitti: ;-) [09:52] seb128: so if we delay that by, say, 30 seconds, then it should be all good [09:52] pitti: btw no need to move the rc script, you can use "bootchart=nostop" as a boot option [09:52] seb128: nostop> nice, didn't know that [09:52] I learned that from Keybuk some days ago ;-) [09:52] pitti: right [09:53] seb128: want me to upload, or do you want to? [09:53] pitti: you can do it if you want [09:54] * soren reboots to figure out why bootchart isn't doing its thing. [09:54] doing then, and then I'll see how much it helped [09:54] ok [09:58] * mrooney waves to pitti and seb, and goes to sleep :) [09:58] 'night mrooney [10:00] I think there is a bug in bzr which prevents it from passing through proxy... How can I download the source code of bazaar then? [10:01] bye mrooney [10:01] seb128: hm, buys some 2 seconds [10:01] pitti: that's good to take ;-) [10:07] Well, I've figured out why bootchart doesn't run on my box... I don't get, though, why it only happens for me. [10:08] why doesn't it work for you? [10:08] seb128: uploaded [10:08] The bootchart init script in initrams runs with set -e. At some point, it tries to copy /lib/ld-linux.so.* into a jail. [10:08] * seb128 hugs pitti [10:08] * pitti hugs back seb128 [10:08] I don't have /lib/ld-linux.so.* in my initrams, so the script bails out at that point, which is before it gets around to starting bootchart. [10:09] Now, why this doesn't happen for you guys is beyond me. [10:09] Do you have /lib/ld-linux.so.* in your initramfs? [10:10] And if you do, do you have any idea how it got there? [10:10] soren: there is an init script so it doesn't need to be ran in initramfs no? [10:10] $ zcat /boot/initrd.img-2.6.28-7-generic |cpio -t|grep ld-linux.so [10:10] lib/ld-linux.so.2 [10:10] ^ i386 [10:11] Oh, both of you are on i386? [10:11] yes [10:11] yes [10:11] * pitti puts a no-change rebuild of bootchart into his ppa, to see whether it fixes the library path problem [10:11] seb128: The init script (outside initramfs) bails out if some of the right directories are tere. [10:11] there. [10:11] maybe that'll magically fix things for you as well :) [10:12] ...which they are, becuase the init script in the initramfs creates those before failing here. [10:12] pitti: I doubt it. [10:13] * soren patches bootchart.. [10:14] certainly the amd64 dynamic linker has a different name [10:15] Indeed. [10:15] I don't see how it could work at all on amd64. [10:15] Ah, it doesn't :) [10:15] though I'm not seeing the bug you refer to here [10:15] but 32778. [10:15] but 327778. [10:15] cjwatson: No? Do you have /lib/ld-linux.so.* for some other reason in your initramfs? [10:16] bug 327778 [10:16] Launchpad bug 327778 in bootchart "bootchart not working on AMD64" [Undecided,New] https://launchpad.net/bugs/327778 [10:16] oh, I'm out of date [10:16] Wow, spelling is hard. :) [10:16] * soren fixes it. [10:16] soren: I meant in the source code. I run i386. But never mind, I just needed to upgrade [10:16] yay, -intel magically fixed itself again [10:16] with today's dist-upgrade [10:16] x and compiz are happy again [10:17] bryce, tjaalton: ^ [10:17] cjwatson: Ah, ok. [10:17] (I noticed the usplash reversion, and maybe that indeed was it for me as well) [10:17] I'm 100% sure I tested it without usplash, too, though; well, *shrug* [10:17] * soren reboots to check his fix === thekorn_ is now known as thekorn [10:22] pitti: magic, and no updated X packages :) [10:37] tjaalton: well, the breakage was equally magic, after all :) [10:47] pitti, without any hacks like .drirc etc ? [10:50] * soren just pushed a new bootchart [10:51] pitti: If you'd be so kind to check that I didn't break i386, that would be lovely. [11:12] ogra: no [11:12] soren: sure [11:13] soren: I didn't check my PPA yet, whether the i386 rebuild works now; I'll just check your version then [11:13] * pitti just had to rescue a .tex from his wife [11:13] emacs thought it should write the file encoded in iso-2022-jp2 *grumpf* [12:02] dholbach: looks like gnome-reset is unmaintained upstream, and broken in jaunty. maybe it should be removed frome the archive? [12:02] no new upstream releases in three years [12:08] Keybuk: WDYT about extending the default bootchart lists to cover the entire GNOME startup as well? it dramatically improves the gdm->session ready time (35 -> 18 s), while only increasing grub->gdm by 1.5 s [12:11] pitti: Bootchart improves gdm->session ready time? [12:13] erm, s/bootchart/readahead/ === sommer_ is now known as sommer [12:21] Oh. [12:25] pitti: It depends on how much RAM you have, doesn't it? If readahead naïvely goes through the list trying loading stuff into ram, you might be discarding some of the earlier boot things once you start filling your cache with GNOME. I haven't looked at the readahead implementation, though. It might do something clever to avoid this. [12:26] soren: right, if you have less RAM that you need to keep the boot and gnome in ram, you'd get taht [12:26] that [12:26] soren: but for that reason readahead has two stages (boot and desktop) [12:26] Ah, I see. [12:28] Still, whatever we put in the readahead list should fit in amount of RAM we put as recommended for a desktop install. [12:31] * pitti nods [12:33] * directhex steals all pitti's "#" characters & hides them [12:34] o_O [12:34] directhex: oh, I see :) [12:34] directhex: better *use* them :) [12:34] pitti, well i have a bunch spare now... [12:35] pitti, i get confused by debian vs ubuntu bug closing format, so go for a nice happy medium of "works in neither" [12:35] \o/ [12:35] directhex: but # is required in both... [12:35] i just suck then [12:36] doko: do all sun-java plugin filenames have the same name? [12:36] i mean the .so [12:37] anyone uses ppp manually here (e.g. pppoe or wvdial)? [12:37] geser, evand: nice race on attacking the sponsoring queue :) [12:38] pitti: Thanks for the gdata upload. I'll test the plugins later on. [12:39] asac: Riddell said that I should check with you about some MIRs pending for Jaunty. Are you the right person or should I contact somebody else? [12:40] asac: bug 324523 and bug 325858 [12:40] Launchpad bug 324523 in opencv "Main inclusion request for OpenCV" [Medium,New] https://launchpad.net/bugs/324523 [12:40] Launchpad bug 325858 in lensfun "Main inclusion request for lensfun" [Medium,New] https://launchpad.net/bugs/325858 [12:41] asac: why do you ask? [12:41]