[01:37] <ion> org.freedesktop.PowerManagement.Backlight.SetBrightness has disappeared :-(
[01:41] <ion> Ah, it has been renamed as org.gnome.PowerManager.Backlight.SetBrightness
[02:17] <ebroder> Any backporters who could look at bug #406680?
[02:32] <meunierd> exit
[02:42] <dtchen> hyperair: yes, the flatvol implementation in 0.9.15 is ... interesting (and intentional). it has been tweaked in 0.9.16(-test3).
[02:43] <dtchen> billybigrigger: unlikely pong
[03:02] <billybigrigger> dtchen, hehe, vacation?
[03:02] <billybigrigger> you must have a nice scrollback set that was days ago
[03:05] <dtchen> billybigrigger: no, traveling for work
[03:05] <billybigrigger> nice
[03:05] <ScottK> ebroder: Commented.
[03:05] <billybigrigger> well i think my question was something to do with pulse the other day
[03:06] <billybigrigger> i don't really remember the problem anymore, i think changing tsched=1 in default.pa fixed some problems
[03:06] <dtchen> billybigrigger: ok, well, the latest pulse upload in karmic has that set anyhow.
[03:06] <dtchen> (thanks, TheMuso!)
[03:07] <billybigrigger> oh, i remember now, everytime any audio player, or media player for that matter, changed to the next song/video, the application volume reset itself to mute or 0% in the new sound preferences
[03:07] <billybigrigger> and a weird volume issue where the next song would be %100, then %118 140 160 etc...
[03:07] <billybigrigger> but that seemed to have stopped too
[03:07] <billybigrigger> so all is good with the new update i guess
[03:08] <billybigrigger> keep up the great work guys, pulse seems to be coming along quite nicely, at least from a user perspective
[03:09] <billybigrigger> i don't know how it goes on the other end :P
[03:16] <ion> billybigrigger: One doesn’t need a huge scrollback, just a functional awaylog. :-)
[03:17] <ebroder> ScottK: For libcompizconfig, do I need to test that it still builds against the new protobuf?
[03:17] <ebroder> Or just that the current one runs with the new libprotobuf3?
[03:35] <hile> anyone noticed that firefox internal window cancel,ok buttons in karmic are reversed compared to gnome defaults? i.e. ok,cancel vs. cancel,ok
[03:36] <hile> very, very confusing when open,print,save are coming from gnome and are in the 'normal' gnome order
[03:40] <hile> I was downloading a file, press the usual button and wondered why nothing happened, then actually read the button 'oh it's cancel not ok in right lower corner'
[04:01] <ion> themuso: I posted https://bugs.edge.launchpad.net/ubuntu/+source/rtkit/+bug/406702
[04:05] <TheMuso> ion: Yes, the kernel does not yet have the bits needed yet.
[04:06] <TheMuso> ion: I hope to push the needed kernel aptches to the kernel team shortly.
[04:06] <ion> themuso: Ah, ok. Should i change it to affect linux instead of rtkit?
[04:09] <TheMuso> ion: Please, and assign it to me if you will.
[04:14] <ion> themuso: Done
[04:23] <TheMuso> ion: thanks
[06:26] <ScottK> ebroder: I see you covered both cases.  That it runs.  If it didn't run, but would run after a rebuild, then we'd have to backport that too.
[06:28]  * ebroder nods
[06:29] <ScottK> ebroder: I did just approve the backport.  Up to a Canonical archive admin now.
[06:29] <ebroder> Yeah, I saw. Thanks a lot
[06:30] <ScottK> No problem.
[06:40] <hyperair> dtchen: tweaked how?
[06:59] <dtchen> hyperair: it's known as reference volumes; see commit fe8b10cc05b3b8e8633ffaff30e73a40a30c8bf8 and http://pulseaudio.org/wiki/InternalVolumes
[06:59] <hyperair> hmm i'll take a look, thanks
[07:13] <ebroder> Any recommendations for tools to create a partial mirror of an apt repo (e.g. just grab jaunty)?
[07:13] <pitti> Good morning
[07:13] <pitti> ebroder: use debmirror, it's magic
[07:14] <ebroder> pitti: I'll take a look
[07:14] <pitti> ebroder: that can filter by release, component, sections, and just about anything else
[07:14] <TheMuso> Seems we have non-installable alternates. Went to do a fresh install on my notebook today before the sprint, and found that grub-pc is uninstallable, as well as an -en langpack. Yay! :)
[07:15] <pitti> ebroder: you can also do things like exclude *-dev or *-doc
[07:15] <ebroder> pitti: Awesome. That looks like exactly what I want
[07:16] <ion> bryce: Does it look like karmic will get radeon KMS?
[07:28] <hyperair> dtchen: in that case, wouldn't it be a good idea to have gsd change the reference volume as well, similar to scrolling on the volume control applet?
[07:29] <hyperair> dtchen: it gets rather confusing if you use both
[07:29] <hyperair> hmm no wait, it seems to use that already
[07:29] <hyperair> nevermind, i'm just outdated
[07:32] <hyperair> dtchen: is there some way to change this volume using the command line?
[07:33] <\sh> ebroder: check http://www.sourcecode.de/content/ubuntu-mirror-what-if-i-need-it-easy <- those are my magic debmirror scripts
[07:34] <\sh> I should push those shell snippets into an LP bzr repo..in the meantime those scripts evolved
[08:27] <lool> ScottK: Thanks I see that libio-compress-perl is upgradeable now; probably some bits are still in universe but at least its insallable again
[08:50] <evand> ScottK: Just a heads up: usb-creator for Windows didn't make it on today's kubuntu-netbook daily-live because there was an error in my changes to the cdimage build scripts.  I've fixed the problem and the next spin of kubuntu-netbook should have it.
[09:55] <ojwb> mvo: I've uploaded 1.0.14-1 packages for xapian-* to debian unstable, with the include-links thing
[09:57] <mvo> ojwb: oh, nice! I will sync/merge it into karmic, thanks a lot!
[09:59] <ojwb> mvo: cool - also if you want to test the value update optimisation patch, that'd be great
[10:00] <mvo> ojwb: thanks, I will give it a go - we do not yet use the values that much in apt-xapian-index, but I expect that is going to change :)
[10:00] <mvo> ojwb: my feeling is we are still (by far) not using all the portential of xapian, I'm constantly impressed by it (I'm porting gnome-app-install to use it as its backend database currently)
[10:01] <mvo> potential even
[10:01]  * mvo makes too many typos
[10:03] <ojwb> yeah, there are a growing number of neat features
[10:10] <ojwb> .-
[10:10] <ojwb> oops
[10:17] <pitti> mvo: hm, apt-get source --only-source linux still doesn't give me what I want
[10:17] <pitti> mvo: isn't --only-source meant to do that?
[10:18] <mvo> pitti: you want linux-image and not linux-meta?
[10:18] <pitti> yes
[10:18] <pitti> it's as if --only-source did nothing
[10:18] <pitti> I want the "linux" source package
[10:20] <mvo> pitti: hm, that looks like the binary-name vs source-name problem came back, I have a look
[10:20]  * mvo adds it to his gtg
[10:20] <pitti> mvo: want a bug for that?
[10:20] <mvo> pitti: I don't think its needed, I added it to my todo list for today
[10:20]  * pitti hugs mvo, thanks! (not that urgent, though)
[10:21] <pitti> I just wondered if I misunderstood --only-source or so
[10:29] <mvo> pitti: its supposed to work like you expected it to work, probably a bug somewhere
[11:33] <pitti> *nnng* need python 2.6 in sid
[11:40] <pitti> doko: ^ any plan when that happens?
[11:41] <doko> gcc-4.4 and openjdk-6 first ...
[11:42] <pitti> ah, ok
[11:43] <ScottK> evand1: Thanks.
[11:44] <ScottK> lool: re: libio-compress-perl and the MIR paperwork is in progress too.
[11:45] <pitti> doko: one question, even if I b-dep on python2.6-dev and set "XS-Python-Version: 2.6", the dependency ends up as python (>= 2.6)
[11:45] <pitti> doko: this won't work in debian experimental, thouhg, since python-defaults still points to 2.5
[11:46] <pitti> doko: is there a way to force the usage of 2.6 in dependencies, etc.? is there some magic to update the hashbang lines accordingly?
[11:47] <doko> pitti: no, needs to be done manually
[11:47] <pitti> ok
[12:02] <slytherin> RainCT: nhandler: Is it possible to add a 'dateofupdate' field to revu DB. The purpose of the field will be to keep track of last updated date of the package (dateofupload will contain date of first upload). We can then sort the list on main page with dateofupdate. Will help in tracking which packager is more responsive to the comments.
[12:50] <Keybuk> why are all my logins so slow now?
[12:50] <seb128> Keybuk, define login?
[12:52] <Keybuk> logins
[12:52] <Keybuk> err
[12:53] <Keybuk> ssh, console, that kind of thing
[12:54] <jpds> Keybuk: Use encrypted ~/Private?
[12:54] <Keybuk> npe
[12:54] <Ng> hey look at that, console logins are slow. disabling pam_motd.so from pam.d/login helps some
[12:55] <Keybuk> yes, I was wondering whether I was having a _personal_ MOTD generated just for me
[12:56] <ogra> do you have your sound on ? it might try to talk to you with a hal'ish voice "hello dave^Wscott"
[13:00] <Ng> Keybuk: looking at the code I don't think it does do that, or at least that module doesn't
[13:04]  * Ng sighs, I just fail at getting the right source and reading it, apparently. it does run-parts /etc/update-motd.d/
[13:04] <Ng> quite how apt-get source failed to show me that, I don't know
[13:32] <RainCT> slytherin: there's no need to add such a field, you can just do a subquery
[13:33] <RainCT> slytherin: something like   (SELECT dateOfUpload FROM Upload WHERE sid=X ORDER BY dateOfUpload DESC LIMIT 1) AS dateOfUpdate
[13:34] <slytherin> oh
[13:34] <slytherin> I didn't think that was possible. I am not yet completely familiar with DB structure.
[13:35] <RainCT> slytherin: don't subestimate SQL ;)
[14:28] <mvo> pitti: the apt-get source --only-source issue should be fixed in bzr now
[14:38] <tgpraveen> has it been decided which bluetooth stack software will be used?is it blueman?
[14:42] <slytherin> tgpraveen: Latest gnome-bluetooth (which is now fork of bluez-gnome) seems to have same functionality. So it is more like candidate. But I am not the maintainer of bluetooth stack, so I don't know for sure.
[15:13] <dpm> pitti: hi, I've been working with Riddell to fix bug 376686. We've got a fix now and it's sitting in the unapproved -proposed queue. May I ask you to approve it?
[15:46] <Keybuk> pitti: how did you force gdm to start X on vt7?
[15:47] <Keybuk> and is there a way to override that?
[15:48] <seb128> Keybuk, he did code changes to use -vt7
[15:48] <seb128> -        res = gdm_server_spawn (server, NULL);
[15:48] <seb128> +        res = gdm_server_spawn (server, (f > 0) ? "vt7" : NULL);
[16:25] <lool> cjwatson: pokely
[16:25] <ogra> heh, good luck
[16:25] <lool> cjwatson: Your latest usplash change exposes crashes in usplash
[16:25] <lool> ogra: He's on leave?
[16:25] <ogra> debconf
[16:26] <lool> Ah I thought it was over
[16:26]  * lool sucks
[16:26] <ogra> and you are even DD :)
[16:41] <slytherin> any of the archive admins free enough to review and approve jakarta-jmeter source from NEW queue?
[17:12] <gilesw> heya all
[17:19] <mathiaz> james_w: hey
[17:19] <mathiaz> james_w: regarding https://code.launchpad.net/~mathiaz/ubuntu/karmic/cim-schema/2.22.0-update/+merge/9397
[17:19] <mathiaz> james_w: ttx approved the review
[17:20] <mathiaz> james_w: and I just uploaded the new package to the archive. What should I do with the merge request?
[17:20] <mathiaz> james_w: IIUC I cannot commit it to the lp:ubuntu/karmic/cim-schema/ branch. Should I just delete it?
[17:22] <james_w> mathiaz: you will have to mark it as merged for now
[17:22] <mathiaz> james_w: great thanks.
[17:22] <james_w> you will be able to push soon, which will do that automatically
[17:23] <mathiaz> james_w: regarding sblim-cmpi-base is it still in the import queue?
[17:23] <mathiaz> james_w: https://code.launchpad.net/ubuntu/+source/sblim-cmpi-base/ is almost empty
[17:23] <mathiaz> james_w: except for my own branch.
[17:26] <james_w> mathiaz: good question
[17:26] <james_w> mathiaz: I can't work out now
[17:32] <james_w> mathiaz: fixed, should be up soon, thanks for reporting
[17:47] <mathiaz> james_w: thanks. Does the fact that I've already created my own branch be a problem for the import?
[17:47] <mathiaz> james_w: thanks. Does the fact that I've already *pushed* my own branch be a problem for the import?
[17:47] <james_w> mathiaz: nope
[17:47] <james_w> though it will completely ignore your branch :-)
[17:47] <mathiaz> james_w: my own branch will just overwritten?
[17:47] <james_w> if that's not the right thing then we should talk
[17:47] <mathiaz> james_w: that's ok.
[17:47] <james_w> nope, your branch is ~mathiaz isn't it?
[17:48] <mathiaz> james_w: yes. ~mathiaz/ubuntu/karmic/sblim-cmpi-base
[17:48] <mathiaz> james_w: I was thinking about the stacked branch format for the repository
[17:48] <mathiaz> james_w: as this is what I'm using locally (bzr init-repo --2a)
[17:51] <james_w> mathiaz: ah, yeah, it won't stack
[17:52] <james_w> that's only an optimization though
[18:10] <mathiaz> james_w: is bzr-loom still developed?
[18:10] <james_w> vaguely
[18:10] <james_w> lifeless merges packages
[18:10] <james_w> patches I mean
[18:10] <james_w> but doesn't actively develop at the moment
[18:10] <james_w> he says that he still plans to
[18:11] <mathiaz> james_w: ok - I've got a branch (openldap) that uses looms
[18:11] <james_w> nice
[18:11] <mathiaz> james_w: to maintain different patches that I wanna send to debian
[18:11] <mathiaz> james_w: but my local version of bzr-loom doesn't seem to work with bzr 1.17
[18:12] <james_w> we can have a look next week if you like?
[18:12] <mathiaz> james_w: which branch of bzr-loom should I look at (lp:bzr-loom)?
[18:13] <james_w> I assume so
[18:13] <mathiaz> james_w: ok - it seems to work now :)
[18:16] <bryce> ion, hopefully
[18:35] <ebroder> Hmm...anybody have a ballpark estimate of how much space a mirror of jaunty{,-security,-updates} takes up?
[18:35] <liw> a few tens of gigs
[18:36] <liw> there should be a tool for computing that, somewhere, I'm sure of it
[18:41] <ebroder> including source packages?
[18:41] <liw> I think so
[18:42] <ebroder> Cool. I should have that much disk space. Let's see how this goes
[18:42] <liw> there's probably a statistics page somewhere
[18:45] <ebroder> https://help.ubuntu.com/community/Debmirror has some old ballpark estimates
[18:46] <ebroder> For a single architecture
[19:23] <ssam> has the osmium builder got stuck? it should not take 24hours to compile a small package
[19:41] <geser> ssam: better ask in #launchpad
[19:44] <ssam> geser, thanks
[21:01] <seb128> mathiaz, hello
[21:01] <mathiaz> seb128: hey
[21:26] <lifeless> mathiaz: james_w: I'd love to spend a week on just on loom, not on the immediate cards I'm afraid; however bugs will get fixed - just be sure to file em ;)
[21:26] <mathiaz> lifeless: how is loom related with pipes?
[21:27] <lifeless> theres some significant overlap in the use cases they want to solve
[21:28] <lifeless> they take a significantly different internal approach to the problem
[21:28] <mathiaz> lifeless: right - the user experience seem to be the same though.
[21:34] <lifeless> mathiaz: the main difference is that a pipeline is a set of full branches; there isn't any versioning about that set
[21:34] <lifeless> loom is a version set of lighter-than-normal branches
[21:35] <mathiaz> lifeless: so there isn't an equivalent of record in the pipeline plugin?
[21:35] <lifeless> correct
[21:53] <d_ed> hey, if I have a source package that creates multiple packages (i.e kdepim creates kmail, organizer, etc...) is there a way I can tell debian/rules that I only want to build one of them?
[21:53] <ebroder> In general, no
[21:53] <ebroder> You have to assume that the products of a single build stage are being spread across a bunch of binaries
[21:53] <d_ed> ok. that's a good enough answer as ever
[21:54] <ebroder> And the rules file isn't usually clever enough to separate that single build stage into the individual stages that make up each binary package
[21:54] <d_ed> yeah, I got that impression. There were a bunch of filenames that seemed to be a list of what to put where after doing a build
[21:54] <d_ed> ta anyway
[22:26] <LordMetroid> Is the upcomming Ubuntu based on Lenny?
[22:26] <LordMetroid> I suppose so, right?
[22:27] <directhex> LordMetroid, all ubuntu releases are based on a snapshot of sid
[22:27] <LordMetroid> Ohh, I see
[22:41] <pgraner> bryce: ping
[22:42] <bryce> pgraner, yep
[22:44] <pgraner> bryce: quick question, I just got a SDP from Intel with 2 G92 Nvidia cards. I have two monitors and wanted to run both at the same time, is there any X magic to get both cards working at the same time?
[22:44] <bryce> pgraner, you'll need to use the proprietary drivers and use their config tools to set it up
[22:45] <pgraner> bryce: :-(
[22:45] <pgraner> bryce: ok, I'll give it a whirl then ...
[22:45]  * pgraner notes that its complete suckage that way
[22:45] <bryce> pgraner, X on the foss side doesn't support multiple video cards yet
[22:46] <bryce> if you can hook both of the monitors to a single card, and leave the other card disabled, you may have luck using -nouveau
[22:46] <pgraner> bryce: naw they both only have one port
[22:46] <bryce> yeah then you're sol, sorry
[22:47] <pgraner> bryce: thanks for the advice
[22:47] <bryce> pgraner, a dual-output 5xx-class ATI card is cheap and would definitely do it....
[22:48] <pgraner> bryce: good to know. I have 2x 30" monitors and would like a good 3d card that can drive both
[22:49] <bryce> yeah I have a RV535 [Radeon X1650 Series]  with a pair of 30" screens here I use day to day.  No probs, can use compiz, 3d, dual-head with max res of 3840 x 1200, fully open source drivers and all
[22:50] <pgraner> bryce: sweet, I need to get that card.
[22:50]  * pgraner runs off to ebay
[22:51] <pgraner> bryce: I was trying to make what Intel sent work, however the proprietary drivers are acting funky
[22:51] <infinity> pgraner: So, you have some nvidia cards you need to get rid of, then? :P
[22:52] <pgraner> infinity: I wish, Intel will want them back in the end :-(