[00:28] <slangasek> xnox: perhaps you have some idea why apt consistently segfaults for me in trusty, even after I downgrade to the version before your no-change rebuild? (bug #1249137)
[00:28] <ubot2> Launchpad bug 1249137 in apt (Ubuntu) "apt-cache crashed with SIGSEGV in pkgRecords::Lookup()" [Undecided,New] https://launchpad.net/bugs/1249137
[00:53] <infinity> slangasek: Back up /var/lib/apt/lists and wipe it out and see if you can reproduce?
[00:53] <slangasek> I believe I did that once already, but let's see
[00:55] <slangasek> still reproducible
[00:55] <infinity> And perhaps more interestingly, throw your sources.list in a chroot and see if you can reproduce there too, cause then it might be huntable.
[00:55] <infinity> (Or include it in the bug report, at least)
[03:10] <xnox> slangasek: I guess "apt-cache stats" is also crashing for you? it's crashing where it's doing a jump to within a package iterator.
[03:10] <slangasek> xnox: no, that doesn't crash
[03:11] <xnox> hm.
[03:12] <xnox> It would point to malformed cache, e.g. a package without Description.
[03:12] <slangasek> curious
[03:15] <xnox> slangasek: apt-cache pkgnames | xargs apt-cache showpkg
[03:15] <xnox> should iterate all of them and hopefully point out a broken one, if there is one.
[03:16] <xnox> albeit that also doesn't do jump to description, hm.
[03:16] <slangasek> perhaps xargs -n1 ?
[03:16] <xnox> it takes .....
[03:16] <xnox> it doesn't have to be one by one.
[03:17] <slangasek> sure, but how will I know which package broke it if it breaks before it displays the package?
[03:17] <xnox> =)
[03:17] <xnox> ok.
[03:17] <xnox> it all works here for me....
[03:18] <slangasek> well, 'showpkg' didn't fail, at least
[03:19] <slangasek> afk for a bit
[03:19] <slangasek>  process and file security contexts and tE: Handler silently failed
[03:19] <slangasek> that's more fun
[03:20] <slangasek> still afk, though
[03:22] <xnox> =/
[03:23] <xnox> the other option is to add more validation / prints to the iterator used. And e.g. make it skip a record.
[03:27] <xnox> slangasek: big data tells me you are not alone.
[03:27] <xnox> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/869348
[03:27] <ubot2> xnox: Error: launchpad bug 869348 not found
[03:27] <xnox> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/970729
[03:27] <ubot2> xnox: Error: launchpad bug 970729 not found
[03:27] <xnox> https://errors.ubuntu.com/?package=apt&period=month
[03:32] <xnox> slangasek: it's a pre-existing condition, not covered by TIL care plan =)
[03:33] <xnox> but i'll look into it. about ~1 000 crashes submitted.
[03:35] <xnox> slangasek: you can wipe sudo rm -i /var/cache/apt/*.bin and check if that helps or not.
[03:37] <xnox> rm -i /var/cache/apt/*.bin && apt-cache gencaches
[04:00] <rbasak> infinity: ^^ thanks! For the other releases, do we just need to upload suitably versioned backports to NEW those, too?
[04:00] <rbasak> utlemming: ^^
[04:19] <infinity> rbasak: Yeah.  Though, ideally, only after my last comments on the bug are addressed. :P
[04:19] <infinity> rbasak: (Feel free to do that yourself, if you like)
[04:19] <rbasak> infinity: ack
[04:19] <infinity> Oh, except that Ben copyrighted the packaging to himself so, technically, only he can relicense it...
[04:19] <infinity> (That really should be (c) Canonical, if he's doing this on work time)
[04:20] <rbasak> I noticed that but I left it
[04:20] <rbasak> The difficult with upstream taking patches didn't occur to me.
[04:23] <infinity> rbasak: It's a non-issue if the person patching the package takes care to explicitly license the patches, but that's hardly in the spirit of ease of collaboration, IMO.
[04:24] <infinity> rbasak: Package licensing matching upstream just means you can forget about the mess and people can pick and choose what they want.
[04:25] <infinity> (There could be rare occasions where you intentionally want your packaging under a specific license, but in the case of this package, 99% of the packaging is non-copyrightable fluff anyway, and the patches would be the only bits that would be interesting..)
[04:25] <rbasak> infinity: agreed. Though if I were being facetious, I'd use a debian/patches/* entry in debian/copyright :-P
[04:25] <infinity> rbasak: Sure, that would be the valid way to go if you wanted "my cool packaging scripts are GPL-2 and I don't want you abusing them, but my patches match upstream's WTF license".
[04:25] <infinity> But there's nothing cool in this debian/* :)
[04:26] <rbasak> Yeah I figure "same as upstream" licensing makes sense for debian/*
[04:30] <infinity> rbasak: Anyhow, if you want to tidy up some of the bits in my points 1 through 6 instead of waiting for Ben to get to it, that won't hurt my feelings.
[04:31] <infinity> rbasak: Cause, as a sponsor, it's totally your responsibility what you upload. :P
[04:37] <rbasak> infinity: I'll make sure they get done. But I'd like utlemming's response first. I think he's eager to fix it all up anyway, as he wants this in Debian too.
[09:13] <Laney> Mmm, yeah, I'm getting that segfault too, interesting
[09:13] <Laney> Only inside my trusty container, mind
[09:18] <Laney> And now it's disappeared after an apt update
[09:18] <Laney> apt-get update
[11:01] <cjwatson> slangasek: 1242417> the kubuntu-settings change that triggered that was introduced in raring, so it should probably be included back to there
[11:02] <cjwatson> (which raises the question of why people only complained about that as of saucy ...)
[11:04] <cjwatson> infinity: maybe I should finish my grand maintenance-check refactoring if I decide I can't face anything else today ...
[11:20] <tkamppeter> Hi, CUPS 1.7.0 final got released, Saucy has 1.7rc1 plus a patch with many changes of 1.7.0. Remaining changes to the final are several bug fixes, modifying around 500 code lines. Can we put this onto Saucy? And if so, how should I proceed?
[11:23] <rbasak> tkamppeter: are you familiar with https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases ? This might help you.
[11:24] <tkamppeter> rbasak, thanks, will look into this.
[16:34] <slangasek> xnox: wiping /var/cache/apt/*.bin did not help, no :)
[16:35] <xnox> slangasek: sigh...
[16:46] <slangasek> cjwatson: kubuntu-settings> back to raring and no further?  It would be easiest to just include it all the way back to precise
[16:47] <cjwatson> it won't hurt to pull it back further, if it's easier
[16:53]  * cjwatson goes back and does a bunch of elderly Debian-reflecting removals
[16:53]  * slangasek grins
[16:53] <cjwatson> Some really crusty stuff in here
[16:53] <cjwatson> Satisfying though :-)
[16:54] <cjwatson> I just removed sysklogd ...
[17:17] <cjwatson> ahh, finally managed to unwind enough dependencies to remove horde3
[17:33] <xnox> cjwatson: would it be terrible to migrate libpinyin4 into release pocket, yet not remove old abi binaries libpinyin2 and libpinyin2-dev ?
[17:34] <xnox> cjwatson: at the moment ubuntu-keyboard code review was accepted, but it's challenging to test, due to enabling "-proposed".
[17:35] <cjwatson> but the CI people seemed to think that ought to be fixed
[17:35] <cjwatson> I'm pretty reluctant to force things like this because it's too easy to miss something
[17:36] <xnox> cjwatson: it has been fixed in the merger, and was the case in the daily  build-ppa. But when one does manual testing on personal device, the image one flashes doesn't have -proposed enabled.
[17:36] <xnox> cjwatson: Ok, i will work with manual testing reviewer to pull the needed debs from the archive.
[17:36] <cjwatson> that's easy to fix, surely?
[17:36] <cjwatson> I mean, if it's local, you can pull the .debs, or edit sources.list, or whatever
[17:37] <xnox> cjwatson: that appears to be challenging, I'll see if we can improve current procedures to include needed steps for -proposed.
[17:38] <xnox> (not to me, but manual reviewers that is)
[17:38] <cjwatson> I was about to ask :)
[17:38] <cjwatson> this is going to come up again for other reasons, so I don't think our standard answer should be to force - indeed I think it's better to ensure that we can cope with it
[17:38] <cjwatson> and better to do so at a point when it's relatively non-urgent
[17:39] <xnox> yeah. ack.
[20:00] <slangasek> bdmurray, stgraber: would appreciate review of the shim-signed in -proposed (incl. the one in precise-proposed/new), bug #1246910 is gathering a fair number of dupes
[20:00] <ubot2> Launchpad bug 1246910 in shim-signed (Ubuntu Saucy) "package shim-signed 1.3+0.4-0ubuntu3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1. " [Undecided,Confirmed] https://launchpad.net/bugs/1246910
[20:02] <stgraber> slangasek: sure, looking now
[20:05] <stgraber> that's for the special one, will do the others with sru-review in a sec
[20:06] <infinity> Did you remember to override it to main?
[20:06] <stgraber> if we get much more of those, I may end up patching sru-review to deal with that LP bug and let you accept from New, and using the right component
[20:06] <stgraber> infinity: I did
[20:07]  * infinity fires up some more glibc test builds and goes to find lunch.
[20:09] <stgraber> slangasek: and accepted everywhere. Considering the minimal delta and the fact it's a straight cherry-pick, I think it'd be safe to reduce the waiting period on those, so we can probably release that one early next week
[20:10] <slangasek> stgraber: thanks - yes, an early release would be good, considering the impact