=== warriorf1rgod is now known as warriorforgod === JanC_ is now known as JanC [02:32] 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? === asac_ is now known as asac [04:50] anyone here that can do a sync request? [04:51] i need lp-solve and suitesparse synced from debian unstable [04:51] Are they new upstream versions? [04:51] the hacks i did for them in january have been accepted and integrated properly [04:51] no, just new debian updates [04:51] 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] the ubuntu patches are no longer needed [04:52] If they have Ubuntu changes, file bugs [04:52] ok will do [04:58] james_w: Katilsday in Uruguay [05:00] could be [05:00] oh, just been told I've got to change countries again [05:03] https://edge.launchpad.net/bugs/338571 https://edge.launchpad.net/bugs/338572 [05:04] Ubuntu bug 338571 in suitesparse "Sync suitesparse 1:3.2.0-4 (main) from Debian unstable (main)." [Wishlist,Confirmed] [05:04] james_w: have fun in Mauritania! [05:04] StevenK: ^ [05:04] slangasek: thanks :-) [05:14] 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] calc: I guess suitesparse needs to be published before lp-solve is synced? [05:27] StevenK: let me see, if it build depends on the right version it can be synced at the same time [05:29] 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] calc: Both done. [05:33] thanks :-) [05:34] now hopefully my build doesn't mysteriously blow up while i am asleep and i can upload in the morning :) [05:34] then back to beating on OOo gvfs support to see i can fix it in time for release === rgreening_ is now known as rgreening [06:23] good morning [06:26] good mornign dholbach [06:26] hiya highvoltage [06:45] hi dholbach [06:54] hiya bryce, hi ara, hi iulian! [06:55] hey dholbach :) welcome back :) [06:55] yoooho [06:55] Hello dholbach. [06:56] evening dholbach [06:57] hey Hobbsee [06:58] heya Hobbsee [07:08] morning doko - what do you think about bug 330613? [07:08] Launchpad bug 330613 in python3-defaults "python3-minimal should not have 'Essential' set to yes" [Undecided,New] https://launchpad.net/bugs/330613 [07:21] dholbach: yes, on my list ... [07:21] doko: super, danke! [07:43] Good morning [07:44] jdstrand, When you get a chance, could you look at accepting syslinux into hardy-proposed? [07:45] jdstrand, OOps. Ignore that. It's been too long since I did an SRU. [07:47] Good morning pitti [07:47] hey persia, how are you? [07:47] 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] StevenK: no, it's indeed as bad as it says! [07:49] pitti: It doesn't show the weather for any of the cites I have set as locations ... [07:55] StevenK: There are also other problems relating to libgweather... bug 334377 [07:55] Launchpad bug 334377 in libmbca "Lots of country names are missing, showing "missing from libgweather" in mobile broadband connection wizard." [Undecided,Invalid] https://launchpad.net/bugs/334377 [07:56] My machine has been logged in for 11 days, I guess libgweather got freaked out about ... 3 days ago? === fargiola` is now known as fargiolas [08:15] Mirv: the patch for bug 102773 is already merged :) [08:15] Launchpad bug 102773 in software-properties "l10n broken in the KDE frontend" [Medium,Fix committed] https://launchpad.net/bugs/102773 [08:16] savvas: oh, right, I visited the bzr page very quickly but apparently missed it :) great, anyway [08:17] ok:) [08:50] 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:50] Launchpad bug 323409 in cyrus-sasl2 "sasl2-bin broken, segfaulting during install" [High,Triaged] https://launchpad.net/bugs/323409 [08:53] * Mirv is starting to see hope at https://wiki.ubuntu.com/TranslatingUbuntu/JauntyTranslationIssues [09:11] Keybuk: just confirmed that it fixes things for me again [09:17] 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] "shift: 2353: can't shift that many" [09:18] it does that in the po directory on the buildds but built fine locally [09:18] i hate site-specific issues like that [09:20] 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] 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:23] Launchpad bug 333903 in jockey "jockey fails to enable broadcom STA driver" [Undecided,Incomplete] https://launchpad.net/bugs/333903 [09:39] pitti: Hey, not sure why you moved the apport traceback to germinate [09:39] pitti: Usually apport doesn't report anything when another program generates an exception [09:39] 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] pitti: I don't see why I should get an exception on the console from apport in any case [09:39] lool: well, it's an exception from germinate, which should appear on the console? [09:40] seb128: hmm, complete mystery to me too, I can't even find what *might* be generating it by 'grep -r shift. .' [09:40] 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] pitti: It's not, there's an exception from germinate and then an exception from apport [09:40] In handling that exception [09:40] At least that's my understanding [09:40] lool: if you want apport to suppress its exception about the file already existing, I can do that [09:40] pitti: I think you should; it shouldn't be an exception in apport in any case [09:40] (I mean it shouldn't reach the console) [09:41] lool: okay; what was the bug# again? [09:41] 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] 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] the exception from germinate is basically "debootstrap failed" and has been dealt with separately (by printing its stderr too) [09:41] pitti: bug #323714 [09:41] Launchpad bug 323714 in germinate "OSError: [Errno 17] File exists: '/var/crash/_usr_lib_germinate_update-metapackage.py.1000.crash' " [Undecided,New] https://launchpad.net/bugs/323714 [09:41] lool: okay, thanks; I'll add an apport task [09:41] maybe it should print an error and sys.exit(1) rather than raising an exception though [09:41] pitti: the exception in germinate is fixed [09:42] cjwatson: ah right, that might be nice too [09:42] pitti: Ok let's keep the germiante task [09:43] doko: do you think that by and large, the icedtea6-plugin will work? [09:43] thanks folks [09:43] 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] pitti: 6u12 was released half a year ago. Now applets appear using these new features. I really don't know ... [09:45] cjwatson: ok, thanks for having a look anyway [09:45] 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] doko: ok, thanks; I'll check with asac whether we have a working plugin installer in firefox [09:45] seb128: is it possible that it varies with /bin/sh -> bash vs. dash? [09:46] cjwatson: sh is dash here, do we use bash on buildds? [09:46] seb128: I fixed the amd64 retracer, FYI (or, rather, the bug which it stumbled upon [09:47] pitti: ok, thanks, I pinged you about that on #ubuntu-desktop when I joined but you probably didn't notice [09:47] seb128: whoops [09:47] pitti: your IRC client clearly needs to be ported to the message indicator system so you know about unread pings ;-) [09:48] hehe [09:48] 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] cjwatson: ok thanks, I will give it a try now [09:50] seb128: That's probably the same bug [09:50] seb128: config.status being run by /bin/sh instead of @SHELL@ [09:50] lool: the one you fixed for glib and gtk? [09:50] seb128: Yes, and it's fixed upstream in intltool and gettext too [09:50] lool: ok, I knew that was ringing a bell somewhere ;-) how did you fix it? [09:50] asac: nevermind, figured it out; discussing on the bug [09:51] seb128: Try changing the $(SHELL) before config.status in Makefile.in.in to @SHELL@ [09:51] seb128: Or rather, add SHELL = @SHELL@ to po/Makefile.in.in, that's what the GNOME guys preferred [09:51] seb128: it will be fixed when the tarball is rerolled with a new intltool/glib-gettext [09:52] $ grep SHELL po/* [09:52] po/Makefile.in.in:SHELL = /bin/sh [09:52] po/Makefile.in.in: $(SHELL) ./config.status [09:52] ok [09:52] lool: thanks! [09:52] Yeah, you want @SHELL@ instead [09:52] we should ask dobey to roll a new intool tarball [09:53] Please do [09:53] so that get fixed in 2.26 [09:53] http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=df8857c0472c33bd786a967569c4b3c9c4c177b2 [09:53] FWIW [09:53] cjwatson: Yes, but not released yet; I patched our package [09:54] right, I just figured I'd gone and looked for that so might as well give the URL :) [09:54] thanks for backporting it [09:55] cjwatson: thanks, it's linked from the bug report too already [09:55] bug #332840 [09:55] Launchpad bug 332840 in gnulib "$(SHELL) config.status broken" [Undecided,In progress] https://launchpad.net/bugs/332840 [09:55] I don't intend to fix gnulib, I don't think it's used that much for Makefile.in.in [09:56] It will be fixed upstream by the same guy [10:20] 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] lool: http://launchpadlibrarian.net/23542187/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu3_FULLYBUILT.txt.gz [10:20] lool: thanks ;-) [10:21] persia: yes, make first sure, that the current package is available in dapper, hardy and intrepid [10:23] doko, So you want 1.5.0-17 backported into -proposed for everything first? [10:24] persia: well, sru's require to have the new version in the development version [10:25] 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] 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] it's there so that we get the maximum testing possible before inflicting on stable users [10:27] hi pitti, gegl FTBFS cause of libopenraw-dev is in universe and there are 2 ways to solve that [10:27] 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] 1) file a MIR 2) build the package without libopenraw-dev build-dep (which is unnecessary) [10:28] cjwatson: I wonder what to do with bug 328486; a beta-blocking milestoned wishlist bug, without an assignee.. [10:28] Launchpad bug 328486 in apturl "automatically add keys when whitelisted for apturl" [Wishlist,New] https://launchpad.net/bugs/328486 [10:29] 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] pitti, what do you think about it? what solution could be better? [10:29] pitti: I discussed it with mvo before filing it [10:30] 11:55 just thinking about jaunty-apturl-add-repo in the context of some previous discussions, and an e-mail thread with Mark today [10:30] 11:56 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] 11:57 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] 11:58 sounds sensible indeed [10:30] 12:01 should I file a bug? [10:30] from 12 Feb [10:30] 12:03 I can do that too, no problem (and milestone it) [10:30] I'll just assign it to mvo now [10:30] cjwatson: ok, assigning to mvo then [10:38] seb128: cool [10:38] quadrispro: if libopenraw-dev isn't really needed, then dropping the b-dep is always better [10:39] 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) === ogra_ is now known as ogra [10:40] 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] Mirv: dunno about libmbca, gnome.mk is for desktop packages usually and the pidgin-libnotify was already using cdbs [10:42] 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] 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] thank you pitti, I'm going to do some tests [10:44] seb128: ok. [10:46] Wow valgrind is 45 MB [10:47] 47M /usr/lib/valgrind/x86-linux [10:59] 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] Launchpad bug 275432 in policykit "libpolkit requires files from policykit for polkit_context_init to work" [High,Confirmed] https://launchpad.net/bugs/275432 [11:00] james_w: it's a jaunty-targetted bug, so it should have an assignee [11:00] oh, this is going to be unpleasant. Apparently at one point openssl had an rpath pointing to /usr/lib [11:00] I think I'm going to have to leave symlinks behind [11:05] 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] cjwatson: That sounds terribly long [11:05] did it have a saved keymap previously? [11:05] It's subsecond on my desktop [11:05] cjwatson: It's the second run [11:06] was the first run in the boot sequence? [11:06] cjwatson: No [11:06] cjwatson: I noticed slowness during upgrade, then reproduced manually on the running system [11:06] would be useful to know which bit of setupcon is taking lots of time [11:07] cjwatson: On a FSL Babbage, also jaunty armel but might be a different keymap, it's real 0m5.121s [11:07] cjwatson: Could it be using lots of rAM? [11:07] I only have 128M on the EVM [11:07] well, if it has the keymap files cached, the particular keymap in use should make no difference [11:07] lool: I don't want to speculate too much without knowing which bit of setupcon is taking ages [11:07] lool: it's a shell script - you could sh -x it [11:08] I'm doing that [11:08] setupcon --force --save [11:08] That's what hangs for long [11:08] now sh -x *that* [11:08] setupcon does quite a few different things [11:08] + ckbcomp -model pc105 us [11:08] + gzip -9 [11:09] can I have the bit before that with the tests? [11:10] from just after setting rules_option [11:10] cjwatson: http://paste.ubuntu.com/127152/ [11:11] you have a /root/.console-setup file [11:11] any particular reason? [11:11] time (ckbcomp -model pc105 us | gzip -9 >/dev/null) => 0m25.938s [11:11] cjwatson: I don't [11:11] 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] cjwatson: http://paste.ubuntu.com/ [11:12] this was in response to bug 332728 [11:12] cjwatson: kernel is hand built though [11:12] Launchpad bug 332728 in console-setup "uses cached keymap even when reading a user configuration file" [Undecided,Fix released] https://launchpad.net/bugs/332728 [11:12] lool: ... I think you forgot the last bit in that URL ;-) [11:12] Hmm? [11:13] cjwatson: sorry didn't understand [11:14] cjwatson: Note: no initramfs [11:14] Probably what causes the difference [11:14] without -9 doesn't change anything [11:16] cjwatson: ooohhh sorry [11:16] cjwatson: http://paste.ubuntu.com/127156/ === cjwatson_ is now known as cjwatson [11:17] lool: sorry, the last I have is: [11:17] 11:12 cjwatson: http://paste.ubuntu.com/ [11:17] 12:16 < lool> cjwatson: ooohhh sorry [11:17] 11:12 this was in response to bug 332728 [11:17] 12:16 < lool> cjwatson: http://paste.ubuntu.com/127156/ [11:17] Launchpad bug 332728 in console-setup "uses cached keymap even when reading a user configuration file" [Undecided,Fix released] https://launchpad.net/bugs/332728 [11:17] 11:12 lool: ... I think you forgot the last bit in that URL ;-) [11:18] cjwatson: I don't have the /root/.console-setup [11:18] cjwatson: And I don't have an initramfs [11:18] and without -9 makes no difference [11:18] apparently I can't read [11:20] 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] lool: this shouldn't affect the boot sequence, though [11:20] lool: when running in the boot sequence, --save isn't used [11:20] Ok [11:20] lool: assuming, that is, that the run_by_init function in /etc/init.d/console-setup still works [11:21] lool: oh, actually, maybe don't file a bug [11:21] lool: your issue is during upgrade, yes? [11:21] lool: in that case, it's perfectly conceivable that stuff may have changed such that the keymap *does* need to be regenerated [11:22] cjwatson: It was during upgrade yes [11:22] cjwatson: Will it affect first boot? [11:22] no, it won't [11:23] it's interesting that it's so slow though [11:23] cjwatson: Ok, so it's normal that it takes so long on console-setup upgrades? [11:23] Right, I find that really slow [11:23] ckbcomp only uses maybe 5MB of memory tops [11:23] $ time ckbcomp -model pc105 us '' '' >/dev/null [11:23] real 0m0.618s [11:24] time (ckbcomp -model pc105 us >/dev/null) => 0m26.826s [11:24] lool: is it possible that 'use integer;' near the top of ckbcomp would speed it up? [11:24] I don't see any faults in /proc/cpu/alignment [11:25] I don't think it needs FP math [11:25] That's likely, trying [11:25] 0m25.583s [11:25] no [11:26] might be worth trying it with -v 10 and seeing what's taking time [11:27] oh, hmm, -v 10 actually not that informative [11:28] verbose perl debugging will probably slow the whole thing down to the point of making it hard to tell [11:28] maybe just print debugging at appropriate points? [11:29] Ok [11:33] I don't have any other obvious bright ideas :-( [11:36] cjwatson: time is spent on iterations of this loop foreach my $key (sort {$a <=> $b} (keys %symbols_table)) { [11:44] lool: would be useful to know how many elements %symbols_table has, and the same recursively for its elements [11:44] the actual work done in the inner loop is trivial [11:45] if the hash lookups are taking ages then we could arrange to do that just once [11:46] cjwatson: flatten() is the one taking most time [11:47] lool: flatten() isn't in the loop you mentioned ... [11:48] oh, you're talking about a different loop than I'm looking at [11:48] * cjwatson starts again [11:50] lool: the Devel::DProf module might help here [11:51] 'perl -d:DProf /usr/bin/ckbcomp -model pc105 us >/dev/null' will produce tmon.out and dprofpp can analyse that [11:52] 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:52] Launchpad bug 309396 in syslinux "Ubuntu UMPC boot menu is truncated" [Medium,In progress] https://launchpad.net/bugs/309396 [11:53] persia: okay, will have a look today [11:53] pitti, Thanks. [11:54] persia: did you upload it already? [11:54] via sponsorship, yes. [11:56] pitti: I uploaded it, which is why I'm not looking at it [11:59] StevenK, I thought you weren't looking at it because you weren't ubuntu-sru [12:00] ah, good [12:00] persia: Shhh [12:11] ta seb128 [12:15] directhex: you're welcome [12:15] 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] seb128, no, i replied & said the exisiting archive version would ftbfs due to transition [12:16] seb128, so it's that or ubuntu1 [12:17] didrocks: you didn't reopen when replying because it's not on the sponsoring list [12:18] damn. incomplete [12:18] i suck [12:18] New again? [12:19] yes [12:19] bug number? [12:19] bug 337634 [12:19] Launchpad bug 337634 in gnome-keyring-sharp "Please sync gnome-keyring-sharp 1.0.0~svn.r87622-2 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/337634 [12:20] directhex: synced, don't forget to reopen next time [12:20] yeah, my mistake. [12:20] i wonder what time i replied... [12:21] 20 past 10, can't even blame tiredness. bah [12:21] dholbach: probably correct [12:22] pitti: blacklist only prevents then named modules from appearing in alias expansion [12:22] pitti: it doesn't actually stop anyone doing "modprobe foo" [12:23] 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] There must be something wrong with the /etc/modprobe.d/blacklist-bcm43. [12:23] pitti: that should be blacklist-bcm43.conf btw ;) [12:23] Keybuk: right, but the udev rules all use -b, which should respect the blacklist? [12:23] Keybuk: oh, you mean it only considers files ending in .conf now? [12:24] Keybuk: that might be the very bug I'm looking for then [12:24] # load wl before b44 so that both work [12:24] install wl modprobe -r b43 b44 b43legacy ssb; modprobe --ignore-install wl $CMDLINE_OPTS; modprobe -Qba b44 [12:24] the comment is exactly the opposite of what you're actually doing ;) [12:24] you probably want an && in there too [12:24] and -Q has gone, so you don't want that [12:24] (and you don't want -a either) [12:25] Keybuk: is .conf required now, or just "best practice"? [12:25] pitti: required [12:25] oh [12:25] it's not fully deprecated yet, but EVERY SINGLE modprobe invocation will bitch about it [12:25] that's not your bug though [12:25] I'm just going down the list :p [12:25] Keybuk: almost all files in modprobe.d/ violate that then [12:25] okay [12:26] pitti: actually, if you look at -changes, I fixed almost all of them yesterday [12:26] the only ones left are those that come with module-init-tools itself [12:26] this is breakage for the sake of breakage from m-i-t upstream, right? :) [12:26] and those created by programs [12:26] the only justification I can think of is things like .dpkg-tmp [12:26] which would be addressed by just saying that your filename can't contain a dot [12:26] cjwatson: no, there's enormous numbers of bugs of people's swap files being treated as module aliases, etc. [12:26] like .dpkg-old or so? [12:27] that doesn't help with /etc/modprobe.d/4913 which vi likes to create [12:27] the run-parts rules deal with that perfectly well, and much less intrusively [12:27] cjwatson: I don't think I agree anymore [12:27] after having tried to maintain the same thing with Upstart [12:27] that's shifting to .conf too [12:28] there's just too many damned stupid file rules to ignore nowadays [12:28] and so the world gets gradually worse :-/ [12:28] why worse? [12:29] upgrade pain on a stick; I expect lots of people to have local modprobe.d files [12:29] it'll pass [12:29] just because it was too hard to DTRT [12:29] upgrade pain is cumulative, and everybody keeps adding their own little bit to the pile [12:29] upgrade problems are something we get hammered about by users [12:30] anyway [12:30] bitching aside [12:30] back to the bug [12:31] pitti: I can't quite see what's going in the description [12:31] I'm sorry that you feel that raising a design concern is bitching :P [12:31] Keybuk: my main headache is that modules get auto-loaded despite being blacklisted [12:31] cjwatson: it's bitching because you're doing it to me, and not upstream [12:31] Keybuk: this obviously worked in intrepid, so I wonder what changed [12:31] as usual, we raise bug reports through distro maintainers [12:32] 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] cjwatson: I happen to agree with the upstream in this case ;) [12:32] having tried to maintain a "filter out known filename patterns" list, it's just too damned hard [12:32] especially if you're doing it in a piece of software that can run at any time [12:32] so you need to deal with transient things like vi's silly "can I write to this directory?" files [12:33] 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] ANYWAY BACK TO THE BUG [12:34] pitti: hmm [12:34] pitti: bug the bug seems to say that a driver *isn't* being loaded [12:35] or am I reading this all wrong? [12:35] Keybuk: sec, doorbell [12:35] pitti: no objections from me in regards to devicekit-power [12:35] Keybuk: no, the bug is that wl isn't being loaded because ssb is auto-loaded [12:36] Keybuk: in intrepid this blacklisted ssb, b43, and b44 [12:36] wl is failing to load? [12:36] ie. it tries, and throws it out? [12:36] Keybuk: thus the modaliases for wl got "unshadowed" [12:36] what do you mean by "unshadowed"? [12:36] thus wl then got auto-loaded through the udev rules, and the rule made sure that b44 got, too [12:36] Keybuk: ssb and wl have the same modaliases [12:36] right [12:36] and apparently ssb won [12:36] so both will be loaded [12:36] whichever is first in depmod.conf/modules.order will win [12:37] if wl is in ubuntu/ it should win [12:37] as long as ssb isn't [12:37] but if ssb and b43 already grabbed the device, wl didn't find anything to drive [12:37] so someone came up with that idea of blacklisting ssb/b43/b44 and let wl install b44 alongside [12:37] which worked fine in intrepid [12:37] but now, the blacklist seems to get ignored entirely [12:38] Keybuk: changing the probing order sounds interesting; where is that configured? [12:38] pitti: is bug 318775 addressed? [12:38] Launchpad bug 318775 in devicekit-power "D-Bus Policy needs checking" [Undecided,New] https://launchpad.net/bugs/318775 [12:38] pitti: two places [12:38] pitti: /etc/depmod.d/depmod.conf configures the search order of directories [12:38] so it will search updates, then ubuntu, then kernel [12:38] err [12:38] /etc/depmod.d/ubuntu.conf [12:38] sorry [12:39] /lib/modules/$(uname -r)/modules.order specifies the load order in general [12:39] DktrKranz: it's fixed in devicekit; not sure whether it's needed in devkit-power, I'll look [12:39] pitti: thanks. Anyway, it looks fine to me [12:39]