[02:26] <kees> @pilot in
[04:13] <lucidfox> How do I reconfigure the redirection of my ubuntu.com address?
[04:14] <micahg> lucidfox: change your default address in LP
[04:14] <lucidfox> Ah. Danke
[04:14] <lucidfox> ...but my default email on LP *is* my @ubuntu.com address >_>
[04:15] <micahg> lucidfox: it shouldn't be unless it was grandfathered in
[04:43] <lucidfox> micahg, I changed my contact address on LP, but mail sent to sikon@ubuntu.com is still routed to my old mailbox
[04:45] <micahg> lucidfox: I think it might take a bit to sync up
[04:51] <jbicha> it may take a few days
[05:07] <lucidfox> Ouch
[05:19] <kees> @pilot out
[05:40] <didrocks> good morning
[05:45] <merlot> mornin' didrocks
[06:16] <ScottK> slangasek: Wouldn't want to you to be disappointed and have nothing to do.  Looks like a few rough edges on Qt.
[06:16] <didrocks> @pilot in
[06:51] <slangasek> ScottK: yep; I understand what's wrong, I'm just doing a local build here first to try to catch all the remaining issues in one go
[07:14] <pitti> Good morning
[07:15] <pitti> barry: yeah, did the last merge because we had to, but I barely know how this thing works :/
[07:15] <pitti> barry: thanks for merging
[09:48] <doko> ev, is the b-d on cheese in ubuquity wanted? MIR is missing
[09:52] <ev> doko: no
[09:52] <ev> we're using gstreamer directly now
[09:53] <pitti> seb128: ^ FYI
[09:53] <pitti> ev: nice! cheese grew so many new dependencies, and a lot of stuff we don't really want
[09:53] <seb128> pitti, thanks, we discussed it yesterday ;-)
[09:53] <ev> pitti: yeah, seb128 and I discussed that
[09:54] <seb128> we still need to solve the camerabin issue though
[09:54] <ev> I'm trying to pull camerabin out of -bad into -good, per seb128's advice
[09:54] <ev> but it's a very large patch
[09:54] <ev> will finish that today with any luck
[09:55] <didrocks> @pilot out
[10:27] <hyperair> lucidfox: ping. regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628194, does libgpod4-nogtk suit your needs?
[10:28] <doko> Daviey, component-mismatches ping
[10:30] <hyperair> lucidfox: no wait, sorry, ignore me
[10:31] <Daviey> doko: o/
[10:32] <doko> Daviey, see my email, could you walk through the list for the server component-mismatches?
[10:33] <Daviey> doko: I'm doing that at the moment, and commenting in -release :)
[10:33] <doko> cool, thanks!
[10:39] <seb128> doko, indicator-me is deprecated, it has been merged in indicator-session
[10:41] <doko> seb128, then please extend the bug report and/or remove it from the archive
[10:41] <seb128> will check with kenvandine one he's online
[10:41] <doko> thanks
[10:43]  * ogra_ grumbles about the combination of lightdm and apport that make logins take 10mins here
[10:46] <tkamppeter> Something changed with time.h in Ubuntu? Can someone have a look at bug 825054?
[11:18] <tkamppeter> Is it correct that /usr/include/sys is empty now? In Natty it was full of *.h files of libc6-dev.
[11:19] <cjwatson> it's not empty here; but you may well find that they've moved to /usr/include/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/sys
[11:20] <cjwatson> (ah, I'm slightly out of date)
[11:20] <cjwatson> they should still be on the compiler's default include path.  it's possible that your configure script or similar may need to be fixed if it brokenly looks in /usr/include directly.
[11:25] <tkamppeter> cjwatson, thanks.
[11:28] <tkamppeter> cjwatson, for me /usr/include/x86_64-linux-gnu has only an asm subdirectory, no sys and no time.h.
[11:31] <cjwatson> perhaps it's busted on amd64
[11:32] <cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/e/eglibc/libc6-dev_2.13-16ubuntu2_amd64.deb | grep sys/time
[11:32] <cjwatson> -rw-r--r-- root/root      6825 2011-08-11 18:04 ./usr/include/x86_64-linux-gnu/sys/time.h
[11:32] <cjwatson> nope, looks fine to me
[11:41] <tkamppeter> cjwatson, reinstalled libc6-dev and now the files are there.
[11:41] <tkamppeter> cjwatson, thanks.
[11:41] <doko> looks like we have an upgrade bug, which is exposed on the buildds too
[11:45] <tkamppeter> doko, cjwatson, looks like powerpc got updated a little bit earlier than the others so that Ghostscript still built on the others and failed on PowerPC.
[12:37] <pobara> hi everyone, I have question: I need to programatically detect if os runs Unity based on gtk2 or gtk3; can this be achieved with gsettings?
[12:37] <pobara> On Ubuntu 11.10 $ gsettings get org.gnome.desktop.session session-name
[12:37] <pobara> says 'ubuntu'
[12:37] <pobara> what does it say on Ubuntu 11.04?
[12:38] <pobara> I asked same question on #ubuntu and #ubuntu-desktop, but noone seems to be able to run gsettings
[12:43] <mdeslaur> pobara: it says "gnome" for me on 11.04
[12:43] <mdeslaur> pobara: but, I'm not quite sure that's a good test for that
[13:10] <tkamppeter> pitti, doko, can you upload c2esp 18-2ubuntu1 for me? See bug 821940. c2esp is not yet in my per-package upload list.
[13:11] <doko> tkamppeter, package location?
[13:11] <tkamppeter> doko, debdiff is attached to the bug.
[13:11] <doko> ahh
[13:30] <kenvandine> @pilot in
[13:35] <tkamppeter> I have a problem with building Ghostscript: devlibs error: There is no package matching [liblcms2-2-dev] and noone provides it, please report bug to d-shlibs maintainer. The correct name of the -dev package is liblcms2-dev. What do I have to do?
[13:43] <janimo> doko, is there a way to make the linker output why certain objects end up in the output? --verbose is not enough, it only prints the object paths it tries. A trace of symbol lookups of sorts
[13:46] <doko> janimo, -y ?
[13:49] <janimo> doko, hmm thanks, I was probably too vague, did not know symbol tracing exists and is named as such. I want to know why a file ends up in the output, even if no symbols are used from it. I'll try with as-needed again
[13:50] <janimo> doko, an object in the linker command line ends up in the result even if it is not. Only on ARM, x86 drops it
[13:50] <janimo> libvirt.so FTBFS, gets linked to libnl-route even if it should not
[13:51] <doko> hmm
[13:55] <janimo> doko, https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/823711
[14:00] <doko> janimo, is it different to revert the order of libnl-route and libnl?
[14:02] <janimo> doko, no, tried that too
[14:03] <janimo> only if I remove nl-route does it go away
[14:03] <doko> does gold do the job?
[14:03] <janimo> as-needed is default right?
[14:03] <doko> yes
[14:04] <janimo> I'll try to change to gold. Can I tell gcc the path to the linker or shall I just do that in the system?
[14:04] <doko> and changing the order on x86 doesn't expose the bug?
[14:04] <doko> -B/usr/lib/gold-ld/
[14:06] <janimo> doko, will try that too just to be sure - I symlinked ld to ld.gold and same reuslt
[14:07] <janimo> same with telling gcc to use gold. will try on x86
[14:08] <janimo> doko, on x86 only the intersection of what is in the command line and what is used gets in the output. So libnl only, andonly when it is put there
[14:09] <janimo> there are 5 symbols from libnl used in libvirt, and none of the other nl libs' symbols
[14:09] <janimo> could be a combination of the recent switch to libnl3 and some toolchain issue
[14:09] <janimo> doko, shall I subscribe linaro-gcc ?
[14:10] <doko> janimo, maybe. does it work with 2.21.1? (see the ubuntu-toolchain-r ppa)
[14:10] <janimo> doko, I'll try
[14:15] <mterry> kees, do you have time for some of your MIRs today?  We're looking to get component mismatches down
[14:15] <doko> janimo, and avoiding the not using libnl-* libs on the command line?
[14:16] <janimo> doko, that works. but those are filled in (all of them) by pkg-config
[14:17] <doko> $(filter-out -lnl-%, ...)
[14:18] <janimo> doko, well sure, but I was hoping to find the bug. Otherwise turning off tests on armel is a workaround as well :)
[14:18] <janimo> this ppa has an older binutils right?
[14:20] <doko> yes, 2.21.1
[14:20] <doko> but I assume it doesn't change, if gold shows the same behaviour
[14:27] <tseliot> pitti: I'm thinking of disabling nvidia-common's debconf interface as I guess we don't need it any more
[14:27] <janimo> doko, same with 2.21.1
[14:30] <doko> smells like relying on some undefined behaviour?
[14:30] <barry> doko: did you do a sync of python-sphinx?
[14:35] <doko> barry: no
[14:35] <doko> at least I can't remember =)
[14:35] <barry> :)  odd that i got offered an update this morning
[14:38] <tumbleweed> barry: I also noticed that, it was synced 2 weeks ago, but only built 20 hours ago
[14:39] <barry> tumbleweed: wussup widdat? :)
[14:39] <tumbleweed> dunno, launchpad throws away failed build logs
[14:39] <tumbleweed> (when tehy are retried)
[14:40] <barry> i bet there in the db somewhere.  i guess it's not that critical.  by request, i was going to do a sync of that today, but looks like i don't need to now
[14:54] <doko> barry, tumbleweed: yes, see my emails from today
[14:54] <barry> doko: which one? :)
[14:55] <barry> doko: component-mismatches/dep-waits?
[14:55] <doko> yes
[14:55] <barry> doko: saw it but haven't followed the link yet.  my ibus upload failed so i need to try again
[15:01] <robtow> I'm trying to build Ubuntu for Beagleboard under Ubuntu 1.10, and rootstock hangs with 100% cpu while "setting up xrulrunner-1.9.2 (1.9.2.10+build1+nobinonly-0unbuntu1)"
[15:01] <robtow> Any advice?
[15:03] <barry> doko: do i need an ffe to re-upload ibus?
[15:03] <doko> no
[15:03] <barry> cool, thanks
[15:26] <didrocks> ev: FYI, I'm pushing an updated usb-creator-gtk dep on the new unity gir. Tested locally and works
[15:29] <ev> didrocks: awesome, thanks!
[15:29] <didrocks> yw ;)
[15:55] <slangasek> ScottK: qt4-x11 reuploaded
[16:07] <ScottK> slangasek: Thanks.
[16:11] <RoAkSoAx> cjwatson: howdy! I have a quick question about preseed. Should debconf values for specific packages be set before telling pkgsel to include the package, or should be done after or it doesn't really matter: http://pastebin.ubuntu.com/664357/
[16:14] <ev> mmm, is PyGI broken for anyone else?
[16:14] <slangasek> ScottK: fwiw I've regression-tested Qt plugin resolution with both native (amd64) and cross (i386) builds, so I expect this to be pretty smooth; do you know anything else I should worry about testing besides a regular QCoreApplication-based plugin load?
[16:15] <ScottK> Probably not.  I'd feel better if you fired up at least one KDE application and it didn't explode.
[16:16] <ScottK> My expectation is it will be fine and it would either be OK for all of KDE or immediately crash and burn.
[16:18] <slangasek> ScottK: recommendation of something to test?  I don't seem to have any KDE apps installed here currently
[16:18] <ScottK> slangasek: kate should be reasonable.
[16:18] <ScottK> I don't think it should pull in too awful much.
[16:19] <slangasek> ok, installing
[16:21] <slangasek> ScottK: Works For Me™
[16:21] <slangasek> ScottK: though I am unsure if the UI theming is what it's supposed to be
[16:36] <ScottK> slangasek: It probably doesn't pull in everything that would make it 'nice' as that would be a LOT.
[16:36] <kees> mterry: yeah, going to be spending all day on MIRs, I think. ran out of time yesterday (got a few done)
[16:37] <kenvandine> @pilot out
[16:43] <cjwatson> RoAkSoAx: preseed files aren't ordered the way you think they are.  what you're doing is setting a load of entries in a database and then setting the whole thing off
[16:43] <cjwatson> RoAkSoAx: so in short, order doesn't matter
[16:45] <cjwatson> RoAkSoAx: though you should make sure to put only a single space or tab between the type ("string") and the value, as mentioned in the installation guide
[16:45] <cjwatson> (can't see from your pastebin whether that's two spaces or a tab)
[16:51] <RoAkSoAx> cjwatson: cool
[16:51] <RoAkSoAx> cjwatson: thanks tfor the info
[16:51] <RoAkSoAx> cjwatson: and it is a tab ;)
[16:51] <cjwatson> ok
[16:54] <tgardner> I've had several lockups with the chromium browser on lucid since a recent update. has anyone else complained? chromium-browser 13.0.782.107~r94237-0ubuntu0.10.04.1
[17:00] <micahg> tgardner: no, I haven't pushed it out yet, is it reproducible?
[17:02] <tgardner> micahg, you haven't pushed what out yet? thats the version that I'm running, likely from -proposed
[17:02] <tgardner> and its quite reproducible
[17:02] <micahg> tgardner: yes, it's in proposed ATM, was going to push out in a bit, but if it's crashing, I'll hold off
[17:03] <tgardner> micahg, try a google search on 'apparmor dfa'
[17:04] <micahg> tgardner: it's with the apparmor profile?  that's not even shipped with it ATM, idk if I"d block on that, but can you file a bug
[17:04] <tgardner> micahg, no, its just a simple search.
[17:04] <tgardner> no apparmor involved. I was trying to figure out what a dfa is
[17:04] <micahg> ah, I see, that's the test case :), let me fire up a vm
[17:05] <micahg> tgardner: are you searching in the URL bar or on google.com?
[17:05] <tgardner> micahg, on google.com
[17:06] <micahg> hmm, maverick isn't broke, let me fire up a lucid vm agaain
[17:08] <micahg> tgardner: i386 or amd64?
[17:08] <tgardner> amd64
[17:13] <tgardner> micahg, how about if I revert to 12.0.742.112~r90304-0ubuntu0.10.04.1 just to make sure its not happening with that version.
[17:13] <micahg> tgardner: that works too :)
[17:19] <tgardner> micahg, reverting appears to fix that particular lockup.
[17:19] <micahg> tgardner: :(, let me try in the i386 instance I just fired up
[17:21] <micahg> it works, but I haven't upgraded the kernel, let me try that
[17:21] <tgardner> micahg, yeah, I'm running full -proposed
[17:21] <tgardner> except for chromium now
[17:23] <micahg> i386 is fine
[17:23]  * micahg tries amd64
[17:26] <hyper_ch> hi there, I run into a statd problem with updates today and I wonder if it's the same bug (which says it has a fix released) or not
[17:27] <tgardner> hyper_ch, statd bug in the browser, or something external ?
[17:27] <hyper_ch> here's the bug I found  https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154   and my problem looks like this   http://pastebin.com/wYkBciWv
[17:27] <hyper_ch> tgardner: statd error so that I can't mount nfs
[17:27] <hyper_ch> manual (re)starting worked
[17:27] <tgardner> hyper_ch, well, I'm not using nfs, and reverting chromium fixed my problem.
[17:28] <hyper_ch> tgardner: statd is related also to browsers?
[17:28] <tgardner> hyper_ch, I dunno.
[17:29] <debfx> tgardner: the firmware-free package has been synced from Debian. I guess it should be removed since we have linux-firmware in Ubuntu?
[17:29] <hyper_ch> maybe I was sent into the wrong channel and should go to #ubuntu-bugs?
[17:30] <tgardner> debfx, yeah, I'd think there would be collisions.
[17:30] <micahg> tgardner: no crash for me, do you have any extensions in chromium?
[17:30] <debfx> ok, I'll file a removal bug
[17:31] <tgardner> micahg, not that I remember.
[17:31] <tgardner> I'm cranking up a Lucid VM to see if I can reproduce it. if not I'll look to see what extensions I might have.
[18:02] <slangasek> ScottK: qt4-x11 is also published on amd64 now, so the screaming should start soon if there's to be any
[18:02] <ScottK> Excellent.
[18:02] <tkamppeter> I have a problem with building Ghostscript: devlibs error: There is no package matching [liblcms2-2-dev] and noone provides it, please report bug to d-shlibs maintainer. The correct name of the -dev package is liblcms2-dev. What do I have to do?
[18:03] <tkamppeter> doko, thanks for the upload of c2esp.
[18:05] <tgardner> micahg, hmm, an amd64 VM seems to work OK. as far as I can tell I've no extensions installed.
[18:13] <tkamppeter> pitti, hi
[18:32] <micahg> tgardner: can you get a backtrace?
[18:44] <tgardner> micahg, you'll have to tell me how. its not crashing as  far as I can tell. it simply locks up.
[18:45] <micahg> tgardner: ah, can you attach strace to it when it locks up?
[18:45] <tgardner> micahg, ok, gimme a bit to upgrade again.
[19:10] <tgardner> micahg, I'm beginning to think this is kernel related. I'm running bleeding edge with a bunch of stable updates. I rebooted with the kernel in -proposed and all seems well.
[19:10] <tgardner> when chromium-browser gets wedged its always at an mmap() call, which I find highly suspicious.
[19:11] <micahg> tgardner: ok, thanks, I was getting worried, I just found a regression in maverick, but lucid looked clean, so good to know, I guess I should push lucid out
[19:12] <tgardner> micahg, yeah, I'm guessing my problem is self induced, but better to catch it now...
[19:12] <micahg> tgardner: indeed :)
[19:13] <tgardner> micahg, here is a very suspicious stable update to the kernel: 'mm: prevent concurrent unmap_mapping_range() on the same inode'
[19:16] <dobey> no patch pilot right now?
[19:25] <micahg> dobey: kenvandine is scheduled, but idk when/if he plans to pilot
[19:27] <dobey> ah. i pinged him on -desktop too, but no response yet. maybe the swamp fire is blocking his view of the screen or something :)
[19:32] <kenvandine> micahg, i did already :)
[19:32] <kenvandine> dobey, you pinged me?
[19:33] <dobey> kenvandine: i did. was wondering if you could sponsor a branch for me. https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-control-panel/fix-823648/+merge/71413
[19:33] <kenvandine> sure
[19:34] <dobey> thanks
[19:35] <micahg> kenvandine: wow, stealth pilot :)
[19:35] <micahg> oh, I saw it now :)
[20:02] <sgnb> it looks like because of bug 810402, everything compiled with ocaml should be recompiled on armel... what about upgrading to 3.12.1 at the same time?
[20:04] <sgnb> cjwatson, doko: ^^^
[20:12] <cjwatson> sgnb: we're after feature freeze - if we have to recompile, I'd rather just recompile what we currently have, unless there is a strong justification
[20:15] <infinity> We kinda need a fixed ocaml first anyway before we can talk about recompiling things.
[20:20] <sgnb> I've uploaded a fixed ocaml 3.12.1 to my PPA, the relevant patch is http://www.glondu.net/tmp/0013-ocamlopt-arm-add-.type-directive-for-code-symbols.patch and can be applied as is to the version currently in Ubuntu
[20:20] <sgnb> (it is also in the git repos at git.debian.org, which seems down right now)
[20:21] <kenvandine> dobey, uploaded
[20:22] <dobey> kenvandine: cheers! thanks!
[20:22] <infinity> sgnb: While I'd certainly be happy to discuss 3.12.1 if it's "nothing but bugfixes", or mostly so, I'll be more than happy to just apply the patch to our current sources for now. :)
[20:22] <kenvandine> dobey, any eta when ubuntuone-client-gnome will be installable again?
[20:23] <infinity> sgnb: Also, glondu.net seems to be grumpy with me currently.
[20:23] <sgnb> infinity: with www?
[20:24] <infinity> sgnb: As you typed above.
[20:24] <dobey> kenvandine: it isn't now?
[20:24] <infinity> sgnb: ICMP is fine, I get nothing on TCP 80.
[20:24] <cjwatson> nothing but bugfixes> right, that would help
[20:25] <cjwatson> sgnb's URL works for me
[20:25] <infinity> Weird...
[20:25] <cjwatson> although I expect that I'm hitting it on IPv6
[20:25] <infinity> Could be.
[20:25] <infinity> I'm still living in the dark ages.
[20:25] <sgnb> ah, my IPv4 NAT rule must be broken (the server has only IPv6)
[20:25] <kenvandine> dobey, not for me
[20:25] <cjwatson> w3m -4 doesn't answer, so yes, that's it
[20:26] <dobey> kenvandine: oh? what is the error?
[20:27] <cjwatson> sgnb: hey, we need more IPv6-only services anyway ;-)
[20:27] <kenvandine>  ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu2 is to be installed
[20:27] <cjwatson> ubuntuone-client-gnome is sitting in binary NEW at the moment
[20:27] <kenvandine> ah
[20:27] <dobey> oh right, because of the -dbg package
[20:29] <cjwatson> also the i386 binaries appear to have been rejected
[20:30] <infinity> Always a good sign.
[20:30] <dobey> oh, by didrocks?
[20:30] <cjwatson> I'm not actually clear why
[20:30] <cjwatson> manual maybe?
[20:30] <cjwatson> did he contact you about t?
[20:30] <cjwatson> *it
[20:30] <sgnb> infinity: should be fixed now
[20:30] <cjwatson> there's nothing in my ubuntu-archive mailbox about it
[20:31] <sgnb> (somehow, it seems that some delay is needed before setting routes with linux 3.0)
[20:31] <dobey> cjwatson: i think something about la files lintian
[20:31] <infinity> sgnb: It is indeed; thanks.
[20:31] <kenvandine> great... and now didrocks is away for 2 weeks :)
[20:31] <kenvandine> dobey, oh, you need to clean those
[20:31] <dobey> which is odd
[20:31] <cjwatson> well, if he gave clear feedback, any other archive admin can process them
[20:31] <cjwatson> .la handling is documented quite clearly in the policy manual
[20:32] <kenvandine> indeed
[20:32] <dobey> i'm not arguing with that :)
[20:32] <cjwatson> and it's there to avoid problems when libraries move around between paths, or when indirect linkage changes
[20:32] <dobey> but i don't know how it would be an issue given that we have a find/rm on the .la and .a files in the rules file
[20:33] <dobey> hence my "that is odd" :)
[20:33] <cjwatson> well, I assume he was going off how the actual binaries looked?
[20:34] <dobey> right. i'm just wondering how the .la files ended up in the binaries if the rules file has the bits to remove them...
[20:34] <infinity> adconrad@cthulhu:~/foo$ dpkg-deb -c ubuntuone-client-gnome_1.7.1-0ubuntu1_i386.deb | grep libub
[20:34] <infinity> -rw-r--r-- root/root      9600 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.so
[20:34] <infinity> -rw-r--r-- root/root      5508 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.a
[20:34] <infinity> -rw-r--r-- root/root      1292 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.la
[20:34] <infinity> They're definitely in the package.
[20:34] <dobey> yes, i see that. but *why*
[20:35] <infinity> I assume because they dislike you for some reason? :)
[20:35] <infinity> (More likely, some helpful helper is installing them after you think you've removed them)
[20:35] <dobey> probably
[20:36] <infinity> If you remove them from your build-tree during the build target, then there's no way anything in binary-arch can operate on them.
[20:36] <infinity> Since they'll be, y'know, not there at all.
[20:36] <infinity> That would be my purge-with-fire method of tha day.
[20:36] <infinity> s/tha/the/
[20:36] <dobey> well we're removing them in binary-post-install
[20:37] <dobey> but i suppose for some reason that is no longer working correctly in the split package for some reason
[20:37] <dobey> wow, brain fail there
[20:37] <kenvandine> 	find debian/tmp/usr/lib -name \*.la -delete
[20:37] <kenvandine> 	find debian/tmp/usr/lib -name \*.a -delete
[20:37] <kenvandine> works
[20:40] <micahg> kenvandine: why are you removing the .a files?
[20:40] <cjwatson> may need to be debian/ubuntuone-client-gnome instead given that this is a multi-binary package
[20:40] <infinity> micahg: Because it's an internal library/plugin, not something meant to be linked statically against, I assume.
[20:41] <kenvandine> +common-install-arch::
[20:41] <kenvandine> +	find debian/tmp -name \*.la -delete
[20:41] <kenvandine> +	find debian/tmp -name \*.a -delete
[20:41] <kenvandine> that'll work
[20:41] <kenvandine> not sure if we need anything to use it statically linked
[20:41] <kenvandine> that was already three
[20:41] <sgnb> cjwatson, infinity: for ocaml, as you wish... all packages providing an -dev binary package (and maybe a few more) should be recompiled (at least on armel) in topological order (as in http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html) with ocaml + the patch above
[20:41] <kenvandine> there
[20:42] <infinity> sgnb: *nod*... I'll get on that as soon as the patch and I have spent some quality time.
[20:42] <infinity> sgnb: I'm not against the idea of the ocaml microrelease, if an argument can be made for it, but I have no idea if it's featurey, or just bugfixey, etc.
[20:44] <sgnb> infinity: in the link above, lwt, oasis, js-of-ocaml, obrowser, ocaml-usb and ocsigen should be fixed by that
[20:44] <infinity> sgnb: You're my personal hero.
[20:44] <infinity> sgnb: For this week, anyway. ;)
[20:44] <sgnb> (after recompiling their dependencies)
[20:47] <dobey> kenvandine: https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-client-gnome/fix-824821/+merge/71424
[20:49] <kenvandine> dobey, great
[20:51] <kenvandine> dobey, my way was simpler :)
[20:54] <kenvandine> dobey, uploaded
[20:54] <dobey> thanks again
[20:54] <kenvandine> anytime!
[20:54] <dobey> now hopefully archive admin can approve it
[20:55] <kenvandine> yeah
[20:55] <kenvandine> woot :)
[20:55]  * kenvandine calls it a day... later!
[21:43] <ScottK> slangasek: I missed one dh_python2 change.  I'd appreciate if you'd approve Bug #825536
[21:51] <slangasek> ScottK: acked
[22:00] <ScottK> slangasek: Thanks.
[22:09] <slangasek> ScottK: sure thing. btw, I missed a library on alsa-libs too... can I multiarch libjson0 as well? :) (bug #825342)
[22:49] <alkisg> http://packages.ubuntu.com/lucid/linux-headers-2.6.35-30-generic-pae is broken currently, it depends on linux-headers-2.6.35-30 which is not available
[22:56] <slangasek> alkisg: please raise a bug on the linux-lts-backport-maverick package for this; it seems to be a regression between the previous version (which did have the package) and the one that actually got published to lucid-updates
[22:56] <alkisg> slangasek: ok, will do so tomorrow (kinda late here). Thank you. :)
[22:57] <slangasek> thank you for reporting it
[23:00] <slangasek> kees: have you seen bug #800853?
[23:01] <kees> slangasek: yeah, I have a long list I've been working on. it's coming up :)
[23:01] <slangasek> ok
[23:01] <slangasek> that one would be particularly helpful to get sorted, blocking as it does both libpam-krb5 and cyrus-sasl2
[23:01] <kees> slangasek: okay, noted.
[23:07] <infinity> Did we switch krb5 providers for main?
[23:08] <infinity> Or, we're going to ship MIT and heimdal?
[23:08] <infinity> I guess...
[23:20] <slangasek> infinity: yeah, too many packages now build-depend on both krb5 implementations :/
[23:21] <infinity> slangasek: Feels a bit ugly, but whatever.
[23:21] <slangasek> does anyone know where my other metacity workspaces will have gone after my most recent upgrade?
[23:22] <slangasek> ... or even where the option to configure workspaces is
[23:23] <infinity> I gave up this morning and switched to xfce...
[23:23] <infinity> Is that a helpful answer?
[23:23] <slangasek> not terribly :)
[23:27] <slangasek> ah, apparently I just needed to run 'metacity --replace' (eh?)
[23:27] <infinity> Of... Course?