[02:32] <calc> doko: do you know if it there would be any sort of problem with downgrading libxalan2-java to 2.7.0, I don't know how java libraries work wrt needing recompiling apps using them etc?
[04:50] <calc> anyone here that can do a sync request?
[04:51] <calc> i need lp-solve and suitesparse synced from debian unstable
[04:51] <StevenK> Are they new upstream versions?
[04:51] <calc> the hacks i did for them in january have been accepted and integrated properly
[04:51] <calc> no, just new debian updates
[04:51] <james_w> given that I couldn't be sure what day it is or what country I am in, I will have to say no :-)
[04:51] <calc> the ubuntu patches are no longer needed
[04:52] <StevenK> If they have Ubuntu changes, file bugs
[04:52] <calc> ok will do
[04:58] <slangasek> james_w: Katilsday in Uruguay
[05:00] <james_w> could be
[05:00] <james_w> oh, just been told I've got to change countries again
[05:03] <calc> https://edge.launchpad.net/bugs/338571 https://edge.launchpad.net/bugs/338572
[05:04] <slangasek> james_w: have fun in Mauritania!
[05:04] <calc> StevenK: ^
[05:04] <james_w> slangasek: thanks :-)
[05:14] <calc> StevenK: will you be able to get to sync those two packages?
[05:15]  * calc needs them for his OOo build in the morning
[05:22]  * calc installed the debian version for his local build and will upload in the morning once its tested
[05:25] <StevenK> calc: I guess suitesparse needs to be published before lp-solve is synced?
[05:27] <calc> StevenK: let me see, if it build depends on the right version it can be synced at the same time
[05:29] <calc> StevenK: it build depends on suitesparse 1:3.2.0-2 which isn't in ubuntu yet so it can be synced at the same time or later either way will work fine
[05:33] <StevenK> calc: Both done.
[05:33] <calc> thanks :-)
[05:34] <calc> now hopefully my build doesn't mysteriously blow up while i am asleep and i can upload in the morning :)
[05:34] <calc> then back to beating on OOo gvfs support to see i can fix it in time for release
[06:23] <dholbach> good morning
[06:26] <highvoltage> good mornign dholbach
[06:26] <dholbach> hiya highvoltage
[06:45] <bryce> hi dholbach
[06:54] <dholbach> hiya bryce, hi ara, hi iulian!
[06:55] <ara> hey dholbach :) welcome back :)
[06:55] <dholbach> yoooho
[06:55] <iulian> Hello dholbach.
[06:56] <Hobbsee> evening dholbach
[06:57] <dholbach> hey Hobbsee
[06:58] <bryce> heya Hobbsee
[07:08] <dholbach> morning doko - what do you think about bug 330613?
[07:21] <doko> dholbach: yes, on my list ...
[07:21] <dholbach> doko: super, danke!
[07:43] <pitti> Good morning
[07:44] <persia> jdstrand, When you get a chance, could you look at accepting syslinux into hardy-proposed?
[07:45] <persia> jdstrand, OOps.  Ignore that.  It's been too long since I did an SRU.
[07:47] <persia> Good morning pitti
[07:47] <pitti> hey persia, how are you?
[07:47] <persia> Reasonably well, although it's a dark and rainy day.  You?
[07:48]  * StevenK kicks his clock applet for no longer updating the weather
[07:48] <pitti> StevenK: no, it's indeed as bad as it says!
[07:49] <StevenK> pitti: It doesn't show the weather for any of the cites I have set as locations ...
[07:55] <primes2h> StevenK: There are also other problems relating to libgweather... bug 334377
[07:56] <StevenK> My machine has been logged in for 11 days, I guess libgweather got freaked out about ... 3 days ago?
[08:15] <savvas> Mirv: the patch for bug 102773 is already merged :)
[08:16] <Mirv> savvas: oh, right, I visited the bzr page very quickly but apparently missed it :) great, anyway
[08:17] <savvas> ok:)
[08:50] <dholbach> Keybuk: it seems that using libdb-dev (db4.7) in cyrus-sasl2 makes it crash all over the place - bug 323409 requests changing it back to db4.6 - WDYT?
[08:53]  * Mirv is starting to see hope at https://wiki.ubuntu.com/TranslatingUbuntu/JauntyTranslationIssues
[09:11] <dholbach> Keybuk: just confirmed that it fixes things for me again
[09:17] <seb128> does anybody has an idea about the build error on http://launchpadlibrarian.net/23540712/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu2_FAILEDTOBUILD.txt.gz?
[09:17] <seb128> "shift: 2353: can't shift that many"
[09:18] <seb128> it does that in the po directory on the buildds but built fine locally
[09:18] <directhex> i hate site-specific issues like that
[09:20] <cjwatson> bdmurray: how often does http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html update? seems to have been static since I first looked at it yesterday
[09:23] <pitti> Keybuk: hm, I'm pulling out my hair in bug 333903; it seems that even if you blacklist a module in modprobe.d/, it still gets autoloaded; any idea what that could be? I checked the udev rules, and all its modprobe calls use -b
[09:39] <lool> pitti: Hey, not sure why you moved the apport traceback to germinate
[09:39] <lool> pitti: Usually apport doesn't report anything when another program generates an exception
[09:39] <pitti> doko: should ubuntu-restricted-extras really still pull in sun-java6-plugin, and thus the sun-java6 JDK? Or should we drop that and replace with icedtea6-plugin ?
[09:39] <lool> pitti: I don't see why I should get an exception on the console from apport in any case
[09:39] <pitti> lool: well, it's an exception from germinate, which should appear on the console?
[09:40] <cjwatson> seb128: hmm, complete mystery to me too, I can't even find what *might* be generating it by 'grep -r shift. .'
[09:40] <lool> In fact we should not ever see exceptions on console, unless it's a report of an internal error which has to be fixde
[09:40] <lool> pitti: It's not, there's an exception from germinate and then an exception from apport
[09:40] <lool> In handling that exception
[09:40] <lool> At least that's my understanding
[09:40] <pitti> lool: if you want apport to suppress its exception about the file already existing, I can do that
[09:40] <lool> pitti: I think you should; it shouldn't be an exception in apport in any case
[09:40] <lool> (I mean it shouldn't reach the console)
[09:41] <pitti> lool: okay; what was the bug# again?
[09:41] <lool> I don't mind if you print a message, albeit I would do exactly the same thing as for the first exception (nothing)
[09:41] <doko> pitti: hmm, difficult question; now with sun-java 6u12, there are features again, which are not found in the icedtea plugin. but maybe we should just drop it for now
[09:41] <cjwatson> the exception from germinate is basically "debootstrap failed" and has been dealt with separately (by printing its stderr too)
[09:41] <lool> pitti: bug #323714
[09:41] <pitti> lool: okay, thanks; I'll add an apport task
[09:41] <cjwatson> maybe it should print an error and sys.exit(1) rather than raising an exception though
[09:41] <lool> pitti: the exception in germinate is fixed
[09:42] <lool> cjwatson: ah right, that might be nice too
[09:42] <lool> pitti: Ok let's keep the germiante task
[09:43] <pitti> doko: do you think that by and large, the icedtea6-plugin will work?
[09:43] <lool> thanks folks
[09:43] <pitti> asac: if a user visits a webpage with a java applet, is there some magic to auto-install icedtea6-plugin, like for flash?
[09:45] <doko> pitti: 6u12 was released half a year ago. Now applets appear using these new features. I really don't know ...
[09:45] <seb128> cjwatson: ok, thanks for having a look anyway
[09:45] <seb128> lool: any idea about http://launchpadlibrarian.net/23540712/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu2_FAILEDTOBUILD.txt.gz maybe? you usually have good idea about weird toolchain issues ;-)
[09:45] <pitti> doko: ok, thanks; I'll check with asac whether we have a working plugin installer in firefox
[09:45] <cjwatson> seb128: is it possible that it varies with /bin/sh -> bash vs. dash?
[09:46] <seb128> cjwatson: sh is dash here, do we use bash on buildds?
[09:46] <pitti> seb128: I fixed the amd64 retracer, FYI (or, rather, the bug which it stumbled upon
[09:47] <seb128> pitti: ok, thanks, I pinged you about that on #ubuntu-desktop when I joined but you probably didn't notice
[09:47] <pitti> seb128: whoops
[09:47] <seb128> pitti: your IRC client clearly needs to be ported to the message indicator system so you know about unread pings ;-)
[09:48] <pitti> hehe
[09:48] <cjwatson> seb128: I think it has been known to be bash on buildds, so while I don't know for sure, it's worth checking
[09:48] <seb128> cjwatson: ok thanks, I will give it a try now
[09:50] <lool> seb128: That's probably the same bug
[09:50] <lool> seb128: config.status being run by /bin/sh instead of @SHELL@
[09:50] <seb128> lool: the one you fixed for glib and gtk?
[09:50] <lool> seb128: Yes, and it's fixed upstream in intltool and gettext too
[09:50] <seb128> lool: ok, I knew that was ringing a bell somewhere ;-) how did you fix it?
[09:50] <pitti> asac: nevermind, figured it out; discussing on the bug
[09:51] <lool> seb128: Try changing the $(SHELL) before config.status in Makefile.in.in to @SHELL@
[09:51] <lool> seb128: Or rather, add SHELL = @SHELL@ to po/Makefile.in.in, that's what the GNOME guys preferred
[09:51] <lool> seb128: it will be fixed when the tarball is rerolled with a new intltool/glib-gettext
[09:52] <seb128> $ grep SHELL po/*
[09:52] <seb128> po/Makefile.in.in:SHELL = /bin/sh
[09:52] <seb128> po/Makefile.in.in:	       $(SHELL) ./config.status
[09:52] <seb128> ok
[09:52] <seb128> lool: thanks!
[09:52] <lool> Yeah, you want @SHELL@ instead
[09:52] <seb128> we should ask dobey to roll a new intool tarball
[09:53] <lool> Please do
[09:53] <seb128> so that get fixed in 2.26
[09:53] <cjwatson> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=df8857c0472c33bd786a967569c4b3c9c4c177b2
[09:53] <cjwatson> FWIW
[09:53] <lool> cjwatson: Yes, but not released yet; I patched our package
[09:54] <cjwatson> right, I just figured I'd gone and looked for that so might as well give the URL :)
[09:54] <cjwatson> thanks for backporting it
[09:55] <lool> cjwatson: thanks, it's linked from the bug report too already
[09:55] <seb128> bug #332840
[09:55] <lool> I don't intend to fix gnulib, I don't think it's used that much for Makefile.in.in
[09:56] <lool> It will be fixed upstream by the same guy
[10:20] <persia> doko, I've uploaded the last change required to not have anything not otherwise scheduled for removal depend on sun-java5-jre or build-depend(-indep) on sun-java5-jdk.  Do you have any concerns about final removal?
[10:20] <seb128> lool: http://launchpadlibrarian.net/23542187/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu3_FULLYBUILT.txt.gz
[10:20] <seb128> lool: thanks ;-)
[10:21] <doko> persia: yes, make first sure, that the current package is available in dapper, hardy and intrepid
[10:23] <persia> doko, So you want 1.5.0-17 backported into -proposed for everything first?
[10:24] <doko> persia: well, sru's require to have the new version in the development version
[10:25] <persia> That makes it complicated.  We don't want to include it because Sun stops offering support before even intrepid expires, but what if Sun releases a new version between now and their end-of-support?
[10:26] <cjwatson> if the package doesn't exist any more in jaunty, I would regard that as justification for an exception from the "must be in jaunty first" SRU rule, personally
[10:27] <cjwatson> it's there so that we get the maximum testing possible before inflicting on stable users
[10:27] <quadrispro> hi pitti, gegl FTBFS cause of libopenraw-dev is in universe and there are 2 ways to solve that
[10:27] <persia> OK.  I'll proceed with the plan to drop it from jaunty on that basis, in case there is a future 1.5.0-18, but not request removal until the current updates are complete.
[10:28] <quadrispro> 1) file a MIR 2) build the package without libopenraw-dev build-dep (which is unnecessary)
[10:28] <pitti> cjwatson: I wonder what to do with bug 328486; a beta-blocking milestoned wishlist bug, without an assignee..
[10:29] <pitti> cjwatson: From my POV I'd just un-milestone/un-target for jaunty; or did you discuss this with someone who wants to work on this soon?
[10:29] <quadrispro> pitti, what do you think about it? what solution could be better?
[10:29] <cjwatson> pitti: I discussed it with mvo before filing it
[10:30] <cjwatson> 11:55 <cjwatson> just thinking about jaunty-apturl-add-repo in the context of some previous discussions, and an e-mail thread with Mark today
[10:30] <cjwatson> 11:56 <cjwatson> would it make sense for the keys that are whitelisted according to the partner-repositories specification also to be available if you add repositories in Software Sources?
[10:30] <cjwatson> 11:57 <cjwatson> i.e. if apturl is willing to add the signing key automatically, then it seems to make sense for it to be added automatically if you add the corresponding repository by hand, too
[10:30] <cjwatson> 11:58 <mvo> sounds sensible indeed
[10:30] <cjwatson> 12:01 <cjwatson> should I file a bug?
[10:30] <cjwatson> from 12 Feb
[10:30] <cjwatson> 12:03 <mvo> I can do that too, no problem (and milestone it)
[10:30] <cjwatson> I'll just assign it to mvo now
[10:30] <pitti> cjwatson: ok, assigning to mvo then
[10:38] <lool> seb128: cool
[10:38] <pitti> quadrispro: if libopenraw-dev isn't really needed, then dropping the b-dep is always better
[10:39] <pitti> quadrispro: if libopenraw-dev provides features which were previously in gimp as well, or are otherwise important, then a MIR sounds better (but keep in mind that we are in feature freeze)
[10:40] <Mirv> seb128: do you think the gnome.mk cdbs could be used also for libmbca? but thanks for that one fix, it could be solving some other problem(s) as well
[10:41] <seb128> Mirv: dunno about libmbca, gnome.mk is for desktop packages usually and the pidgin-libnotify was already using cdbs
[10:42] <Mirv> seb128: dunno either, but libmbca is also using cdbs and having the same problem, so I wonder if there is any other besides gnome.mk that could fix the similar problem there
[10:43] <seb128> Mirv: well the issue is simple something needs to call intltool-update, cdbs gnome.mk does that for us but it can also be called manually in the rules
[10:44] <quadrispro> thank you pitti, I'm going to do some tests
[10:44] <Mirv> seb128: ok.
[10:46] <lool> Wow valgrind is 45 MB
[10:47] <lool> 47M     /usr/lib/valgrind/x86-linux
[10:59] <pitti> james_w: do you still have enough context of bug 275432 in your head to be able to work on this? Or would you rather not? (then I'll see to make some time to look into it)
[11:00] <pitti> james_w: it's a jaunty-targetted bug, so it should have an assignee
[11:00] <cjwatson> oh, this is going to be unpleasant. Apparently at one point openssl had an rpath pointing to /usr/lib
[11:00] <cjwatson> I think I'm going to have to leave symlinks behind
[11:05] <lool> cjwatson: On a TI EVM board running jaunty armel and otherwise idle: # time /etc/init.d/console-setup start => real    0m27.171s, user    0m26.281s
[11:05] <lool> cjwatson: That sounds terribly long
[11:05] <cjwatson> did it have a saved keymap previously?
[11:05] <lool> It's subsecond on my desktop
[11:05] <lool> cjwatson: It's the second run
[11:06] <cjwatson> was the first run in the boot sequence?
[11:06] <lool> cjwatson: No
[11:06] <lool> cjwatson: I noticed slowness during upgrade, then reproduced manually on the running system
[11:06] <cjwatson> would be useful to know which bit of setupcon is taking lots of time
[11:07] <lool> cjwatson: On a FSL Babbage, also jaunty armel but might be a different keymap, it's real    0m5.121s
[11:07] <lool> cjwatson: Could it be using lots of rAM?
[11:07] <lool> I only have 128M on the EVM
[11:07] <cjwatson> well, if it has the keymap files cached, the particular keymap in use should make no difference
[11:07] <cjwatson> lool: I don't want to speculate too much without knowing which bit of setupcon is taking ages
[11:07] <cjwatson> lool: it's a shell script - you could sh -x it
[11:08] <lool> I'm doing that
[11:08] <lool> setupcon --force --save
[11:08] <lool> That's what hangs for long
[11:08] <cjwatson> now sh -x *that*
[11:08] <cjwatson> setupcon does quite a few different things
[11:08] <lool> + ckbcomp -model pc105 us
[11:08] <lool> + gzip -9
[11:09] <cjwatson> can I have the bit before that with the tests?
[11:10] <cjwatson> from just after setting rules_option
[11:10] <lool> cjwatson: http://paste.ubuntu.com/127152/
[11:11] <cjwatson> you have a /root/.console-setup file
[11:11] <cjwatson> any particular reason?
[11:11] <lool> time (ckbcomp -model pc105 us | gzip -9 >/dev/null) => 0m25.938s
[11:11] <lool> cjwatson: I don't
[11:11] <cjwatson> when you have that file, it assumes that you're using a per-user (well, root, but still not the one in /etc) configuration and therefore that it shouldn't use the cached keymap
[11:12] <lool> cjwatson: http://paste.ubuntu.com/
[11:12] <cjwatson> this was in response to bug 332728
[11:12] <lool> cjwatson: kernel is hand built though
[11:12] <cjwatson> lool: ... I think you forgot the last bit in that URL ;-)
[11:12] <lool> Hmm?
[11:13] <lool> cjwatson: sorry didn't understand
[11:14] <lool> cjwatson: Note: no initramfs
[11:14] <lool> Probably what causes the difference
[11:14] <lool> without -9 doesn't change anything
[11:16] <lool> cjwatson: ooohhh sorry
[11:16] <lool> cjwatson: http://paste.ubuntu.com/127156/
[11:17] <cjwatson> lool: sorry, the last I have is:
[11:17] <cjwatson> 11:12 <lool> cjwatson: http://paste.ubuntu.com/
[11:17] <lool> 12:16 < lool> cjwatson: ooohhh sorry
[11:17] <cjwatson> 11:12 <cjwatson> this was in response to bug 332728
[11:17] <lool> 12:16 < lool> cjwatson: http://paste.ubuntu.com/127156/
[11:17] <cjwatson> 11:12 <cjwatson> lool: ... I think you forgot the last bit in that URL ;-)
[11:18] <lool> cjwatson: I don't have the /root/.console-setup
[11:18] <lool> cjwatson: And I don't have an initramfs
[11:18] <lool> and without -9 makes no difference
[11:18] <cjwatson> apparently I can't read
[11:20] <cjwatson> lool: ok, can you please file a bug and assign it to me? --save probably shouldn't bother updating the cached keymap when it's already up-to-date
[11:20] <cjwatson> lool: this shouldn't affect the boot sequence, though
[11:20] <cjwatson> lool: when running in the boot sequence, --save isn't used
[11:20] <lool> Ok
[11:20] <cjwatson> lool: assuming, that is, that the run_by_init function in /etc/init.d/console-setup still works
[11:21] <cjwatson> lool: oh, actually, maybe don't file a bug
[11:21] <cjwatson> lool: your issue is during upgrade, yes?
[11:21] <cjwatson> lool: in that case, it's perfectly conceivable that stuff may have changed such that the keymap *does* need to be regenerated
[11:22] <lool> cjwatson: It was during upgrade yes
[11:22] <lool> cjwatson: Will it affect first boot?
[11:22] <cjwatson> no, it won't
[11:23] <cjwatson> it's interesting that it's so slow though
[11:23] <lool> cjwatson: Ok, so it's normal that it takes so long on console-setup upgrades?
[11:23] <lool> Right, I find that really slow
[11:23] <cjwatson> ckbcomp only uses maybe 5MB of memory tops
[11:23] <cjwatson> $ time ckbcomp -model pc105 us '' '' >/dev/null
[11:23] <cjwatson> real    0m0.618s
[11:24] <lool> time (ckbcomp -model pc105 us >/dev/null) => 0m26.826s
[11:24] <cjwatson> lool: is it possible that 'use integer;' near the top of ckbcomp would speed it up?
[11:24] <lool> I don't see any faults in /proc/cpu/alignment
[11:25] <cjwatson> I don't think it needs FP math
[11:25] <lool> That's likely, trying
[11:25] <lool> 0m25.583s
[11:25] <lool> no
[11:26] <cjwatson> might be worth trying it with -v 10 and seeing what's taking time
[11:27] <cjwatson> oh, hmm, -v 10 actually not that informative
[11:28] <cjwatson> verbose perl debugging will probably slow the whole thing down to the point of making it hard to tell
[11:28] <cjwatson> maybe just print debugging at appropriate points?
[11:29] <lool> Ok
[11:33] <cjwatson> I don't have any other obvious bright ideas :-(
[11:36] <lool> cjwatson: time is spent on iterations of this loop foreach my $key (sort {$a <=> $b} (keys %symbols_table)) {
[11:44] <cjwatson> lool: would be useful to know how many elements %symbols_table has, and the same recursively for its elements
[11:44] <cjwatson> the actual work done in the inner loop is trivial
[11:45] <cjwatson> if the hash lookups are taking ages then we could arrange to do that just once
[11:46] <lool> cjwatson: flatten() is the one taking most time
[11:47] <cjwatson> lool: flatten() isn't in the loop you mentioned ...
[11:48] <cjwatson> oh, you're talking about a different loop than I'm looking at
[11:48]  * cjwatson starts again
[11:50] <cjwatson> lool: the Devel::DProf module might help here
[11:51] <cjwatson> 'perl -d:DProf /usr/bin/ckbcomp -model pc105 us >/dev/null' will produce tmon.out and dprofpp can analyse that
[11:52] <persia> pitti, When you get a chance, could you look at bug #309396?  There's some interest in getting it into -proposed before the Alpha Freeze.
[11:53] <pitti> persia: okay, will have a look today
[11:53] <persia> pitti, Thanks.
[11:54] <pitti> persia: did you upload it already?
[11:54] <persia> via sponsorship, yes.
[11:56] <StevenK> pitti: I uploaded it, which is why I'm not looking at it
[11:59] <persia> StevenK, I thought you weren't looking at it because you weren't ubuntu-sru
[12:00] <pitti> ah, good
[12:00] <StevenK> persia: Shhh
[12:11] <directhex> ta seb128
[12:15] <seb128> directhex: you're welcome
[12:15] <seb128> directhex: there was a sync where I asked if there was something other than cosmetic change the other day, did you close it after that?
[12:16] <directhex> seb128, no, i replied & said the exisiting archive version would ftbfs due to transition
[12:16] <directhex> seb128, so it's that or ubuntu1
[12:17] <seb128> didrocks: you didn't reopen when replying because it's not on the sponsoring list
[12:18] <directhex> damn. incomplete
[12:18] <directhex> i suck
[12:18] <directhex> New again?
[12:19] <seb128> yes
[12:19] <seb128> bug number?
[12:19] <directhex> bug 337634
[12:20] <seb128> directhex: synced, don't forget to reopen next time
[12:20] <directhex> yeah, my mistake.
[12:20] <directhex> i wonder what time i replied...
[12:21] <directhex> 20 past 10, can't even blame tiredness. bah
[12:21] <Keybuk> dholbach: probably correct
[12:22] <Keybuk> pitti: blacklist only prevents then named modules from appearing in alias expansion
[12:22] <Keybuk> pitti: it doesn't actually stop anyone doing "modprobe foo"
[12:23] <pitti> DktrKranz, ScottK, sistpoty|work, Hobbsee: with your motu-release hat on, any objection against me updating devicekit-power to the latest upstream version? it has zero reverse dependencies, but I'd like to package the new g-p-m into a PPA for playing; it adds two small new features
[12:23] <Keybuk> There must be something wrong with the /etc/modprobe.d/blacklist-bcm43.
[12:23] <Keybuk> pitti: that should be blacklist-bcm43.conf btw ;)
[12:23] <pitti> Keybuk: right, but the udev rules all use -b, which should respect the blacklist?
[12:23] <pitti> Keybuk: oh, you mean it only considers files ending in .conf now?
[12:24] <pitti> Keybuk: that might be the very bug I'm looking for then
[12:24] <Keybuk> # load wl before b44 so that both work
[12:24] <Keybuk> install wl modprobe -r b43 b44 b43legacy ssb; modprobe --ignore-install wl $CMDLINE_OPTS; modprobe -Qba b44
[12:24] <Keybuk> the comment is exactly the opposite of what you're actually doing ;)
[12:24] <Keybuk> you probably want an && in there too
[12:24] <Keybuk> and -Q has gone, so you don't want that
[12:24] <Keybuk> (and you don't want -a either)
[12:25] <pitti> Keybuk: is .conf required now, or just "best practice"?
[12:25] <Keybuk> pitti: required
[12:25] <pitti> oh
[12:25] <Keybuk> it's not fully deprecated yet, but EVERY SINGLE modprobe invocation will bitch about it
[12:25] <Keybuk> that's not your bug though
[12:25] <Keybuk> I'm just going down the list :p
[12:25] <pitti> Keybuk: almost all files in modprobe.d/ violate that then
[12:25] <pitti> okay
[12:26] <Keybuk> pitti: actually, if you look at -changes, I fixed almost all of them yesterday
[12:26] <Keybuk> the only ones left are those that come with module-init-tools itself
[12:26] <cjwatson> this is breakage for the sake of breakage from m-i-t upstream, right? :)
[12:26] <Keybuk> and those created by programs
[12:26] <cjwatson> the only justification I can think of is things like .dpkg-tmp
[12:26] <cjwatson> which would be addressed by just saying that your filename can't contain a dot
[12:26] <Keybuk> cjwatson: no, there's enormous numbers of bugs of people's swap files being treated as module aliases, etc.
[12:26] <pitti> like .dpkg-old or so?
[12:27] <Keybuk> that doesn't help with /etc/modprobe.d/4913 which vi likes to create <g>
[12:27] <cjwatson> the run-parts rules deal with that perfectly well, and much less intrusively
[12:27] <Keybuk> cjwatson: I don't think I agree anymore
[12:27] <Keybuk> after having tried to maintain the same thing with Upstart
[12:27] <Keybuk> that's shifting to .conf too
[12:28] <Keybuk> there's just too many damned stupid file rules to ignore nowadays
[12:28] <cjwatson> and so the world gets gradually worse :-/
[12:28] <Keybuk> why worse?
[12:29] <cjwatson> upgrade pain on a stick; I expect lots of people to have local modprobe.d files
[12:29] <Keybuk> it'll pass
[12:29] <cjwatson> just because it was too hard to DTRT
[12:29] <cjwatson> upgrade pain is cumulative, and everybody keeps adding their own little bit to the pile
[12:29] <cjwatson> upgrade problems are something we get hammered about by users
[12:30] <Keybuk> anyway
[12:30] <Keybuk> bitching aside
[12:30] <Keybuk> back to the bug
[12:31] <Keybuk> pitti: I can't quite see what's going in the description
[12:31] <cjwatson> I'm sorry that you feel that raising a design concern is bitching :P
[12:31] <pitti> Keybuk: my main headache is that modules get auto-loaded despite being blacklisted
[12:31] <Keybuk> cjwatson: it's bitching because you're doing it to me, and not upstream
[12:31] <pitti> Keybuk: this obviously worked in intrepid, so I wonder what changed
[12:31] <cjwatson> as usual, we raise bug reports through distro maintainers
[12:32] <cjwatson> I can do it as a bug report if you'd rather, but from this conversation it sounds like you'd just close it
[12:32] <Keybuk> cjwatson: I happen to agree with the upstream in this case ;)
[12:32] <Keybuk> having tried to maintain a "filter out known filename patterns" list, it's just too damned hard
[12:32] <Keybuk> especially if you're doing it in a piece of software that can run at any time
[12:32] <Keybuk> so you need to deal with transient things like vi's silly "can I write to this directory?" files
[12:33] <cjwatson> upstart doesn't really worry me much because it's new and not many people are going to have written jobs files for it
[12:34] <Keybuk> ANYWAY BACK TO THE BUG
[12:34] <Keybuk> pitti: hmm
[12:34] <Keybuk> pitti: bug the bug seems to say that a driver *isn't* being loaded
[12:35] <Keybuk> or am I reading this all wrong?
[12:35] <pitti> Keybuk: sec, doorbell
[12:35] <sistpoty|work> pitti: no objections from me in regards to devicekit-power
[12:35] <pitti> Keybuk: no, the bug is that wl isn't being loaded because ssb is auto-loaded
[12:36] <pitti> Keybuk: in intrepid this blacklisted ssb, b43, and b44
[12:36] <Keybuk> wl is failing to load?
[12:36] <Keybuk> ie. it tries, and throws it out?
[12:36] <pitti> Keybuk: thus the modaliases for wl got "unshadowed"
[12:36] <Keybuk> what do you mean by "unshadowed"?
[12:36] <pitti> thus wl then got auto-loaded through the udev rules, and the rule made sure that b44 got, too
[12:36] <pitti> Keybuk: ssb and wl have the same modaliases
[12:36] <Keybuk> right
[12:36] <pitti> and apparently ssb won
[12:36] <Keybuk> so both will be loaded
[12:36] <Keybuk> whichever is first in depmod.conf/modules.order will win
[12:37] <Keybuk> if wl is in ubuntu/ it should win
[12:37] <Keybuk> as long as ssb isn't
[12:37] <pitti> but if ssb and b43 already grabbed the device, wl didn't find anything to drive
[12:37] <pitti> so someone came up with that idea of blacklisting ssb/b43/b44 and let wl install b44 alongside
[12:37] <pitti> which worked fine in intrepid
[12:37] <pitti> but now, the blacklist seems to get ignored entirely
[12:38] <pitti> Keybuk: changing the probing order sounds interesting; where is that configured?
[12:38] <DktrKranz> pitti: is bug 318775 addressed?
[12:38] <Keybuk> pitti: two places
[12:38] <Keybuk> pitti: /etc/depmod.d/depmod.conf configures the search order of directories
[12:38] <Keybuk> so it will search updates, then ubuntu, then kernel
[12:38] <Keybuk> err
[12:38] <Keybuk> /etc/depmod.d/ubuntu.conf
[12:38] <Keybuk> sorry
[12:39] <Keybuk> /lib/modules/$(uname -r)/modules.order specifies the load order in general
[12:39] <pitti> DktrKranz: it's fixed in devicekit; not sure whether it's needed in devkit-power, I'll look
[12:39] <DktrKranz> pitti: thanks. Anyway, it looks fine to me
[12:39] <Keybuk> pitti: is b43legacy being loaded?
[12:40] <DktrKranz> (and it's not probably motu-release stuff, btw)
[12:40] <Keybuk> or is b43 itself being loaded?
[12:40] <pitti> Keybuk: b43 in that case
[12:40] <Keybuk> b43 deps on ssb
[12:40] <pitti> DktrKranz: thanks
[12:40] <pitti> Keybuk: right, that's why all three get blacklisted right now
[12:40] <asac> pitti: yes. there should be a "missing plugin .." button
[12:40] <lool> cjwatson: Hmpf dprof isn't packaged, this is getting a bit far for me; if you don't mind I'll document that in a low priority bug report and people who want to do the research are welcome to
[12:40] <Keybuk> pitti: you don't want the "_" in b43_legacy :p
[12:41] <Keybuk> b44 would also load ssb
[12:41] <cjwatson> lool: uh - it's in the perl package
[12:41] <cjwatson> perl: /usr/lib/perl/5.10.0/Devel/DProf.pm
[12:41] <pitti> Keybuk: no, I don't think so :) it's called b43legacy
[12:42] <pitti> Keybuk: hm, /etc/depmod.d/ubuntu.conf doesn't look like something I should modify in apport
[12:42] <Keybuk> random thought
[12:42] <Keybuk> WHEN are they being autloaded?
[12:42] <Keybuk> are these modules being copied into the initramfs?
[12:42] <pitti> Keybuk: haven't pinpointed that yet with the reporter
[12:42] <Keybuk> pitti: yes
[12:42] <Keybuk> ssb is in my initramfs
[12:42] <pitti> Keybuk: ah, you think that the blacklist needs to be copied to initramfs?
[12:43] <Keybuk> pitti: probably
[12:43] <pitti> aaah
[12:43] <Keybuk> I'd guess that's the regression - more modules have been copied into the initramfs, but the blacklist isn't being
[12:43] <pitti> Keybuk: good point, I'll try that
[12:43] <Keybuk> you prob. just need an update-initramfs
[12:43] <Keybuk> as I'm pretty sure all files in /etc/modprobe.d are copied across
[12:44] <pitti> Keybuk: so, the jockey handler does call update-initramfs
[12:44] <pitti> Keybuk: but i didn't ask the bug reporter to do so after changing it
[12:44] <lool> cjwatson: Oh ok
[12:45] <pitti> Keybuk: so it's not the entire explanation, but it might explain the failures in debugging it
[12:45] <lool> cjwatson: I didn't imagine that for a second
[12:46] <Keybuk> pitti: to help debug, /var/log/udev would tell us the modaliases on his system
[12:46] <Keybuk> and get him to try modprobe -n -v on each of the aliases he finds there
[12:52] <lool> bryce: When you have a sec, please look at #334711
[12:59] <ScottK> pitti: If you're confortable with it, I'm good.
[12:59] <pitti> ScottK: ok, thanks
[13:04] <pitti> Keybuk: you can run modprobe for a modalias?
[13:04] <pitti> Keybuk: i. e. "sudo modprobe ssb:v4243id0812rev09"?
[13:05] <pitti> indeed, nice
[13:09] <lool> cjwatson: http://paste.ubuntu.com/127211/
[13:12] <cjwatson> lool: could I get the full tmon.out?
[13:13] <lool> cjwatson: http://people.ubuntu.com/~lool/tmon.out
[13:13] <lool> cjwatson: That's a really interesting tool BTW
[13:13] <cjwatson> thanks, got it
[13:16] <cjwatson> it's not going to be straightforward though :-/
[13:17] <cjwatson> the biggest user is simply 100000 calls to one subroutine that takes a tiny fraction of a second per call, but it mounts up
[13:17] <cjwatson> it could be that sub calls are just really slow on arm
[13:17] <cjwatson> or it could be that the whole algorithm needs to be improved
[13:17] <lool> cjwatson: Perhaps we could avoid ::approximate?
[13:18] <lool> 100000 calls seems bad indeed
[13:19] <cjwatson> nytprof (http://blog.timbunce.org/tag/perl/) looks really amazing but I think I'll work with this first :)
[13:20] <cjwatson> lool: err. I don't think we can just throw out bits of the algorithm, no. :)
[13:20] <lool> cjwatson: Sorry, I first thought approximate was some perl function, but I saw it in the source later on
[13:21] <cjwatson> ah, no, it's part of the xkb symbol resolution stuff
[13:21] <cjwatson> I admit that I don't actually understand its purpose yet myself
[13:21] <lool> cjwatson: The next idea I thought of was to convince perl it needs more optimization, perhaps there's some inlining concept in perl?
[13:21] <cjwatson> but I would start by doing so
[13:21] <cjwatson> not really, no
[13:22] <cjwatson> I would rather start by analysing and understanding the problem
[13:27] <lool> cjwatson: It looks like a many hours job from my side; I hope you don't mind I leave it here
[13:27] <lool> cjwatson: Happy to assist in testing or benchmarks though
[13:27] <lool> #338729
[13:29] <cjwatson> lool: yep, that should be fine, thanks
[13:29] <Keybuk> pitti: yes, that's _kinda_ the whole point <g>
[13:45] <dholbach> Keybuk: are you going to sponsor it? :)
[13:45] <Keybuk> dholbach: what's sponsoring?
[13:45] <dholbach> Keybuk: right
[13:47] <Keybuk> dholbach: assign the bug to me
[13:47] <Keybuk> and I'll do it in my sponsoring hour next week
[13:49] <dholbach> Keybuk: I think it's more urgent than that - so I'll do it now
[14:11] <BUGabundo> pitti: ping
[14:12] <BUGabundo> apport Suggest python-launchpadlib
[14:12] <pitti> bryce: some speculations for i845: could we resurrect -i810 on those? could we start vesa on those by default
[14:12] <pitti> BUGabundo: yes?
[14:12] <BUGabundo> but to use apport-collect its required
[14:12] <BUGabundo> shouldn't it be recommends?
[14:12] <BUGabundo> or depends?
[14:12] <pitti> bryce: just thinking about a fallback strategy if we won't find a proper solution by the release, so that upgrades won't break completely
[14:13] <pitti> BUGabundo: I'll switch apport over to launchpadlib soon anyway
[14:13] <pitti> BUGabundo: for now, apport-collect tells you that the package is missing
[14:17] <pitti> seb128: ah, seems bug 277309 is fixed now; confirm?
[14:17] <pitti> seb128: (WFM)
[14:20] <seb128> pitti: no it's not
[14:20] <seb128> pitti: again that bug is the "suspend icon is only in the human theme"
[14:20] <seb128> the jaunty issue (no theming) has been fixed
[14:21] <seb128> pitti: switch to clearlooks, press the power button, notice the "no icon"
[14:21] <pitti> seb128: ah, but that remaining issue isn't a regression, is it?
[14:21] <seb128> no it's not
[14:21] <seb128> it's there since intrepid
[14:21] <seb128> since we use the new dialog
[14:22] <pitti> I wonder why it should be a release blocker then
[14:22] <seb128> it should not?
[14:22] <pitti> seb128: there's no good counterpart in clearlooks and other themes for the icon?
[14:22] <seb128> that's you guys who have confused the jaunty issue with this one and have dups and tweaked settings the wrong way
[14:23] <seb128> pitti: there is no suspend icon, I don't know if one other icon could be a good workaround, should be a question for icon guys ;-)
[14:24] <seb128> pitti: see bug #274889 for a discussion about the icons used
[14:24] <pitti> seb128: ok, thanks for the heads-up
[14:24] <seb128> pitti: your marked duplicated the wrong way around imho, you closed the bug which had a technical discussion about the issue for a newer one with less details
[14:25] <pitti> uh, was that me?
[14:25] <seb128> yes
[14:25] <pitti> sorry then
[14:25] <pitti> please feel free to swap them
[14:25] <seb128> according to the launchpad activity log
[14:25] <seb128> ok, will do
[14:27] <BUGabundo1> back
[14:27]  * BUGabundo1 wonders if ADSL is going to be up for a while
[14:27] <pitti> asac: bug 323109 is on track for jaunty release, or rather not? (it's not a regression)
[14:28] <BUGabundo1> pitti: asac told me once that upstream doesn't want us using the integration with NM
[14:28] <pitti> huh?
[14:38] <Amaranth> BUGabundo1: we already do though, if NM is not connected firefox goes into offline mode
[14:40] <BUGabundo1> that should not be like that, according to asac
[14:41] <BUGabundo1> upstream doesn't seem to want that!
[14:53] <Keybuk> seb128: randomly
[14:53] <Keybuk> which is the right package to assign "my USB stick doesn't auto-mount" bugs to?
[14:53] <Keybuk> I've utterly lost track with which bit of the GNOME stack is responsible
[14:53] <Keybuk> gvfs or nautilus now?
[15:00] <asac> pitti: upstream has networkmanager support disabled by default on trunk. so unless we can convince them they wont put much resources in it. it could be an easy fix though. just requires some debugging to find out, what breaks this existing feature when you use NM for offline state. (it works if you dont use NM, but manually iirc)
[15:01] <asac> so we cannot really say if its on track for jaunty or not as we dont know the cause for the brokenness yet.
[15:01] <pitti> asac: right, I meant if it *should* be on the jaunty radar, i. e. if you consider it a release blocker
[15:02] <asac> pitti: its an important bug for the spec, but i dont think its a blocker
[15:03] <pitti> asac: I agree
[15:03] <asac> i think the spec is medium itself
[15:03] <asac> but dont remember exactly
[15:03] <asac> pitti: but why are not-milestoned targetted bugs bad?
[15:03] <asac> pitti: i thought it means its an "oppertunity"
[15:04] <pitti> asac: well, every bug is an opportunity
[15:04] <asac> hehe
[15:04] <pitti> asac: if a bug is targeted at jaunty, it means that it's on the release team's radar and should be fixed ASAP
[15:04] <pitti> it's basically the set of bugs which we consider "release critical" for jaunty
[15:06] <asac> pitti: so what would you suggest me to use for "my" jaunty radar?
[15:07] <pitti> asac: personally I assign bugs to me and set them to "in progress"; that's the set of bugs I"m currently working on
[15:07] <pitti> asac: you can also milestone it for ubuntu-9.04 without targetting it at jaunty
[15:07] <pitti> if you like that better
[15:07] <asac> pitti: thats true. but i like to have a in progress list for jaunty
[15:07] <asac> but well.
[15:07] <pitti> asac: use the ubuntu-9.04 milestone then
[15:07] <asac> i wiill misuse importance than to tweak my personal priority
[15:07] <pitti> milestones on the floating task are for personal use
[15:09] <asac> ok. i will think abit about it, now that i know that any targetted task are RM
[15:13] <BUGabundo1> asac: I've changed my FF to use NM, and it fails to set Offline 50% of the times!
[15:14] <asac> BUGabundo1: well. disable your 70 extensions first ;) ... can you still reproduce then=
[15:14] <asac> ?
[15:15] <BUGabundo1> asac: I'll try latter with 3.2
[15:15] <BUGabundo1> can't take the net off now! connected to server ss
[15:15] <BUGabundo1> *ssh
[15:15] <asac> i mean, afaik you run firefox 3.1 dailies with disableextensioncheck and 70 extensions installed out of which 60 claim maxVersion=3.0 :)
[15:15] <asac> BUGabundo1: try without extensions and not with 3.2 ;)
[15:16] <BUGabundo1> that would require a new 3.1 profile!
[15:16] <BUGabundo1> I don't close my FF all that much
[15:16] <asac> BUGabundo1: no you can use safe-mode
[15:18] <BUGabundo1> that too
[15:19] <BUGabundo1> forgot about that
[15:19] <BUGabundo1> still requires to close FF
[15:19] <BUGabundo1> asac: will try when I get home
[15:21] <asac> cool
[15:25] <BUGabundo1> asac: FYI its only 53 addons.... lol
[15:28] <seb128> Keybuk: not easy to say without debug info, you can reassign to gvfs, it's often hal which is buggy though
[15:29] <Keybuk> seb128: indeed, just never sure which bit of the stack to assign it to so that debugging can begin that's not something ridiculous like util-linux
[15:29] <seb128> Keybuk: gvfs
[15:30] <seb128> it's likely wrong but I will read those and I know what to ask
[15:30] <Keybuk> it'd be interesting to see if we can move that stuff to CoreDisksKitStar sooner rather than later ;)
[15:30] <Keybuk> ie. karmic
[15:39] <superm1> seb128, reg bug 331818, did I not properly push the upload to bzr, or was it something on your end that didn't get pushed right?  If it was me, i'd just like to make sure i'm aware of it so I dont make a mistake again.
[15:40] <seb128> superm1: we moved the bzr to the ubuntu-desktop team I think you pushed to the "old" location
[15:41] <superm1> seb128, ah yeah this i didn't realize.  i did push to the core-dev branches
[15:41] <superm1> seb128, did you update the Vcs-Bzr in the debian/control to reflect it too now then?
[15:42] <seb128> superm1: yes
[15:42] <seb128> I think that was just a race between change and your upload
[15:42] <seb128> nothing to worry about really
[15:42] <superm1> seb128, okay thanks
[15:49] <thbishop> now that Dell and others are shipping Ubuntu pre-installs and the whole Netbook linux thing is taking off, are these companies dedicating resources to Ubuntu development upstream?
[15:59]  * directhex hands dholbach a slice of cake
[16:00] <dholbach> directhex: gracias!
[16:00]  * directhex really does attempt to show appreciation when people process his crap, he's just not very good at it
[16:20] <slangasek> doko: I see jflex 1.4.2-1 is unstable now; is that the version we need to sync, or are we waiting for yet another upload?
[16:30] <pitti> slangasek: the latter
[16:30] <pitti> slangasek: jaunty and sid have by and large the same version, modulo changelog
[16:30] <pitti> slangasek: I updated the bug this morning and linked to the debian svn fix
[16:31] <slangasek> ok
[16:33] <bdmurray> cjwatson: I've updated and I'm setting up a daily cronjob for it
[16:33] <cjwatson> bdmurray: cool, thanks
[16:45] <slangasek> Keybuk: ah, the binary-index modprobe isn't in yet?
[16:46] <Keybuk> slangasek: not yet
[16:47] <slangasek> ok. is that the same upstream version that breaks compatibility with /etc/modprobe.d?
[16:47] <Keybuk> it doesn't break any compatibility
[16:47] <Keybuk> it does warn if the filenames don't end in ".conf"
[16:48] <slangasek> ah, right
[16:48] <slangasek> but we hide that by default at boot so it's ok :)
[17:05] <cjwatson> dendrobates: should have trimmed off a little under 4MB of your amd64 server CD size now
[17:05] <dendrobates> cjwatson: great, thanks.
[17:06] <cjwatson> you have about 11 to go ...
[17:06] <alex-weej> with notify-osd is it intended that i can only show one bubble per app?
[17:12] <kees> doko: my local machine can't compile openjdk-6; it eventually dies with:
[17:13] <kees> Could not reserve enough space for object heap
[17:13] <kees> but that's because I use a 1G vmem rlimit.
[17:14] <kees> [pid  1187] mmap(NULL, 2225078272, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
[17:15] <kees> (this is from "bootstrap/jdk1.6.0/bin/java -version")
[17:16] <cody-somerville> seb128, search in gedit seems broken. The find button stays deactivated even if you type stuff in.
[17:21] <ScottK> alex-weej: Try #dx.
[17:23] <alex-weej> scottK: no topic. what is it?
[17:23] <ScottK> alex-weej: That's where the Canonical Desktop Experience people who do notify-osd are.
[17:48] <jdong> does anyone know how crack-ish the freenx stack is these days?
[17:48] <jdong> I have to look into some low-bandwidth remote desktopping solutions and remember from the ol' days that FreeNX was one of the best in terms of usability
[18:36] <slangasek> awesome, right-clicking on an event in evolution crashes it
[18:38] <Simira> a new feature?
[18:39] <slangasek> the backtrace on the console is very pretty, so I assume so
[18:39] <slangasek> but maybe I'll file a bug report just in case
[18:39] <seb128> slangasek: it's fixed in svn
[18:39] <slangasek> oh, ok :)
[18:39] <slangasek> the 'BADARG: Bad argument to function' one?
[18:39] <seb128> slangasek: that's because libical is built to abort on error, I'm pondering unsetting that before jaunty
[18:40] <seb128> slangasek: bug #331428?
[18:41] <seb128> slangasek: I might backport that now in fact because we will not get new tarball before alpha6 and that's an annoying one
[18:41] <slangasek> seb128: yep, that's the one :)
[19:08] <tx2650> Hi. How can I tell Intrepid to download the old (2.6.24) Hardy kernel?
[19:10] <mrooney> tx2650: good question, if you don't get an answer here you could also try #ubuntu-bugs
[19:10] <tx2650> tnx
[19:12] <siretart>   
[19:12] <andresmujica> tx2650:  clean your apt-cache, backup your source.list, then change intrepid with hardy, then update your cache then install the hardy kernel, then recover your original source.list, clean your cache, and update again.  CAREFULLY
[19:18] <maxb> andresmujica, tx2650: No, don't clean your apt-cache. That is not useful and would just waste download time in the future, potentially
[19:18] <tx2650> internet connection is not an issue
[19:18] <maxb> Still needless
[19:19] <maxb> I'd be tempted to just download the .debs manually rather than messing with apt, if it's just for a kernel
[19:21] <tx2650> it seems that that would cause many problems. I`m going to backup and reinstall.
[20:18] <stgraber> seb128: what could cause whatever monitors /media/ not to send a dbus signal ?
[20:24] <tx2650> just a question: what`s with cpufreq on em64t? No support in Hardy or Intrepid?
[20:34] <seb128> stgraber: directory are filesystem entries they don't talk dbus
[20:34] <seb128> stgraber: not sure a dbus signal should be sent there
[20:48] <stgraber> seb128: dbus-monitor shows a few entry from a vfs service when a mountpoint appears in /media but for some reasons on some of my systems (intrepid/jaunty) nothing happens ...
[20:53] <seb128> stgraber: no idea about that it's friday evening now and over work hour, will have a look next week
[20:57] <joinAD> how do we go about adding ubuntu to a active directory domain?   was trying Likewise
[20:58] <slangasek> likewise does it.
[20:59] <joinAD> my syntax must be wrong then, or Server08 is not playing nice
[20:59] <joinAD> sudo domainjoin-cli join syrtime-local ACCOUNT PASS
[21:00] <Laney> Can someone help debug an FTBFS in miro? Seems to be boost-python related: http://orangesquash.org.uk/~laney/miro_ftbfs.txt
[21:01] <slangasek> joinAD: I don't recall the syntax off the top of my head, but I've tested it successfully in the past; if #ubuntu holds no answers for you, you might ask on #ubuntu-server
[21:03] <joinAD> thanks
[21:03] <sistpoty> Laney: /usr/include/boost/python/detail/wrap_python.hpp (failed) would be the first point to look for, I guess
[21:04] <sistpoty> Laney: so question is, why boost doesn't find it (it's from there) and if boosts deps are right (in regards to -dev packages)
[21:04] <Laney> yeah, it seemed fine to me
[21:13] <sistpoty> Laney: I can't find a failed buildlog in lp... where does it actually fail?
[21:18] <Laney> sistpoty: It didn't fail when it was uploaded
[21:18] <Laney> It needs updating for py 2.6, which is when I came across this
[21:18] <Laney> download the source and try to build and you'll see
[21:18] <sistpoty> Laney: ok, will try later ;)
[21:23] <Laney> hmm, this might be because of 2.5/2.6 skew
[21:23] <Laney> but miro does not work with py 2.6
[21:25] <sistpoty> Laney: complete guess right now (I'm just going through FFe's and found it): libtorrent-rasterbar has this in changelog: "--with-boost-python=boost_python-mt-py26 flag."
[21:25] <sistpoty> Laney: so maybe it might be worth a look what libtorrent-rasterbar makes with this flag
[21:25] <Laney> alright
[21:26] <sistpoty> Laney: cf. bug #335741
[21:26] <Laney> I see problems with Boost.Python and forcing 2.5 though
[21:26] <Laney> ooh
[21:26] <Laney> that title sounds workable
[21:26] <Laney> thanks
[21:45] <superm1> slangasek, i think i may have encountered a bug on cdimage when creating alternate disks.  what project is the appropriate place to file such bugs?
[21:46] <superm1> (unless you can confirm that it's the right behavior; it appears that udeb dependencies are not getting resolved when the cd is built)
[22:02] <superm1> slangasek, i'll put it on germinate for now, if you've got some better ideas i'll  be all ears
[22:04] <sistpoty> Riddell: may I bug you to look at FFe bug #334121 again? ;)
[22:49] <sistpoty> thanks jdstrand for letting faumachine through new (3rd time indeed was a charm) *g* :)
[23:04] <BUGabundo> asac: pitti I tested FF 3.1 with a clean profile: Without NM integration it will not change to off line. with flag to FALSE if NM is off, FF will go Offline too
[23:09] <slangasek> superm1: I was going to suggest the ubuntu-cdimage project; I guess udeb deps are supposed to get resolved, or else lib deps would be a headache - what udeb are you seeing that problem with?
[23:49] <avb1> hello all
[23:49] <avb1> guys, why everything is linked with libselinux?
[23:49] <avb1> ubuntu doesnt use it
[23:49] <avb1> or its in use by apparmor?
[23:49] <avb1> i thought its not
[23:54] <slangasek> various core utilities have to be linked with libselinux in order for them to correctly handle SELinux when it is enabled
[23:54] <slangasek> so we link against the lib even though it's not enabled by default.
[23:58] <avb1> i see, so, ubuntu dont use it by default, but its still "supported"
[23:58] <superm1> slangasek, i've filed bug 338967, so maybe follow up on that