[00:00] vish: compiz --replace should be ok too, afaik that's the only default option we pass if you don't do any manually [00:01] stgraber: plymouth batches up everything it sees on the console and copies it to boot.log. In your case, it sounds like plymouth-upstart-bridge isn't writing them to the console for some reason? [00:02] stgraber: it might depend on when p-u-b (hey, good acronym, I never thought of that ...) gets started; it can't start until dbus is up [00:03] stgraber: might be worth passing --verbose as a kernel parameter and looking at upstart output, though if you're doing that it might be easiest to use a serial console so that you can capture the output [00:32] Ugggh.. -rw-r--r-- 1 root root 0 2011-04-07 10:01 /usr/lib/pymodules/python2.7/bzrlib/__init__.py [00:33] ugh? [00:34] slangasek: 0 bytes? [00:34] my natty updates yesterday crashed in the middle of update-initramfs .. (ubuntuone-syncdaemon was eating RAM like the fat guy on the meaning of life)... [00:35] there are various reasons for a 0 byte __init__.py file to be used [00:35] bzr won't work.. network manager applet is borked.. [00:35] things are screwed. :-P [00:35] [ ] this close to reinstall. :( [00:35] though I don't recall /usr/lib/pymodules being a standard path [00:35] and I don't have that path at all here, hmm [00:36] slangasek: thats supposed to be a symlink [00:36] is it? [00:37] yes, all the other ones in those dirs are symlinks [00:42] hmmm.. is python-support not cleaning up after itself? [00:42] it claims to own /usr/lib/pymodules [00:42] when I removed /usr/lib/pymodules/python2.7/bzrlib ... bzr started working again. [00:45] So.. [00:45] there may be a problem when people switch modules to dh_python2 from python-support [00:45] it might be related to your crash, in fact [00:45] Seems the dirs are left behind in /usr/lib/pymodules .. [00:45] but won't be updated [00:45] because I didn't have /usr/lib/pymodules/python2.7/bzrlib here, which is why I was wondering what you were talking about :) [00:46] slangasek: well anything that uses python-support will dump symlinks and .pyc files in there.. [00:46] slangasek: I have > 100 dirs in there [00:46] sure - but for me, bzrlib did *not* leave files behind when switching [00:46] most of those others are, I suspect, from packages still using python-support [00:47] dh_python2 *does* remove pycentral bits.. [00:48] slangasek: yeah again.. probably related to my broken upgrade [00:49] the prerm does make an attempt to take care of this.. haven't looked at the pre-dh_python2 prerm .. === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === asac_ is now known as asac [02:46] cjwatson, this is so goofy. that partman hang from those new scripts seems to be because umount is failing to unmount my windows partition. umount fails because it looks like there is a bug in umount where it is passing the device name to the kernel umount() instead of translating it to the mount point. It seems there are two causes of this: 1) ntfs-3g canonicalizes the /dev/mapper/ name to /dev/dm-n, and trying to umount the /dev/dm- [02:46] n name fails as well it seems because umount is interpreting the - in some odd way as not part of the device name [02:48] so this looks like 3 bugs for the price of one... guess I need to file a new bug on ntfs-3g and one on mount [02:51] * psusi hugs qemu-kvm [04:34] SpamapS: python-support rebuilds it's symlink farm after package updates, so an interrupted upgrade could explain what you saw (design 'limitation' in python-support) [04:50] kees: hey, still around? [04:54] kees: https://code.launchpad.net/~dobey/ubuntu/natty/banshee/fix-and-amz/+merge/57041 is against 2.0.0 if you could sponsor it real quick when you see this. thanks again. i gotta go now though. cheers. === dendrobates is now known as dendro-afk === debfx_ is now known as debfx === yofel_ is now known as yofel [09:40] Hello all [10:43] slangasek: oops, sorry about libx11 :/ [13:09] doko_ - thanks for the binutils upload [13:17] chrisccoulson: np === dendro-afk is now known as dendrobates [14:08] what data is indexed by mandb ? [14:10] Manual pages [14:12] StevenK: so it stores the whole man page or a certain portion of it ? [14:15] abhinav-: It indexes it for searching. [14:16] The manual page itself is already stored on the filesystem. [14:20] abhinav-: there's a description of what it indexes in lexgrog(1) [14:20] (the WHATIS PARSING section) [14:21] abhinav-: why? [14:22] cjwatson: thanks. I have applied for a GSoC project for NetBSD. The task is to create a full text search tool for searching manual pages :) [14:23] abhinav-: I didn't know NetBSD used man-db [14:24] cjwatson: no it doesn't. they have asked to look for existing tools which index man pages, and explain why I should do it from scratch [14:24] abhinav-: I've thought about doing such a thing in man-db, but so far I've concluded it may not be worth the time investment, since on my system 'man -K' can do a brute-force search of all manual pages in under a minute [14:24] (it's implemented fairly efficiently) [14:25] well, efficiently as brute-force searches go [14:25] cjwatson: but it will search only the name section ? [14:25] -k searches the name section, -K searches the whole text [14:25] oh [14:26] if anyone wants to do a full-text index in man-db, it should probably be based on an existing widely deployed engine, probably xapian [14:26] and probably ought to put effort into things like matching rendered text rather than the groff input [14:27] yes xapian is a good choice. they are more inclined to using sqlite's FTS module. [14:27] man-db is GPLv3, though, so I expect NetBSD won't want it ;-) [14:27] yes :) [14:27] (and I don't want to relicense) [14:28] yes, I will just mention it as part of my case study :) [14:28] but, yeah, consider how much effort it's worth, given the relatively small amount of data compared to the power of even reasonably modern systems [14:29] man-db's 'man -K' gains a lot even just from doing its own decompression and searching rather than execing external programs for that [14:30] I'm interested in whatever you come up with, though [14:30] oh yes, that's a good insight. I did try indexing in sqlite database, and tried some search queries, results weren't very encouraging [14:30] cjwatson: thanks :) === c2tarun_ is now known as c2tarun === Claudinux_ is now known as Claudinux === doko_ is now known as doko [17:43] hi all - it seems like unity ui changes are still landing. is that correct? [18:16] ScottK: could you please approve bug #755661 [18:16] Launchpad bug 755661 in lucid-backports "Please backport dh-autoreconf" [Undecided,New] https://launchpad.net/bugs/755661 [18:17] yay dh-autoreconf [18:26] * ScottK looks [18:27] debfx: Done. [18:27] thanks === DreamThi1f is now known as DreamThief [20:00] Hello, I am working on a derivative distro, is it possible to change the default session from Unity to Gnome classic ? [20:00] in a deriv? sure. [20:00] yes [20:02] directhex: how ? [20:03] through a config file ? a gconf setting ? [20:07] AnAnt, presumably through a session file, pointed at by gdm [20:10] ? [20:20] tjaalton: it's ok, it's clearly my fault for not getting the change committed to the branch :) [20:22] directhex: could you explain further ? [20:24] reasonably sure just dropping a "default.desktop" symlink in /usr/share/xsessions is enough. but it's WAY out of my usual area of expertise. [20:29] thanks