[06:53] <dholbach> good morning
[08:10] <ev> wgrant: woo! After the fix for bug 1179329 goes live, is there a further switch that gets flipped to enable ddebs in the librarian?
[08:10] <ev> thanks again for all the hard work on this
[08:10] <ev> quite excited
[08:10] <wgrant> ev: Just need an ubuntu-archive-tools change landed and a really thorough QA session tomorrow and then we can go live
[08:11] <wgrant> I QAed things fairly roughly on DF today and found no bugs, but I want to be a bit more thorough before I break the world :)
[08:24] <infinity> wgrant: And we need to get together with pitti and fix up ddebs-retriever.
[08:25] <ev> yay!
[08:26] <infinity> wgrant: When we flip this switch, are we just changing the flags passed to sbuild, so it does the same thing as PPAs with ddebs enabled, and we can tear out the copy-to-public_html code later?
[08:26] <infinity> wgrant: Cause the smoother cutover would be to publish to both .changes and public_html and then let pitti fix his tools.
[08:26] <infinity> wgrant: (Which was what we did with translations, long ago)
[08:27] <infinity> wgrant: Though, I guess if there's a brief period where his tool breaks, it's not world-ending, at least they won't expire from the librarian, so nothing will be lost, just delayed.
[08:30] <infinity> wgrant: Anyhow, I guess we'll talk about it when pitti's around.
[08:33] <wgrant> infinity: Yes, it will publish to both AFAICR
[08:33] <wgrant> But I wrote that code in like 2009, so I'll need to check
[08:35] <infinity> wgrant: Oh, yeah, just looked, the ddeb stuff in sbuild isn't wrapped in an if.
[08:37] <infinity> wgrant: In fact, we're still publishing translations to public_html too.  Lolz.
[08:37] <infinity> wgrant: So, yeah, once we soft-transition ddebs, I'll tear all that code out.
[08:38] <wgrant> infinity: Yes, I didn't bother ripping out the translations code because I was going to rip out ddebs soon
[08:38] <wgrant> And do them at the same time :)
[08:38] <wgrant> 4 years ago
[08:38] <infinity> wgrant: Yeah, well all have curious definitions of "soon" around here. ;)
[08:39] <wgrant> ddebs were also one of the main blockers for the sbuild upgrade, too
[08:39] <infinity> wgrant: I suspect that was my reasoning too.
[08:39] <infinity> wgrant: I might revisit the sbuild upgrade thing once this is all landed.
[08:40] <wgrant> I have branches from 3 years ago that worked
[08:40] <wgrant> But sbuild has been split into a thousand pieces since then.
[08:40] <wgrant> So I'm not sure how relevant they are
[08:40] <infinity> wgrant: I'm still not entirely comfy with replacing the devil we know, but I do like the idea of buildd and developer machine behaviour being closer.
[08:41] <wgrant> https://code.launchpad.net/~wgrant/launchpad/use-system-sbuild and https://code.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result were my old branches
[08:41] <infinity> wgrant: Yeah, I think I had those checked out before the Great Backup Fire of Earlier This Year.
[08:41] <wgrant> infinity: Once we turn on ddebs, people will also need to be prepared to fix issues like IIRC systemd that you ran into in Oakland
[08:42] <wgrant> Producing ddebs without a corresponding deb
[08:42] <wgrant> But they should all be pretty trivial to fix as they are uncovered.
[08:42] <infinity> wgrant: use-system-sbuild (well, the name of the branch) is probably optimistic anyway.  We'll likely have to maintain a separate branch like Debian does.
[08:42] <wgrant> infinity: Yeah, but I hope it can at least be out of tree.
[08:42] <infinity> wgrant: I imagine that systemd bug isn't something that will pop up often, but we'll see. :)
[08:43] <infinity> wgrant: And a few of us know the cause, so fixing it shouldn't be a big deal.
[08:43] <wgrant> Yeah
[08:44] <infinity> I will miss the old sbuild when we get around to upgrading.  It may be a mess, but it's a mess I know inside-out.
[08:44] <wgrant> It's a much simpler mess than the new one.
[08:44] <infinity> I'm a committer to the new schroot and sbuild, and I've barely scratched the surface on those.
[09:15] <infinity> -set_target_properties(poppler PROPERTIES VERSION 28.0.0 SOVERSION 28)
[09:15] <infinity> +set_target_properties(poppler PROPERTIES VERSION 37.0.0 SOVERSION 37)
[09:15] <infinity> Dear poppler upstream: Double-U Tee Eff.
[09:16] <infinity> apw: Say, when are you doing some +1 for me this cycle?  I might have a poppler transition for you. :P
[09:16] <Laney> seb128 is handling it
[09:16] <infinity> Laney: That works for me too.
[09:16] <Laney> eds is coming soon too. The two best transitions.
[09:16] <infinity> Laney: I just wanted to give apw flashbacks to his previous poppler transitions.
[09:17] <infinity> Laney: eds doesn't usually mangle the API as badly, IME.
[09:17] <infinity> Laney: poppler seems to need porting every second upload, not just rebuilding.
[09:17] <Laney> apparently this poppler one is free of porting too
[09:17] <infinity> Oh, then no big deal.
[09:18] <infinity> But man, that's some SOVER bump.
[09:18] <infinity> I'm beginning to wonder if they just rev it every week even if nothing's changed in the tree.
[09:19] <Laney> There was some argument recently about how it's actually a private lib and other things are naughty for using it
[09:19] <infinity> ...
[09:19] <infinity> Given the countless things we link to it, that seems a bit laughable.
[09:19] <seb128> -glib and -qt are meant to be the public apis
[09:19] <Laney> Well, yes
[09:20] <infinity> Oh, actually, I guess we don't link THAT many things to it directly.
[09:23] <apw> infinity, you are a sick sick man :)
[09:24] <infinity> apw: I've been called much worse.
[09:27] <asac> saucy kernel broke my computer :)
[09:27] <asac> going back to last 3.8 that is instlaled makes it boot
[09:27] <asac> apw: ?
[09:27] <asac> known?
[09:28] <asac> with 3.9 basically nothing happens after grub ... even with quiet and splash removed
[09:29] <seb128> infinity, btw any chance that you or somebody from the sru team would review the unity stack SRU which is waiting for 3 weeks in the raring queue?
[09:30] <infinity> seb128: Yeah, I promised Mirv I'd look at it.  Will get that done tomorrow.
[09:30] <seb128> infinity, thanks
[09:31] <infinity> asac: WFM.  Try the usual reinstalling and such (ie: blame your hard drive)?
[09:31] <seb128> I'm using 3.9.0-3 without issue here
[09:32] <asac> hmmm. have 3.9.0-2 if i parse dpkg -l correctly
[09:34] <asac> heh ... ok seems half of the dist-upgrade didnt finish before i shut downthe computer :) - might be one reason
[09:34] <seb128> lol
[09:34] <asac> ok now i have an initrd :)
[09:34] <asac> let me try
[09:36] <asac> infinity: seb128: thx :)
[09:36] <seb128> asac, yw ;-)
[09:46] <geser> barry: thanks for sponsoring the python-json-pointer fix. Now python-json-patch needs the same fix too (#1185739 if you have time)
[10:12] <Mirv> asac: I've seen a real life situation (on precise) as well where battery run out in the middle of upgrade, and no initrd. would be nice to have auto-try-older-kernel feature.
[10:13] <asac> yeah
[10:13] <asac> well... i wonder why the grub picks stuff up before its finished
[10:13] <asac> guess maybe its doing the initrd before putting the vmnlinux in place
[10:13] <asac> so if it doesnt finish its not seen
[10:24] <seb128> shrug
[10:24] <seb128> what's the best way to check that binaries are published/available to the builders?
[10:25] <xnox> seb128: rmadison $packagename
[10:25] <seb128> I watched the poppler binaries on the launchpad page for the upload to have their (Accepted) status dropped, but that was not enough apparently
[10:26] <seb128> xnox,    poppler | 0.22.4-0ubuntu1 | saucy-proposed | source
[10:26] <cjwatson> Accepted status dropped + publisher run finished
[10:26] <seb128> yet the builders picked 0.20
[10:26] <cjwatson> rmadison -S $packagename
[10:26] <cjwatson> source of build-dependencies is of no interest to the builders :)
[10:27] <mitya57> seb128: the LP page says they are still in -proposed
[10:27] <cjwatson> mitya57: that doesn't matter
[10:27] <seb128> mitya57, no, they are not yet in proposed (which is my issue)
[10:27] <seb128> cjwatson, thanks, that doesn't list the new binaries, I guess the publisher is not done running then
[10:27] <cjwatson> seb128: you MUST wait for the publisher run to finish; rmadison -S and look for the *binaries* is a slightly conservative way to check that
[10:28] <cjwatson> it's typically no more than about five minutes out of date
[10:28] <seb128> cjwatson, I (wrongly) assumed that launchpad's drop of "(Accepted)" would mean that ... thanks ;-)
[10:28] <cjwatson> no, I'm afraid that means that the publisher run has started
[10:31] <cjwatson> mitya57: (the builders necessarily build from -proposed, otherwise transitions would be impossible)
[10:35] <mitya57> cjwatson: sounds reasonable
[10:58] <chrisccoulson> does anybody want to step up and fix the firefox build failure on ppc that has been blocking the migration from proposed for a couple of weeks now?
[10:58] <chrisccoulson> if not, i'm afraid that i'm just going to turn off the ppc build
[11:05] <cjwatson> chrisccoulson: I can have a go if infinity could turn his porter box back on
[11:12] <chrisccoulson> cjwatson, thanks. although, i think it might be quite a simple fix (i bet http://hg.mozilla.org/mozilla-central/rev/489ab986ea69 would do it, assuming there are no other failures)
[11:14] <cjwatson> I'll start by giving that a try, sure.  Do incremental builds work reasonably?
[11:17] <chrisccoulson> cjwatson, from the packaging? i'm not so sure about that. i generally always work from within a mercurial checkout (http://hg.mozilla.org/releases/mozilla-beta in this case), using patch queues (https://developer.mozilla.org/en/docs/Mercurial_Queues - very similar to using quilt)
[11:31] <zyga> rsalveti: ping
[11:31] <zyga> rsalveti: have you written any `pactl list` parsers in the last three years? maybe while working at linaro?
[11:41]  * zyga breaks for lunch
[11:50] <ogra_`> cjwatson, hmm, with your lightdm upload, what happens on systems where all plymouth jobs are overriden (like ubuntu-touch)
[11:52] <ogra_`> (lightdm is used in the raring tablet version and has all plymouth jobs disabled)
[11:52] <ogra_`> oh, ignore me, thats precise
[12:04] <cjwatson> ogra_`: It wasn't my upload anyway; I just copied it to -updates after SRU verification.
[12:06] <ogra_`> ah
[12:31] <xnox> cjwatson: are you by any chance running cross builder for armhf for saucy with results published publicly? similar to http://people.canonical.com/~cjwatson/cross/armhf/
[12:31] <cjwatson> xnox: Not quite yet, but I have a work item to set it up
[12:31] <cjwatson> Probably next week
[12:32] <xnox> ok. cool. would be interesting to see if packages regress and stop cross-building.
[12:32] <cjwatson> Yes
[14:48] <rsalveti> zyga: hey, no
[14:55] <zyga> rsalveti: hmm
[14:55] <zyga> rsalveti: thanks, I had a deja-vu
[14:55] <rsalveti> :-)
[14:55] <zyga> rsalveti: I was writing some parser and I recalled you having the same issues like I had today
[15:12] <Laney> mardy: hey, I'm packaging eds and evolution 3.8 and was wondering if you could tell me how to test whether the UOA stuff is working
[15:12] <Laney> It looks like it should integrate with google calendar but I can't see how
[15:14] <seb128> Laney, did you try adding a google account to the system settings panel and see if you have your gmail account in evo?
[15:15] <Laney> I have two google accounts in there
[15:15] <Laney> no gmail account either
[15:15] <seb128> and the corresponding gmail account don't show in evo?
[15:15] <seb128> :-(
[15:15] <Laney> it also doesn't say that the accounts will integrate with e-d-s or evolution
[15:16] <Laney> but if I "Show accoutns that integrate with: evolution-data-server" it lists Google and Yahoo
[15:20] <Laney> seb128: mardy: oho, I'd not restarted e-d-s - now it seems good
[15:20] <seb128> great
[15:21] <Laney> right, well I'll start off the transition then
[17:06] <Laney> jamespage: Hey, since you seem to have updated hsqldb (:P), do you think you'd be able to bring hsqldb1.8.0 to saucy?
[17:06] <Laney> The new series apparently breaks libreoffice, so the Debian maintainer forked the package
[17:08] <cjwatson> Hm, how come that wasn't autosynced?
[17:08] <Laney> Don't know, but if I read the hsql changelog correctly it makes Soyuz have some kind of sad.
[17:08] <Laney> hsqldb*
[17:09] <cjwatson> It shouldn't have made it sad at that level
[17:09] <cjwatson> I might be able to tell you more next time I get my six-hourly mail from auto-sync; I typically read them and delete them, so I don't have the last one to hand
[17:09] <cjwatson> s/read/skim/
[17:10] <Laney> Actually, the relevant part of the diff looks trivial so I might just JFDI
[17:10] <Laney> unless you would rather wait and find out?
[17:10] <cjwatson> I'm sort of curious
[17:10] <cjwatson> But feel free to prepare the diff, indeed
[17:11]  * Laney spots a bit of RAS syndrome
[17:21] <cjwatson> It doesn't even mention hsqldb in its output
[17:21] <cjwatson> Hmm
[17:24] <Laney> Will it be out of the way if I upload it to the queue for you/someone to accept at your leisure?
[17:29] <Laney> cjwatson: ^? (got it ready to go)
[17:33] <cjwatson> Laney: one sec
[17:35] <lfaraone> Is there a preferred way for an application to signal to apport "please don't send this sensitive variable in crash reports"?
[17:37] <Laney> cjwatson: seb128: Right, I've got to shoot off. I'll put it on chinstrap signed — please upload when ready.
[17:37] <seb128> Laney, ok, thanks
[17:38] <cjwatson> Ah
[17:38] <cjwatson> [Skipping (not built on any target architecture)] hsqldb1.8.0_1.8.0.10+dfsg-3
[17:39] <cjwatson> Laney,seb128: ^- So that explains it.  On Debian, hsqldb1.8.0 is only needed on kFreeBSD
[17:39] <cjwatson> (which is clear from a close look at http://packages.qa.debian.org/h/hsqldb1.8.0.html)
[17:39] <seb128> hum
[17:39] <Laney> hmm?
[17:39] <cjwatson> So I guess my question is why our LO thinks it's kfreebsd?  Is there something else going on, or was it a mismerge?
[17:39] <infinity> Then why do we want it?
[17:39] <Laney> What about the arch:all package?
[17:39] <seb128> what did they do with libreoffice?
[17:39] <seb128> infinity, libreoffice conflicts with >= 1.8.1
[17:39] <Laney> libhsqldb1.8.0-java
[17:39] <seb128> infinity, see build failure of today's upload
[17:40] <cjwatson> Well, Debian's arch:all packages are built differently, remember; we wouldn't be able to build it that way
[17:40] <infinity> Oh, silly.
[17:40] <seb128> (we tested the build in a ppa on local boxes which didn't have proposed enabled)
[17:41] <seb128> Sweetshark, I think we should go with "use the libreoffice copy", seems the easiest way out
[17:41] <Laney> What way?
[17:41] <infinity> That's arguably a bug/misfeature that we can't build all-only for something that doesn't include i386 in its arch list.  But the simple solution is a small delta that excludes the freebsd binaries.
[17:41] <Laney> The maintainer uploaded just the _all package - that's what we'd do.
[17:41] <Laney> Anyway. Doing.
[17:41] <cjwatson> Hm, does that actually work in Soyuz?  If so, feel free.
[17:41] <infinity> Laney: No, that doesn't work for us, see above.
[17:41] <cjwatson> I'm not sure.  auto-sync excludes such cases, but I didn't really think too hard about the "other arches + all" case.
[17:42] <infinity> If the arch list is all+something_we_don't_build, we skip it.  A bug, to be sure, but there it is.
[17:42] <cjwatson> seb128,Sweetshark: Well, if we can work around this in a small package, I'd rather do that than changing libreoffice.
[17:42] <infinity> It has to be either all, all+any, or all+i386
[17:42] <infinity> Anyhow, the work around is simple.  Drop the freebsd packages from debian/control, and the source becomes all-only.
[17:43] <cjwatson> Yeah.
[17:43] <Laney> yes, I have the package ready. The solution is well-known. :-)
[17:43] <Laney> (.)
[17:43] <cjwatson> Oh.  Indeed, that's what was done in hsqldb.
[17:43] <cjwatson> Fine, now I understand :)
[17:43] <infinity> I should fix that bug, though.
[17:43] <cjwatson> So yeah, go ahead and upload hsqldb1.8.0
[17:44] <infinity> I wonder if it was an intentional behaviour, under the assumption that "all+weirdarch" would mean that we'd only want to ship foo-all.deb if we also had $weirdarch.
[17:44] <Laney> yeah, done - now just get the LO build-dep/build-conflicts change uploaded and it can build overnight
[17:44] <infinity> Which, actually, is a pretty fair assumption.  Maybe it's not a bug, but just a misfeature in this corner case.
[17:45]  * Laney goes away
[17:45] <Sweetshark> cjwatson,seb128: yes, my order of preference is: a/ upload 1.8 package b/ use internal copy c/ hack libreoffice and hope it works against the new version (BAD IDEA)
[17:45] <seb128> Sweetshark, seems like debian went for a/ and that's what we will do as well
[17:45] <cjwatson> infinity: I would argue misfeature-in-corner-case, I think.
[17:46] <infinity> cjwatson: Of course, it *is* a bug that we can't build armhf+all or powerpc+all.
[17:47] <Sweetshark> seb128: yep, thanks.
[17:47] <infinity> cjwatson: (Well, we can, but we seem to fail to create the build records... See how linux-ppc in raring never had a build record on i386 until I ran create-missing-builds in saucy and it got one)
[17:47] <infinity> cjwatson: So, that's curious.
[17:48] <infinity> cjwatson: (A bug in linux-ppc that it claims to build arch:all packages anyway, but it illustrates the point)
[17:49] <cjwatson> infinity: I'd say this is also related to the historical lack of support for build-arch/build-indep
[17:52] <infinity> cjwatson: Goes deeper than that.  I wouldn't try to fix this until we fix arch:all affinity as well.
[17:53] <infinity> cjwatson: Currently, we only create the record if it's all-only or all+(some set that includes i386), and that seems fair because a hypothetical armhf+all *could* rely on the armhf binaries in the build tree to make the all package.
[17:54] <infinity> cjwatson: So, until we can build those all debs on the armhf builder it's likely fair to assume that we can't just throw an i386 build record out for it and hope.
[18:33] <stgraber> ScottK: ping
[18:33] <ScottK> stgraber: pong.
[18:34] <stgraber> ScottK: would Kubuntu be interested in using the new upstart user sessions?
[18:36] <ScottK> Maybe.
[18:36] <ScottK> What's invovled?
[18:36] <stgraber> ScottK: one file in /usr/share/upstart/sessions and one extra line in /etc/upstart-xsessions
[18:36] <stgraber> ScottK: I did a quick test with today's daily build of Kubuntu and it appears to work properly
[18:37] <stgraber> ScottK: dump http://paste.ubuntu.com/5717639/ into /usr/share/upstart/sessions/startkde.conf and add "kde-plasma" to /etc/upstart-xsessions
[18:37] <stgraber> ScottK: then all you have to do is logout and log back in to have the session run under upstart
[18:39] <stgraber> ScottK: the next steps would be to include that upstart job in kde-workspace-bin, have people test it by manually editing their /etc/upstart-xessions and if they don't find any regression, then we can add it by default
[18:40] <stgraber> Laney and I did an archive wide scan for possible regressions (packages shipping Xsession scripts altering the STARTUP variable) and I believe we now added upstart jobs for all of those, so in theory this should be regression free and let you use the same extra features as Ubuntu Desktop (starting stuff depending on hardware events or system events mostly)
[18:41] <stgraber> the main reason I'm looking into making this work for all our supported desktop environments is that xnox showed some interest in moving ubiquity from a system upstart job to a userjob, so if we don't want to end up duplicating the work on ubiquity's side, it'd be best if everyone was using the user sessions
[18:42]  * stgraber stops talking ;)
[18:48] <ScottK> stgraber: Sorry, got pulled onto the phone.
[18:48] <ScottK> Back now.
[18:48] <ScottK> I'd say it's something we ought to try.
[18:49] <stgraber> ScottK: want me to commit that upstart job to the kde-workspace bzr branch or do you want to test it more yourself before that?
[18:49] <ScottK> Go for it.
[18:50] <ScottK> Feel free to upload it, then we can do a call for testing.
[18:55] <xnox> \o/ awesome =)
[19:19] <stgraber> ScottK: gah, I forgot how long and painful (for my CPU) a kde-workspace build is ;)
[19:20] <stgraber> ScottK: I was hoping for a "quick" test build to check that I didn't mess up that extra dh_install override...
[19:21] <ScottK> :-)
[20:27] <stgraber> ScottK: doh, didn't notice that the packaging branch was out of date...
[20:28] <stgraber> yofel: you forgot to commit 4:4.10.3-0ubuntu3 to the kde-workspace bzr branch
[20:28] <stgraber> fixing that now and then uploading ubuntu4
[20:29] <stgraber> yofel: or not, ignore me
[20:29] <yofel> heh, I was just wondering ^^
[20:29] <yofel> np
[21:08] <slangasek> stgraber: hey, why does this nfs-utils merge have a tree full of binaries in it?
[21:08] <stgraber> slangasek: that's a good question
[21:09] <slangasek> they seem to have come by way of the Debian branch
[21:09] <slangasek> let's see if they're in the upstream tarball (ugh)
[21:09] <stgraber> slangasek: right, just checked, not my fault, it's coming from Debian
[21:10] <slangasek> in the upstream tarball, in fact
[21:10] <slangasek> cute
[21:11] <stgraber> nice
[21:11] <stgraber> surprising the Debian maintainer didn't notice. I only looked at the Debian/Ubuntu delta, but would have expected the Debian maintainer to notice a bunch of binaries showing up when merging the new upstream :)
[21:13] <stgraber> so I guess that means we'll see a dfsg-ized source package show up in Debian pretty soon or a new upstream release (if upstream is re-active enough)
[21:15] <slangasek> stgraber: well, I guess that all of the binaries included can be built from the provided source using the Debian toolchain, so strictly speaking I'm not sure we have to repack to strip them
[21:16] <stgraber> hmm, true, we know the package builds and changes are that those binaries are for the same version as the source, so in theory that's fine
[21:17] <slangasek> it did more than triple the size of the orig.tar.bz2, but I guess no one cared about that :)
[21:19] <stgraber> surprisingly enough that same source has been packaged in a bunch of other distros and I can't see any bug report ;) only report I can find of the tarball containing binaries is lintian.debian.net
[22:37] <slangasek> stgraber: ok, so after upgrade, all NFS operations are erroring out with 'Broken pipe'
[22:37] <slangasek> stgraber: only the kerberized ones
[22:38] <slangasek> stgraber: oh, there we are; gssd is segfaulting
[22:40] <stgraber> slangasek: fun... let me see if we do any custom patching of gssd
[22:41] <stgraber> slangasek: nothing that Debian doesn't ship as well, weird
[22:41] <slangasek> stgraber: IIRC, Luk also does not have kerberos set up to test this
[22:47] <stgraber> slangasek: can you easily test this on Debian to confirm it's broken there too?
[22:49] <slangasek> stgraber: not very easily, but I can rig something up tonight.  In the meantime, let me see about a backtrace
[23:00] <slangasek> stgraber: http://paste.ubuntu.com/5718290/
[23:01] <slangasek> stgraber: so the actual segfault happens down in libgssglue, by the look of things
[23:06] <guenther> ScottK: around?
[23:09] <cjwatson> Laney: So, I just made deduplicate-packages about 40 times as fast
[23:09] <cjwatson> Laney: http://paste.ubuntu.com/5718309/
[23:09] <cjwatson> Laney: That takes it from about 3.5 minutes to about five seconds
[23:11] <cjwatson> deb822 is *slow* on files that size :)
[23:12] <cjwatson> (the effective encode/decode in the write there is probably unnecessary, but at this point I couldn't be bothered optimising further)
[23:51] <slangasek> stgraber: ok, looks like it's probably a bug with limit_krb5_enctypes; I haven't pinned it down just yet, but that seems to be the function that's returning the bogus cred struct
[23:52] <stgraber> and that didn't happen with the old gsssd?
[23:57] <slangasek> stgraber: no