[00:02] <TheMuso> 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] <slangasek> TheMuso: jaunty
[00:03] <TheMuso> slangasek: Right. What hda codec do you have?
[00:04] <Amaranth> is 12% for pulseaudio on a 2Ghz C2D when playing music in banshee "lots of CPU usage"?
[00:04] <TheMuso> Amaranth: Depending on pulse version, probably.
[00:04] <slangasek> As far as I'm concerned, showing up in top is 'lots of CPU usage'
[00:05] <Amaranth> I've got 0.9.14 now and it's only using 4-6% so I dunno
[00:05] <TheMuso> Amaranth: Again, what hda codec do you have, if you have hda at all
[00:05] <Amaranth> Then again I'm watching a flash video, not playing music in banshee
[00:05] <slangasek> TheMuso: remind me how to find the codec?
[00:07] <Amaranth> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
[00:07] <Amaranth> 	Subsystem: Apple Computer Inc. Device 00a1
[00:07] <Amaranth> unless there is something else you're looking for?
[00:07] <TheMuso> slangasek: CHecking with aplay -l, or /proc/asound/card#/codec# I think it is
[00:08] <slangasek> ah, *a*sound, right
[00:08] <TheMuso> so for me its /proc/asound/card0/codec#2
[00:08] <slangasek> TheMuso: Codec: Analog Devices AD1981
[00:08] <Amaranth> $ cat /proc/asound/card0/codec#0
[00:08] <Amaranth> Codec: Realtek ALC889A
[00:08]  * Amaranth cries
[00:08] <Amaranth> I already know I'm boned
[00:08] <TheMuso> 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] <TheMuso> 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] <TheMuso> 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] <TheMuso> This turns off glitch free.
[00:14] <Amaranth> gah, between pulseaudio and banshee 25% of one of my cores is gone
[00:14] <TheMuso> slangasek: Your codec is not on the broken list, but this doesn't mean anything unfortunately.
[00:15] <slangasek> 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] <Amaranth> 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] <Amaranth> I get that about 5 times a second from pulseaudio
[00:16] <TheMuso> 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] <slangasek> TheMuso: so if we don't know what devices are broken, that makes it hard to implement an appropriate blacklist for jaunty?
[00:17] <Amaranth> now pulseaudio is down to 2-4% CPU though
[00:17] <TheMuso> slangasek: Indeed it does.
[00:17] <TheMuso> Amaranth: After adding that flag?
[00:17] <Amaranth> yeah
[00:17] <TheMuso> Right.
[00:18] <TheMuso> 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] <Amaranth> I seem to always get broken hardware
[00:18] <slangasek> 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] <Amaranth> also don't most laptops use realtek codecs?
[00:19] <RAOF> For what it's worth, pulseaudio 0.9.15 _still_ underruns at the barest hint of CPU usage on my hda-intel.
[00:19] <Amaranth> slangasek: what media player is that? obviously not one using gstreamer
[00:19] <TheMuso> Amaranth: Unfortunately realtek codecs are some of the most common, however I *BELIEVE* its an alsa driver issue.
[00:19] <slangasek> Amaranth: er, it is one using gstreamer
[00:19] <slangasek> perhaps I have a faster processor than you?
[00:19] <Amaranth> slangasek: You got a 2.8Ghz Core i7 or something?
[00:20] <TheMuso> hrm even the login sound has glitches in it for my notebook.
[00:20]  * TheMuso turns off glitch-free
[00:20] <RAOF> Yeah; banshee and pulseaudio trade places at ~2% CPU regularly on this system.
[00:20] <Amaranth> I find it amusing that glitch-free _causes_ glitches
[00:20] <Amaranth> Also, banshee and rhythmbox both used 10% CPU on my slower computer as well
[00:20] <Amaranth> It seems as my CPU speed increases their use of the CPU does as well
[00:20] <slangasek> clearly something was lost in translation, and it was meant to be called "free glitches"
[00:21] <TheMuso> Ok, turning that off helped the login sound, now time to test with rhythmbox and mp3s.
[00:21] <Amaranth> RAOF: What processor?
[00:21] <RAOF> core 2 7400 or some such.
[00:21] <TheMuso> I'm seriously considering offering Lennart SSH access to a box to help debug this issue on a realtek device.
[00:22] <RAOF> Amaranth: 7200
[00:22] <Amaranth> RAOF: How about in real terms? 2.4Ghz? 2.2Ghz? :P
[00:22] <RAOF> 2.0 GHz.
[00:22] <Amaranth> Cache matters but not for this
[00:23] <Amaranth> grr, that's what I have
[00:24] <Amaranth> Why is my pulseaudio and banshee using 5x as much CPU?
[00:25] <Amaranth> I've got the T7300 (2.0Ghz)
[00:26] <RAOF> With 4MB cache :P
[00:27] <TheMuso> RAOF: Have you tried turning off glitch free?
[00:27] <RAOF> Just have.
[00:27] <TheMuso> right
[00:28] <Amaranth> Is pulseaudio really not supposed to show up in top using CPU?
[00:28] <RAOF> 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] <slangasek> Amaranth: who are you asking?  *I* consider it unacceptable for a software sound mixer to take up that much processor time...
[00:29] <Amaranth> I meant typically, not ideally
[00:30] <Amaranth> 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] <Amaranth> But now with banshee it's using more CPU having pulseaudio then not
[00:31] <TheMuso> 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] <TheMuso> 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] <Amaranth> yep, definitely sounds like he meant "free glitches"
[00:38] <RAOF> 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] <TheMuso> RAOF: no still using 0.9.14 here atm, although will upgrade shortly.
[00:47] <LaserJock> is postgresql
[00:47] <LaserJock> lighter than mysql
[00:49] <TheMuso> Wow, pulseaudi 0.9.15~test1 turns on my notebook's digital out.
[00:49] <TheMuso> And uses that as the default sink.
[00:50] <RAOF> This sounds unlikel to be what you want.
[00:50] <TheMuso> yep
[00:50]  * TheMuso clears home dir pulse files
[00:50] <TheMuso> And things work again
[00:50] <TheMuso> 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] <RAOF> 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] <TheMuso> great
[00:53]  * TheMuso does that here to see what happens.
[00:53] <RAOF> It appears to be generating that message at a rate of ~100Hz, given what the ratelimit warning is suggesting.
[00:53] <TheMuso> ouch
[00:54] <TheMuso> Well except for canberra, I don't get glitches with audio from rhythmbox. Time to try some wav files with aplay etc.
[00:57] <TheMuso> aplay works ok
[01:21] <TheMuso> 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] <RAOF> TheMuso: I find that it seems to mute for no discernable reason.
[01:22] <RAOF> 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] <RAOF> Also it seems to override the volume-control-applet, which isn't my idea of a good time.
[01:23] <RAOF> Oh, and that it'll be muted on startup without fail.
[01:24] <TheMuso> RAOF: Right, I may not have things set up correctly with configs etc however.
[01:24] <TheMuso> 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] <RAOF> You seem to turn off module-positional-sounds, or whatever, which apparently is broken, so that's right.
[01:25] <RAOF> Pulseaudio _desperately_ needs an actual user-visible use-case.
[01:25] <TheMuso> RAOF: I agree, switching streams between devices is not common enough for users to want it yet.
[01:26] <RAOF> I disagree.  It's just a policy-daemon & UI away from being awesome.
[01:26] <TheMuso> I don't use pulse, because it introduces too much latency for speech.
[01:26] <RAOF> I want to switch streams ALL the time; when I plug in my USB speakers, headset, unplug to move around, ...
[01:26] <TheMuso> 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] <RAOF> 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] <RAOF> But if pulse isn't actually getting _better_ at doing just the sound bit, then... :(
[01:29] <RAOF> I guess you can only live on "it'll get better, really" for so long.
[01:29] <TheMuso> RAOF: No, I agree, the plugging in devices etc is neat.
[01:30] <TheMuso> 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] <TheMuso> I don't mind git hashes, but not parts of them in debian changelogs.
[01:41] <maxb> But revnos are somewhat incompatible with git's love of rewriting history
[01:42] <ion_> One should never rewrite history that has already been pushed.
[01:43] <jdong> is THAT what Git does?
[01:44] <jdong> 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] <ion_> Sure, if you add --force everywhere. :-P
[01:45] <ion_> 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] <jdong> you guys laugh now, but in 50 years I will be one cookie poorer :)
[01:46] <superm1> 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] <ion_> 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] <bryce> heya TeTeT
[01:53] <TeTeT> hi bryce
[02:01] <ion_> jdong: nc heh.fi 56888
[02:02] <jdong> ion_: lol can I have that code so I can run another one?

