[00:12] <ebroder> Does anybody have any recommendations for docs on writing PolicyKit-aware apps?
[01:56] <dtchen> cjwatson: yes, xfonts-scalable can be synced.
[02:07] <wip> hello everyone, i really just need to know if a new rt-kernel is coming out soon. (or maybe i have to recompile it myself, cause there's no plan for rt release)
[02:08] <wip> i just need a quick reply on this matter...
[02:23] <dtchen> wip: #ubuntu-ports or #ubuntustudio-devel. also, quite likely.
[02:23] <wip> dtchen: thank you!
[02:41] <lifeless> doko: https://bugs.edge.launchpad.net/bzr/+bug/392355
[02:41] <lifeless> doko: any thoughts?
[02:42] <TheMuso> dtchen: I assume you are aware of why I can't do a test release of pulse 0.9.16-test1?
[04:00] <bjsnider> how can i stop dh_shlibdeps from adding a specific dependency?
[04:02] <StevenK> Stop linking against that library
[04:03] <bjsnider> it's not that simple
[04:03] <bjsnider> i need it as a build-dep
[04:04] <lifeless> bjsnider: thats orthogonal
[04:04] <bjsnider> but it is then automatically being added as a dependent package when in fact it isn't
[04:04] <lifeless> test via ldd
[04:04] <lifeless> I bet it is linked against
[04:04] <bjsnider> how would i do that?
[04:05] <lifeless> ldd <binary>
[04:09] <bjsnider> well, i don't have the binary
[04:09] <bjsnider> but are you saying the source code itself is asking for that file?
[04:09] <lifeless> what are you building?
[04:10] <ebroder> bjsnider: dh_shlibdeps looks through the resulting package for all binaries in that package, finds all libraries they link against, and adds those libraries as automatic dependencies
[04:10] <bjsnider> but when you say libraries they link against, that's int he source code, is that right?
[04:11] <bjsnider> in other words, it's not because of anything i put in the control file
[04:11] <lifeless> bjsnider: *what are you building* - a binary or a library, or both?
[04:11] <bjsnider> both
[04:11] <lifeless> so, use ldd on the binary
[04:12] <lifeless> or the library
[04:12] <bjsnider> i don't have them
[04:12] <lifeless> how can you not have them?
[04:12] <lifeless> you're building them in your debs
[04:12] <bjsnider> yeah
[04:12]  * ajmitch doesn't understand why this dependency shouldn't be added
[04:13] <bjsnider> it isn't a dependency
[04:13] <bjsnider> the program doesn't need it to run
[04:13] <StevenK> According to ldd, it does
[04:13] <Pici> Are you sure?
[04:13] <bjsnider> it should be a suggests
[04:13] <bjsnider> wrong. i know better than ldd
[04:13] <lifeless> then unpack the deb, and check with ldd
[04:13]  * ebroder disbelieves
[04:13] <lifeless> its very simple
[04:13] <bjsnider> i think this thing is just too...what's the word
[04:13] <lifeless> 'correct'
[04:13] <bjsnider> immature
[04:13] <StevenK> Haha
[04:13] <bjsnider> unpolished
[04:14] <bjsnider> alpha
[04:14] <StevenK> I call bullshit
[04:14] <lifeless> bjsnider: have you checked with ldd, or are you just speculating?
[04:14] <lifeless> bjsnider: and do you know what ldd actually does?
[04:14] <bjsnider> well, let me download the thing...
[04:14] <bjsnider> of course not
[04:15] <bjsnider> if i knew that it did i wouldn't be in here
[04:15] <lifeless> man ldd gives a reasonable description
[04:15] <lifeless> note that the *docs* are 8 years old. God knows how old ldd itself is :)
[04:15] <ajmitch> probably about 30+
[04:15] <StevenK> Instead you come in here and accuse our tools of being immature and unpolished
[04:16] <lifeless> ajmitch: Actually, I suspect its from when a.out was superceded
[04:16] <ebroder> Sounds like a bad Western in the making. "For as long as there have been shared libraries, there's been an ldd..."
[04:16] <lifeless> ajmitch: but I don't recall the yar
[04:16] <ajmitch> lifeless: probably, I wouldn't expect it to go all the way back to prehistory
[04:17] <ajmitch> if the application is mistakenly linking against a shared library but uses none of its symbols, then that app needs fixed (iirc)
[04:17] <lifeless> thats right
[04:17] <persia> Right.  That's a build system issue,
[04:17] <lifeless> libtool can cause this
[04:17] <lifeless> as can scons
[04:17] <lifeless> and $homebrew
[04:17] <lifeless> but the first thing to do is to gather data
[04:18] <lifeless> find out which of the binaries||libraries are dragging in the dependency. Thus ldd
[04:18]  * lifeless goes off to write code
[04:19] <ajmitch> dpkg-shlibdeps throws up warnings in that case
[04:20] <bjsnider> what would such a warning look like?
[04:20] <RAOF> "useless dependency on $LIB could be dropped if $BINARY didn't needlessly link against it"
[04:20] <lifeless> its entertaining when dpkg throws that up and is wrong
[04:20] <bjsnider> ah, yes i recall seeing those when i was running debuild
[04:20] <lifeless> (because typedefs)
[04:21] <bjsnider> i don't think this is my problem
[04:27] <lifeless> bjsnider: well, do the ldd test, gather data and report back; I'm sure we can provide more hints
[04:27] <bjsnider> i can't do the ldd test
[04:27] <ebroder> bjsnider: Then we can't help you
[04:28] <persia> bjsnider, Why can't you do the ldd test?
[04:29] <bjsnider> i uninstalled these packages
[04:29] <bjsnider> bringing them back in would break my system
[04:29] <bjsnider> i could build them here but that would take awhile
[04:29] <ebroder> Do you have the .debs?
[04:29] <bjsnider> yes
[04:29] <persia> So?  Download it (as a file).  unpack it (man dpkg-deb).  run ldd on the files.
[04:30]  * ajmitch would like to know what the package is & what the unneeded dependency is
[04:33] <maco> ajmitch, i dont see bryce's modified hunspell...
[04:34] <bjsnider> i'm talking to the developer here and i found out the problem
[04:34] <ajmitch> maco: sorry, hunspell-en-us was the one he uploaded
[04:36] <maco> ajmitch, ah ok
[04:43] <bjsnider> i talked the developer out of linking to that library.
[04:43] <bjsnider> thank you for all of your guidances
[04:43] <maco> ajmitch, alright, attached a hunspell-en-us debdiff to that bug as well now. feel like another upload?
[04:43] <ajmitch> maco: to the same bug, which was closed already? :)
[04:44] <maco> ajmitch, marked it as affecting both packages
[04:44] <ajmitch> ah good
[04:44] <ajmitch> let me fetch the source
[04:59] <dtchen> TheMuso: yes, i've spent the last few hours getting 2.6.31-rc1 running on my systems to fix rtkit packaging
[05:02] <TheMuso> dtchen: Oh ok cool.
[06:06] <cjwatson> dtchen: synced, then, thanks
[06:09] <vkfwb> I am looking for someone who can help me facilitate an update to Ubuntu package of fwbuilder; I am the author and project lead, our upstream package has been updated and we'd like to see Ubuntu packages updated too
[06:11] <dholbach> good morning
[06:16] <ScottK> vkfwb: Since we generally get fwbuilder from Debian, our preferred method would be to get the package updated in Debian and then ask someone in #ubuntu-motu about a sync from Debian once that's done.
[06:18] <ScottK> cjwatson: I've taken a shot at updating livecd-rootfs (in bzr, not uploaded).  Given the hash I made of tasksel, I'd particularly appreciate it if you'd take a look at it.
[06:19] <StevenK> ScottK: I tried to update tasksel at one point and ran screaming, if I recall.
[06:19] <ScottK> I didn't run and I should have.
[06:19] <ScottK> cjwatson straightened it out.
[06:20] <cjwatson> ScottK: can't say offhand whether it will work :-), but it looks OK
[06:20] <StevenK> cjwatson: I note UNR has disappeared completly from the tasks, I need to wait for cron.germinate to land?
[06:20] <cjwatson> tasksel is easy to update, but perhaps only once you know how. Make the changes you want (whether in the seeds or in ubuntu-seeds.pl), then 'rm -rf ubuntu-tasks && make ubuntu-tasks'
[06:21] <cjwatson> StevenK: oh, err, yeah, I guess you do
[06:21] <cjwatson> sorry
[06:21] <StevenK> ScottK: I have a livecd-rootfs change waiting, I can upload it along with your changes?
[06:21] <cjwatson> maybe that was a slightly premature update
[06:21] <ScottK> StevenK: Yes.  Please.
[06:21] <StevenK> Waiting for cron.germinate, anyway
[06:22] <cjwatson> well, that sounded like it'd happen today
[06:22] <StevenK> Oh well, UNR dailies have probably been broken for a few days anyway
[06:22] <cjwatson> feel free to temporarily revert the relevant bits of tasksel if you urgently need to
[06:22] <cjwatson> I'm on holiday today, just stopping in while the baby's feeding
[06:22] <StevenK> cjwatson: No, I just need patience. :-)
[06:23]  * StevenK mangles the livecd-rootfs changelog
[06:23] <StevenK> ScottK: Leave your distro in the changelog set as UNRELEASED, too
[06:23] <ScottK> StevenK: Didn't I?
[06:24] <cjwatson> he did, second commit
[06:24] <vkfwb> ScottK: the package has been updated in Debian
[06:24] <StevenK> Oh, right
[06:24] <vkfwb> ScottK: should I ask on ubuntu-motu then ?
[06:24] <ScottK> vkfwb: Yes.
[06:24] <cjwatson> hmm, did anyone do an autosync yesterday?
[06:24] <vkfwb> ScottK: ok, thanks
[06:24] <StevenK> cjwatson: It was my archive day, and I didn't, since yesterday was effectively DIF
[06:25] <StevenK> cjwatson: I can handwave and run one now ...
[06:25] <cjwatson> vkfwb: has it? I don't see anything newer than 3.0.5-2 in Debian unstable
[06:25] <cjwatson> which is what we have in karmic
[06:25] <cjwatson> StevenK: still Thursday in your timezone :-)
[06:25] <ScottK> Still Thursday some places.
[06:25] <StevenK> cjwatson: Actually, it's 3pm Friday in my timezone
[06:26] <cjwatson> oh
[06:26] <cjwatson> sorry, mixed up then
[06:26] <StevenK> +10
[06:26] <cjwatson> but I don't think it matters all that much ...
[06:26] <ebroder> Oh - random question. How can I find out why zephyr 3.0~beta.2483-2 was autosynced? It's only in unstable, not testing. Not that I'm complaining - older versions didn't build without krb v4
[06:26] <StevenK> ebroder: We pull from unstable
[06:27] <ebroder> Oh, right. I was confusing unstable and experimental
[06:27] <StevenK> cjwatson: I have my finger hovering over Enter, now is the time to object to an autosyncer run
[06:28] <StevenK> And I can't see that Scott did two commits to livecd-rootfs
[06:28] <ScottK> StevenK: The 2nd one was only several tens of minutes ago.  Dunno if that's relevant
[06:29]  * StevenK runs bzr up
[06:29] <cjwatson> StevenK: run it, then we can check the .changes files before you press enter on flush-syncs :)
[06:30] <StevenK> cjwatson: Or selectively dump a few things before flushing :-)
[06:30] <cjwatson> indeed
[06:33] <StevenK> cjwatson: Done, there doesn't look to be anything evil
[06:33] <StevenK> cjwatson: But a second opinion is appreciated.
[06:34] <cjwatson> StevenK: could you do contrib and non-free for completeness?
[06:34] <ajmitch> StevenK: so you proved me wrong when I told someone that it was DIF already :)
[06:34] <StevenK> ajmitch: I can't help it if cjwatson overrules what I decided :-)
[06:34] <ajmitch> heh
[06:35] <ajmitch> TGIF, now I can get some stuff done :)
[06:36] <pitti> Good morning
[06:36] <ajmitch> hey pitti
[06:36] <StevenK> Morning pitti
[06:36]  * pitti waves to downunder
[06:37] <ajmitch> that's a long way to wave
[06:38] <cjwatson> well, it *is* DIF, but we should do an autosync as close to the end as possible, IMO
[06:39] <cjwatson> StevenK: everything there looks OK
[06:39] <StevenK> cjwatson: -C contrib pulled in nothing
[06:39] <pitti> FYI, I did one yesterday
[06:39] <cjwatson> kernel-package is the only remotely scary one, but we don't use it for our kernel builds anyway
[06:39] <pitti> including non-free and contrib
[06:39] <cjwatson> oh, you did?
[06:40] <pitti> yeah, it was DIF, so I had the same thought as you :)
[06:40] <cjwatson> in that case maybe we *shouldn't* do an autosync now. I was working on the assumption that it hadn't been done yesterday.
[06:40] <cjwatson> StevenK: cancel my overruling :-)
[06:40] <StevenK> cjwatson: I'm happy to clear them out, and then whistle that we did nothing
[06:40] <pitti> I guess by now we need another new-binary-debian-universe run
[06:41] <pitti> StevenK: if you could do some NEW today, that would be appreciated; there's some stuff like policykit-1 which we need soon
[06:41] <pitti> (I'm the uploader, so I can't review myself)
[06:41] <StevenK> pitti: I spent an hour doing NEW yesterday during my archive day :-)
[06:42] <StevenK> pitti: But I'll happily review policykit-1 for you.
[06:42] <cjwatson> StevenK: yeah, pretend I never said anything I guess ;-)
[06:42]  * ScottK looks a bit at debian-cd and decides it's bedtime.
[06:42] <StevenK> ScottK: debian-cd is scary, yes :-)
[06:43] <ScottK> Yep.  I'll save that step for when I'm not way short on sleep (it's nearly 2 am here).
[06:44] <StevenK> pitti: There looks to be some wierd control chars in your debian/changelog that less doesn't like
[06:47] <pitti> StevenK: no locale installed on cocoplum, I guess?
[06:47] <pitti> might have been a →
[06:47] <pitti> I often see that corruption for maintainers with accents in the name
[06:47] <StevenK> Ahhh, then I'll deal
[06:47] <pitti> it's policy compliant :)
[06:48] <StevenK> pitti: Given it's a version bump, it looks good.
[06:48]  * StevenK pushes the shiny accept button
[06:48] <pitti> it's by and large a new upstream version only
[06:49] <pitti> StevenK: thanks! (and now perhaps policykit-1-gnome? :-) )
[06:49] <pitti> same story
[06:49] <StevenK> pitti: I don't know ... you already owe me beer :-P
[06:49] <slangasek> pitti: "less -r"; has less to do with locales being installed than with charset configuration
[06:49] <pitti> heh
[06:51] <StevenK> pitti: -gnome also accepted
[06:59] <pitti> \o/ thanks
[07:00] <StevenK> pitti: I'm look at the list for stuff in universe that UNR wants -- libmono-i18n-west2.0-cil is a little suprising, since tomboy pulls that in
[07:00] <StevenK> pitti: And hwtest-gtk -- should UNR be using something else?
[07:00] <slangasek> tomboy pulls it in how?
[07:01] <StevenK> i   tomboy                Depends    libmono-corlib2.0-cil (>= 1.2.2.1)
[07:01] <StevenK> i A libmono-corlib2.0-cil Recommends libmono-i18n-west2.0-cil
[07:01] <StevenK> Indirectly
[07:02] <slangasek> ah; so it's an existing components-mismatches issue?
[07:03] <StevenK> It looks to be in components-mismatches, yes
[07:03] <pitti> StevenK: mono was recently split into several smaller libraries
[07:04] <pitti> well possible that some of them got NEWed to universe
[07:04] <StevenK> pitti: Happy to promote libmono-i18n-west2.0-cil
[07:04] <pitti> StevenK: hwtest-gtk> please use checkbox-gtk
[07:04] <StevenK> pitti: Okay
[07:05] <StevenK> pitti: gnome-themes (the source) is in main, but gnome-themes (the binary) is in universe
[07:05] <pitti> superm1: ok, got the rules working now; thanks for testing
[07:05] <pitti> StevenK: known, and intended
[07:05] <pitti> we only want gnome-themes-selected
[07:05] <pitti> does somethign pull it in?
[07:05] <StevenK> Yeah, UNR directly
[07:05] <StevenK> I'll change the seed there too
[07:06] <pitti> ah, thanks
[07:06] <StevenK> pitti: app-install-data-commercial ?
[07:06] <cjwatson> -partner
[07:06] <StevenK> Right, I thought so
[07:06] <cjwatson> wow, you have some ancient stuff there
[07:06] <cjwatson> -partner was renamed in like gutsy
[07:07] <slangasek> anyone else seeing launchpad problems at the moment?
[07:07] <cjwatson> not I
[07:08] <pitti> WFM
[07:08] <StevenK> pitti: Last one, if I'm allowed to promote libmono-i18n-west2.0-cil is hplip-cups
[07:08] <pitti> StevenK: promotion> sure, splitout
[07:08] <pitti> StevenK: binary-only promotion is generally fine
[07:09] <cjwatson> ... except gnome-themes ;-)
[07:09] <pitti> should be checked for sensibility, of course, but doesn't need MIR stuff
[07:09]  * cjwatson goes back to bed
[07:10] <pitti> cjwatson: "back"? are you in the US?
[07:10] <cjwatson> no, just got woken by baby feeding
[07:10] <pitti> aah
[07:10] <pitti> see you later then!
[07:10] <StevenK> pitti: Promoted, thanks
[07:10] <cjwatson> and decided to come and do a couple of uploads I ran out of time for last night
[07:10] <cjwatson> not today you won't, I'm on holiday :)
[07:10] <pitti> ah, enjoy
[07:11] <dholbach> cjwatson: enjoy :)
[07:12] <StevenK> pitti: In regards to hplip-cups:
[07:12] <StevenK> i   ubuntu-netbook-remix Recommends hplip
[07:12] <StevenK> i A hplip                Recommends hplip-cups (>= 3.9.6)
[07:14] <pitti> seems fine to me
[07:15] <StevenK> pitti: But hplip is in main, and hplip-cups is in universe
[07:16] <pitti> looks like a recent and intended splitout to me
[07:16] <pitti> StevenK: "looks fine" -> I meant "for promotion"
[07:16] <StevenK> Oh
[07:16] <StevenK> Right, then let me do that
[07:17] <StevenK> pitti: Also done, thanks!
[07:18]  * StevenK peers at tix in component-mismatches and his list
[07:44] <sianis> hi
[07:47] <sianis> fta: could you please look at this? https://answers.launchpad.net/gwibber/+question/75068
[07:48] <soren> bryce: My aspell changes from way back didn't get uploaded because I wasn't core-dev at the time (probably not even MOTU either), and noone else cared enough to sponsor it.
[07:56] <lifeless> kirkland: still aroun?
[08:24] <chrisccoulson> cjwatson - i'm struggling to recreate this issue you're seeing on the live CD. when i restart, i don't see the inhibit dialog flash up briefly.
[08:24] <chrisccoulson> i don't know if its possible for you to start a failsafe xterm session from the live CD, then manually start "gnome-session --debug", with the output saved to some permanent storage
[08:25] <chrisccoulson> if that's possible, then it might be worth trying to recreate it like that as there should be some indication in the log why it happens
[08:41] <lifeless> pitti: is your laptop fan running slower/not at all in karmic?
[08:42] <pitti> lifeless: no noticeable difference
[08:43] <pitti> it is running pretty often, the 430 tends to heat up a lot
[08:43] <lifeless> pitti: mine isn't, machine is thermal-tripping I think
[08:45] <pitti> StevenK: could I ask you to bin-NEW policykit-1?
[08:47] <pitti> lifeless: hm, if only I knew which bit was responsible for controlling the fan (shouldn't the computer do that itself?)
[08:48] <lifeless> acpi_fan I thought
[08:48] <lifeless> whats
[08:48] <lifeless> cat /proc/acpi/thermal_zone/THM/temperature
[08:48] <lifeless> for you
[08:49] <lifeless> its odd, trip_points for me is 99C
[08:49] <lifeless> I'm going to start watching it
[08:50] <pitti> $ cat /proc/acpi/thermal_zone/THM/temperature
[08:50] <pitti> temperature:             68 C
[08:50] <pitti> and fan is running
[08:50] <soren> Mine's 53 C
[08:50] <pitti> $ cat /proc/acpi/thermal_zone/THM/trip_points
[08:50] <pitti> critical (S5):           99 C
[08:50] <lifeless> soren: is your fan running, and do you have a D430 ?
[08:50] <soren> ...but "acpi -V" says: Thermal 0: ok, 58.5 degrees C
[08:50] <soren> lifeless: Fan running. D430, yes.
[08:51] <lifeless> ok, my fan is either _super_ quiet or fucked
[08:51] <lifeless> I can't feel a breeze
[08:51] <lifeless> Thermal 0: ok, 51.5 degrees C
[08:51] <soren> lifeless: My fan is virtually always running, and I can both hear and feel it.
[08:51] <soren> Well, that's not too bad.
[08:51] <lifeless> do you have anything in /proc/acpi/fan/?
[08:51] <soren> I don't know when the fan usually kicks in.
[08:52] <soren> Nope.
[09:00] <pitti> lifeless: it's empty here as well
[09:00] <lifeless> thanks
[09:10] <pitti> hm, did edge just go down?
[09:10] <soren> pitti: Works for me.
[09:11]  * pitti shrugs and disables redirection
[09:18] <nellery> would any of you mind posting your full output of acpi -V?
[09:19] <nellery> or just acpi -c
[09:23] <hyperair> http://pastebin.com/f36ef454e
[09:24] <nellery> thanks.
[09:25] <hyperair> hmm i wonder if my CPU can really hit 105 degrees and not burn
[09:25] <hyperair> as of now, it overheats and hard powers down at ~80
[09:28] <nellery> mine has heating problems as of Jaunty...
[09:28] <nellery> regularly about 55 degrees and goes up to 81ish degrees when I do things such as build packages
[09:53] <hyperair> mine's always been ~55 idling
[09:53] <hyperair> and 75-80 when compiling
[09:53] <hyperair> make -j2 can cause a hard shutdown
[10:25] <apw> can anyone elighten me as to the meaning of an CHROOTWAIT on a PPA build?
[10:31] <apw> cjwatson, i wonder if you could look at this failed PPA build, if i am reading it right i suspect it may be affecting all builds: http://launchpadlibrarian.net/28408818/buildlog_ubuntu-karmic-amd64.linux_2.6.31-1.13apw1_CHROOTWAIT.txt.gz
[10:32] <apw> it appears that two common build deps are colliding
[10:50] <apw> ahhh i see the problem, its not general at least ... panic  over
[11:06] <soren> How do I specify a base revision during a merge?
[11:07] <soren> Whoops
[11:07] <soren> Wrong channel.
[11:07] <soren> (How did I end up in here?)
[11:09] <directhex> soren, you turned left at Albuquerque?
[11:10] <soren> I didn't.
[11:10] <soren> Should I have?
[11:49] <ogra> cprov, if the project cant be renamed or deleted, i'll just leave it idling and create a new one, thats fine with me ... i just didnt want to leave a mess in LP
[11:55]  * ogra wonders why we dont have some --help to man converter ... i.e. calling "cmd --help | helptoman > cmd.manpage" that creates a skeleton manpage with all the options and descriptions --help spits out for cmd
[11:55] <hyperair> ogra: help2man
[11:56] <ion> :-P
[11:56] <hyperair> ogra: Laney generated banshee's manpage that way =p
[11:56] <ogra> hyperair, that works for sucha case ?
[11:56]  * ogra goes and tries
[11:56] <hyperair> it's not exactly like that
[11:56] <ogra> i always thought that converts files
[11:56] <hyperair> but essentially it takes the output of --help and generates a manpage
[11:56] <hyperair> i think you give it a command, and it runs command --help, grabs output from that, and dumps a manpage
[11:57] <hyperair> you can even specify another argument to use in place of --help
[11:57] <Laney> it gives you a good starting point
[11:58] <hyperair> mmhmm
[11:59] <ogra> yeah, looks ok
[11:59] <ogra> thanks !
[12:14]  * ogra wishes KVM would recognize his external display on boot
[12:15] <ogra> err
[12:15] <ogra> s/KVM/KMS/
[12:15] <ogra> damned abreviations
[12:24] <geser> does somebody know how I can figure out, why I'm missing the ACLs e.g. on the sound device files in karmic? it's getting nasty to issue a setfacl when I want to use my smart card reader or hear music
[13:23] <ion> Wait, what? https://wiki.ubuntu.com/KernelTeam/Specs/KarmicSSD?action=diff&rev1=11&rev2=12 “Using the most appropriate log structured file system, such as ext4.”
[13:25] <hyperair> ext4 is log structured now?
[13:25]  * ogra points ion to cking_, 
[13:25] <cking_> call it a typo.
[13:25] <hyperair> heh'
[13:32] <Ng> can I run apport for a single process rather than enabling it system-wide?
[13:34] <Ng> nm
[13:34] <pitti> Ng: not that easily, I'm afraid, since it hooks into the kernel
[13:34] <Ng> pitti: yeah
[13:34] <pitti> Ng: you don't need to enable it in /etc, though, you can do sudo force_start=1 /etc/init.d/apport start
[13:35] <Ng> oh nice
[13:52] <kirkland> lifeless: hi there, i'm back now
[13:53] <kirkland> lifeless: sorry i missed earlier, was away for the evening
[14:50] <lool> Geez empathy pulls the whole geoclue stuff
[14:57] <ogra> cprov, "The name 'rootstock' has been blocked by the Launchpad administrators."
[14:57] <cprov> ogra: let me check
[14:57] <ogra> thanks
[15:01] <cprov> ogra: anything matching '^root' is blacklisted.
[15:01] <ogra> gah
[15:01] <ogra> lool, ^^^^ :P
[15:02] <ogra> cprov, any way around that ?
[15:03] <ogra> it took us two weeks of discussion to find the name ...
[15:03] <cprov> ogra: no, unfortunately
[15:03] <ogra> sigh, ok
[15:03] <cprov> ogra: you can always use 'project-rootstock' :-/
[15:03] <ogra> yeah, i'll do that
[15:04] <cjwatson> apw: chrootwait on linux> looks bad; check the two packages to see if there really is a file conflict. I'm on holiday today though. I suggest looking for infinity or somebody else on #is if it needs manual recovery.
[15:05] <apw> cjwatson, panic was avoided, it was from my own previous package, but luckil;y prevented that being uploaded into the archive and getting the problem for real!
[15:06] <Keybuk> heh, I just found the wiki page that explained all of the silly release names I gave dpkg
[15:06] <cjwatson> apw: oh, that was your PPA - OK
[15:07] <apw> what was odd, was i had deleted those packages so didn't expect them to be usable, so i thought it had to be main archive packages.  keybuk disabused me of that notion and it got fixed in time
[15:08] <apw> it was a lot of luck though, as that might have gotten uploaded to the real archive if i'd not had that overlap, so a bit of luck on our side for a change
[15:11] <pitti> mterry: \o/
[15:12] <mterry> pitti, that was easier than I thought
[15:12] <pitti> mterry: so, instead of adding this to acpi-support, we should just grab that patch into dk-p right away
[15:12] <pitti> (IMHO)
[15:13] <pitti> and clean up acpi-support further instead
[15:13] <mterry> pitti, Yeah, I'm patching my acpi branch now
[15:13] <pitti> mterry: want me to upload new dk-p?
[15:13] <mterry> pitti, yeah, please.  Thanks
[15:19] <pitti> mterry: uploaded
[15:21] <mterry> pitti, cool
[15:52] <asac> anyone has a bridge setup in /etc/network/interfaces and could post it?
[15:52] <asac> thx
[15:52] <soren> asac: What do you want it to do? I have several.
[15:53] <soren> asac: Should it be connected to a real interface, or is it for virtual networking only?
[15:53] <asac> soren: paste all with a quick explanation
[15:55] <ogra> soren, dont ! else NM will grow bridge support quickly !!!
[15:55] <asac> yay
[15:56] <ogra> :)
[15:56] <asac> no chance to keeping it out of server soon ;)
[15:56] <ogra> haha
[15:56] <ogra> and soren is at fault :P
[15:56] <soren> asac: http://paste.ubuntu.com/204307/
[15:57] <soren> asac: Apologies for typos, if any. It's not copied from anywhere, I just typed it in.
[15:57] <soren> ogra: I've been shouting for bridge support in network-manager for a long time.
[15:57] <lool> asac: http://paste.ubuntu.com/204308/
[15:58] <lool> soren: NM upstream blogged about that coming up soon
[15:58] <lool> (briding and ipv6)
[15:58] <soren> lool: About time :)
[15:58] <soren> asac: Is that useful, or do you need more explanation?
[16:02] <asac> soren: in that example, what sets the IP address of extbr0?
[16:02] <asac> soren: oh its dhcp
[16:03] <asac> so thanks. all fine.
[16:12] <slangasek> mterry: hopefully I'll catch up on bug #385949 today
[16:12] <mterry> slangasek, cool.  things fell into place today, so everything's ready, but there's no rush
[16:13] <slangasek> mterry: btw, your DEP5 conversion is incorrect - Thom May is not a copyright holder on this package
[16:13] <slangasek> yep - I was more or less waiting for the pm-fwibble part to be addressed before changing acpi-support, now I have no excuse not to finish the merge :)
[16:13] <mterry> slangasek, ah, whoops on the DEP5.  I thought I just ported the old copyright notices, but adjust as you see fit
[16:14] <slangasek> mterry: the old line said 'Author', not 'copyright' :)
[16:14] <soren> asac: Any time.
[16:15] <mterry> slangasek, so either he assigned his copyright or it should have said "inspired by" not "author", eh?  cause if he was an author, it's automatic copyright
[16:16] <mterry> slangasek, but I don't know his involvement; that's just why I put him down
[16:18] <slangasek> mterry: no, it's work-for-hire
[16:18] <slangasek> he worked for Canonical
[16:18] <slangasek> as the email address suggests
[16:19] <mterry> slangasek, ah, k.  my bad
[16:41] <slangasek> bryce: do we have the new intel-gpu-tools jbarnes mentions in https://bugs.freedesktop.org/show_bug.cgi?id=22359 ?  I have a fresh crash here
[16:45] <pitti> nixternal, Riddell: jockey currently uses pykdeuic to build *.ui into *.py and ship the latter, while apport currently ships *.ui and loads them directly; what approach is more standard and recommended in KDE nowadays?
[16:47]  * ScottK wonders if agateau knows?  ^^
[16:48] <agateau> ScottK: pitti: using uic to build *.ui into *.cpp :/
[16:49] <ScottK> Thanks.
[16:49] <agateau> I am not sure there is a recommended way for Python ATM
[16:49] <agateau> there aren't that much Python code in kdesvn for now
[16:49] <agateau> I for one always turn the ui into py
[16:49] <pitti> agateau: ... and for Python? :-)
[16:49] <pitti> agateau: so, loading them at runtime is discouraged?
[16:49] <pitti> ok, thanks
[16:49] <agateau> but that maybe my C++ background
[16:50] <pitti> nixternal's apport KDE port loads them directly, so I wondered
[16:51] <agateau> I believe we can say using pyuic or uic is more common
[16:51] <agateau> since even C++ app could load them directly
[16:51] <agateau> and very few kde apps do so
[16:53] <pitti> slangasek: I meant that most of the event scripts in acpi-support are probably redundant nowadays, since all other distros have these fixed in the kernel?
[16:57] <slangasek> pitti: yes, *most* of them are, but I'm not going to go ripping them all out when it's possible to tell which ones are redundant by reading what they do
[16:57] <slangasek> i.e., I'm not going to have my wireless toggle pulled out from under me
[17:01] <pkt> what is the deal with konq-plugins?
[17:01] <pkt> the konq-plugins source package produces both konq-plugins and a number of standalone plugins
[17:01] <ScottK> pkt: #kubuntu-devel is a better channel for that question.
[17:01] <pkt> now e.g., konq-plugins and konqueror-plugin-searchbar conflict with eachother
[17:02] <pkt> oh, there is a kubuntu-devel? sorry :)
[17:04] <Fenix|work> Greetings and salutations!
[17:10] <slangasek> kirkland: give me a design that lets us separate critical auth logs from non-critical ones...?
[17:10] <lool> kirkland: Why not do a freshness check on update-motd data on login and refresh it if needs be?
[17:11] <lool> Would that be too slow?
[17:12] <kirkland> lool: depends on the consumers of update-motd
[17:13] <kirkland> slangasek: Jun 26 10:10:01 t61p /USR/SBIN/CRON[14584]: (root) CMD ([ -x /usr/sbin/update-motd ] && /usr/sbin/update-motd 2>/dev/null)
[17:13] <kirkland> slangasek: that seems more appropriate to log in a cron log
[17:13] <kirkland> slangasek: rather than /var/log/syslog
[17:13] <kirkland> slangasek: and /var/log/cronlog could be asynch
[17:19] <slangasek> kirkland: that's not the PAM log in question
[17:19] <kirkland> slangasek: oh?
[17:19] <kirkland> slangasek: which one?
[17:19] <slangasek> Jun 26 09:10:01 dario CRON[6777]: pam_unix(cron:session): session opened for user root by (uid=0)
[17:20] <slangasek> Jun 26 09:10:06 dario CRON[6777]: pam_unix(cron:session): session closed for user root
[17:20] <kirkland> slangasek: okay, question for you ...
[17:20] <Fenix|work> is anyone involved with dmraid here?
[17:21] <kirkland> slangasek: what if i added update-motd [--enable-cron|--disable-cron|--enable-inotify|--disable-inotify] options, where the cron ones would add/remove a symlink at /etc/cron.d/update-motd which pointed to the configuration in /usr/share/update-motd
[17:21] <kirkland> slangasek: and something similar for the inotify bits
[17:22] <kirkland> slangasek: would that sort of modification of /etc by a utility be acceptable?
[17:23] <kirkland> slangasek: you could tweak your config with:  update-motd --disable-cron --enable-inotify
[17:23] <slangasek> kirkland: acceptable, but feels kinda rube goldberg, and I would never run that command by hand on my system
[17:23] <kirkland> slangasek: which might tell you "iwatch: command not found;  sudo apt-get install iwatch"
[17:23] <kirkland> slangasek: that would only be there until we had an inotifyd in main that update-motd could depend on
[17:24] <kirkland> slangasek: at which point, the default becomes inotify
[17:24] <kirkland> slangasek: we could alternatively have a config file and an init script
[17:25] <kirkland> slangasek: /etc/update-motd.config has METHOD=cron|inotify
[17:25] <slangasek> kirkland: I just don't think any of that is worth the effort, because it's only the default behavior that interests me.
[17:25] <slangasek> if I'm going to deviate from the defaults, I don't need a command to do that - I can just rip out the package and/or the cronjob
[17:25] <kirkland> slangasek: true
[17:26] <bryce> slangasek, yep they're in karmic now (in universe)
[17:26] <kirkland> slangasek: i could make update-motd a proper daemon
[17:26] <kirkland> slangasek: and kill the cronjob
[17:26] <slangasek> bryce: ok; what's the relevant version number?
[17:26] <slangasek> kirkland: again, why is that worth doing when the proper solution is 6 months away?
[17:26] <kirkland> slangasek: what do you suggest, then for karmic?
[17:27] <slangasek> kirkland: accept that I'm going to continue to be cranky about it? :-)
[17:27]  * kirkland tries waaaaay to hard to please users
[17:27] <bryce> intel-gpu-tools | 1.0.1-0ubuntu1 | http://archive.ubuntu.com karmic/universe Packages
[17:27] <bryce> there's apparently a new version but I've not pulled that in yet
[17:28] <slangasek> bryce: right, the new version is what jbarnes mentioned
[17:30] <Keybuk> kirkland: maybe I'm missing something, but this really doesn't seem like it's something that _has_ to land for karmic?
[17:31] <kirkland> Keybuk: no, not at all
[17:31] <Keybuk> are there genuinely omg-critical problems caused by update-motd not being as quite up-to-date as it could be?
[17:31] <kirkland> Keybuk: i don't think that's the issue
[17:31] <Keybuk> what's the issue?
[17:31] <kirkland> Keybuk: i think the issue is the cronjob that wakes up the disk to write the pam log
[17:32] <Keybuk> how's that any different to anything else?
[17:32] <Keybuk> an inotify daemon is going to wake the disk up <g>
[17:32] <Keybuk> if people don't want their disk woken up for writes, they can turn laptop-mode on
[17:32] <Keybuk> or disable syslog
[17:34] <slangasek> "disable syslog" - meh
[17:34] <slangasek> Keybuk: the issue is that when you have the cronjob, you have a guaranteed disk wake-up once every 10 minutes just to write the synchronous log entry to /var/log/auth.log, whether or not update-motd has anything to do
[17:34] <slangasek> I am not asserting this is omg-critical
[17:34] <Keybuk> Upstart will have exactly the same issue though
[17:35] <slangasek> upstart is going to call pam_open_session() once every 10 minutes?
[17:35] <Keybuk> slangasek: it'll call pam_open_session() whenever it needs to run something as a specific user
[17:35] <Keybuk> so if update-motd is running as non-root, it'll still do it
[17:36] <slangasek> er, but the idea is that update-motd should only be called when there's something to update?
[17:36] <Keybuk> right
[17:36] <slangasek> so that should be less frequently than the current 10-minute cycle
[17:37] <Keybuk> sure
[17:37] <slangasek> then that satisfies my need for beauty :)
[17:38] <Keybuk> please tell me cron isn't doing pam_open_session() for things in /etc/cron.d _just_ to source /etc/environment
[17:40] <Fenix|work> Has anything changed in dmraid in the last couple of months?  Ubuntu now sees my ASR array with a different name that's padded with lots of spaces and won't mount the partitions.
[17:41] <kirkland> Fenix|work: possible TheMuso could help, but he's likely gone for the weekend
[17:41] <slangasek> Keybuk: no, it's doing it because that's the right thing to do when starting a session of any sort as another user
[17:42] <slangasek> it also calls it for pam_limits... :)
[17:43] <Keybuk> slangasek: shall we debate whether things in /etc/cron.d are the root user's cronjobs, or system cron jobs
[17:43] <Keybuk> where root user cronjobs should obviously be run under a PAM session
[17:43] <Fenix|work> kirkland, I sent him an email but received no response.  I don't want to file a bug in launchpad because I don't think it's a bug... but my home server is kinda screwed now as it won't boot.  My array went from being 'asr', 'asr_1 and 'asr_5' to 'asr_OS             ', 'asr_OS             1' and 'asr_OS             5'.  It's really wierd.
[17:43] <Keybuk> while system cron jobs arguably shouldn't be? :p
[17:44] <slangasek> Keybuk: cron.d/ follows the crontab syntax that includes specifying a username, and root isn't special-cased
[17:44] <slangasek> (yes, we shall debate this :-)
[17:44] <kirkland> Fenix|work: it's probably okay to just file a bug;  he'll mark it invalid if it is
[17:44] <Keybuk> slangasek: do you think it should behave that way?
[17:44] <Fenix|work> kirkland, dumb question here, but I haven't been able to find an answer to it.  Is there any way to rename a dmraid array? :)
[17:45] <Fenix|work> if I can rename it, then I can leav TheMuso alone... when he's awake, I'm sleeping. :)
[17:46] <Keybuk> slangasek: Upstart makes a distinction between things that are "system" and things that are "user's"
[17:46] <slangasek> Keybuk: I'm uncertain.  Conceivably, pam_open_session() could be used to apply settings (such as ulimits) to root cronjobs that aren't meant to apply to the cron daemon itself
[17:46] <Keybuk> since it wouldn't make any sense to call pam_open_session() when starting apache, for example
[17:47] <hyperair> hmm so i hear that a Scott was singing eye of the tiger O_o
[17:48] <Keybuk> then again, Upstart also allows things like limits to be specified in the job
[17:48] <slangasek> blech :)
[17:48] <Keybuk> blech?
[17:48] <ogra> hyperair, the other scott
[17:49] <hyperair> which Scott?
[17:49]  * Keybuk doesn't sing
[17:49] <slangasek> Keybuk: as if pam_limits wasn't confusing enough, without the possibility of interaction with upstart job settings
[17:50] <Keybuk> slangasek: oh, that's easy ;)
[17:50] <Keybuk> slangasek: pam settings override upstart if the job calls for a pam session
[17:51] <slangasek> there's nothing easy about pam_limits :(
[17:51] <Keybuk> the idea is that you specify the default sane environment in init
[17:52] <slangasek> anyway, I think I'd be ok with a cron implementation that skipped PAM sessioning for root jobs, as long as we got the Debian maintainer on board as well so behavior isn't gratuitously different between the two
[17:52] <Keybuk> and PAM thus applies policy
[17:52] <slangasek> well, ok
[17:52] <slangasek> note that one of the things our pam_limits does is reset all limits to the kernel default, though
[17:52] <Keybuk> slangasek: probably a better way would be just to have upstart open pam sessions for cronjobs from /etc/crontab and /etc/cron.d
[17:52] <slangasek> before applying any other settings from /etc/security/limits.conf
[17:52] <Keybuk> and not open pam sessions for temporal jobs specified in /etc/init
[17:52] <Keybuk> slangasek: how does it know what the kernel default is?
[17:53] <slangasek> it encodes it :P
[17:53] <Keybuk> because one thing I found quite quicky is that the kernel default is not the same as what you get when you reset the settings ;)
[17:53] <slangasek> and then every few months I get bug reports telling me the kernel has changed :P
[17:53] <Keybuk> ahh :p
[17:53] <slangasek> "reset"?
[17:56]  * Keybuk decides not to worry about PAM interaction for now
[17:57] <cjwatson> pitti: thanks, fixing that ubiquity bug now
[17:57]  * cjwatson contemplates running py_compilefiles on everything at build time
[17:57] <kees> slangasek: what about having some crackful early-start process write ot /var/run with kernel RLIMIT defaults it will read?
[18:00] <fta> doko, is binutils-gold usable on lpia? seems broken here
[18:00] <fta> doko, dpkg-divert: `diversion of /usr/bin/ld to /usr/bin/ld.single by binutils-gold' clashes with `diversion of /usr/bin/ld to /usr/bin/ld.real by lpia-wrapper'
[18:00] <fta> doko, from http://launchpadlibrarian.net/28419299/buildlog_ubuntu-karmic-lpia.chromium-browser_3.0.191.0~svn20090626r19361-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz
[18:05] <slangasek> kees: would be simpler than the current behavior, but adds a dependency on an external process for correct operation of pam_limits; I'm ambivalent
[18:06] <kees> slangasek: yeah; I like the idea of it working with whatever the kernel decides to do, making PAM kernel-version-agnostic (at least in this regard), and it could maybe be just a quick init-script.  perhaps PAM could fall-back when the file doesn't exist?  hrm.
[18:07] <kees>  /var/run/no,really...limits.conf
[18:08] <slangasek> kees: I'm operating on the theory that where limits differ between kernel versions this is due to bugfixes, so tracking the latest kernel behavior is preferred
[18:16] <kees> slangasek: hmm, okay, I can accept that.  the trouble is noticing when it changes.
[19:38] <Sarvatt> whats the proper way to adjust module parameters and add/remove them upon plugging in or going on battery power if ac.d and battery.d are removed from acpi-support? i've been adjusting the txpower and enabling power save for wifi and removing webcam/nic modules through scripts in there
[20:26] <nhandler> cjwatson: When you get a chance, could you update http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ ? It is still for version 3.8.0.1ubuntu4
[20:31] <brainsonfire> hi, i hope someone here might have an idea on this issue. my usb mouse doesnt work in jaunty (tried 2 different laptops), but it works in gutsy
[20:31] <brainsonfire> here my Xorg.0.log        http://pastebin.com/m39d73628
[20:31] <brainsonfire> xinput recognizes 2 devices when i plug it in, first one being a mouse, second one a keyboard (?)
[20:31] <brainsonfire> the mouse works for a split second then stops but the light keeps glowing
[20:32] <brainsonfire> mouse shows up in lsusb
[20:32] <brainsonfire> hal-devices shows 3 devices
[20:33] <brainsonfire> i have no clue how to debug/influence this behaviour
[20:35] <brainsonfire> ill try installing xserver-xorg-input-evdev and -mouse from karmic
[20:40] <slangasek> mterry: did you forget a bzr push?  I still see pm-powersave in your acpi-support branch
[20:41] <slangasek> mterry: I'll merge up what you have so far, but wait for confirmation before uploading
[20:41] <mterry> slangasek, acpi-support still calls pm-powersave in the no-power-manager case
[20:41] <mterry> slangasek, just a fallback
[20:41] <slangasek> ok
[20:52] <slangasek> mterry: btw, svn revision 54 of DEP5 includes arbitrary changes that were not publicly discussed, and have been reverted
[20:52] <slangasek> mterry: please use a better one :)
[20:52] <slangasek> s/better/newer/
[20:53] <mterry> slangasek, ah, will re-examine the spec
[20:53] <James_P> hey guys
[20:54] <mterry> slangasek, trying to be helpful with that dep5 conversion, didn't mean to make so much work  :)
[20:54] <slangasek> mterry: well, these are precisely the issues that have held up the dep5 stuff generally :/
[20:55] <mterry> slangasek, man, it's weird that the recentchanges feed is for all DEPs; doesn't seem scalable
[20:55] <ScottK> mterry: It might more productive to not bother with conversion until there is a stable format to convert to.
[20:56] <mterry> ScottK: Yeah...  didn't want to wait for fossilized spec, but thought it was more stable than it was
[20:56] <James_P> I *know* this channel specifically isn't for support, but I have a strange problem, and you're welcome to tell me to leave. I'm quite comfortable with a command line though, and I thought it may be a kernel upgrade causing it
[20:58] <James_P> It's just, my mouse doesn't work. It's a USB mouse, lsusb identifies it, and catting /dev/psaux shows nothing - any hints?
[21:03] <mterry> James_P, try #ubuntu
[21:03] <mterry> James_P, that is the official support channel
[21:05] <James_P> it is indeed, i've helped out a fair few people there in the past with various things. however, i was just hoping for some hints as to how the kernel detects the mouse and maps it to /dev/psaux
[21:26] <mterry> James_P, I don't know, myself.  best I have to is to look at /dev/input/* stuff too
[21:28] <James_P> mterry, thanks, i'll check that. thank you :)
[22:15] <fta> doko, apparently, i can't build ffmpeg with ld gold, it fails in configure when trying gcc, the binaries are created in 644 mode (without x)
[23:06] <slangasek> Keybuk: I thought the new upstart was going to be out before I got home? :)
[23:35] <ScottK-desktop> Does generating a new readaheadlist profile subtantially slow down the boot process?
[23:35] <ScottK-desktop> Either it does or something has gone horribly wrong here ....
[23:36] <soren> ScottK-desktop: It does.
[23:37] <ScottK-desktop> soren: Thanks (first time I've tried it).
[23:41] <glick> excuse me, is it a bug, people tell me to change my hostname to go to system>administration>networking
[23:41] <glick> but thre is no such tab
[23:42] <glick> i have "network tools" but it has no "general" tab
[23:43] <ebroder> glick: Use #ubuntu for support
[23:44] <glick> ebroder, yeah they keep telling me about an option i dont have, so i was wondering if its a bug or something
[23:45] <ebroder> glick: Did you try mentioning that you don't have it?
[23:46]  * glick sigh, yeah
[23:46] <glick> its okay, thanks
[23:46] <ebroder> glick: Network tools isn't the right application
[23:46] <ebroder> It could be that you're just running an older version of Ubuntu or something
[23:46] <glick> im running jaunty
[23:47] <ajmitch> win 21
[23:49]  * ebroder switches to a jaunty machine
[23:51] <ebroder> glick: I don't really use graphical Ubuntu, so I'm not sure what the right way to do this is. If you want to get a networking pref app, you can install gnome-network-admin. I'm not sure if it's intentionally not installed or if something's supposed to take it's place or what