[00:08] <bluefoxicy> wtf?
[00:08] <bluefoxicy> I have sound, but not if I'm watching a DVD in totem
[00:09] <directhex> liba52?
[00:38] <Viper550> https://blueprints.launchpad.net/ubuntu/+spec/remove-gimp
[00:40] <dtchen> TheMuso: 'net access is intermittent ATM; i'll push rtk as soon as i can keep a decent connection
[00:42] <TheMuso> dtchen: np, I've already got it packaged.
[00:43] <TheMuso> dtchen: and its in the new ubuntu-audio-dev PPA.
[00:43] <dtchen> TheMuso: ok
[00:43] <TheMuso> and I'm about to upload pulse 0.9.16 there as well,a nd then get rtkit pushed to revu for inclusion in the archive.
[00:44] <dtchen> right-o
[00:44] <dtchen> HDA should be much better now that 2.6.31-git is in
[00:45] <TheMuso> Right.
[00:45] <TheMuso> bryce: Are any of you on the X team aware that the latest nvidia 180 drivers in the archive don't build against 2.6.31? If not, I'll file a bug.
[00:47] <bryce> TheMuso, -nvidia will be broken until we get a new version from Nvidia built against .31
[00:47] <directhex> Viper550, actually, it's been considered and marked as a "not happening without a damn good reason"
[00:47] <dtchen> TheMuso: http://pastebin.ubuntu.com/207816/ is what i've been using
[00:47] <directhex> Viper550, see https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-06-09#The%20GIMP
[00:47] <TheMuso> bryce: Ok.
[00:47] <bryce> TheMuso, bug #394262 already covers this
[00:48] <TheMuso> bryce: ok thanks
[00:48] <TheMuso> Might set up nouveau then, as I want to give 2.6.31 a whirl.
[00:48] <bryce> TheMuso, this is normal; the binary drivers always break at this point in the cycle when the kernel (or xserver) gets updated to new API/ABI stuff
[00:49] <TheMuso> yeah I wasn't sure whether a fix was in the short term pipeline, thats all.
[00:49] <bryce> TheMuso, that'd be great
[00:49] <TheMuso> but I am aware of such breakage.
[00:49] <bryce> doubtful
[00:49] <bryce> we'll see though, Nvidia tends to be reasonably quick, although it could be several weeks
[00:50] <TheMuso> bryce: Do I need to create a xorg.conf file for nouveau similar to nvidia? COuld I just change the driver name in the xorg.conf file I have now?
[00:51] <bryce> TheMuso, yeah pretty much
[00:52] <TheMuso> ok
[00:52] <superm1> TheMuso, if it looks obvious, you can write a kernel patch that can be applied by dkms too
[00:52] <bryce> -nvidia sometimes needs a lot of stuff in xorg.conf that nouveau won't need, so actually you could probably strip a lot of stuff out
[00:52] <superm1> until nvidia has a new version
[00:52] <TheMuso> ...and nouveau fails to build as well. I'll see if I can track down a fix for that.
[00:52] <superm1> TheMuso, a quick google yields: http://leigh123linux.fedorapeople.org/pub/patches/nvidia-185.18.14.patch
[00:53] <TheMuso> superm1: pOk thanks, I wasn't going to bother with that, but I'll take a look.
[00:53] <dtchen> that and you just have to modify dkms.conf, and you're on your way
[00:53] <superm1> here's the whole thread for it: http://forums.fedoraforum.org/showthread.php?p=1231266
[00:53] <bryce> superm1, weird, that patch looks familiar for some reason
[00:53] <bryce> superm1, is that the same change that's done to fglrx to make it build with .31?
[00:54] <superm1> bryce, I don't think i've submitted anything for fglrx to build on .31
[00:54] <superm1> bryce, i've tracked down a ton of stuff for .29 and .30 though
[00:54] <dtchen> it's very likely the same change
[00:55] <bryce> superm1, I think it was Sarvatt or Tormod that mentioned it to me
[00:56] <superm1> knowing that i2c changed a lot, I think it's quite a hacky solution though to just remove i2c alltogether like that..
[00:56] <dtchen> yeah, should poke zander for a real fix
[01:01] <RAOF> TheMuso: Nouveau'll fail until I update the nouveau-kernel-source package.  Doing this requires updating the xserver-xorg-video-nouveau package, and libdrm-nouveau1 package, so there are a couple of pieces that need to fall into place first :)
[01:02] <TheMuso> RAOF: Ok. I think at this point I'll just stick with 2.6.30. 2.6.31 is not urgent.
[01:03] <RAOF> If you're lucky, the new nouveau stack will even do KMS.  And if you're _super_ lucky, it might even bring up X with kms enabled!
[01:03] <ccheney> TheMuso: yea 2.6.31 crashes on boot for me :-\
[01:03] <TheMuso> ccheney: It doesn't crash for me, I just don't have X.
[01:04]  * ccheney thinks he will have to do a nice manually type in of the crash dump later to report the bug
[01:05] <TheMuso> Mind you, I've only tried 2.6.31 on my desktop.
[01:05] <TheMuso> My notebook will likely be another story.
[01:05] <ccheney> ah i tried booting it on my x200
[01:06] <ccheney> grr this is really annoying every time i restore my firefox it eventually crashes before finishing loading everything
[01:10] <cjwatson> EvanCarroll: that's one package, afaict. I understand you're upset but I wish you'd stop generalising that to all of Debian's perl packaging, which is not as broken as all that
[01:11] <cjwatson> EvanCarroll: it's pretty aggravating for those of us who package (small amounts of) perl stuff in Debian without this kind of problem
[01:12] <cjwatson> and I don't think the problem I believe you're talking about has anything to do with core perl in Debian
[01:15] <EvanCarroll> cjwatson: the issue is with anything debian modifies that is perl.
[01:15] <EvanCarroll> cjwatson: It is totally wrong on its face.
[01:15] <cjwatson> how is that in any way specific to perl?
[01:15] <cjwatson> you could say the same thing about any distro patch (although it's only actually a problem in a minority of cases)
[01:16] <EvanCarroll> I never said it was, I said it was specific to the way debian packages perl. it is all kinds of wrong.
[01:16] <cjwatson> no, it's really not
[01:16] <EvanCarroll> Yes, it really is.
[01:16] <EvanCarroll> You see, you don't, if you're sane, open up a namespace and just drop your own stuff into it.
[01:16] <cjwatson> from previous discussions, you're objecting to a patch that's been applied to one of the xml modules, changing its interface
[01:16] <EvanCarroll> that completely defeats the purpose of a namespace.
[01:16] <cjwatson> and distro changes to interfaces are often unwise, sure
[01:16] <cjwatson> that has zero to do with perl packaging in Debian as a whole
[01:17] <cjwatson> it's a single maintainer doing a silly thing
[01:17] <EvanCarroll> No, I'm objecting to the debian policy that makes that kind of patch acceptable and ubiquitious
[01:17] <cjwatson> but it's not ubiquitous
[01:17] <EvanCarroll> Debian does it all over.
[01:17] <ccheney> anyone know if there is a way to dump the current list of open webpages in a firefox profile? i can't get my firefox to come back up even with disabling all extensions
[01:17] <cjwatson> that's a gross overstatement
[01:17] <bryce> ccheney, wow I'd love to know how to do that
[01:17] <bryce> that'd be *so* handy
[01:17] <ccheney> asac: ping ^ ? :)
[01:18] <ccheney> bryce: its probably in some sqlite format or something but any way to dump it at all would be useful
[01:18]  * bryce nods
[01:18] <ccheney> i have probably 100 tabs that i no longer can access :-\
[01:18] <cjwatson> ccheney: it's in sessionstore.js in your profile
[01:19] <cjwatson> you can run it through indent or whatever and then read it out fairly straightforwardly
[01:19] <ccheney> cjwatson: thanks! :)
[01:19] <cjwatson> some json library might even be able to parse it properly for you
[01:19]  * ccheney hugs cjwatson 
[01:23] <cjwatson> ah, no, sessionstore.js is apparently not json
[01:23] <ccheney> cjwatson: do you know if there is a way to make indent properly break a js single line file that is 800KB?
[01:24] <cjwatson> no, I think I had to fiddle about a bit last I tried that
[01:24] <ccheney> ok
[01:25] <cjwatson> ccheney: googling for "sessionstore.js parse" has some useful hits
[01:25] <ccheney> ah thanks for the tip :)
[01:25] <cjwatson> including e.g. http://tsukasa.net.au/~hg/greg_stuff/file/tip/parse_sessionsstore.py (untried)
[01:26] <cjwatson> ... breaks for me, probably requires some munging
[01:27] <ccheney> yea
[01:27] <cjwatson> (specifically there are some values starting with #, I haven't looked into why)
[01:35] <ccheney> one of the first links had a way to do it with grep
[01:35] <ccheney> of course the file seems to have every url you have opened since your session started (or close to it)
[01:35] <ccheney> 1542 urls for mine, lol
[01:35] <ccheney> but a lot are dupes so it should be easy to get the useful ones out of the list
[01:36] <ccheney> erm what is the guest password?
[01:36] <ccheney> i used guest to search for the stuff in firefox but when i switched back to the guest session was locked and wanted a password
[01:37] <bryce> ccheney, I've got a script that handles it now
[01:37] <bryce> it's fugly and perl but works.  let me fix one thing and I'll pastebin
[01:37] <ccheney> ok
[01:38] <bryce> http://pastebin.ubuntu.com/207837/
[01:40] <bryce> oops forgot one other bit...  http://pastebin.ubuntu.com/207838/
[01:40] <cjwatson> ccheney: if you look at the file structure in more detail, closed tabs are in a different part of the file, and it's easy to distinguish the things that are open right now
[01:40] <ccheney> ah ok
[01:43]  * ccheney notes his two year old came up and told him it was time to eat, and pulled his highchair out
[01:44] <ccheney> bryce: the script seems to be slightly off still only showed me 5 urls
[01:46] <bryce> ccheney, hmm, maybe it is printing only one url per window, rather than one per tab
[01:47] <bryce> yeah
[02:07] <bryce> ccheney, cjwatson: actually it is JSON-ish, just that it breaks some syntax rules
[02:34] <bryce> ccheney, bingo.  got it
[03:26] <bryce> ccheney, http://www2.bryceharrington.org:8080/drupal/ff-pages
[05:20] <emma> how are things going
[05:21] <mneptok> emma: heya!
[05:21] <emma> hi there :)
[05:21] <emma> How are things going with your projects?
[05:22] <mneptok> emma: OSCon coming up. working on prep for that. and the Community Leadership Summit.
[05:25] <emma> Oh very cool.
[05:26] <mneptok> emma: you going to either?
[05:27] <slangasek> I'm boycotting OSCON because it's not in Portland
[05:28] <slangasek> oh wait, that's not boycotting, I didn't attend when it was here
[05:30] <mneptok> slangasek: that doesn;t stop you from being unrighteously indignant
[05:33] <ghindo> slangasek, There's still open source bridge, Linux plumbers, etc.
[05:36] <mneptok> the Linux Plumbers' Conference intrigues me, but i don't like prostate exams ...
[05:37] <lifeless> LOL
[05:38] <slangasek> ghindo: oh, I'm well aware. :)
[05:38] <slangasek> I found the spontaneous appearance of OSBridge to be wonderfully amusing
[05:39] <mneptok> slangasek: the OS Bridge people cut out "I planned to start my talk with an interpretive erotic dance to the theme from 'Knight Rider' ..." from the video of my keynote. i am not amused.
[05:39] <slangasek> heh
[06:27] <TheMuso> woohoo about time. Skype is getting pulseaudio support.
[06:34] <dholbach> good morning
[06:50] <dholbach> Ubuntu Development and Packaging Q&A in 10m in #ubuntu-classroom
[07:08] <pkt> anyone here knowledgeable about the ca-certificates-java issue?
[07:08] <pkt> the changelog claims it is fixed, but it seems it isn't
[07:09] <pkt> and I can't find any hint of where exactly it filters out certificates using unsupported algrorithms
[07:11] <pkt> oh, nevermind I found the code
[07:11] <pkt> now, still need to figure out why it doesn't work ...
[07:54] <pitti> Good morning
[07:54] <pitti> kirkland: confirmed, please drop all the hal bits and the fdi; teh ACL si taken care of
[07:55] <pitti> meh, I need to wake up, can't type yet
[08:49] <YokoZar1> Can a package recommend a minimum version of a package?   If I recommend foo (>= 1.2) and there's a foo 1.0 and a bar 1.2 that provides foo,  will bar be installed?
[08:51] <geser> provides are always unversioned
[08:52] <geser> so foo (>= 1.2) will wait on foo 1.2-1 even if bar 2.0 provides foo
[08:58] <asac> ccheney: while running?
[08:59] <asac> (list of open webpages)
[09:00] <j^> fta, whats the best place to file a bug for chromium-browser?
[09:01] <j^> FFMPEG_MT_CONFIGURE_FLAGS has to include --extra-cflags="-m32" --extra-ldflags="-m32" on amd64 to build usable libs
[09:04] <geser> mvo: do you need some more tests/output for bug 385144?
[09:06] <mvo> geser: yes, it looks like its exiting with a signal but the debug output does not catch which one (yet) - could you please either run strace on the http child (if that is possible I image its pretty quick to open/close) ?
[09:14] <Quintasan> hi
[09:19] <geser> mvo: http://launchpadlibrarian.net/28621735/apt.strace I see there a EPIPE on a write near the end
[09:22] <mvo> geser: thanks, let me look into the source to see how it fits there :)
[09:35] <lesshaste> I've remove the /var/cache/debconf directory by mistake, how can I restore it? It makes apt-get install unhappy
[09:37] <siretart`> lesshaste: wrong channel, see channel topic. btw, the answer is: restore from your backups
[09:38] <lesshaste> ok
[09:38] <lesshaste> thanks
[09:44] <cjwatson> siretart`: FWIW, it's a cache ... he'd probably have to use debconf-loadtemplate or something to put a skeleton back together, but all he's really lost is some default answers to questions
[09:44] <cjwatson> (and actually there's a debconf bug filed in Debian for the fact that debconf doesn't recover automatically)
[09:49] <siretart`> oh? that's interesting. thanks for the note
[09:51] <siretart`> does a similar bug also exist for apt?
[09:57] <cjwatson> siretart`: I don't know
[10:52] <glatzor> hello mvo
[10:52] <mvo> hey glatzor!
[10:52] <glatzor> mvo, I think that aptdaemon is now in a quite good state for uploading
[10:52] <mvo> glatzor: I'm on my way for lunch, but I send you some mails
[10:52] <mvo> glatzor: I did the upload this morning
[10:53] <mvo> glatzor: I played with it too and its pretty cool
[10:53] <glatzor> mvo, oh, I made some changes in today's train ride
[10:53] <glatzor> mvo, but great!
[10:53] <glatzor> mvo, enjoy yourself!
[10:54] <mvo> glatzor: trunk is at r174 for me
[10:54] <mvo> glatzor: or do you mean g-a-i changes?
[10:55] <glatzor> now it is at 175 :)
[10:55]  * mvo hugs glatzor
[10:55] <glatzor> I converted the console client to gobject
[10:56] <mvo> glatzor: I noticed, nice
[10:56] <mvo> glatzor: I will upload that after lunch, but its going to take a bit to go through NEW anyway, so no worries
[10:57] <tseliot> soren: if you added a patch to the bcmwl can you update its bzr branch, please? lp:~broadcom-sta-hackers/broadcom-sta/ubuntu
[11:30] <tseliot> cjwatson: I still can't get my udeb to be used. Do you think something's wrong in my debian/control file? http://bazaar.launchpad.net/~albertomilone/+junk/product-check/files
[11:31] <TheMuso> Gah, turns out the kernel patch that rtkit needs is not even in 2.6.31 yet, and yet rtkit docs say you need 2.6.31 or newer. Since we are at rc1, I would have thought that is what he meant. :)
[11:31] <TheMuso> s/he/Lennart
[11:32] <pitti> TheMuso: hm, and it doesn't work at all without rtkit?
[11:32] <pitti> shouldn't it work at least as good as with 0.9.15 without rtkit?
[11:34] <TheMuso> pitti: I don't know what happens without rtkit.
[11:35] <TheMuso> I think pulse just won't work with realtime privileges.
[11:35] <TheMuso> However the patch does appear to be in a tree that gets merged periodically into mainline.
[11:36]  * TheMuso pulls the tree to see what branch the patch resides in.
[11:36] <cjwatson> tseliot: I doubt your debian/control matters; surely it's more important what patch you're applying to debian-installer when rebuilding it?
[11:38] <tseliot> cjwatson: patch? I only added my udeb to the binary_local-udebs directory of my project
[11:38] <cjwatson> that's not sufficient
[11:38] <cjwatson> you're expecting this to be used at d-i startup, right? before d-i gets round to loading any bits of itself from the archive?
[11:38] <cjwatson> that kind of implies rebuilding d-i ...
[11:39] <cjwatson> if you don't want to do that, I wish you'd said earlier, since I'd have suggested a different approach :)
[11:39] <tseliot> cjwatson: yes so that I can abort the installation on some hardware units
[11:39] <tseliot> oh
[11:39] <cjwatson> therefore you have to rebuild d-i with product-check listed somewhere appropriate under build/pkg-lists/, maybe build/pkg-lists/base
[11:40] <cjwatson> and then the contents of the product-check udeb will be embedded into the initrd as a result
[11:40] <cjwatson> d-i's build process will have to be pointed at your archive
[11:43] <tseliot> cjwatson: hmm... this is all I have in my project: https://pastebin.canonical.com/19272/
[11:44] <cjwatson> something of all of that is an apt archive, right?
[11:45] <cjwatson> anyway, I'm not going to debug your archive layout for you :-)
[11:45] <cjwatson> just advising what would need to be changed
[11:45] <tseliot> cjwatson: ok, thanks
[11:45] <cjwatson> if binary_local-udebs (odd name) is an apt archive, it can be included in d-i's build process
[11:45] <cjwatson> there's a sources.list equivalent around somewhere in there
[11:46] <cjwatson> easiest is to just build it and watch the output closely, you'll pick up what's going on
[11:46] <cjwatson> does mean that you'll have to deliver the updated initrd somehow
[11:46] <tseliot> cjwatson: we use the bootstrap file (which acts like a sources.list)
[11:56] <mvo> geser: *wehhh* I can reproduce the problem with apt-cacher-ng now :-D
[11:57]  * mvo is happy
[11:58] <geser> mvo: does apt-cacher-ng manage to trigger this bug because it can serve packages that fast?
[11:59] <mvo> geser: not sure yet, but its delivering faster than squid for me
[11:59] <mvo> geser: might be some odd problem with apt-cacher-ng as well, but whatever it is, apt should deal better with it :)
[12:04] <mvo> wb glatzor
[12:08]  * glatzor waves mvo
[12:09] <glatzor> mvo, I just added some security features
[12:13] <glatzor> mvo, won't using the md5sum of a package as identifier in the xapian cache instead of the package name help to only re-index "changed" packages?
[12:15] <cjwatson> let's not use md5sums as unique ids
[12:16] <mvo> glatzor: I guess what we need is something like that, a uniq hash so that we can identify what is new
[12:16] <mvo> and only add that
[12:17] <glatzor> mvo, or we could just store the hash as an attribut in the xapian document
[12:39] <ogra> tkamppeter, are there any known bugs with HP 1018 LaserJet printers ? i havent printed for quite a while and just had to use a deskjet instead, the 1018 used to work, but now it doesnt on my karmic and neither on my girlfriends intepid
[12:44] <pitti> ogra: how it doesn't work? detection? doesn't print at all? prints wrongly?
[12:45] <ogra> doesnt do anything
[12:45] <pitti> ogra: /var/log/cups/error_log?
[12:45] <ogra> i can plug it in, it gets recognized
[12:45] <pitti> ogra: ah, so you do see it in "lpinfo -v"?
[12:45] <ogra> hmm, i have rebooted several times, the log only has four lines
[12:46] <ogra> one sec, i'll go back and plug it in
[12:47] <ogra> oh, fun, now xsane looks for scanners when i plug it in
[12:47] <pitti> you mean it spawns xsane?
[12:47] <ogra> yes, lpinfo sees it though
[12:47] <pitti> that sounds like an ancient gnome-volume-manager test version
[12:48] <ogra> well, i suspect its something with a driver update
[12:48] <ogra> susie says it stopped around a week or two ago on her intrepid
[12:48] <pitti> ogra: and evince or whatnot don't generate an error, it just disappears?
[12:48] <pitti> that should be in the log then
[12:48] <ogra> the printer fully works on windows
[12:48] <pitti> intrepid! hmm
[12:48] <pitti> we didn't do an update to intrepid recently
[12:48] <ogra> yes, she uses intrepid, i use karmic
[12:49] <ogra> well, she uses to wait for months with hers :)
[12:49] <ogra> she doesnt like reboots so leaves u-m idle in the panel
[12:49] <ogra> http://paste.ubuntu.com/208071/
[12:49] <pitti> ok, no idea about drivers, I'm afraid; I'll leave that for Till then
[12:49] <ogra> thats my karmic lpinfo
[12:50] <ogra> looks fine to me
[12:50] <pitti> indeed
[12:50] <ogra> doesnt print a testpage though
[12:50] <pitti> so this needs some error_log after a print attempt, I think
[12:50] <ogra>  [02/Jul/2009:13:46:49 +0200] Resume-Printer: Unauthorized
[12:50] <ogra> looks suspicious
[12:51] <pitti> ogra: can you do "cupsctl --debug-logging", then print something, then "cupsctl --no-debug-logging", then put error_log somewhere?
[12:51] <pitti> ah, the log is usually full of "unauth" stuff
[12:52] <ogra> hmm
[12:52] <ogra> after cupsctl --debug-logging the printer ui doesnt react anymore
[12:52] <ogra> i cant click on "print testpage"
[12:52] <ogra> i mean, i can but nothing happens
[12:52] <pitti> lpstat -p has the job?
[12:53] <pitti> sorry, lpstat; lpstat -p is printer status (also interesting)
[12:53] <ogra> Drucker HP-LaserJet-1018 ist inaktiv.  Aktiviert seit Do 02 Jul 2009 13:50:39 CEST
[12:53] <pitti> ok that
[12:53] <ogra> no job, UI unresponsive
[12:53] <ogra> i cant close it either
[12:53] <pitti> fail
[12:53] <ogra> oh, there was a popunder
[12:54] <ogra> ogra@osiris:~$ lpstat
[12:54] <ogra> HP-LaserJet-1018-58     ogra            153600   Do 02 Jul 2009 13:54:00 CEST
[12:54] <ogra> ...
[12:54] <ogra> Drucker HP-LaserJet-1018 druckt gerade HP-LaserJet-1018-0.  Aktiviert seit Do 02 Jul 2009 13:54:00 CEST
[12:54] <ogra> it thinks the printer prints
[12:54] <ogra> which it doesnt
[12:55] <pitti> sounds like a hplip bug then
[12:55] <pitti> ogra: do you have some stuff in error_log now?
[12:55] <pitti> it should have the filter chain, etc.
[12:55] <ogra> yep ... but also says it printed successfully
[12:55] <pitti> ogra: I'd recommend opening a hplip bug with that error_log and lpstat stuff
[12:55] <ogra> i can put it up, but there seem to be no errors
[12:55] <ogra> ok
[12:56] <ogra> will do, thanks a lot
[12:56] <pitti> upstream reads them, too, and have a clue about hplip
[12:56] <ogra> its a bit weird, until recently that was the most reliable printer in my house ...
[12:57] <ogra> strange that it stopped working on all ubuntus here
[12:57] <pitti> <IT crowd voice>Hello, IT, have you tried turning it off and on again?
[12:57] <ogra> indeed
[12:57] <ogra> various times
[12:58] <ogra> and i removed it and left it finding itself on plugin etc
[12:58]  * ogra thinks he did everythig a dumb user can do before digging deeper :)
[12:58] <pitti> and today is not Tuesday, so it's not that infamous file bug
[12:59] <ogra> heh, no, i thought that first when susie told me she couldnt print last week
[12:59] <ogra> she though i'm kidding when i asked which day it was
[13:00] <pitti> ogra: "Gewerkschaftlicher Feiertag" :-P
[13:00] <ogra> lol
[13:00] <liw> Tuesday bug?
[13:01] <pitti> liw: bug 248619
[13:01] <pitti> weirdest bug EVAR
[13:01] <pitti> liw: caused printing from OO.o to fail on Tuesdays
[13:03] <Ng> that was a great bug :)
[13:03] <liw> heh
[13:04] <liw> pitti, thanks, I needed that as fortification before I slaughter a perfectly working desktop machine with dmraid
[13:07] <TheMuso> liw: You have my sympathies.
[13:08] <liw> TheMuso, thank you
[13:09]  * liw is sure he saw a screwdriver somewhere, probably next to the phone number for emergency services
[13:09] <TheMuso> lol
[13:22] <lool> Hmm 2.6.31 oopses for me in the initramfs; it seemed to be acpi + i915 related but I can't find other reports, it surprizes me that nobody else is seeing that
[13:24]  * ogra__ didnt upgrade the last 4 days ... i'll do and tell you 
[13:24] <lool> I saw at least pitti boot that successfully on his laptop since he mentionned testing a patch on top of 2.6.31-rc1
[13:25] <pitti> lool: right, working fine here
[13:25] <ogra__> still 2.6.30-10-generic here
[13:25] <pitti> lool: Mobile 945GM/GMS
[13:25] <ogra__> PM965/GM965/GL960 here
[13:26] <pitti> lool: if you can isolate it, please report a bug in bugs.fd.o against -intel, the guys are pretty responsive nowadays
[13:26] <pitti> lunch, bbl
[13:26] <ogra__> hmm, it wants to remove udev-extras ?
[13:26]  * ogra__ just goes for it ...
[13:35] <lool> pitti: Yeah, I've actually followed your bugs because they looked like mine and am trying two patches which they sent  :)
[13:42] <ogra> ogra@osiris:~$ uname -r
[13:42] <ogra> 2.6.31-1-generic
[13:42] <ogra> all fine here after upgarde
[13:42]  * ogra tries a suspend/resume
[13:43] <ogra> perfect
[13:44] <lool> Grumpf
[13:54] <MacSlow> asac, ping
[13:54] <MacSlow> asac, got a "moment"?
[13:55] <seb128> grrrr
[13:56] <seb128> what can be making load on a box and not been listed as using cpu in top for example?
[13:56] <seb128> my laptop has a 3.65 load
[13:56] <seb128> but nothing is using cpu in an obvious way
[13:56] <MacSlow> nasty
[13:56] <seb128> it's doing nothing I just have IRC running
[13:56] <MacSlow> seb128, something in the kernel itself maybe?
[13:57] <seb128> dunni
[13:57] <seb128> dunno
[13:57] <seb128> that's why I'm asking ;-)
[13:57] <MacSlow> seb128, I assume stuff like top & Co only show user-space processes
[13:57] <Laney> iotop?
[13:58] <seb128> Laney, the disk doesn't seem to be busy it makes no noise
[13:58] <seb128> hum
[13:58] <seb128> 0.00 B/s   35.76 K/s  0.00 %  0.00 % gconfd-2
[13:58] <walters> one thing to keep in mind is that top compresses threads by default, but each runnable thread contributes to load i think
[13:59] <glatzor> mvo, hello. I will be offline now until sunday or saturday. see you! I just comitted some improvements to the console client
[14:00] <mvo> glatzor: thanks, you rock
[14:00] <mvo> glatzor: I look at bit into xapian now
[14:00] <seb128> ok it's gconfd
[14:09] <asac> MacSlow: ?
[14:09] <MacSlow> asac, still/again wifi issues
[14:10] <MacSlow> asac, not sure if it's a NetworkManager or ath9k thing
[14:10] <asac> MacSlow: did you try backport-modules yet?
[14:11] <MacSlow> asac, after pulling and plugging back in the ath9k PCMCIA-card I only results from "iwlist scan" for about 10 secs
[14:13] <seb128> Laney, thanks, iotop has been useful to figure it was gconf being busy
[14:13] <asac> MacSlow: try installing linux-backports-modules-hardy
[14:13] <Laney> seb128: no worries, it's been useful for me in similar situations before
[14:13] <alex-weej> anyone have any idea why a boat load of processes keep wakign up in karmic?
[14:13] <alex-weej> it's literally frying my legs
[14:14] <alex-weej> stuff like indicator applet has used 18 seconds of CPU time since about 20 mins ago
[14:14] <asac> MacSlow: that might also fix your intel thing
[14:15] <alex-weej> i am watching top and there are about 30 processes always running
[14:15] <MacSlow> asac, rebooting with that... was missing from the 2.6.30-10 update
[14:16] <alex-weej> and gconfd2 is going absolutely mental
[14:18] <seb128> alex-weej, your issue is probably some application doing lot of gconf queries
[14:19] <alex-weej> gconfd2 is just one of many processes going off a lot
[14:19] <seb128> alex-weej, that's what I had some minutes ago, see the log
[14:19] <seb128> restarting the session made things better ;-)
[14:19] <seb128> not sure how to track easily what is talking to gconf
[14:19] <seb128> one frequent issue is things being restarted in loop by gnome-session
[14:19] <seb128> ie nautilus when not drawning the desktop or vino
[14:19] <seb128> hum ok so probably a different one
[14:19] <asac> MacSlow: huh? you are not on hardy?
[14:20] <MacSlow> asac, I'm (need to be) on karmic
[14:20] <ogra> MacSlow, karmic has .31
[14:20] <alex-weej> seb128, looking at the process list, it seems everything gconf-using is running pretty much all the time
[14:20] <MacSlow> asac, backports-modules was missing
[14:21] <MacSlow> ogra, I know, but can't use that as it has broken KMS for my i965
[14:21] <asac> MacSlow: ah. ok. still 3945 doesnt work for you?
[14:21] <seb128> alex-weej, do you use compiz?
[14:21] <ogra> hmm, works on my i965
[14:21] <MacSlow> ogra, nothing really works for me
[14:21] <ogra> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
[14:21] <MacSlow> asac, yes the iwl3945 is very likely to be broken
[14:22] <asac> MacSlow: i would really suggest to file a kernel bug and poke them directly
[14:22] <MacSlow> ogra, under 2.6.31 my laptop doesn't even boot
[14:22] <ogra> weird
[14:22] <asac> iwl3945 is definitly supposed to work on .31
[14:24] <alex-weej> seb128, killed gconfd2 and it stopped waking everything up
[14:24] <alex-weej> all of the ubuntuone stuff seems to be constantly doing stuff though
[14:24] <alex-weej> it's not even "connected"...
[14:26] <tgpraveen> MacSlow: hi in karmic it is planned to suppress notify-osd bubbles which are non critical for fulsscreen apps.
[14:27] <tgpraveen> so will empathy/pidgin msgs be critical or non critical?
[14:27] <MacSlow> tgpraveen, that is the plan
[14:27] <MacSlow> tgpraveen, notifications from apps such as IM-clients should be either low or normal... not critical
[14:28] <tgpraveen> MacSlow: but that will mean that if i am watching a movie and my friend IMs me i will miss it till the movie completes. is this not a bad thing?
[14:29] <tgpraveen> IM msgs, voice calls are all critical as they require immediate response unlike say emails. will there be a setting to change this atleas?
[14:29] <MacSlow> tgpraveen, I don't think so
[14:29] <MacSlow> tgpraveen, if it is urgent would be pinged again from your friend
[14:30] <MacSlow> tgpraveen, besides e.g. watching a movie is also meant to set you state to "busy" or "unavailable" so your friend won't be surprised if you don't respond right away
[14:32] <tgpraveen> MacSlow: well in many use cases i might be watching the movie while i wait for my friend to contact me. also i dont understand waht u say above
[14:32] <tgpraveen> "he would ping again" even if he does then also no notification will come and hence wont have any effect
[14:32] <MacSlow> tgpraveen, don't make the movie fullscreen then
[14:33] <MacSlow> asac, you know what that's all about
[14:33] <MacSlow> tgpraveen, btw.. you should be talking to the Design folks not me, regarding such issues
[14:34] <tgpraveen> MacSlow: if a explicit do-not-disturb mode is there then i can understand no notifications but if i am say available status in IM then i guess my frnds would expect me t o reply
[14:34] <MacSlow> asac, you know what that's all about http://people.ubuntu.com/~mmueller/nm-applet-wtf.png
[14:34] <tgpraveen> MacSlow: oh ok should i mail to ayatana amiling list?
[14:35] <MacSlow> tgpraveen, or bug them on #ayatana on this IRC-network
[14:35] <ogra> MacSlow, stop connecting to japanese wlans !
[14:35] <tgpraveen> ok.thx
[14:36] <ogra> MacSlow, what font is that ?
[14:36] <ogra> looks intresting
[14:37] <asac> MacSlow: whats going on with the AP names?
[14:37] <asac> do you get those bogus values from the driver?
[14:38] <MacSlow> asac, how should I know
[14:38] <MacSlow> asac, I only ever entered "linksys" (the one with the shield)
[14:38] <MacSlow> asac, where's this list shown there stored?
[14:42] <asac> MacSlow: wpasupplicant
[14:42] <MacSlow> asac, that's a tool or a directory?
[14:48] <smb> looks a bit like receiving trash and trying to convert into something
[14:49] <smb> Definitely not the AP names I'd expect to see in Germany...
[14:51] <smb> MacSlow, question would be if you get the same names with the iwlist scan
[14:51] <jdstrand> didrocks: hi! so I found the 'quickly' project and had some trouble. I don't have time to work through all of it right now, but I did a checkout, then installed everything found in debian/control, did quickly new ubuntu-project ... and everything seemed to work. problem is that it told me to click a ui file to update the gui, but that didn't work. .ui wasn't associated with glade apparently, and trying to start it didn't work either
[14:51] <jdstrand> didrocks: this is using jaunty bt
[14:51] <jdstrand> w
[14:51] <jdstrand> btw
[14:52] <didrocks> jdstrand: hum, this seems more a glade issue. I will try it on jaunty this evening
[14:53] <seb128> jdstrand, do you get glade used when clicking on a .ui in nautilus?
[14:54] <jpds> MacSlow: In which branch has bug #337820 been fixed?
[14:54] <didrocks> jdstrand: also, you can try "quickly glade" in the project
[14:54] <seb128> jdstrand, hum in fact that's not supposed to be working apparently
[14:54] <jdstrand> seb128: I didn't at first, but now am (weird)
[14:54] <seb128> (which is probably a bug)
[14:55] <jdstrand> seb128: oh, not weird, I think I told it to open with glade via the application chooser thingie
[14:55] <jdstrand> s/am/is/
[14:55] <jdstrand> regardless, opening glade and trying to open the .ui file explicitly didn't work either
[14:56] <jdstrand> I got the following error: Failed to load ....ui. The following catalogs are unavailable: ...
[14:56] <didrocks> jdstrand: thanks because we use .xml file for ours widget
[14:56] <jdstrand> I'm a bit new to glade-- seems the catalog is the xml file? well, that xml file does exist
[14:56] <didrocks> jdstrand: does the documentation tell to double-clic in a .ui file?
[14:57] <didrocks> normally quickly glade what it has to do for you
[14:57] <didrocks> +does
[14:57] <MacSlow> jpds, trunk
[14:57] <jdstrand> didrocks: after running quickly it starts the application, which has some text telling me to double click the .ui file to edit the interface
[14:57] <MacSlow> jpds, I also have patched/updated g-p-m and g-s-d in my PPA
[14:57] <didrocks> jdstrand: ok, I must ask rick to update it
[14:58] <MacSlow> jpds, I don't know if those all made it into karmic's main repo yet though
[14:58] <jdstrand> didrocks: quickly glade from within the directory worked
[14:58] <jpds> MacSlow: Oh, I looked in the commit history and couldn't find a revision with it.
[14:58] <jdstrand> cool
[14:58] <jdstrand> so maybe it is just a doc update
[14:58] <jdstrand> s/doc/template/
[14:59] <MacSlow> jdstrand, maybe it's a duplicate I didn't mark yet and thus wasn't marked as fixed
[14:59] <didrocks> yes. I will do it this evening and adding some stuff to quicklyl release
[14:59] <didrocks> (doc update)
[15:00] <MacSlow> jdstrand, sorry.
[15:00] <MacSlow> jpds, maybe it's a duplicate I didn't mark yet and thus wasn't marked as fixed
[15:00] <jpds> MacSlow: Oh, was it fixed in g-p-m trunk then?
[15:01] <MacSlow> jpds, no... I only did a distro patch for it...
[15:06] <tkamppeter> ogra, what does "hp-info -i -d hp:/usb/HP_LaserJet_1018?serial=KP08PCR --id" return (on your Karmic box)?
[15:08] <ogra> tkamppeter, http://paste.ubuntu.com/208165/
[15:13] <tkamppeter> ogra, it did not load its firmware. Can you run hp-setup -i
[15:13] <ogra> one sec
[15:14] <superm1> TheMuso, re skype + pulse, where'd you hear that? public sources somewhere? https://developer.skype.com/jira/browse/SCL-237 and https://developer.skype.com/jira/browse/SCL-271 were the only two public public bug reports I knew, and nothing appeared to have changed
[15:15] <ogra> ah, it downlods something
[15:16] <ogra> tkamppeter, works !
[15:20] <tkamppeter> ogra, so on karmic only the firmware was missing. Can you try also on Intrepid? If there is no "hp-plugin" on Intrepid, please install hplip-gui and run hp-setup.
[15:21] <ogra> will do, but my girlfriend is using the machine at the moment so that has to wait a bit
[15:21] <tkamppeter> ogra, OK.
[15:35] <kirkland> pitti: awesome, thanks.
[15:35] <pitti> kirkland: I thought I already told you a couple of weeks ago
[15:36] <pitti> 09 Jun 08 11:20:51  <pitti> kirkland: please drop /usr/share/hal/fdi/policy/10osvendor/10-kvm.fdi and /usr/share/PolicyKit/policy/org.freedesktop.hal.kvm.policy from  kvm, it's not used any more (hal deprecation)
[15:37] <kirkland> pitti: heh :-)  yeah, sorry, it's been pretty crazy
[15:37] <pitti> kirkland: is it just that, or does it have other hal integration which we need to convert?
[15:37] <pitti> kirkland: no need to be, just wondering if that's complete, or whether we need to design more stuff
[15:37] <kirkland> pitti: there was an lshal call in a reportbug.sh script -- i dropped that because i have apport hooks now
[15:37] <pitti> it might need hal to detect USB devices or whatnot
[15:38] <kirkland> pitti: i plan on uploading the new kvm today-ish
[15:38] <pitti> kirkland: oh, that could just stay as long as it's ||true'd, to avoid delta (doesn't matter much)
[15:38] <kirkland> pitti: i went ahead and dropped it
[15:38]  * pitti pats https://wiki.ubuntu.com/Halsectomy
[15:41] <kirkland> pitti: i dropped the .fdi as well as org.freedesktop.hal.kvm.policy
[15:41] <kirkland> pitti: http://bazaar.launchpad.net/~kirkland-auto/%2Bjunk/qemu-kvm-packaging/revision/28
[15:41] <pitti> kirkland: cool; it shold just be cruft, we disabled ACLs in hal a few weeks ago
[16:01] <liw> TheMuso, are you still here? I have two SATA disks installed (and they work), but the J-Micron bios raid thing does not recognize them, and I think I've cycled through all possible configurations now -- any suggestions?
[17:28] <superm1> pitti, bryce: so if xorg.conf is going to be fully gone by default, what do you guys think about shipping an xorg.conf inside xorg-driver-fglrx and nvidia-glx-* that diverts any user xorg.conf, and then puts it's own while the package is installed?
[17:29] <superm1> that'd mean jockey wouldn't need to do all sorts of work mucking around with the xorg.conf in the first (common) place
[17:30] <bryce> superm1, it sounds ok to me
[17:30] <bryce> superm1, though I wonder if the user has configured input devices or something, if we'd still need jockey to do its thing
[17:31] <superm1> bryce, oh hmm. what input device config stuff ends up in there?
[17:31] <superm1> I thought that should have all been fdi files
[17:31] <superm1> or whatever the successor will be in the new hal-less era
[17:31] <ScottK> superm1: Just because it's not there by default, doesn't mean it's completely gone.  I think you need to take care not to muck up what a user has put there.
[17:32] <superm1> ScottK, well you are more likely to have a successful boot when adding and removing one of those drivers if you give it a fresh start I seem to feel though
[17:32] <pitti> superm1: in theory there's nothing that stops nvidia's postinst from doing the exact same python-xkit invocation than jocokey
[17:32] <superm1> along the lines of bryce's comment the other day that "what cases do we still need bulletproofx"
[17:33] <pitti> with the added benefit that it would work with apt-get
[17:33] <pitti> right, I woudln't entirely divert it away
[17:33] <pitti> just check "can I change this", and then change it inline
[17:34] <ScottK> superm1: I can understand it simplifies the problem significantly, but that still doesn't make it OK to throw away user changes.
[17:34] <superm1> pitti, well then perhaps checking if the file doesn't exist, adding in one, and taking note that you did so then, and removing it when you purge
[17:34] <pitti> superm1: right, that's pretty much what jockey does as well
[17:35] <superm1> ScottK, yeah that's why i was saying to divert it, user changes would still be there, and they could merge them at their leisure
[17:35] <ScottK> Ah, that seems a bit user hostile to me.
[17:36] <pitti> as a compromise, it could create a default xorg.conf (or change the standard boilerplate one), and if you have a custom one, do nothing
[17:36] <pitti> that would still cover the common case
[17:36] <pitti> and if you hand-crafted your xorg.conf, you won't need hand-holding
[17:37] <superm1> yeah that sounds  somewhat more sane.  then you can still depend on having jockey do it's modifications if you had the custom one, and let the package ship and remove it's otherwise
[17:38] <bryce> yeah that sounds safer to me as well
[17:39] <AnAnt> Hello, I have a question that guys on ubuntu-motu weren't able to answer, it's regarding sl-modem packaging
[17:39] <AnAnt> https://lists.ubuntu.com/archives/ubuntu-motu/2009-June/005910.html
[17:39] <bryce> you're right that hopefully the majority of input device configuration no longer needs done through xorg.conf, but it seems there is often still random corner cases left
[17:39] <AnAnt> can someone lead me to where I can ask about udev related stuff ?
[17:40] <pitti> AnAnt: /join #udev
[17:40] <pitti> (I hang out there as well)
[17:40] <AnAnt> pitti: hmmm, ok, but did you read the URL ?
[17:40] <pitti> AnAnt: oops, no
[17:41] <didrocks> jdstrand: "quickly" creates a better initial ui file now (a recent commit introduced 6000 instead of 600 as width). I fixed also the welcoming message. If you want to test, you can bzr pull ;)
[17:41] <pitti> AnAnt: I don't see why sl-modem couldn't ship a .rules file which creates those devices
[17:41] <pitti> AnAnt: however, it seems weird to me that you have to do that in the first place
[17:42] <pitti> AnAnt: usually, devices are created in the kernel in /sys
[17:42] <AnAnt> pitti: even if I do that, there's something that needs to be done in the C code itself
[17:42] <pitti> AnAnt: if there's no real device behind the /dev node, then it wouldn't make sense to have it?
[17:42] <pitti> AnAnt: what does it need to do with udev?
[17:42] <ogra> pitti, tricky if they are virtually attached to a serial port
[17:42] <AnAnt> pitti: well, sl-modem needs a /dev/slamr (or /dev/slusb)
[17:43] <pitti> right, but if you mknod a new device, then there needs to be a kernel driver behind it which does the actual open()
[17:43] <pitti> isn't sl-modem purely an userspace driver?
[17:43] <pitti> and if it does have a kernel portion, why doesn't this just register a device properly, so that udev will "just create" it?
[17:43] <AnAnt> pitti: there are the slamr & slusb kernel modules
[17:44] <AnAnt> pitti: well, it doesn't, I posted the udevadm output
[17:44] <AnAnt> pitti: the problem is that Ubuntu doesn't want static devices to be created
[17:44] <pitti> AnAnt: so you are saying that the kernel functions to register a device are GPL only?
[17:45] <pitti> AnAnt: right, static devices are wrong
[17:45] <AnAnt> pitti: well, that's what I understand from the current maintainers
[17:45] <ogra> AnAnt, .rules can match on pretty much everything, your UEVENT has a DEVPATH=/bus/pci/drivers/slamr
[17:46] <pitti> EXPORT_SYMBOL_GPL(class_device_register);
[17:46] <pitti> oh
[17:46] <AnAnt> pitti: well, I don't understand, if the code is 3-clase BSD, why does it have a problem with the GPL class_device_register function ?
[17:46] <pitti> hm, then I'm afraid I don't really have a good answer here
[17:46] <pitti> AnAnt: I don't know :/
[17:46] <AnAnt> isn't GPL compatible with 3-clase BSD
[17:46] <AnAnt> ok
[17:47] <AnAnt> you think ubuntu-kernel guys can help ?
[17:47] <pitti> I don't know, worth a try
[17:47] <AnAnt> ogra: I hope that would help, thanks for the tip !
[17:48] <pitti> ogra, AnAnt: but I don't understand that
[17:48] <ogra> the udev side should be the easiest part :)
[17:48] <ogra> pitti, i think it took ian several months when he enabled it forst
[17:48] <pitti> how can a driver be legal to load, and bind to a major/minor, but not register a sysfs object to create the device automatically?
[17:48] <ogra> *first
[17:49] <ogra> it was never ported to sysfs support ?
[17:49] <pitti> if that's a real limitation, then it's super-easy to circumvent with a custom udev rule, so that would be silly
[17:49] <ogra> is it even alive upstream anywhere ?
[17:49] <pitti> allegedly not
[17:49] <ogra> right, thats the prob i suspect
[17:50] <AnAnt> pitti: there's a long discussion in debian bug 354216 aboutit
[17:50] <AnAnt> I tried to understand, but it's really way above my head
[17:50] <AnAnt> ogra: they just accept patches
[17:51] <AnAnt> ogra: I mailed them the relevant patches of Ubuntu & Debian packages, and they accepted it
[17:51] <ogra> right, but nobody actively forward ported the code
[17:51] <AnAnt> ogra: nope, the old active developers don't answer emails
[17:51] <ogra> my assumption is it was ported from 2.4 to 2.6 and then never actively developed to match teh new models
[17:52] <ogra> static dev -> udev -> sysfs etc ...
[17:52] <ogra> it kept only alive through hackish patches
[17:52] <ogra> and workarounds
[17:52] <AnAnt> yup
[17:53] <AnAnt> and ppl still need it
[17:53] <ogra> indeed
[17:55] <AnAnt> ogra: do you know how to match this DEVPATH=/bus/pci/drivers/slamr in a udev rules file ?
[17:55] <ogra> man udev ?
[17:55] <AnAnt> pitti: btw, there is some workaround that the previous debian maintainer did that I don't understand
[17:56] <ogra> shoudl describe it
[17:56] <AnAnt> he done this: MODULE_LICENSE("Dual BSD/GPL");
[17:56] <AnAnt> well, I would  understand if he done MODULE_LICENSE("BSD");
[17:56] <AnAnt> but I dunno why he done it Dual BSD/GPL
[17:57] <AnAnt> in upstream code it was: MODULE_LICENSE("Smart Link Ltd.");
[17:57] <AnAnt> which is not a license, but rather a copyright holder
[17:57] <AnAnt> so changing it to a license is what I can understand
[17:58] <AnAnt> but I don't understand that he set it to BSD/GPL !
[17:58] <pitti> AnAnt: perhaps to coerce the GPL checks for above exported functions to accept it?
[17:58] <AnAnt> pitti: but wouldn't that be an illegal workaround ?
[17:59] <pitti> that's what the bug was all about :)
[17:59] <AnAnt> aha
[17:59] <AnAnt> yet debian-legal seems to have accepted it
[17:59] <pitti> I have no clue at all how EXPORT_SYMBOL_GPL works, though
[17:59] <AnAnt> ok
[18:00] <AnAnt> thanks guys
[18:00]  * pitti is into code, not licenses..
[18:27] <tjaalton> pitti, bryce, superm1: or we default to fglrx, nvidia on those if it's installed, and the fallback is the free driver (+ vesa, fbdev)
[18:27] <superm1> tjaalton, yeah that would be even more ideal.  easy to do?
[18:27] <tjaalton> superm1: quite easy
[18:28] <pitti> tjaalton: right, wasn't that already a patch upstream, which got reverted later, and heavily disputed?
[18:28] <tjaalton> upstream dropped one such patch, but said that it's up to the distros to do that kind of stuff
[18:28] <tjaalton> pitti: yep
[18:29] <pitti> TheMuso: FWIW, still no sound with latest pulse :(
[18:29] <pitti> TheMuso: ah, mixer foobar, works now
[18:35] <pitti> TheMuso: nicely udevified \o/
[18:39] <soren> tseliot1: broadcom-sta branch pushed.
[18:39] <tseliot1> soren: thanks
[18:46] <ScottK> pitti: Would you please rescore kdebindings on armel.  There's a large number of packages waiting for it.
[18:47] <pitti> ScottK: nudged
[18:47] <ScottK> Where 4 is a large number.
[18:47] <ScottK> pitti: Thanks.
[18:47] <pitti> ScottK: in binary, it's very large :-P
[18:47] <ScottK> Heh
[19:41] <lool> pitti: BTW on the patch I mentionned earlier: Intel's patch fixed my suspend / resume issues and the Xorg hangs I was getting when the screen turned off too!  And the latest tree boots fine too, so all is fine basically
[19:41] <pitti> lool: yay
[19:51] <mathiaz> slangasek: hi - what's your opinion on providing slapd.scripts-common as standalone scripts so that they can be used by other things than maintainer scripts?
[20:00] <ogra> doko, hulp
[20:03] <pitti> cjwatson, Keybuk: this morning I did some i915 debugging and noticed that the screen gets disabled as soon as KMS loads _if_ i915 is not loaded from initramfs, but from normal udev init script (udevtrigger); in http://bugs.freedesktop.org/show_bug.cgi?id=19304#c88, Jesse pointed out that this is likely due to missing fbcon
[20:04] <pitti> cjwatson, Keybuk: is that intentional, and did we commit to always load the driver from initramfs now? or a bug?
[20:07] <ScottK> directhex: Mono may or may not be evil, but it's stopping kdebindings on armel.  Would you please have a look at https://launchpad.net/ubuntu/+source/kdebindings/4:4.2.95-0ubuntu1/+build/1101054/+files/buildlog_ubuntu-karmic-armel.kdebindings_4:4.2.95-0ubuntu1_FAILEDTOBUILD.txt.gz and recommend a solution.
[20:08] <ogra> ScottK, i'm working on it
[20:08] <ScottK> ogra: Thanks.  Would you please hit retry on kdebindings then when it's fixed ....
[20:09] <ogra> ScottK, i'm just not sure how evil it is to just dump --with-gc=boehm into configure or what else that breaks
[20:09] <ogra> thats why i try to reach doko
[20:09]  * ScottK has no idea either.
[20:10] <ogra> (apparetnly that fixes the build failure but switches off a lot other stuff)
[20:10]  * ScottK wouldn't lose much sleep over drop mono bindings from KDE either.
[20:10] <andersk> Is there a main sponsor available to ACK bug 394634?  It fixes quite a number of SSL servers that were broken in the last ca-certificates version.
[20:11] <ogra> ScottK, lucky you ... i'm committed to provite all of ubuntu-desktop on arm
[20:12] <ScottK> ogra: I'd drop it period, not just on one arch.  We don't have and KDE stuff packaged that actually uses mono.
[20:12] <ogra> yeah, we have f-spot, tomboy and soon banshee
[20:14]  * ScottK vaguely remembers reading some mail list stuff and blog posts about that.  ;-)
[20:14] <ogra> nah, you must be hallucinating :)
[20:14] <ScottK> Wouldn't be the first time.
[20:19] <directhex> ScottK, okay, give me a minute to beat meebey with a spoon
[20:20] <ScottK> directhex: You did see ogra said he was working on it, right?
[20:20] <directhex> ScottK, yeah. i think the fix is known, it just hasn't been uploaded yet
[20:21] <ogra> directhex, funnily i dont see 2.4+dfsg-5 anywhere but on the ftbfs list ... how did it enter ubuntu ?
[20:21] <directhex> ogra, it built fine on all non-arm arches
[20:21] <directhex> ogra, upstream told us that some arch-specific flags were no longer needed - they lied
[20:22] <directhex> let me check git
[20:22] <ogra> right, i see that, but i dont see it on -cahnges or so
[20:22] <vimpulse> hi all.  I attached a patch to https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/94382 to change the string "Use the entire disk" to "Erase and use entire disk" two weeks ago.  Because the bug could be considered a data loss bug, could someone please increase the priority?  Or better yet, cjwatson or TheMuso, could you please review and commit the patch?  :)
[20:22] <ogra> directhex, very likely --with-gc=boehm in ./configure ...
[20:22] <directhex> ogra, yes, but only on arm
[20:22] <ogra> directhex, and a dep on libgc
[20:22] <directhex> let me check -3 which worked
[20:23] <ogra> right, thats what i'm testbuilding atm
[20:23] <cjwatson> pitti: we didn't commit to always loading it from initramfs, as far as I know
[20:23] <ogra> directhex, that drops EABI support on ARM though, which we would like to have ...
[20:23] <directhex> -4 even
[20:23] <cjwatson> vimpulse: I don't consider it a data loss bug; please don't inflate issues. We'll look at it
[20:23] <cjwatson> vimpulse: it needs translations so we won't rush it
[20:24] <cjwatson> vimpulse: oh, heck, and it's on partman-auto - that really needs to go through Debian
[20:24] <cjwatson> oh, but you patched ubiquity for it, ok
[20:25] <vimpulse> cjwatson:  ok, I'm glad to know you saw the patch.  :)  What does "it needs translations" mean -- that it shouldn't be committed until the translators make up foreign-language translations?
[20:25] <cjwatson> no
[20:25] <cjwatson> it just means that it's not a panic-upload-immediately-to-everywhere-we-can kind of thing
[20:25] <cjwatson> which is what "data loss" tends to imply
[20:26] <vimpulse> cjwatson:  what are the steps before it gets committed?
[20:26] <cjwatson> vimpulse: you've done everything you need to do, thanks
[20:26] <directhex> i think http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commit;h=86dceb1f4a0089e324b9bf2c2a998b7ebf79f597 broke it
[20:26] <ogra> hmm
[20:26] <directhex> ogra, can you try building it with the above change reverted?
[20:26] <cjwatson> vimpulse: (btw, #ubuntu-installer is more appropriate)
[20:27] <vimpulse> cjwatson:  thanks for the info.  Also, next time I have ubiquity-related questions, I will ask in ubuntu-installer.
[20:27] <ogra> directhex, i will, i'm waiting for the --with-gc=boehm build to finish though since i dont want to have wasted that build time
[20:28] <cjwatson> vimpulse: should be able to commit that tonight
[20:28] <vimpulse> cjwatson:  excellent :)
[20:28]  * ogra wanders away for a while while his arm board builds ...
[20:29] <directhex> ogra, this looks like the only commit affecting arm between -4 and -5
[20:29] <directhex> ogra, i think it might break kfreebsd though
[20:29] <directhex> i'm sure you care lots about breaking kfreebsd on ubuntu
[20:31] <ScottK> We do have a downstream that probably cares.
[20:35] <gp_will_be_back_> hi
[20:38] <directhex> ScottK, well, until Front Desk/DAM make the appropriate changes, -6 needs to wait on meebey. so reverting the above commit for a hurried -5ubuntu1 is probably the best plan for hurried developers.
[20:39] <YokoZar> Plenary videos appear to be up!
[20:39]  * ScottK looks at ogra then
[20:43] <directhex> ScottK, generally though i'd be VERY hesitant to upload a boehm version
[20:43] <ScottK> directhex: Well I'm just waiting for ogra to fix it.
[20:49] <gp_will_be_back_> is there any way to find file count per directory
[20:54] <gp_will_be_back_> is there any way to find file count per directory
[20:54] <gp_will_be_back_> is there any way to find file count per directory
[20:54] <ScottK> gp_will_be_back_: Knock it off.  Repeating the question will get you kicked.  It won't get you an answer.
[20:55] <gp_will_be_back_> i am sorry scotty
[20:57] <gp_will_be_back_> i guess u guys dont know the answer .......i should try perl or python channel
[20:58] <Tm_T> gp_will_be_back_: repeating won't help there either, though
[20:58] <gp_will_be_back_> hehe no need to repeat there
[22:33] <billybigrigger> hey all
[22:34] <billybigrigger> where can i find out more info on when the 2.6.31 kernel will be released to karmic for testing? as i don't think i can file bugs againts the .31 rc1 can i?
[22:34] <cjwatson> sure you can
[22:35] <cjwatson> it's the current kernel in karmic
[22:35] <billybigrigger> dkms can't seem to install my vboxnetflt module for networking in vbox
[22:35] <cjwatson> 2.6.31 won't be released to karmic until it's ... released upstream :-)
[22:35] <cjwatson> oh, don't file the bug here though please, use the bug tracking system
[22:35] <ion> cjwatson: Aww, no time travel for karmic?
[22:35] <billybigrigger> so are we going to see 8 different release candidates like with the 2.6.30 kernel?
[22:36] <cjwatson> billybigrigger: entirely depends on what upstream do
[22:36] <cjwatson> they usually have a fair number of rcs
[22:37] <billybigrigger> cool beans
[22:37] <billybigrigger> cjwatson::: my bad
[22:37] <billybigrigger> i didn't see this :P
[22:37] <billybigrigger> Get:1 http://archive.ubuntu.com karmic/main linux-image-2.6.31-1-generic 2.6.31-1.14 [28.1MB]
[22:37] <billybigrigger> i was using the .31 rc1 kernel from the mainline ppa
[22:39] <cjwatson> ah, right, I understand your confusion now
[22:39] <cjwatson> indeed, you wouldn't want to file Ubuntu bug reports about a PPA
[22:41] <billybigrigger> yeah
[22:53] <Sarvatt> billybigrigger: https://bugs.edge.launchpad.net/virtualbox/+bug/392314
[23:16] <billybigrigger> Sarvatt::: thanks
[23:18] <billybigrigger> ok so when will i see vbox 3.0 come through repos?
[23:24] <orbitus> kvm and its unquestioned advantages aside, what is the state of xen on ubuntu? the hypervisor is included, the -xen kernel (rightfully) abandoned. however, there are many many people who want a xen+ubuntu combination.
[23:24] <orbitus> is there any path at all which would result in a xen kernel included as a package so users neither have to go elsewhere or otherwise hit a wall?
[23:30] <orbitus> this is a question motivated by pragmatism rather than any desire to start a heated discussion about whether one platform is superior to another
[23:32] <TheMuso> superm1: Someone stated as much in one of the bugs on Launchpad, and gave a link to a thread/poll where the devs where asking what version of pulse to support.
[23:33] <TheMuso> pitti: Good to hear.
[23:33] <pitti> TheMuso: in the literal sense :)
[23:34] <TheMuso> heh