[00:06] <slangasek> Laney: ah, kudos :)
[01:23] <Noskcaj> robert_ancell, is it ok with you if i prepare light-locker 1.1 for trusty?
[01:23] <robert_ancell> Noskcaj, sure
[02:13] <Noskcaj> Can someone explain what i have to do to fix http://paste.ubuntu.com/6800659/ ?
[02:27] <sarnold> hey jackson_, you didn't miss any replies while you were timedout
[05:25] <pitti> Good morning
[08:10] <dholbach> good morning
[09:00] <smb> infinity, Apparently I, too do not switch back and forth enough. Trusty was was the first time I realized the issue. To be honest, I did not really do much with i386 and Xen (before trying to figure out how to cope without the i386 HV).
[09:00] <smb> infinity, And I guess not many other people did, or at least stick with one side of the force
[09:01] <smb> infinity, I guess we can probably think about it next week a bit more. I am not minding not having libc-xen if it does make no difference
[09:04] <infinity> smb: Yeah, it's literally useless in Ubuntu.
[09:05] <infinity> smb: Might make sense in Debian to roll the functionality into libc6-i686, and get rid of -xen in both distros.
[09:06] <smb> infinity, True, if I manage to ever get any reply again
[09:09] <mitya57> dholbach: I like your new name: http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/debian/control#L4 :D
[09:09] <dholbach> haha
[09:10] <dholbach> mitya57, fixed :)
[09:10] <mitya57> thanks :)
[09:13] <infinity> smb: Get a reply from whom?  Me?
[09:13] <smb> infinity, Not for a change not. :-P More waldi
[09:14] <infinity> smb: Oh, this has nothing to do with waldi, though.  I just need to confer with the other debian glibc maintainers, and then drop libc6-xen, which seems like the right thing to do, IMO.
[09:14] <smb> infinity, Ah well then. So changing Xen would be a necessity after :)
[09:20] <dholbach> davidcalle, happy birthday!
[09:21] <davidcalle> dholbach, thanks :)
[10:26] <doko> rbasak, ruby-rgen MIR required (puppet recommends it)
[10:26] <doko> rbasak, and can you make puppet using ruby2.0 by default?
[10:27] <rbasak> doko: noted. I created bug 1271857 earlier but I need to fill it out.
[10:27] <rbasak> Not sure about ruby2.0. That seems like a big ask until upstream switch.
[10:27] <doko> ahh
[11:13] <zequence> Hi. Need a sponsor to upload lp:ubuntustudio-default-settings to fix lightdm bug #1259525
[11:33] <rbasak> Any quick tips on rebuilding a python module with debugging symbols for debugging purposes? Is there a simple switch somewhere, or do I have to mess with flags manually?
[11:37] <pitti> zequence: can do
[11:39] <pitti> zequence: uploaded, and I pushed the dch -rm / release tag to bzr
[11:42] <zequence> pitti: Thanks!
[11:45] <rbasak> Answer: CFLAGS and DEB_BUILD_OPTIONS=nostrip did the trick.
[13:42] <rbasak> cjwatson: could you add src:libvirt-python to the server packageset, please?
[13:46] <cjwatson> rbasak: I no longer have the power.  Ask the DMB
[13:47] <rbasak> Oh, OK. Will any DMB member do? Or do I need to ask the DMB formally?
[13:48] <cjwatson> Probably just any member.  But I also haven't properly handed over the scripts yet (was planning to sort that out with somebody next week) so you might need to mail them.
[13:48] <cjwatson> i.e. they won't yet have anything they can commit the exception to
[13:48] <xnox> rbasak: people email devel-permissions mailing to add packages to packagesets. (spotted those in the past for like input-methods packageset, and others)
[13:49] <xnox> list.
[13:49] <cjwatson> xnox: the autogenerated packagesets are special.
[13:49] <cjwatson> not part of the same process
[13:49] <xnox> cjwatson: oh.
[13:50] <rbasak> I'll email the DMB seeing as it sounds non-trivial. Thanks!
[13:55] <dholbach> @pilot in
[14:08] <jamespage> rbasak: I thought the server packageset was automagically generated
[14:09] <cjwatson> jamespage: it is, there's a list of exceptions
[14:09] <rbasak> jamespage: it is, but AIUI if other seeds also pull in server packages, then the packages don't get attributed to server, and thus don't end up in the packageset. Or something like that.
[14:09] <cjwatson> it would probably be best for the DMB to run an auto-refresh first and then see whether the package in question is in a further-in seed than server
[14:10] <cjwatson> s/seed/packageset/
[14:10] <rbasak> I emailed the DMB: https://lists.ubuntu.com/archives/devel-permissions/2014-January/000576.html
[14:11] <rbasak> Many (most?) packages I uploaded hit this issue. I try and ask rather than get every one sponsored - hopefully then future ubuntu-server uploaders won't be affected as much.
[14:18] <markav> Hello, can someone help me. My application (Commericial) on ubuntu software center pending review for a week. given the usual?
[14:19] <ogra_> markav, ask in #ubuntu-app-devel
[14:19] <markav> thx
[15:24] <seb128> hum
[15:24] <seb128> https://launchpadlibrarian.net/163197609/upload_5491603_log.txt
[15:24] <seb128> does anyone knows what happened there?
[15:24] <seb128> libreoffice build failed to upload on i386
[15:24] <seb128> is there a way to retry upload or do we need to retry a full build?
[15:29] <cjwatson> seb128: it's transient bad luck, I'm afraid you have to retry
[15:29] <cjwatson> the whole thing
[15:29] <seb128> cjwatson, ok, thanks :/
[15:30] <cjwatson> sometimes the librarian server fails to respond properly, I don't know why
[15:30] <seb128> sorry for the buildd DoS people ;-)
[15:30] <cjwatson> AIUI that's basically "Server said: <EOF>"
[15:30] <cjwatson> we're not short of x86 buildd resources at the moment
[15:33] <seb128> good
[16:32] <mdeslaur> doko: mind if I merge nss?
[16:32] <doko> mdeslaur, not at all
[16:33] <mdeslaur> doko: thanks
[16:44] <xnox> ChickenCutlass: cmake in trusty is now fixed again, and correct cross-compiler is used. So powerd now can cross-compile, sans 's/python/python:any/' change.
[16:46] <ChickenCutlass> xnox, fantastic, thanks
[16:47] <xnox> ChickenCutlass: https://code.launchpad.net/~xnox/powerd/ftxbfs/+merge/202891
[16:47] <jodh> xnox: can we now safely re-enable abi-compliance-checker for upstart?
[16:48] <ChickenCutlass> xnox, great
[16:49] <xnox> jodh: once it propagates from debian -> trusty, yeah
[16:50] <jodh> xnox: what version do we require then? the changelog suggests 1.99.8-1 would work?
[16:55] <dholbach> more sponsoring tomorrow
[16:55] <dholbach> @pilot out
[16:56] <juliank> doko: I'm wondering why you changed the apt package to install the APT binary. I mean, it was not an oversight not to include it in the package.
[16:59] <doko> juliank, talked with mvo about it. should go in before ff
[17:00] <juliank> doko: OK, thanks.
[18:05] <jtaylor> I found a fun way to break your amd64 system today: apt-get install libc6-amd64; apt-get remove libc6-amd64
[18:05] <jtaylor> no more lib64/ld.so = broken system
[18:07] <Laney> known
[18:07] <jtaylor> k, didn't find a bug in lp
[18:08] <Laney> I was under the impression that it was fixed
[18:08] <Laney> I only know of https://wiki.ubuntu.com/Touch/Emulator#A.2BAC8.21.2BAFw_If_you_are_on_amd64
[18:08] <jtaylor> I still can reproduce it on trusty
[18:08] <jtaylor> chroot works fine
[18:09] <jtaylor> to reproduce it
[18:10] <xnox> jtaylor: yes, it is known.
[18:11] <xnox> Laney: no it wasn't fixed, it's just emulator was taught to not have libc6-amd64 dependency.
[18:11] <Laney> yeah I see
[18:11] <xnox> jtaylor: the bug is against libc6 in debian I believe, as it affects it there as well.
[18:11] <Laney> didn't really follow it
[19:24] <Noskcaj> Can someone please sync weather-plugin for bug 1244629 ?
[19:25] <Noskcaj> It needs to be fixed in time for the point release of precise
[19:38] <brendand> hi, we want to replace the checkbox-qt package with checkbox-gui which will provide the same functionality, but with a different implementation. does this in any way affect the process to get checkbox-gui into universe or do we need to follow the same process?
[19:38] <brendand> replace as in dpkg Replaces: checkbox-qt
[20:23] <tedg> So I'm having some trouble trying to get some Python bindings into a package.
[20:24] <tedg> The branch I'm trying to do is here: https://code.launchpad.net/~ted/+recipe/babeltrace-daily-python
[20:24] <tedg> But it's causing stuff to be put in site-packages
[20:24] <tedg> and it seems like I need dist-packages?
[20:24] <tedg> Oops, that's not the branch :-)
[20:24] <tedg> https://code.launchpad.net/~ted/babeltrace/python-binding-packaging
[20:41] <kentb> can I get someone to review and sponsor a fix for:  https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059?
[20:42] <infinity> kentb: Versioning the build-dep isn't really necessary.
[20:43] <kentb> infinity: ok. I can change that.
[20:43] <infinity> Might also be nice to know *why* the ABI broke for libopenwsman1 before just blindly rebuilding things, but meh...
[20:43] <Noskcaj> infinity, Is s-p-u enough to sync xfce4-weather-plugin? bug 1244629
[20:44] <Noskcaj> I've found a few people willing to test
[20:45] <infinity> Noskcaj: Looks like we don't import proposed-updates.
[20:45] <Noskcaj> ok. Should i make a merge now instead?
[20:45] <infinity> kentb: Generally, when you've broken ABI in a library, you've done something wrong...
[20:46] <kentb> infinity: anything I can read over that'll help me root that out or figure out what got busted?
[20:47] <infinity> kentb: http://paste.ubuntu.com/6804964/
[20:47] <infinity> kentb: What's busted is that you should have changed the package name to libopenwsman2
[20:48] <kentb> infinity: ok. got it. thank you.  so the 'right' way would be to fix that in libopenwsman then also change the build dep in wsmancli?
[20:48] <infinity> kentb: *then* the rdeps need no-change rebuilds to depend on the newer package.  But at least you could then have done it without panicking. ;)
[20:49] <infinity> kentb: No need to change the build-dep.
[20:50] <kentb> infinity: ok. so I'll fix openwsman then
[20:50] <kentb> err libopenwsman
[20:50] <infinity> kentb: Don't forget to update all the references in the openwsman packaging too.
[20:51] <kentb> ok
[20:52] <infinity> kentb: And to smooth upgrades over your breakage, you might want libopenwsman2 to "Replaces: libopenwsman1 (= 2.4.3-0ubuntu1)"
[20:52] <infinity> kentb: Which you can drop later in the cycle, or in 14.10.
[20:52] <infinity> (That wouldn't have been necessary without the screwup, since lib1 and lib2 shouldn't actually have file overlaps, ever...)
[20:58] <mwhudson> soo
[20:58] <mwhudson> after x does that "eating the font bitmap cache" thing
[20:58] <mwhudson> is there a way to reset it short of restarting?
[21:00] <kentb> infinity: ok. just to make sure it's 1) fix the package name 2) add the "replaces" line 3) all references in the control file to libopenwsman1 need to be changed.  is that right?
[21:01] <infinity> kentb: Should do.  You'll need to rename debian/libfoo1.* to libfoo2.*
[21:02] <infinity> mwhudson: "Have you tried turning it off and on again?"
[21:02] <dobey> anyone have any recommendations for how to use multiple build systems during the same build in debian/rules? have a project that is transitioning from autotools to cmake, and now i need to install some stuff with cmake. i already have overrides for configure/build/test to make sure the new cmake bits and new code don't break, but just doing "make install" doesn't seem like it'll cut it
[21:02] <infinity> dobey: Override dh_auto_install too?
[21:02] <kentb> infinity: alright. I'll cook that up now.
[21:03] <dobey> infinity: right. but i'm not sure what to use for the "make install" itself
[21:03] <dobey> because if i just do "make install" it'll try to install to /usr/local or something i guess
[21:03] <infinity> dobey: Well, hard to say without a lot more context, I guess.
[21:03] <dobey> hrmm, i guess i need to fix the configure state too, to use the right prefix
[21:04] <infinity> dobey: In theory, your configure (or whatever) should be setting DESTDIR.
[21:04] <infinity> (Or doing whatever prefixy things make install needs)
[21:05] <dobey> infinity: https://bazaar.launchpad.net/~ubuntuone-hackers/unity-scope-click/trunk/view/head:/debian/rules is what i currently have
[21:17] <dobey> infinity: or alternatively, is it possible to do "(cd build && dh_auto_configure --buildsystem cmake)" ? or does dh require running cmake in the source tree?
[21:21] <infinity> dobey: dh generally expects to be running in the parent of debian/
[21:31] <Laney> there's a --builddirectory option that might be your thing
[21:32] <Laney> Haven't used it myself
[21:33] <dobey> i think i have something that should work now
[21:33] <jtaylor> can someone provide me with a backtrace of the numpy python-dbg testsuite failure on ppc64el?
[21:34] <jtaylor> I'm willing to debug it but don't have the nerve now for running qemu (if that even works)
[21:34] <Laney> dh_auto_* --builddir=build
[21:34] <Laney> directory, ykwim
[21:51] <kentb> infinity: here's what I got for openwsman...anything else?:  http://people.canonical.com/~kentb/openwsman.debdiff
[21:53] <infinity> kentb: Looks good.
[21:54] <kentb> infinity: ok. thanks. I'll flie a separate bug for that and fix the changelog for wsmancli to just say 'no-change rebuild
[21:54] <infinity> kentb: Could just track them all on the same bug.
[21:55] <kentb> infinity: ok. will do that then
[21:55] <infinity> kentb: If you need a sponsor, I can do them all in a bit.
[21:55] <kentb> infinity: ok. if you would, please.  I'll let you know when ready.
[22:06] <kentb> infinity: ok. debdiffs are uploaded.
[22:06] <infinity> kentb: Refresh my memory on the bug number?  I'll review and sponsor those right now before I get distracted.
[22:06] <infinity> Well, I'll sponsor the library one, and wait until it's built, and do the other. :P
[22:07] <kentb> infinity: thanks, it's https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059
[22:07] <infinity> kentb: Ta.
[22:08] <infinity> kentb: A no-change rebuild probably shouldn't bump standards-version.  I'll revert that. ;)
[22:09] <kentb> infinity: whoops, you're right
[22:15] <infinity> kentb: Oh, hrm, I should have looked closer.  This ships multiple libraries in one package, and only one bumped SOVER.  Ick.
[22:15] <infinity> kentb: This really should be split.
[22:16] <kentb> infinity: ok. so new bug and I guess the other stuff with a "1" in the name should be converted over?
[22:17] <infinity> kentb: Yeah, looking at this, libopenwsman1 (or 2) shouldn't exist at all.
[22:18] <infinity> kentb: All those libs should be broken out to libwsman1, libwsman-client1, etc.
[22:18] <infinity> Err, client2
[22:18] <infinity> kentb: You can still have one bit -dev package that depends on all of the little libs, though.
[22:18] <infinity> kentb: But shipping all the libs together is a recipe for disaster if upstream doesn't bump SOVER on all of them together.
[22:19] <infinity> s/one bit/one big/
[22:19] <infinity> Glad I did a test build and looked at the output, I guess.
[22:22] <kentb> infinity: lovely...ok. so what did you see in the output that allowed you to catch that?
[22:24] <infinity> kentb: I just looked at the package contents listing vomit at the end of sbuild.
[22:24] <infinity> kentb: "less foo.deb" would have worked as well.
[22:24] <infinity> kentb: But, basically, a bunch of libraries in a single package is generally only sane if you have an upstream guarantee that they'll always have lockstep SONAMEs.
[22:25] <infinity> (Or if you're libc, and get to be a unique snowflake about the dynamic linker)
[22:25]  * Snow-Man is a whole collection of unique snowflakes.
[22:25] <infinity> Snow-Man: Do you highlight on "snow"?
[22:26] <Snow-Man> maybe?
[22:26] <Snow-Man> :D
[22:26] <slangasek> he highlights on infinity; he's your Internet Friend
[22:26] <Snow-Man> hahaha
[22:26] <infinity> Overly-attached Snow-Man?
[22:27] <infinity> Also, it's that time of year again: http://www.youtube.com/watch?v=LDWJn3IwiaM
[22:27] <teward> anyone seen xnox or knows when they'll be alive?
[22:28] <Snow-Man> I love that when she says 'blood is red' the advertisment that came up was 'PHP'
[22:28] <Snow-Man> … followed by 'JAVA'
[22:28] <infinity> Snow-Man: PHP is the blood, Java's the bruises?
[22:29] <infinity> teward: He's on London time, so probably escaped work hours ago.
[22:30] <teward> infinity: ah, i see.  meh, he's got enough pings elsewhere, he'll probably see them when he connects.
[22:31] <Snow-Man> infinity: that's certainly been my experience..
[22:40] <kentb> infinity: so, pretty much anything with a unique library name under /usr/lib needs a package?
[22:43] <slangasek> kentb: unless there's some very specific reason to believe the sonames will change in lockstep, yes
[22:43] <kentb> slangasek: ok. got it. I'll work on this tonight, then and then have someone review it tomorrow