[02:03] <ion_> ;-)
[02:13]  * jdong looks up and sees a fellow Linerva resident
[03:23] <mdomsch> superm1, ping
[03:35] <superm1> mdomsch, contentless pong
[03:36] <mdomsch> hehe
[03:36] <mdomsch> xps m1330 headphone volume sucks
[03:36] <mdomsch> solution known?
[03:37] <superm1> mdomsch, not until IDT's equalizer support enters ALSA
[03:37] <mdomsch> boo
[03:37] <superm1> a lot of codecs are intentionally set lower than they can actually drive
[03:38] <mdomsch> yeah, but I can't even hear the audio with noise-canceling headphones on
[03:38] <superm1> 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] <superm1> on the chasis
[03:38] <superm1> oh wait you said headphone volume. no this i wasnt aware of
[03:39] <superm1> make sure you are turning up "front" all the way?
[03:39] <superm1> as well as PCM and master and what not
[03:39] <mdomsch> mplayer -af volume=20
[03:39] <mdomsch> is the only thing that helps
[03:39] <mdomsch> yeah
[03:39] <mdomsch> all lines maxed
[03:40] <superm1> perhaps your headphone jack is being detected as a line out rather than a HP
[03:40] <superm1> i've been seeing that on another platform. do both headphone jacks do this?
[03:40] <mdomsch> there are 3 jacks - only one (the one labeled microphone) outputs any audio at all
[03:41] <mdomsch> regardless of the 'line in as output' setting
[03:41] <mdomsch> so I think I"m getting "line out" levels instead of headphone levels
[03:41] <superm1> what kernel is this?
[03:41] <mdomsch> fedora 10 2.6.27.x
[03:41] <mdomsch> (my ubuntu load is horked, not your problem...)
[03:42] <superm1> can you double check with a git snapshot of alsa?  if the problem persists, i can try to help out more tomorrow
[03:42] <mdomsch> I can't tonight, but no worry or rush - I just thought you might know already
[03:42] <mdomsch> I'm OoO rest of the week
[03:42] <mdomsch> rain! :-)
[03:43] <mdomsch> superm1, have a good week
[03:43] <superm1> 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] <mdomsch> and hail!
[04:47] <hyperair> jpds: hmm intersting. i never knew there was such a thing as memoserv
[04:48] <hyperair> jpds: it's fine =p i was just curious where you got it from.
[05:44] <superm1> 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] <dholbach> good morning
[05:47] <stgraber> morning ? already ? I should really go to bed then :)
[05:48] <LaserJock> man
[05:48] <LaserJock> it seems like dholbach's mornings keep getting earlier and earlier
[05:49] <stgraber> yeah, it's not even 7am in europe :)
[05:49] <dholbach> LaserJock: no no - I was up earlier yesterday :)
[06:56] <LaserJock> anybody here happen to know SQL?
[06:57] <Mithrandir> LaserJock: just ask your question, lots of people here probably know SQL
[07:00] <LaserJock> 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] <LaserJock> it seems to not like having a "-" i.e. www-data
[07:01] <LaserJock> is that a common problem?
[07:02] <Mithrandir> you need to quote it, I suspect.
[07:02] <Mithrandir> and you should create your own db user and use that instead of a shared one.
[07:03] <LaserJock> yeah, well, i didn't pick that
[07:03] <LaserJock> but the quoting I could maybe fix
[07:17] <pitti> Good morning
[07:18] <directhex> no it isn't. my new pc STILL isn't working
[07:20] <pitti> 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] <lool> 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] <lool> superm1: I don't really know how you could find a way to avoid splitting, or it would be complex just to please Debian
[08:34] <atari2600a> hey, I'm not sure if this is the correct place to ask, but asking the developer channel seems right
[08:34] <atari2600a> how come libdvdcss isn't included in restricted?  I'm sure many people prefer VLC over mplayer
[08:35] <atari2600a> (or whatever totem is based off of)
[08:36] <liw> it is not legal to distribute them in some parts of the world that are considered important to Ubuntu, unfortunately
[08:36] <atari2600a> oh
[08:36] <atari2600a> that sounds....quite reasonable actually
[08:36] <atari2600a> well luckily videolan maintains a /deb directory
[08:36] <liw> I think the legal restrictions are incredibly unreasonable :)
[08:36] <atari2600a> well thank you, /parting now
[09:10] <pitti> Keybuk: hello
[09:11] <pitti> Keybuk: got a minute to discuss some questions about readahead and bootspeed?
[09:22] <pitti> seb128: got my current bootcharts at http://people.ubuntu.com/~pitti/tmp/, BTW
[09:22] <seb128> hey pitti
[09:22] <pitti> seb128: I recreated /etc/readahead/boot to include the full desktop
[09:23] <pitti> and that dropped gdm->desktop from 35 to 18 seconds
[09:23] <pitti> with only adding about 1.5 to the grub->gdm time
[09:24] <seb128> that's good
[09:24] <seb128> is that on your laptop?
[09:24] <pitti> seb128: yes
[09:24] <pitti> seb128: I'm running vesa and metacity now, though
[09:24] <seb128> 18 seconds on a slow disk is good
[09:24] <pitti> (-intel is broken ATM)
[09:25] <pitti> seb128: it's not quite the 8 seconds I get on a hot cache (second login), but much better
[09:25] <seb128> gdm is taking a lot of time
[09:25] <pitti> seb128: be aware that this is not autologin
[09:25] <seb128> gdmgreeter to gnome-session is over 15 seconds on your chart
[09:25] <pitti> so there's a period of low cpu and I/O when I log in
[09:25] <pitti> so the two are neatly separated
[09:26] <seb128> ok, I guess the 3 seconds blue gdm bar is you typing your password
[09:26] <pitti> the 6 seconds between aplay and the gdm fork is the entering password time
[09:27] <seb128> that makes sense
[09:27] <pitti> hm, or that
[09:27] <seb128> there is not a lot of easy desktop targets now looking at the chart
[09:27] <pitti> I deliberately waited a couple of seconds to let everything else settle
[09:28] <pitti> seb128: you are looking on the -gnome or -default one?
[09:28] <seb128> default
[09:28] <seb128> the gnome one is cheating ;-)
[09:28] <pitti> well, "optimizing" :)
[09:28] <pitti> but yes, desktop startup is pretty tight now
[09:29] <seb128> well not something users will get
[09:29] <pitti> I wish we wouldn't need this seahorse thing
[09:29] <pitti> seb128: that's something I want to discuss with Keybuk (extend the readahead lists)
[09:29] <seb128> pitti: did you notice seahorse-daemon is not started now?
[09:29] <pitti> and we should get rid of this cpp and cc1
[09:29] <seb128> pitti: you don't want the agent either?
[09:29] <pitti> seb128: right, daemon doesn't start
[09:30] <pitti> seb128: well, of course I'd like to keep the functionality
[09:30] <pitti> just unqualified wishful thinking :)
[09:30] <seb128> we need dbus activation on signals
[09:30] <pitti> it should get d-bus activated or so
[09:30] <pitti> well, neither gpg nor ssh support d-bus, they just check an env variable, don't they?
[09:31] <pitti> $GPG_AGENT_INFO and $SSH_AUTH_SOCK
[09:31] <seb128> right
[09:31] <seb128> SSH is gnome-keyring
[09:31] <seb128> I'm wondering if we need a gpg agent by default
[09:31] <seb128> or if that should be conditional on a gconf key too or something
[09:31] <pitti> I was just going to ask
[09:32] <pitti> seb128: at least we could convert it to an xdg autostart instead of an Xsession.d/ script
[09:32] <pitti> then it can start later, and in parallel
[09:32] <pitti> ah, no
[09:33] <seb128> there is no xsession script for this one
[09:33] <pitti> it needs to set that silly env var for all processes
[09:34] <seb128> there is also a gdmprefetch taking 1.6 seconds in your chart that we should comment
[09:34] <seb128> I think Keybuk said that was useless
[09:35] <pitti> martin    3975  0.0  0.6  19716  6536 ?        Ss   10:16   0:00 /usr/bin/seahorse-agent --execute x-session-manager
[09:36] <pitti> hm, but that looks like an Xsession.d script...
[09:36] <pitti> /etc/X11/Xsession.d/60seahorse-plugins
[09:39] <seb128> do we install that by default?
[09:39] <seb128> or is that something you added?
[09:40] <seb128> it's a recommends so it's installed
[09:41] <pitti> oh, what's that apport thing doing there...
[09:41] <seb128> I've not it installed on this box ;-)
[09:41] <seb128> dunno
[09:41] <pitti> ah, it indeed caught a crash
[09:41] <seb128> I noticed apport on my charts too
[09:41] <pitti> it's tiny on the -gnome chart (no crash there)
[09:41] <seb128> but that's around the time where the desktop is loaded so that's not an issue
[09:41] <pitti> it's from update-notifier, I guess
[09:42] <seb128> we can probably delay evolution-alarm-notify too
[09:42] <pitti> seb128: seahorse Recommends: seahorse-plugins
[09:42] <seb128> I'm going to use this sleep workaround too I think ;-)
[09:42] <pitti> good idea
[09:42] <pitti> and isn't seahorse-plugins what provides the gpg agent?
[09:43] <seb128> that's it indeed
[09:43] <pitti> seb128: e-a-n isn't taking much resources, though
[09:44] <mvo> pitti: 18s? that is pretty impressive :)
[09:44] <seb128> it creates activity for aorund 3 seconds on your chart
[09:44] <pitti> seb128: oh, right, was looking at the readahead'ed one
[09:45] <soren> Do I need to put something on my kernel command line to activate bootchart?
[09:45] <pitti> mvo: gdm to session, not grub to session :)
[09:45] <seb128> and trigger the e-d-s start I think which takes some 9-10 seconds
[09:45] <pitti> soren: no, just install it
[09:45] <pitti> soren: I removed /etc/rc2.d/S99stop-bootchart, so that I can run it until after GNOME started
[09:45] <mvo> oh, misread :) still a good improvement
[09:45] <pitti> seb128: is e-d-s really triggered by e-a-n, or rather by the panel?
[09:45] <liw> hmm, gdm does not seem to allow one to configure automatic login to a specific user, but with the screen locked immediately
[09:45] <jpds> soren: Just restart and there should be a png in /var/log/bootchart/ .
[09:45] <pitti> seb128: or does the panel only start e-d-s once you try to open the calendar?
[09:46] <soren> jpds, pitti: that's what I thought, but it didn't happen. Odd.
[09:46] <pitti> soren: hang on
[09:46] <pitti> soren: for me, it crashed with an exception
[09:46] <pitti> I had to do a "sudo ln -s headless xawt" to make it find a library
[09:47] <pitti> ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/headless/libmawt.so is shipped by the package
[09:47] <pitti> but bootchart looks in ./usr/lib/jvm/java-6-openjdk/jre/lib/i386/xawt/libmawt.so
[09:47] <pitti> it probably needs a rebuild, or so
[09:48] <soren> pitti: I've got /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/xawt/libmawt.so
[09:48] <pitti> soren: well, kill the rc2.d symlink and start /etc/init.d/stop-bootchart by hand after login, then you should see
[09:48] <seb128> pitti: I need to check, I'm not sure
[09:48] <soren> pitti: It's supposed to collect data in /var/run/bootchart, correct?
[09:49] <seb128> pitti: the clock applet should try to use it only when you click on it to display the calendar
[09:49] <seb128> "should"
[09:49] <pitti> seb128: I'll test it; I disable e-a-n and see when e-d-s gets started
[09:49] <seb128> ok
[09:49] <seb128> soren: not run, log
[09:49] <pitti> soren: yes, but moves them to /var/log/bootchart.tgz or os
[09:49] <pitti> s/os/so/
[09:50] <soren> Oh. I thought it collected data in /var/run and then turned that into a png in /var/log
[09:50] <seb128> soren: right
[09:50] <seb128> soren: I though you were asking where to look for the charts
[09:51] <soren> seb128: I was at first :)
[09:51] <soren> ..but since that failed.. :)
[09:51] <pitti> seb128: confirmed, that works
[09:51] <pitti> seb128: move e-d-s autostart .desktop -> ps ux|grep evo is empty
[09:51] <seb128> pitti: ;-)
[09:52] <pitti> seb128: so if we delay that by, say, 30 seconds, then it should be all good
[09:52] <seb128> pitti: btw no need to move the rc script, you can use "bootchart=nostop" as a boot option
[09:52] <pitti> seb128: nostop> nice, didn't know that
[09:52] <seb128> I learned that from Keybuk some days ago ;-)
[09:52] <seb128> pitti: right
[09:53] <pitti> seb128: want me to upload, or do you want to?
[09:53] <seb128> pitti: you can do it if you want
[09:54]  * soren reboots to figure out why bootchart isn't doing its thing.
[09:54] <pitti> doing then, and then I'll see how much it helped
[09:54] <seb128> ok
[09:58]  * mrooney waves to pitti and seb, and goes to sleep :)
[09:58] <seb128> 'night mrooney
[10:00] <shankhs> 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] <pitti> bye mrooney
[10:01] <pitti> seb128: hm, buys some 2 seconds
[10:01] <seb128> pitti: that's good to take ;-)
[10:07] <soren> 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] <seb128> why doesn't it work for you?
[10:08] <pitti> seb128: uploaded
[10:08] <soren> 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] <soren> 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] <soren> Now, why this doesn't happen for you guys is beyond me.
[10:09] <soren> Do you have /lib/ld-linux.so.* in your initramfs?
[10:10] <soren> And if you do, do you have any idea how it got there?
[10:10] <seb128> soren: there is an init script so it doesn't need to be ran in initramfs no?
[10:10] <pitti> $ zcat /boot/initrd.img-2.6.28-7-generic |cpio -t|grep ld-linux.so
[10:10] <pitti> lib/ld-linux.so.2
[10:10] <pitti> ^ i386
[10:11] <soren> Oh, both of you are on i386?
[10:11] <pitti> yes
[10:11] <seb128> 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] <soren> seb128: The init script (outside initramfs) bails out if some of the right directories are tere.
[10:11] <soren> there.
[10:11] <pitti> maybe that'll magically fix things for you as well :)
[10:12] <soren> ...which they are, becuase the init script in the initramfs creates those before failing here.
[10:12] <soren> pitti: I doubt it.
[10:13]  * soren patches bootchart..
[10:14] <cjwatson> certainly the amd64 dynamic linker has a different name
[10:15] <soren> Indeed.
[10:15] <soren> I don't see how it could work at all on amd64.
[10:15] <soren> Ah, it doesn't :)
[10:15] <cjwatson> though I'm not seeing the bug you refer to here
[10:15] <soren> but 32778.
[10:15] <soren> but 327778.
[10:15] <soren> cjwatson: No? Do you have /lib/ld-linux.so.* for some other reason in your initramfs?
[10:16] <soren> bug 327778
[10:16] <cjwatson> oh, I'm out of date
[10:16] <soren> Wow, spelling is hard. :)
[10:16]  * soren fixes it.
[10:16] <cjwatson> soren: I meant in the source code. I run i386. But never mind, I just needed to upgrade
[10:16] <pitti> yay, -intel magically fixed itself again
[10:16] <pitti> with today's dist-upgrade
[10:16] <pitti> x and compiz are happy again
[10:17] <pitti> bryce, tjaalton: ^
[10:17] <soren> cjwatson: Ah, ok.
[10:17] <pitti> (I noticed the usplash reversion, and maybe that indeed was it for me as well)
[10:17] <pitti> I'm 100% sure I tested it without usplash, too, though; well, *shrug*
[10:17]  * soren reboots to check his fix
[10:22] <tjaalton> pitti: magic, and no updated X packages :)
[10:37] <pitti> tjaalton: well, the breakage was equally magic, after all :)
[10:47] <ogra> pitti, without any hacks like .drirc etc ?
[10:50]  * soren just pushed a new bootchart
[10:51] <soren> pitti: If you'd be so kind to check that I didn't break i386, that would be lovely.
[11:12] <pitti> ogra: no
[11:12] <pitti> soren: sure
[11:13] <pitti> 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] <pitti> emacs thought it should write the file encoded in iso-2022-jp2 *grumpf*
[12:02] <tjaalton> dholbach: looks like gnome-reset is unmaintained upstream, and broken in jaunty. maybe it should be removed frome the archive?
[12:02] <tjaalton> no new upstream releases in three years
[12:08] <pitti> 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] <soren> pitti: Bootchart improves gdm->session ready time?
[12:13] <pitti> erm, s/bootchart/readahead/
[12:21] <soren> Oh.
[12:25] <soren> 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] <pitti> soren: right, if you have less RAM that you need to keep the boot and gnome in ram, you'd get taht
[12:26] <pitti> that
[12:26] <pitti> soren: but for that reason readahead has two stages (boot and desktop)
[12:26] <soren> Ah, I see.
[12:28] <soren> 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] <pitti> o_O
[12:34] <pitti> directhex: oh, I see :)
[12:34] <pitti> directhex: better *use* them :)
[12:34] <directhex> pitti, well i have a bunch spare now...
[12:35] <directhex> pitti, i get confused by debian vs ubuntu bug closing format, so go for a nice happy medium of "works in neither"
[12:35] <directhex> \o/
[12:35] <pitti> directhex: but # is required in both...
[12:35] <directhex> i just suck then
[12:36] <asac> doko: do all sun-java plugin filenames have the same name?
[12:36] <asac> i mean the .so
[12:37] <asac> anyone uses ppp manually here (e.g. pppoe or wvdial)?
[12:37] <pitti> geser, evand: nice race on attacking the sponsoring queue :)
[12:38] <jpds> pitti: Thanks for the gdata upload. I'll test the plugins later on.
[12:39] <Lure> 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] <Lure> asac: bug 324523 and bug 325858
[12:41] <RainCT> asac: why do you ask?
[12:41] <directhex> pitti, with ndoc done, there are now officially only two Mono apps (libs are another topic) in Ubuntu built against the 1.0 runtime. one is blocked on a mono sync, the other is blocked on a lib stuck in debian NEW (though we could 0ubuntu1 the lib if need be)
[12:41] <asac> RainCT: in ~network-manager team ppa there is a new ppp package ;)
[12:42] <pitti> directhex: want me to look into the mono sync?
[12:42] <asac> RainCT: just would like a confirm from a "manual" user that it doesnt break too much
[12:42] <asac> before upload
[12:42] <pitti> directhex: s/look into/just do it if it is okay/
[12:42] <directhex> pitti, that'd be lovely
[12:42] <pitti> directhex: bug #?
[12:43] <directhex> pitti, bug 323790
[12:44] <RainCT> asac: Sorry, I'm not using it anymore, was just curious :)
[12:45] <RainCT> (I used wvdial before Hardy, when it was necessary to manually configure 3G devices like a modem.. Now nm configures them automatically, and I've switched to WiMAX anyway)
[12:46] <pitti> directhex: done
[12:47] <directhex> woo! i'll wait for it to filter through, and give muine a little test in a pbuilder
[12:48] <Laney> \o/!
[12:48] <directhex> now to give a MOTU a back rub until they let me stick sublib straight into the archive
[12:49] <pitti> cjwatson: you are already doing the gparted sponsoring?
[12:50] <slangasek> superm1: yep, mythbuntu reenabled
[12:50] <RainCT> kirkland: Hey. I'm wondering what the MOTD tab in screen-profiles is supposed to be for :P
[12:51] <cjwatson> pitti: yes, please see the latest comments in the bug, I want to hear back from Debian on the .orig.tar.gz before proceeding
[12:51] <kirkland> RainCT: if you install screen-by-default-at-login, you'll miss the MOTD on login
[12:51] <directhex> Laney, muine was your work, do you want to give it the requestsync poke once it's tested on jaunty? or shall i
[12:51] <pitti> cjwatson: ah, ok
[12:51] <kirkland> RainCT: it's easy to disable, F9->manage-default-windows->uncheck MOTD
[12:52] <tjaalton> hmm, libmjpegtools0c2a was removed from the archive?
[12:52] <RainCT> kirkland: and wouldn't it make more sense to show it above the bash prompt, and not have it always there?
[12:52] <kirkland> RainCT: perhaps...  how do you suggest doing that?
[12:52] <RainCT> (well, I'm still on Intrepid, from what I've heard perhaps in Jaunty the MOTD is more interesting :))
[12:52] <kirkland> RainCT: i couldn't figure out how
[12:53] <kirkland> RainCT: MOTD is slightly more dynamic, which is why that's a watch in the tab
[12:53] <RainCT> kirkland: uhm.. just printing the MOTD and then launching bash doesn't work?
[12:54] <kirkland> RainCT: how do you know you want to run bash?
[12:54] <RainCT> kirkland: or whatever shell it is.. aren't they all the same?
[12:54] <RainCT> kirkland: well, nvm about this :)
[12:55] <kirkland> RainCT: i'm open to ideas
[12:55] <RainCT> kirkland: Another thing, the menu doesn't work fine here (it can't handle resizing, etc)
[12:55] <kirkland> RainCT: i'm not wild about dedicating a tab to it
[13:02] <Laney> directhex: I don't mind. I'll be home at 5.30 or so to do it but do it sooner if you can
[13:02] <Laney> I have reached not-caring-about-my-uploads-page nirvana
[13:03] <directhex> there's an uploads page?
[13:03] <pitti> speaking about ext4, I should update the usplash fsck integration...
[13:03] <Laney> yeah, go to your launchpad profile
[13:03] <RainCT> directhex: launchpad.net/people/+me/+packages
[13:03] <Laney> "related software"
[13:03] <Laney> RainCT: URL NERD
[13:04] <directhex> Displaying first 30 packages out of 32 total
[13:04] <directhex> that's a lot!
[13:04] <Laney> \o/
[13:04] <directhex> why on *earth* did i fix a bug in the "gourmet" package?
[13:05] <directhex> a *python* app!
[13:05] <RainCT> lol
[13:05] <RainCT> directhex: look at sebner's page.. "Displaying first 30 packages out of 302 total" \o/
[13:05] <RainCT> (but most of those are syncs.. bah :P)
[13:06] <Laney> Look at sysinfo 0.7-1ubuntu{1,2,3,4} ;)
[13:07]  * RainCT thinks that "sponsored packages" should also be displayed :P
[13:08] <directhex> RainCT, #launchpad wi'yersen then!
[13:10] <kirkland> RainCT: hmm, i'm not succeeding
[13:10] <kirkland> RainCT: i'm tring to add something like this to ~/.screenrc-windows
[13:10] <kirkland> screen -t shell 3 cat /etc/motd && $SHELL
[13:11] <cjwatson> pitti: ext4/usplash/fsck> good catch, I missed that
[13:12] <pitti> cjwatson: just noticed, apparently it was the first time I got fsck at boot on my new ext4 system
[13:12] <highvoltage> you and your fancy shiney ext4 filesystems
[13:12] <pitti> I like losing data :)
[13:12] <johan> isn't the packages from ddeb.ubuntu.com supposed to be sync:ed with the ones from archives.ubuntu.com?
[13:12] <pitti> johan: in theory yes, in practice it's a constant source of trouble
[13:13] <kirkland> RainCT: okay, i found a workaround
[13:13] <johan> pitti: I'm discovering that, seems xulrunner is causing trouble today
[13:13] <kirkland> RainCT: if you file a bug, i'll upload a fix :-)
[13:13] <johan> pitti: and only for i386/intrepid
[13:14]  * pitti -> brb, testing fsck in usplash
[13:15] <RainCT> kirkland: for the MOTD or the menu?
[13:16] <geser> pitti: how usable is ext4 already? I've heard a talk from Theodore Ts'o at FOSDEM about ext4.
[13:16] <allquixotic> bryce: I hit something where suspend causes the computer to come back to GDM login at resume. This could be the "crash on resume" others have seen, but are we sure it isn't some sort of intentional log-off, or crash for other reasons?
[13:18] <allquixotic> geser: ext4's on disk format was considered final as of 2.6.28 (which is Jaunty's kernel) and it seems ready for ordinary desktop use... all of my current partitions are ext4 and they are fine
[13:19] <allquixotic> geser: It's not like ext3 is somehow _more_ reliable because it's older; I've had completely hosed ext3 partitions only because of power failure. Weak. I thought journalling was supposed to take care of that. It didn't.
[13:19] <dholbach> tjaalton: sounds like a good idea
[13:20] <ScottK> allquixotic: A related question is how broad is the user space tool support for ext4?
[13:20] <dholbach> tjaalton: do you want to request it? if not I'll do it later on
[13:20]  * dholbach needs to take the dog out
[13:20] <allquixotic> ScottK: gparted seems not to be aware of ext4 yet, but Jaunty's installer is, and e2fsprogs (e2fsck, tune2fs, etc) are fully ext4-aware
[13:21] <ScottK> I recall someone mentioning there's a new gparted available.
[13:21] <ScottK> Just needs to be merged/packaged/or something.
[13:21] <dholbach> it's in the sponsoring list
[13:21] <pitti> geser: works fine for me, and fsck is pleasantly fast :)
[13:23] <allquixotic> Production server sysadmins are going to be cautious regardless of how stable we say it is, only because ext4 has yet to stand the test of time as a production filesystem. So we could say it's rock solid and swear by it, but some people are going to stick with ext3 or even older cruft just because it's well understood, whereas ext4 has new things that aren't as well understood.
[13:23] <allquixotic> But for desktop users, I'm going to promote ext4 whenever users ask me, in Jaunty.
[13:23] <geser> pitti: they made it 6-8 times faster according to the talk
[13:23]  * ScottK knows of admins that still use ext2 because it's got an established track record.
[13:23] <tjaalton> dholbach: ok
[13:23] <geser> pitti: so using ext4 is as dangerous as using jaunty?
[13:26] <cjwatson> yes, I know about gparted, just trying to make sure we're duly synced up with Debian first
[13:26] <allquixotic> cjwatson: have you filed a bug about UXA yet?
[13:26] <cjwatson> no
[13:26] <cjwatson> largely because I upgraded usplash and it now appears to work
[13:26] <cjwatson> I'm giving it a day or two's burn before changing my comment on UxaTestingg
[13:27] <kirkland> RainCT: just a bug explaining your reasoning that we don't need to dedicate an entire window to the MOTD
[13:27] <cjwatson> BTW, on ext4, if you boot today's alternate installer with partman/default_filesystem=ext4 then it should autopartition with ext4 rather than ext3
[13:28] <RainCT> kirkland: Okay. Have you seen this message, though:
[13:28] <RainCT> >> kirkland: Another thing, the menu doesn't work fine here (it can't handle resizing, etc)
[13:28] <kirkland> RainCT: oh, missed that one
[13:29] <cjwatson> actually desktop too, I think
[13:29] <kirkland> RainCT: hmm, yeah, open a 2nd bug for that one
[13:29] <kirkland> RainCT: perhaps nijaba will know how to fix that
[13:29] <tjaalton> cjwatson: I've used ext4 since day one, and installing 12 desktops with it as we speak :)
[13:29] <kirkland> RainCT: b/c I don't ;-)
[13:30] <cjwatson> tjaalton: sure, just saying that now autopartitioning support for it is available; previously you had to use manual partitioning to get it
[13:30] <cjwatson> or upgrade in-place from ext3
[13:30] <tjaalton> cjwatson: yep
[13:30] <cjwatson> should I add an 'ext4' preseeding alias for partman/default_filesystem=ext4?
[13:31] <cjwatson> anaconda had that parameter in some Fedora release, I believe
[13:37] <cjwatson> hmm, actually that's a little tricky
[13:38] <RainCT> kirkland: alright, filed bug #328066
[13:39] <EagleScreen> cjwatson: I think you proposed usb-creator to depends on gksu
[13:39] <kirkland> RainCT: thanks
[13:40] <cjwatson> EagleScreen: given its code at the time when I proposed that, it should. It would be better for it to find an appropriate root-privilege-acquisition tool.
[13:40] <cjwatson> EagleScreen: my bug was that it used gksu unconditionally without a dependency
[13:40] <EagleScreen> what about using su-to-root and add depends on menu?
[13:41] <cjwatson> I don't care
[13:41] <cjwatson> if only it weren't in the menu package, which is completely useless for everything else in Ubuntu since we use .desktop files, and quite possibly harmful ...
[13:42] <cjwatson> and in universe for pretty much that reason
[13:42] <kirkland> RainCT: okay, can you test this for me?  see if it works better for you?
[13:43] <RainCT> kirkland: sure
[13:43] <nijaba> kirkland: RainCT: sorry, trying to catch up, what would I know how to fix?
[13:43] <RainCT> (also filed bug #328067, with a screenshot)
[13:44] <RainCT> nijaba: look at that bug please :)
[13:44] <kirkland> nijaba: the screen-profiles configuration menu doesn't handle window resizes
[13:44] <EagleScreen> cjwatson: I have seen .desktop files which use su-to-root and they seems to work propertly
[13:44] <kirkland> nijaba: hit f9 to open it, then resize gnome-terminal
[13:44] <cjwatson> EagleScreen: the menu package isn't installed by default, and we don't want it to be
[13:44] <kirkland> RainCT: okay, grab this shell script: http://pastebin.ubuntu.com/116828/
[13:45] <kirkland> RainCT: save it as /tmp/foo.sh, chmod it 755
[13:45] <kirkland> RainCT: edit your ~/.screenrc-windows file
[13:45] <EagleScreen> why you dont want it? if can know it..
[13:45] <kirkland> RainCT: replace the watch command with just /tmp/foo.sh
[13:45] <kirkland> RainCT: and launch screen
[13:45] <nijaba> RainCT: is this right after resizing the window?  If so, I believe it is a newt problem, and I have no clue how to fix it
[13:46] <RainCT> nijaba: yep
[13:46] <cjwatson> EagleScreen: because the menu package causes you to get the additional "Debian" menu
[13:46] <cjwatson> hmm, or at least used to
[13:46] <cjwatson> maybe it doesn't any more
[13:46] <nijaba> RainCT: an it is not specific to terminator, it will do the same everywhere.
[13:47] <EagleScreen> oh!, but i havent the Debian menu in KDE 4.2 and i have menu installed, is it happening only in Gnome?
[13:47] <cjwatson> "used to"
[13:47] <cjwatson> doesn't seem to happen in GNOME nowadays
[13:47] <cjwatson> it really would be preferable to have su-to-root in a separate package though
[13:47] <RainCT> nijaba: yep, I've just updated the bug's description..
[13:47] <cjwatson> menu has historically had "interesting" effects
[13:49] <RainCT> kirkland: works fine
[13:49] <kirkland> RainCT: cool, i'll upload the fix
[13:49] <cjwatson> EagleScreen: anyway, I wasn't saying usb-creator must use gksu, just that at the time it was broken without it, so I don't want to spend lots of time on this discussion
[13:49] <kirkland> RainCT: note that you'll need to remove (or prune) ~/.screenrc-windows
[13:49] <EagleScreen> I think applications like usb-creator shuldn't depend on gksu becouse it cause installation of unecessary Gnome packages in KDE
[13:49] <RainCT> kirkland: Okay. By the way, what's the key combination to end screen?
[13:50] <kirkland> RainCT: F6 will detach, but leave your stuff still running
[13:50] <cjwatson> EagleScreen: sure
[13:50] <kirkland> RainCT: F8 will show you all key bindings
[13:50] <cjwatson> EagleScreen: (note that ubiquity manages this without su-to-root, albeit with more hacks)
[13:51] <kirkland> RainCT: if you want to exit and kill all programs/windows, you want "pow_detach  D"
[13:51] <EagleScreen> may be i will report a bug, I understand that you probably have more important things to do
[13:51] <kirkland> RainCT: so ctrl-a-D
[13:51] <cjwatson>   * Apply patch from Colin Watson to su-to-root. Closes: #103879
[13:51] <cjwatson> gosh, I have no memory of that
[13:51] <cjwatson> EagleScreen: please do, usb-creator isn't my program
[13:51] <EagleScreen> okay, thanks, see you later
[13:52] <cjwatson> ah, I don't remember that patch because it was miscredited to me and I never noticed ;-)
[13:52] <RainCT> kirkland: that just detaches it
[13:53] <jpds> RainCT: exit, or Ctrl-D
[13:54] <apw> bryce, did the 'switching away to VT looks like the computer is on acid' bug fixes get uploaded?  got a bug reference?
[13:54] <RainCT> jpds: that only closes the terminal, there's still the menu (and right now the MOTD).. talking about screen with screen-profiles
[13:55] <RainCT> kirkland: anyway, thanks for fixing that :)
[13:58] <Keybuk> pitti: you mean readahead, not bootchart, don't you?
[14:00] <soren> Keybuk: He did.
[14:00] <soren> 12:13:42 < ~pitti> erm, s/bootchart/readahead/
[14:00] <Keybuk> pitti: I thought that gdm had its own readahead list
[14:00] <Keybuk> which it ran internally?
[14:03] <pitti> Keybuk: yes, readahead
[14:03] <pitti> Keybuk: it does, but it doesn't seem to be very effective
[14:04] <pitti> geser: there's still a data corruption bug open, although this might have been fixed with 2.6.28-7
[14:04] <pitti> geser: for now, I only use it on /, not /home, so that errors become visible, but aren't disastrous
[14:05] <Keybuk> pitti: the problem with doing it in a single phase is that you're then reading a *lot* of data into the page cache
[14:05] <Keybuk> usually more than the available memory
[14:05] <pitti> Keybuk: right, soren pointed that out already
[14:05] <Keybuk> isn't it simply that the gdm lists are out of date?
[14:05] <pitti> Keybuk: but I wondered whether it should/could be put into /etc/readahead/desktop instead of boot?
[14:05] <Keybuk> that file is only used if /usr is on a separate filesystem
[14:06] <Keybuk> and contains things from the mainline boot
[14:06] <Keybuk> (it's poorly named)
[14:06] <pitti> ok
[14:06] <pitti> Keybuk: another question I had is why the readline init script blocks instead of putting it into the background and give it a sleep 3 headstart?
[14:07] <Keybuk> because that is faster
[14:07] <pitti> curious
[14:07] <Keybuk> you don't have SSD
[14:07] <Keybuk> with spinning disks, you're attempting to minimise seek time
[14:07] <Keybuk> running it in the background would mean the disk was attempting to do the readahead
[14:07] <Keybuk> while also attempting to do writes, etc. required by other things during boot
[14:08] <Keybuk> so you're defeating your own attempt
[14:08] <Keybuk> with SSD, you're simply attempting to eliminate I/O wait
[14:08] <Keybuk> SSD you tend to order the list differently too
[14:08] <Keybuk> rotary you order by on-disk position
[14:08] <Keybuk> SSD you order by required time in the boot
[14:13] <RoyK> hi. where does ubuntu get the weather data shown in the status line?
[14:13] <maxb> What datasource does people.ubuntu.com/~ubuntu-archive/madison.cgi use? It appears to be out of date.
[14:14] <cjwatson> it's a mirror synced every six hours
[14:14] <cjwatson> how out of date?
[14:14] <maxb> only 3 hours, so never mind then
[14:58] <PecisDarbs> pitti: can I talk to you about https://bugs.edge.launchpad.net/ubuntu/+source/jockey/+bug/295158? :)
[15:10] <superm1> lool, okay well that question was mostly posed as a naming convention that you could agree on.  surely the split has to happen for that bug to be solved.  i'm guessing python-wnck and python-rsvg etc.  i'll make them dependencies of python-gnome2-desktop then too so in ubuntu packages should still be able to depend on python-gnome2-desktop if they so pleased in ubuntu until this type of change could float into debian
[15:14] <seb128> superm1: what is the bug you are speaking about?
[15:14] <seb128> superm1: you want to do yet another gnome-python binary split?
[15:15] <superm1> seb128, that was the idea, but i'm talking to evand about this right now, so perhaps we'll be able to avoid it
[15:15] <superm1> evand indicated he'll rework it to use png instead so ubiquity doesn't need rsvg, so that bug is a moot point for this purpose then
[15:17] <EagleScreen> hello, a few time ago I was "talking" here about the problem of some packages that depends on gksu, causing them to install unnecessary Gnome packages in KDE, it is necessary an alternative autentication method to avoid this problem
[15:18] <pochu> superm1: if you plan to split gnome-python-desktop, the work has already been done in the Debian svn repo
[15:19] <pochu> superm1: cf http://svn.debian.org/viewsvn/pkg-gnome/desktop/experimental/gnome-python-desktop/debian/control.in?rev=18217&view=markup
[15:19] <superm1> pochu, well i'd like to avoid having to do it at the ubuntu level before debian, and it's looking to be a lower priority now because ubiquity won't need it soon and be breaking xubuntu and mythbuntu anymore
[15:20] <Riddell> EagleScreen: this seems to be something that concerns you :)
[15:20] <Riddell> EagleScreen: you could work out what's wrong with su-to-root that people don't like and fix that
[15:22] <EagleScreen> I have three ideas: 1) is to use su-to-root, but it is in universe, and is not a good idea packages in main to depend on packages in universe. 2) is make a .desktop file for KDE and another one for Gnome as synaptic does. 3) is to launch the program from an script that check if gksu or kdesudo is installed and run one of them. For 2) or 3) the package could depends on gksu | kdesudo. What do you think about these alternatives?
[15:23] <Riddell> EagleScreen: I guess i'd first find out why su-to-root is in universe
[15:23] <lool> superm1: I'm fine with your proposed changes
[15:24] <EagleScreen> yes Riddell, i am going to investigate it, any report in Launchpad?
[15:24] <Riddell> EagleScreen: no idea I'm afraid
[15:27] <superm1> pochu, has that change not been uploaded in debian because of the lenny freeze?
[15:28] <superm1> pochu, even though this behavior is getting changed in ubiquity, perhaps it's still worthwhile to pull that change as it looks beneficial anyhow
[15:28] <Chipzz> EagleScreen: as suggested, 1) could be solved by getting it promoted to main ;)
[15:30] <EagleScreen> yes Chipzz, but people say that menu package in which is su-to-root, has some kind of problem
[15:31] <EagleScreen> C. Watson propose to split menu and su-to-root, may be it is a good idea
[15:34] <Chipzz> that's what I was going to say next :)
[15:34] <Chipzz> although I know neither package
[15:37] <pochu> superm1: it's targetting experimental for now, but it's probably waiting Lenny, I guess
[15:37] <pochu> superm1: I'm not totally sure as I didn't do the change
[15:38] <directhex> yay, experimental
[15:38] <leszek> hi, why is the python-gnome2-desktop package in intrepid creating its own libtool thats used for compiling, when obviously rebuilding the package with this libtool is not working ?
[15:44] <seb128> leszek: what do you mean creating its own libtool?
[15:44] <pitti> PecisDarbs: hi
[15:45] <PecisDarbs> pitti: hi
[15:46] <pitti> PecisDarbs: the bug for jockey is still open, for detecting it
[15:47] <leszek> seb128, I mean that it won't use the one installed
[15:47] <pitti> PecisDarbs: however, it needs to be fixed in sl-modem as well
[15:47] <seb128> leszek: why should it use it?
[15:47] <PecisDarbs> pitti: I wanted to do that small change in Jokey and slmodemd init.d script before Jaunty release it's that possible. I can try to write a patch for that init.d, but I don't know where I have to fix it in Jockey
[15:47] <leszek> seb128, because I get a compile error with this "internal" libtool
[15:47] <PecisDarbs> pitti: yes, so I wanted to know if I will write a small patch will someone put it there? :)
[15:47] <pitti> PecisDarbs: if you can get sl-modem fixed, I can transition the same fix to jockey
[15:47] <leszek> seb128, so I cannot rebuild the package
[15:47] <seb128> leszek: it built fine on the buildds and on my box, check your installation
[15:47] <pitti> PecisDarbs: yes, I'm happy to review and sponsor it
[15:48] <PecisDarbs> pitti: cool, then I will jump on it tonight, thanks :)
[15:48] <leszek> seb128, ok will check that
[15:48] <pitti> PecisDarbs: if you have a patch, please subscribe me to the sl-modem bug
[15:48] <pitti> PecisDarbs: cool, good luck!
[15:48] <PecisDarbs> ok
[15:50] <Keybuk> debugging with sudo perl -e 'open FOO, ">/dev/sda"'
[15:50] <Keybuk> what could possibly go wrong?
[15:52] <pitti> o_O
[15:57] <EagleScreen> I can see that su-to-root is just a bash script inside menu package, so it should be extracted easily
[16:00] <cjwatson> EagleScreen: talk to the Debian maintainer
[16:00] <cjwatson> this would be better done in a common fashion
[16:04] <leszek> hmm... I still get a lot of ../libtool: line 824: X--mode=compile: command not found
[16:04] <leszek>  errors and whole of ther libtool errors, what the hell is going on ?
[16:05]  * tedg wants a bot that anytime someone mentions "sudo perl" it kicks them from the channel :)
[16:05] <leszek> seb128, hmm... still get libtool command not found errors, like : ../libtool: line 824: X--mode=compile: command not found
[16:05] <seb128> leszek: run autoreconf, you are running autotools incorrectly
[16:06] <james_w> leszek: you need to autoreconf the source to remove those
[16:07] <leszek> ah ok
[16:08] <seb128> leszek: why do you rebuild the package btw?
[16:09] <leszek> I patched libwnck for vertical panel, but need to patch python-gnome2-desktop to have this functionality in python also
[16:10] <seb128> what is different in the vertical case?
[16:11] <leszek> the wnck.Tasklist is not growing horizontaly but verticaly or should grow this way
[16:11] <leszek> its a libwnck bug known also from the gnome-panel ;)
[16:13] <leszek> seb128, here is the patch that I found for libwnck : http://bugzilla.gnome.org/attachment.cgi?id=124112
[16:14] <leszek> would be nice to have this patch somehow build in :P
[16:15] <seb128> what is the bug number?
[16:15] <seb128> that change seems to not be correct
[16:16] <leszek> GNOME Bug 86382.
[16:26] <bryce> apw, yep #325781
[16:26] <apw> bug #325781
[16:29] <apw> bryce, ta, seems that the new ones have appeared in my updates list since this morning, which is when i saw it
[16:29] <apw> will download and test those
[16:29] <ogra> ogra@osiris:~/Desktop$ du -hcs /var/log/bootchart
[16:29] <ogra> 37M	/var/log/bootchart
[16:29] <ogra> hmm
[16:29] <ogra> we should probably start considering adding /var/log/bootchart to logrotate
[16:29] <ogra> i totally forgot i had it installed ...
[16:32] <apw> what time are the iso's made UTC ?
[16:34] <cjwatson> apw: depends which ones you mean
[16:34] <cjwatson> there is a crontab with various times for various images
[16:34] <cjwatson> apw: http://paste.ubuntu.com/116916/
[16:46] <LaserJock> anybody know offhand how I could figure out for somebody what they need to download to get working nvidia drivers?
[16:47] <LaserJock> seems like a "you need to get the following .debs" would be helpful
[16:50] <bryce> asac: http://wiki.x.org/wiki/RadeonProgram
[16:52] <lool> mvo: Hmm I've lost all my keybindings over the compiz upgrades (not sure which); it seems this is now handled by a new plugin which isn't enabled and didn't have my config anyway
[16:53] <mvo> lool: could you plesae check if you have the gnomecompat plugin enabled?
[16:53] <lool> mvo: I do not
[16:53] <mvo> lool: hrm, thanks!
[16:53] <mvo> lool: I check why its not, it should be :)
[16:53] <tseliot> LaserJock: nvidia-glx-VERSION and its dependencies and the linux-headers should be enough
[16:53] <lool> mvo: Enabling it didn't get the keybindings back either
[16:54] <LaserJock> tseliot: ok, cool
[16:54] <lool> mvo: BTW over time it seemed to me compiz switched from .ini to gconf and back, I'm not sure what it is using now
[16:54] <asac> bryce: nice. though my R580 isnt in that table at atll
[16:54] <lool> At some point, I was tired of it and wrote a python script to write my settings via the python bindings, but even these broke
[16:55] <mvo> lool: urghs, can we talk/debug it in a bit? I need to run for some errands
[16:57] <lool> mvo: Hmm sure
[16:57] <lool> The backend switches were a while ago, and I saw these in Debian as well
[16:58] <mvo> lool: I added a patch that should prevent it, could you please check if you got the latest libcompizconfig apckage too?
[17:00] <bryce> asac, sauerbraten works pretty good on my card; 120 fps
[17:00] <cjwatson> dholbach: so, um, given that TeamReports is still apparently preparing the January report, should I just create a February page as well?
[17:01] <dholbach> cjwatson: oh, I can do it well, sorry
[17:01] <asac> bryce: ok finally i will check that too now ;)
[17:01] <LaserJock> tseliot: do you happen to know if dkms is installed by default on Intrepid?
[17:01] <asac> bryce: but for you compiz works too ... so.
[17:01] <cjwatson> don't mind doing it, just wasn't sure whether it was supposed to go into January until it's finalised or something
[17:02] <lool> mvo: I have 0.7.8-0ubuntu3 which seems the latest
[17:02] <tseliot> LaserJock: I'm not sure. superm1 should know it though
[17:03] <dholbach> cjwatson: done: https://wiki.ubuntu.com/TeamReports/February2009
[17:03] <cjwatson> thanks
[17:03] <ogra> is my screen supposed to have a black wallpaper after login with the lastest upgrades or is that a bug
[17:03] <ogra> (i mean after gdm and before nautilus draws the desktop)
[17:04] <ogra> pitti, hmm, sad i hoped my X would behave better when you said yours works ... but i still have hangs switching virtual desktops in compiz
[17:06] <cjwatson> dholbach: do I just delete the "Team Name" blocks upon adding something?
[17:06] <cjwatson> actually, never mind, not relevant since I'm adding a TB meeting note
[17:06] <dholbach> yeah, sounds good
[17:11] <Keybuk> quest udev% ls -l /dev/disk/by-uuid | grep sdc1
[17:11] <Keybuk> lrwxrwxrwx 1 root root 10 2009-02-11 17:10 CD55-342D -> ../../sdc1
[17:11] <Keybuk> quest udev% sudo mke2fs /dev/sdc1 > /dev/null
[17:11] <Keybuk> mke2fs 1.41.3 (12-Oct-2008)
[17:11] <Keybuk> quest udev% ls -l /dev/disk/by-uuid | grep sdc1
[17:11] <Keybuk> lrwxrwxrwx 1 root root 10 2009-02-11 17:12 96aa3c56-00dc-4dfa-96e1-91ebe5689e33 -> ../../sdc1
[17:11] <Keybuk> \o/
[17:11] <kees> mvo, bdmurray: is there a general wiki landing page to help people with all the various package management errors they can hit?
[17:11] <jdong> Keybuk: am I interpreting that as by-uuid dynamically updates?
[17:11] <Keybuk> jdong: yes
[17:12] <jdong> neato!
[17:16] <superm1> LaserJock, it's only installed if you have a driver that needs it such as nvidia or fglrx
[17:16] <LaserJock> superm1: heh, ok
[17:16] <LaserJock> this poor friend of mine has no internet and lives 1000 miles away
[17:16] <highvoltage> :(
[17:16] <superm1> oh that makes life more difficult doesn't it.
[17:17] <superm1> LaserJock, they're on ubuntu DVD media too
[17:18] <LaserJock> superm1: well, I tried to find a DVD briefly but I couldn't find one for Intrepid
[17:18] <LaserJock> and he can't download a DVD .iso obviously
[17:18] <LaserJock> I sent him an openSUSE DVD to see if maybe he can get *something* going
[17:19] <LaserJock> poor guy has been trying to get linux working for a couple months now
[17:19] <superm1> well how are you going to get him a set of debs in the first place then?
[17:19] <LaserJock> .debs he can download from my brother
[17:19] <LaserJock> but my brother tried to download an Ubuntu DVD but it was too much
[17:19] <cjwatson> LaserJock: http://cdimage.ubuntu.com/releases/intrepid/release/
[17:20] <LaserJock> cjwatson: darn it, I shoulda looked there. I was looking on releases.ubuntu.com
[17:21] <highvoltage> LaserJock: where I live bandwidth is very expensive, so I download the ubuntu archives and distribute it on DVD. perhaps you could do the same and send it to them to distribute
[17:21] <LaserJock> I just had a couple minutes to look for it so I could hand it off to some people
[17:22] <LaserJock> highvoltage: you do just Main?
[17:22] <LaserJock> it's just amazing how difficult this can be for people even in the US :-)
[17:22] <LaserJock> I've gotten so used to great bandwith
[17:22] <jdong> is there an effective/intuitive way of downloading a package and all its dependencies suitable for burning on a CD?
[17:23] <LaserJock> well, aptoncd might work
[17:23] <jdong> I had a script that starts with like a pbuilder environment and grabs the packageset that it tries to download
[17:23] <LaserJock> but part of my problem is just getting the guy up-and-running so he can learn how to use Linux at all
[17:24] <highvoltage> LaserJock: I do main universe multiverse and restricted for i386. it's about 22GB for intrepid
[17:25] <Turl> hi there, can you take a look at https://bugs.launchpad.net/ubuntu/+bug/328156 ?
[17:25] <highvoltage> LaserJock: heh well, over here all of us think that everyone in the US has at least uncapped 20mbit connections
[17:26] <LaserJock> I think I'll just mail him the DVD
[17:26] <LaserJock> it only takes me ~ 45 min to download
[17:28] <cjwatson> jdong: I'm pretty sure there's a document on this in the apt-doc package
[17:30] <cjwatson> /usr/share/doc/apt-doc/offline.html/index.html
[17:36] <calc_> highvoltage: heh, US has crap broadband, Korea is where its at ;-)
[17:36] <calc_> i'm hoping to get 10/1.5 on friday upgraded from my previous max of 3.0/0.5
[17:37] <LaserJock> calc_: US can have crap connectivity period, my parents have a nice speedy 28.8k dialup ;-)
[17:37] <calc_> highvoltage: aiui in korea and japan you can get gigabit to your home fairly cheap
[17:37] <highvoltage> calc_: wow
[17:37] <calc_> highvoltage: persia has gigabit aiui
[17:39] <calc_> what does a blue (@) mean in the new screen theme?
[17:39] <Turl> anyone please? https://bugs.launchpad.net/ubuntu/+bug/328156
[17:39] <tedg> calc_: run!!!!
[17:39] <calc_> tedg: heh
[17:40] <kees> james_w: in BzrBuildPackage, you have --builder defaulting to "dpkg-buildpackage -rfakeroot -uc -us".  shouldn't this be "debuild -uc -us" given Ubuntu's compiler flag default settings that doko built into debuild?
[17:40] <LaserJock> calc: if it starts blinking faster and faster cut the red wire
[17:40]  * calc finally gets to go back home in the morning, back to nice 25C weather, no more snow and ice on the ground, heh
[17:41] <james_w> kees: yes, it probably should, I've been meaning to change it, but never quite got around to it
[17:41] <doko> kees: these are built into dpkg-buildpackage
[17:41] <james_w> kees: I think I'll just make it "debuild"
[17:41] <kees> doko: oh, you moved them into dpkg-buildpackage?
[17:41] <kees> doko: when did that happen?
[17:41] <doko> kees: hmm, I never moved them ...
[17:42]  * kees scratches his head.  memory fail.  :P
[17:42] <calc> kees: thats what happens when you get old ;-)
[17:43] <kees> :P
[17:48] <jdong> cjwatson: thanks! (apt-doc pointer)
[17:55] <kees> james_w: is there a work-flow documented anywhere for the steps to take to do the bzr-style work?  i.e.  "bzr bd -w" *repeat* "debcommit" "debcommit -r" "bzr bd" *upload* etc?
[17:56] <james_w> that pretty much sums it up :-)
[17:56] <kees> I'm not clear on what goes into the change between the debcommit and the debcommit -r (without manually doint a bzr ci --unchanged -m 'releasing...')
[17:56] <james_w> (-w is un-needed now btw)
[17:56] <kees> why?
[17:56] <james_w> it's the default
[17:56] <kees> ah! heh, okay
[17:57] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[17:57] <james_w> that's where I'm doing the documentation currently
[17:58] <cjwatson> kees: people who know about it generally put DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts, after which your last change before releasing is dch -r (which changes UNRELEASED to jaunty at the top of debian/changelog, and updates the timestamp)
[17:58] <kees> okay, cool.  back-links from BzrBuildPackage would be nice.  :)
[17:58] <cjwatson> much friendlier to revision control
[17:58] <kees> cjwatson: ah! that's the missing piece for me.
[17:59]  * LaserJock wishes we could put cjwatson's brain on paper :-)
[18:01] <Keybuk> cjwatson: the comments on bug #85014 may amuse ;)
[18:01] <kees> cjwatson, james_w: is there a tool that does the s/UNRELEASED/jaunty/ on the change log, or is that bit manual?
[18:02] <james_w> dch -r
[18:05] <cjwatson> Keybuk: what a mess
[18:05] <cjwatson> especially from somebody using the royal we
[18:06] <kees> james_w: okay, perfect, so process is:   *setup* (*hack* ("bzr bd", test)*repeat* debcommit)*repeat* "dch -r" "debcommit -r" *upload*
[18:06] <Keybuk> cjwatson: it's not as if I even closed the bug won't fix ;)
[18:06] <kees> seems almost like "debcommit -r" should run "dch -r"
[18:06] <cjwatson> I'd find it surprising if debcommit changed the working tree
[18:08] <jpds> Keybuk: Looking at his related bugs... I'd say he likes to write essays for responses.
[18:09] <cjwatson> what's that stuff about jigdo being broken? I assume that it's somebody trying to jigdo a point release or something
[18:09] <cjwatson> (which has never worked)
[18:09] <kees> cjwatson: oh... you didn't update vte bzr :)
[18:10] <cjwatson> kees: I did, I asked somebody to pull for me since I'm not in ubuntu-desktop
[18:10] <cjwatson> kees: lp:~kamion/vte/udeb-fixes I think
[18:10] <kees> cjwatson: oh! yeah, I'm going to be in the same boat, it seems.
[18:20] <kees> james_w: exported directories from 'bzr bd' are world-writable.
[18:21] <james_w> kees: ouch
[18:21] <james_w> kees: which directory exactly?
[18:21] <kees> all of them, it seems
[18:21] <kees> $ ls -lda vte-0.19.4
[18:21] <kees> drwxrwxrwx 11 kees kees 4096 2009-02-11 10:17 vte-0.19.4/
[18:21] <kees> $ ls -lda vte-0.19.4/src
[18:21] <kees> drwxrwxrwx 2 kees kees 4096 2008-12-15 12:45 vte-0.19.4/src/
[18:21] <kees> i wonder if this is a tarball glitch
[18:22] <kees> $ tar zvtf vte_0.19.4.orig.tar.gz
[18:22] <kees> drwxrwxrwx 500/500           0 2008-12-15 12:45 vte-0.19.4/
[18:22] <kees> oh, so it is.  how intensely strange.
[18:23] <james_w> the python tarfile module is a little lacking in places, and I know there is some issues with UMASK handling where it differs from tar, perhaps this is another area where it falls short
[18:23] <kees> tar man says:
[18:23] <kees>        --no-same-permissions
[18:23] <kees>               apply umask to extracted files (the default for non-root users)
[18:23] <kees> so it seems that tar explicitly applies umask when unpacking
[18:25] <kees> ah, debian bug 470494
[18:37] <kees> james_w: until tarfile is fixed, would you consider switching to subprocess.call(['tar',...  ?
[18:37] <james_w> kees: yes, I would consider it
[18:41] <james_w> I need to do it to fix bug 303931 as well
[18:50] <kees> cjwatson: did you just ping seb128, or is there a more formal process to request pulls for a branch?
[18:51] <kees> (better yet, anyone from the desktop team able to pull cjwatson and my branches for vte?)
[18:51] <cjwatson> kees: I think I pung mvo
[18:53] <kees> james_w: this works for external tar usage (and likely solves your other bug too):  lp:~kees/bzr-builddeb/external-tar
[18:54] <kees> tedg: around?  can you merge two branches of vte for me and cjwatson?
[18:54] <tedg> kees: Me?
[18:55] <kees> tedg: yawp
[18:55] <kees> tedg: you're in the ubuntu-desktop group
[18:55] <tedg> Heh, yeah, but considering I'm not on that team I'd feel a little odd about editing their branches.
[18:55] <tedg> bryce: ^
[18:56] <kees> tedg: you're the only one in the timezone.  :)  and bryce isn't on the member list for some reason.
[18:56] <cjwatson> FWIW I already uploaded my branch to the archive with consent from other folks involved
[18:56] <tedg> kees: Heh, okay.
[18:57] <cjwatson> so pulling it would just reflect reality
[18:57] <kees> I didn't really have consent exactly, but I just did a patch update to match the current upstream tracker.
[18:57] <tedg> kees: cjwatson: what are the branches?
[18:58] <kees> tedg: lp:~kamion/vte/udeb-fixes and lp:~kees/vte/bolding-update
[18:58] <cjwatson> into lp:~ubuntu-desktop/vte/ubuntu
[18:58] <cjwatson> you should just be able to pull the former; don't know if you'd need to merge or pull the latter
[18:59] <james_w> thanks kees
[18:59] <kees> james_w: np
[19:07] <tedg> kees: You just had to go and use a tag didn't you... now upgrading the branch format to support tags...  :)
[19:09] <kees> tedg: d'oh, sorry, it's part of the process I was trying to follow.  :P
[19:11] <tedg> kees: No problem.  No stack dumps on bazaar this time, so I'm a happy bazaar user today :)
[19:11] <tedg> kees: cjwatson: pushed.
[19:12]  * kees hugs tedg
[19:15] <bgamari> Has anyone put together Python 2.6 packages for Intrepid yet?
[19:15] <bgamari> According to bug #278230, it was supposed to be released in a PPA after release?
[19:30] <btQuark> any idea if the synaptics-usb kernel driver is to be supported any time soon?
[19:30] <btQuark> i've created a ticket on some of the ubuntu trackers (brainstorm imho) but did not get any responses
[19:30] <btQuark> actually the drivers seems to work well, but is in conflict with the hid-drivers
[19:31] <btQuark> and needed to use the synaptics x driver with any synaptics device connected via usb
[19:31] <btQuark> provided by jan-steinhoff.de
[19:31] <btQuark> it would be most lovely it that would work :D
[19:42] <RoyK> hi. where does ubuntu get the weather data shown in the status line?
[19:45] <ogra> it asks the little frog builtin to your CPU
[19:53] <btQuark> rofl
[19:56] <quadrispro> lol
[19:56] <RainCT> XDD
[20:06] <bryce> ogra: you're saying your CPU croaked?
[20:06] <ogra> yeah, but mine already has T.O.A.D 2.0 builtin :)
[20:07] <ogra> waay advanced :)
[20:07] <ScottK> Based on calc's feedback on weather, I thought it was anywhere it doesn't matter because you don't know where you live anyway.
[20:10] <ogra> ScottK, well, actually it polls airport data ... prob is if you dont live near an airpirt you have no weather ...
[20:20] <jpds> RoyK: It uses libgweather.
[20:27] <mvo> kees: what branch do you want me to merge? happy to do that
[20:28] <RoyK> jpds: any idea what weather source that uses?
[20:30] <ogra> RoyK, airport data
[20:31] <jpds> RoyK: According the source, various sources, but you might have better luck looking around: http://svn.gnome.org/viewvc/libgweather/trunk/
[20:32] <ogra> try: firefox file:///usr/share/libgweather/Locations.xml
[20:33] <ogra> that gives you a list of all known locations mapped to the airport
[20:34] <RoyK> why on earth would people write XML files in one line?
[20:36] <ogra> RoyK, because it saves whitespace ... (i agree its silly, but it might save a byte or so and usually xml is interpreted)
[20:37] <ogra> thats why i pointed you to firefox ;)
[20:38] <RoyK> I didn't see that - just opened it with vi
[20:39] <RoyK> still doesn't say anything about the source used
[20:42] <RoyK> hm. that svn repo doesn't work
[20:43] <ogra> RoyK, it uses the NWS servers
[20:46] <RoyK> ogra: ok
[20:46] <RoyK> ogra: are their data available freely_
[20:46] <RoyK> ?
[20:46] <ogra> apparently
[20:47] <ogra> i know many IRC bots using it
[20:47] <RoyK> ok
[20:48] <RoyK> met.no, the Norwegian counterpart just opened all their data recently - with lots of details down to weather reports for small towns with 500 people and so on
[20:48] <RoyK> worldwide as well
[20:48] <RoyK> a few companies have been a little pissed off by them for that :)
[20:49] <RoyK> see yr.no for the main site
[20:49] <ogra> i guess you could patch gweathr to use other servers
[20:53] <LaserJock> I just leave the lab once in a while and look outside :-)
[20:58] <ogra> LaserJock, pfft, thats cheating ... thats like taking to your wife across the table while you could IM her
[20:58] <ogra> *talking
[20:58] <RoyK> lol
[20:59] <LaserJock> ogra: yeah, I suppose it is
[20:59] <LaserJock> I need to figure out a nice avahi Valentines Day gift
[20:59] <ogra> *grin*
[21:00] <LaserJock> maybe just ssh in to her laptop and change the background to a vase of roses?
[21:00] <LaserJock> much cheaper :-)
[21:04] <ogra> lol
[21:39] <mathiaz> If a package (mysql-server-5.1) declares a conflict with another one (mysql-server-5.0) but *no* replaces what should apt-get install mysql-server-5.1 do on a system with mysql-server-5.0 installed?
[21:42] <mathiaz> apt-get shows that mysql-server-5.0 will be removed and mysql-server-5.1 installed.
[21:42] <mathiaz> isn't a conflict supposed to prevent that?
[21:43] <cpufreak> a conflict means they can't both be installed at the same time.
[21:48] <mathiaz> shouldn't apt-get refuse to install mysql-server-5.1 rather than remove mysql-server-5.0 and installing mysql-server-5.1?
[21:51] <LaserJock> mathiaz: hmm, is it perhaps guessing since you've explicitly said you wanted to install mysql-server-5.1 that mysql-server-5.0 is "lower priority"?
[21:52] <LaserJock> so "I want to install" is higher priority than "already installed"
[21:53] <mathiaz> LaserJock: hm. may be. What I want to achieve is that if mysql-server-5.0 is installed you cannot install mysql-server-5.1 (which would be an upgrade from mysql point of view)
[21:54] <mathiaz> LaserJock: if there isn't any replaces then the install fails because /usr/bin/mysqld is both in -5.0 and 5.1
[21:55] <LaserJock> mathiaz: well, I think the Conflicts system just says "you can't have both"
[21:57] <mathiaz> According to the debian policy (http://www.debian.org/doc/debian-policy/ch-relationships.html - 7.4 Conflicting binary packages - Conflicts): if the package being installed is marked as replacing [...] then dpkg will automatically remove the package which is causing the conflict, otherwise it will halt the installation of the new package with an error
[21:57] <mathiaz> in this use case mysql-server-5.1 does *not* replace mysql-server-5.0
[21:57] <mathiaz> it only conflicts with mysql-server-5.0
[21:57] <LaserJock> right
[21:59] <LaserJock> so is there a problem with people installing -5.1?
[22:00] <Laney> that talks about dpkg
[22:00] <Laney> apt must be being more clever than that
[22:00] <mathiaz> LaserJock: a fresh install of 5.1 works
[22:00] <mathiaz> LaserJock: however if you have 5.0 installed you'd better not install 5.1
[22:01] <LaserJock> mathiaz: why not?
[22:01] <mathiaz> LaserJock: even though 5.0 and 5.1 are considered two different src packages they share data
[22:01] <LaserJock> but Conflicts makes sure you don't have both
[22:01] <mathiaz> LaserJock: so installing 5.1 tries to setup a brand new install
[22:02] <mathiaz> LaserJock: while there is already one running for 5.0
[22:02] <mathiaz> LaserJock: there isn't any proper upgrade logic in 5.1 to handle an upgrade from 5.0
[22:02] <mathiaz> LaserJock: and I don't plan to get this done in jaunty
[22:02] <LaserJock> that sounds kind of like a different kind of problem though
[22:03] <mathiaz> LaserJock: so I want to make sure that people can't install 5.1 if they have 5.0 already there
[22:03] <LaserJock> does Replaces work?
[22:03] <LaserJock> will that remove 5.0 first?
[22:04] <mathiaz> LaserJock: yes - even *without* Replaces 5.0 is removed
[22:04] <mathiaz> LaserJock: yes - even *without* Replaces, 5.0 is removed
[22:13] <kirkland`> any idea why a fresh install of Jaunty desktop would leave me with really huge, strange looking fonts?
[22:14] <maxb> dpi issue - System > Preferences > Appearance > Fonts > Details... > override DPI to 96 and see if it looks sane again
[22:17] <beuno> pitti, FWIW, some update today fixed the black-screen-on-startup issue for me
[22:18] <cjwatson> tedg: vte> thanks
[22:20] <cjwatson> bgamari: "deb http://ppa.launchpad.net/doko/ppa/ubuntu jaunty main" - no extensions yet, though, so it may not be very useful in many cases. It's planned to go into Jaunty over the next few days though
[22:20] <cjwatson> mathiaz: there is no way, period, for a package to say that it may not be removed in favour of another package
[22:20] <bgamari> cjwatson, alright, I just installed jaunty
[22:20] <cjwatson> mathiaz: Conflicts says that they can't be installed simultaneously, and Conflicts+Replaces says "can't be installed simultaneously, also this one is better than that other one so use it if you can't decide"
[22:21] <bgamari> cjwatson, It will still be a few days though?
[22:21] <cjwatson> bgamari: yes
[22:21] <cjwatson> mathiaz: if this is a problem, maybe having upgrade logic in 5.1 *needs* to be on your (plural) list for jaunty ...
[22:21] <bgamari> cjwatson, alright, thanks
[22:21] <cjwatson> mathiaz: or else fail in 5.1's preinst, but that will cause confusion for users
[22:22] <mathiaz> cjwatson: ok - I'll see how complicated the upgrade logic would be. The backup plan is to fail in preinst
[22:22] <cjwatson> BTW, the reason that Conflicts+Replaces has a special meaning distinct from Replaces is not entirely obvious (or at least wasn't to me) but is quite simple
[22:23] <cjwatson> the reason is that Replaces talks about what happens when two packages are installed simultaneously but share files
[22:23] <cjwatson> but Conflicts ensures that the two packages cannot both have their files unpacked
[22:23] <cjwatson> so when Conflicts is used, Conflicts+Replaces is free for another bit of information
[22:24] <cjwatson> there are a lot of places in the archive where people use Conflicts+Replaces but meant to use just Replaces; this is partly because until a couple of years ago dpkg didn't handle Replaces on its own quite right, so people used Conflicts+Replaces to force the issue
[22:25] <LaserJock> hmm, I'm really getting to think cjwatson > Policy :-)
[22:27] <Keybuk> cjwatson: random of the day
[22:27] <Keybuk> do we have to include Canonical's own copyright in debian/copyright for upstream packages we patch? :)
[22:32] <nhandler> cjwatson: You really should add that to some FAQ on the wiki (if it exists). That is a pretty common question that many people have. It would be great to be able to point them to a wiki page instead of trying to explain it each time
[22:32] <cjwatson> LaserJock: Policy says this, it's just a bit vague about it
[22:32] <cjwatson> nhandler: actually, I'd rather expand it in the policy manual
[22:32] <cjwatson> it's silly to have a document, and then a clarification document
[22:32] <nhandler> cjwatson: That would work too ;)
[22:33] <cjwatson> Keybuk: depends how significant and original our changes are, I suppose
[22:35] <cjwatson> I thought we had some kind of document about this, but can't find it
[22:48] <Keybuk> cjwatson: well, our copyright line is in the upstream .c file
[23:16] <cjwatson> Keybuk: technically speaking it probably ought to be acknowledged in debian/copyright; this should all be a bit more rational with the new copyright format, I think
[23:18] <Keybuk> there's a new copyright format?
[23:19] <cjwatson> http://wiki.debian.org/Proposals/CopyrightFormat
[23:19] <Keybuk> let me guess, rfc822 files?
[23:19] <cjwatson> what else?
[23:20] <LaserJock> copyrightkit
[23:20] <ion_> laserjock: :-D
[23:20] <cjwatson> usual caveats about design-by-wiki-committee, but the guts of the proposal are pretty good
[23:21] <Keybuk> that is a massive document
[23:22] <cjwatson> it is, but most of it is devoted to enumerating machine-readable names for individual licences
[23:22] <cjwatson> it's got a bit out of hand in the last few months and needs to be taken off the wiki and trimmed down by a maintainer
[23:23] <cjwatson> looks like there's consensus among the active editors that that needs to happen, so it should happen post-lenny
[23:23] <cjwatson> ... i.e. next week
[23:24] <cjwatson> Keybuk: /usr/share/doc/base-passwd/copyright is my interpretation of what the results would actually look like, although it's written to a somewhat older version
[23:25] <cjwatson> oh, the proposal also has lots of inline comments, further increasing massiveness
[23:26] <Keybuk> doesn't that just make the whole thing overly complicated?
[23:26] <Keybuk> previously I just amalgamated all the various copyright lines into one bloce
[23:27] <Keybuk> now every time every single file has a slightly different copyright line, you need to list it separately?
[23:27] <cjwatson> Files: *
[23:28] <cjwatson> I think you could perfectly well get away with smoothing over trivial differences
[23:28] <Keybuk> is that allowed?
[23:28] <Keybuk> in your example, you list different files in different blocks just because they have different copyright, but the same licence
[23:30] <cjwatson> only because they had completely different heritage
[23:30] <cjwatson> the copyright dates on the .c file and the man pages are probably not identical, for instance
[23:30] <cjwatson> I think stating the union is fine
[23:31] <directhex> cjwatson, copyrightformat needs a sensible way to document +dfsging source
[23:31] <cjwatson> if it were very fiddly I'm pretty sure I would just list all the copyright holders in Files: src/* or whatever
[23:31] <cjwatson> same as upstream probably does in AUTHORS
[23:32] <cjwatson> directhex: why isn't that in debian/README.source, which documents other unusual source handling practices?
[23:32] <cjwatson> directhex: although if you search for "orig" in the proposal you'll find a comment about this
[23:33] <directhex> cjwatson, it is. it just seems opportune to have a machine-readable list of +dfsg changes, if you're having a machine-readable list of other things
[23:33] <cjwatson> anyway, given a vaguely sane editor and marginally less wikibikesheddery I think it should be OK
[23:35] <directhex> we've been using it for a while in pkg-monofoo, but it's definitely changed at least once between when we started using it & now
[23:35] <cjwatson> yes
[23:35] <cjwatson> I certainly don't think it's ready yet, although I've started using it with a nominated revision in some of my packages for practice
[23:36] <cjwatson> among other things, GPLv3 taught us that we need some kind of automated way to track this stuff
[23:36] <directhex> if nothing else, something approximating the copyright format is *MUCH* nicer for *HUMAN* readability than a wooly "well, it's a bit o' this and some o' this"
[23:36] <RAOF> I also like the structure; I find it makes it easier for me to do the initial copyright search and to update stuff.
[23:37] <directhex> and a dash o' that
[23:37] <directhex> RAOF, updating copyright seems to never ever happen
[23:37] <cjwatson> rarely, at least. I do try to remember on new upstream versions
[23:37] <cjwatson> but particularly when it's just a year update, people forget
[23:37]  * RAOF checks his copyright on new upstreams fairly conciensiously.
[23:38] <directhex> i've been bitten by people not updating their copyright when trying to re-use some of their content
[23:38] <RAOF> Right.  Hello, tomboy keybinding code!
[23:38] <cjwatson> copyright is important to acknowledge, but we're unlikely to be breaking any laws by leaving a holder out of debian/copyright (it'll be documented in the files themselves anyway)
[23:38] <cjwatson> whereas licences are actually important to track
[23:39] <cjwatson> and also change rather more rarely and with more fanfare, so are a bit easier to pay attention to
[23:39] <directhex> cjwatson, from where i'm sat i don't care as long as ftpmaster lets it through the gate
[23:39] <cjwatson> as an Ubuntu ftpmaster, I care :)
[23:41] <directhex> as an ubuntu ftpmaster, you have a waiting list of less than a month. copyright needs to be pristine first try in debian because if it ain't, then it's to the back of the queue
[23:43] <LaserJock> does anybody know if the text installer on the DVD runs tasksel at all?
[23:43] <directhex> and the back of the queue sucks
[23:49] <cjwatson> directhex: I think it's worth recognising that the Debian FTP team has other things to do with lenny coming on
[23:49] <cjwatson> s/on$/up/
[23:49] <cjwatson> and TBH, every time you've mentioned mono in the last month it seems to have gone with a complaint about Debian NEW
[23:49] <cjwatson> I understand your frustration but ...
[23:49] <cjwatson> LaserJock: yes
[23:50] <directhex> cjwatson, i'm a mono packager, what else am i likely to mention?
[23:50] <cjwatson> it just gets a bit old
[23:50] <LaserJock> cjwatson: as in, does it offer the user task selections?
[23:50] <cjwatson> LaserJock: should od
[23:50] <cjwatson> do
[23:50] <LaserJock> cjwatson: hmm, ok, I'll give it a go again, I got impatient
[23:50] <cjwatson> tasksel should offer task selection provided that more than one task is available on the DVD, and it isn't preseeded
[23:51] <cjwatson> mind you, I guess it might be preseeded
[23:51] <LaserJock> ah, ok
[23:51] <cjwatson> yeah, I suppose it is
[23:51] <cjwatson> does this need to be changed?
[23:51] <LaserJock> because it was acting just like the regular Ubuntu Alt CD
[23:51] <LaserJock> well, I was trying to think of ways people could get Edubuntu all in one go
[23:52] <LaserJock> and since the DVD is the only place were all the needed packages exist, it'd be nice
[23:52] <cjwatson> it does make some sense to remove that
[23:52] <LaserJock> also, I used the 8.10 DVD and I didn't see a LTSP install option
[23:52] <LaserJock> when I hit F4 that is
[23:54] <cjwatson> that's odd, it looks like it's there
[23:54] <cjwatson> file a bug about that one
[23:55] <cjwatson> I suspect that gfxboot-theme-ubuntu is a bit confused about what it's booting
[23:55] <TheMuso> cjwatson: whats with ports images in http://cdimage.ubuntu.com/daily/current?
[23:55] <LaserJock> cjwatson: I get Normal, Safe graphics mode, Use driver update CD, OEM install from the F4 menu
[23:56] <cjwatson> TheMuso: I screwed up
[23:56] <TheMuso> Ok np, just checking to see if it was known.
[23:56] <cjwatson> I was doing an image rebuild and accidentally did so from a shell in which I had been doing some script debugging and had some variables exported
[23:56] <TheMuso> np.
[23:56] <LaserJock> cjwatson: what should I file a bug against?
[23:57] <cjwatson> TheMuso: I'll fix it up now, thanks for the reminder
[23:57] <cjwatson> LaserJock: gfxboot-theme-ubuntu