[01:28] <infinity> xnox: Please don't go back in time with versions. :P
[01:28] <infinity> xnox: I think you wanted that 3.2.1-0ubuntu1 to be 3.2.1-1ubuntu1
[01:29] <infinity> xnox: (The binary packages weren't renamed, just the source, so going backward from 3.2.1-1 to 3.2.1-0ubuntu1 will explode)
[01:31] <infinity> xnox: And now that I've grumped at you, I'll reupload with a sane version number. :P
[01:43] <xnox> infinity: I see. At first I thought to use 3.2.1-1ubuntu1, but then though "what if debian does a sane thing and uploads libotr2 with 3.2.1-1?" and I foolishly decided I should be lower, but you are quite right I should not go back in time with binaries =))))
[01:43] <infinity> xnox: Debian can't upload 3.2.1-1, for the same reason.  The binaries would get rejected.
[01:44] <infinity> xnox: So, the first Debian version of libotr2 would have to be >> 3.2.1-1 (probably -2 or -1.1, which would sort higher than -1ubuntu1)
[01:45] <xnox> infinity: I see, true.
[01:46] <infinity> xnox: In fact, if I were you, I'd probably NMU libotr2_3.2.1-1.1 with extreme prejudice, leaving the same debian/control as the previous upload, so the maintainer effectively gets to own it, whether he wanted to or not. :P
[01:47] <infinity> xnox: (Well, unless the API transition looks like a simple and sane one, in which case, get to patching, which is probably the RIGHT way forward, and perhaps what we should be doing in Ubuntu...)
[01:47] <xnox> infinity: I ponder about fetching all libotr old-debs for all Debian arches & crafting a mega-changes file with matching checksums on all arches and uploading. Would that work or will dak notice this?
[01:47] <infinity> xnox: dak won't let you spontaenously start providing the exact same binary from a new source, you'll need to bump version and rebuild.
[01:48] <xnox> infinity: patching and transitioning is not easy. I am expecting that libotr2 will stick forever, as rdeps are dead upstream....
[01:48] <xnox> infinity: ok. thanks for explaining =)
[01:48] <infinity> xnox: Dead rdeps, we deal with all the time.  How bad is the API transition, really?
[01:48] <infinity> xnox: You could probably bribe apw with copious amounts of beer.  He's really good at API transitions. :P
[01:49] <infinity> xnox: Anyhow, your bandaid method's accepted and built now, so that'll do for the immediate future.
[01:50] <infinity> Speaking of dead upstreams and API transitions, I should finish fixing t38modem later, to finish that transition.
[01:50] <xnox> infinity: it looks non-trivial and I have no interest it doing it..... http://paste.ubuntu.com/1333764/ see line 713 onwards
[01:52] <xnox> about t38modem I'd like to take seb128 view on the archive: if it's broken & unmaintained just remove it from the archive.
[01:52] <infinity> swig tends to blow minor API changes way out of proportion, due to the code it generates, but point taken.
[01:53] <xnox> infinity: that was the most simple error message I saw.....
[01:53] <infinity> xnox: Your opinion's duly noted.  But I don't think "we broke it, and now it's broken, so remove it" is a valid view, and I've shared that with seb before.
[01:53] <infinity> xnox: By that same view, we should remove all of libotr's rdeps.
[01:53] <infinity> (In fact, it would remove 90% of rdeps on any library transition)
[01:53] <xnox> at least libotr is useful =)))))
[01:54] <infinity> xnox: You don't get to be the arbiter of which packages are useful. :P
[01:54] <xnox> unlike t38modem.....
[01:54] <infinity> "Useful to you" != "useful".
[01:54] <infinity> For instance, I don't use, nor give a crap about, OTR.
[01:54] <infinity> So, clearly, it should just be removed, right? ;)
[01:54]  * xnox let the 13.10th bi-annual Archive Hunger Games begin....
[01:55] <xnox> s/13.10/13.04/
[01:55] <infinity> Or, just admit that if changing something in the archive breaks something else in the archive, maybe we should fix what we broke, rather than claiming our upload was "more important" than the previous.
[01:55] <infinity> I know, sounds like crazy talk.
[01:57] <infinity> (And, in the t38modem/ptlib case, I find ptlib's minor API changes on seemingly tiny version bumps pretty distasteful, blaming it on the upstreams of linking packages for "not keeping up" is a bit laughable)
[01:57] <infinity> Some day, someone other than libc maintainers will sort out how to do versioned symbols.  And I'll be very, very confused for a while.
[01:57] <xnox> Sure. I just hope somebody will care about random packages I don't care about enough (aka write patches). And my threshold is low enough.
[01:59]  * xnox above makes little grammatical sense but I hope it still parses in English with -Wno-error
[02:03] <xnox> good night
[03:45] <slangasek> infinity: pcre
[03:45] <slangasek> not actually doing versioned symbols... just making them completely irrelevant by having a future-proof ABI. :)
[03:49] <infinity> slangasek: That works too.
[03:51] <infinity> I wonder sometimes if Philip resents that PCRE became so much more popular than the MTA it was written for.
=== doko_ is now known as doko
[10:28] <cjwatson> tumbleweed: there's a new lazr.restfulclient on pypi which is purported to help with concurrency bugs - don't suppose you'd care to package it?
[10:28] <cjwatson> tumbleweed: (or I can do it in Debian if you're busy and don't mind an NMU)
[10:29] <cjwatson> (oops, sorry, that probably should have been on #ubuntu-devel - meh)
[11:34] <ogra_> chroot: cannot run command `sh': No such file or directory
[11:34] <ogra_> intresting message from the livefs builders
[11:34] <ogra_> i suspect that needs some lamont'ing or equivalent
[11:37] <jcollado> I'm looking for raring desktop images. In http://cdimage.ubuntu.com/daily-live/current/, I only see images for mac and arm. Is there any other place I should look at?
[11:40] <ogra_> image builds are currently failing ...
[11:40] <ogra_> and it looks like thats already going on since a while
[11:40] <xnox> already reported and infinity was chasing is/webops to fix it....
[11:41] <xnox> see ~2AM UTC today. ^^^^
[11:42] <jcollado> ogra_, xnox: Ok, thanks. I'll check later.
[12:14] <tumbleweed> cjwatson: np, I'll look this evening
[17:10] <infinity> cdimage crontab is completely disabled while we sort out raring livefs chroots, so I don't have to contend with automated builds.
[17:15] <xnox> thanks.
[17:22] <stgraber> infinity: my livefs builds just finished. I still have the cdimage/debian-cd scripts running for those but that shouldn't impact you
[17:29] <ogra_> yay, we have a shell again
[17:29] <ogra_> (on the livefs builders)
[17:29] <infinity> Some of them are still broken, mind you.
[17:30] <infinity> (working on proxying the right people to unbreak them)
[17:30] <ogra_> yeah, just saw the error message but it looks like improvement
[17:30] <ogra_> "chroot: cannot run command `sh': No such file or directory" vs "sh: 1: cd: can't cd to /build/"
[17:31] <infinity> Yes, it's a mild improvement. :P
[19:27] <infinity> stgraber: ^-- Do packagesets ever change in small enough increments for this output to be anything but noise?
[19:28] <infinity> (And does anyone actually care, except the person who just changed them?)
[19:30] <stgraber> infinity: they usually are < 25 entries, that particular change was the addition of an xorg packageset with quite a bunch of sources.
[19:30] <stgraber> infinity: what I usually like to see is smaller changes that happen when we run some automated scripts
[19:31] <infinity> stgraber: Fair enough.  If the output's useful to someone, that works.  I'm just ont sure I've ever cared. ;)
[19:31] <infinity> s/ont/not/
[19:36] <stgraber> infinity: are you also copying the new kernels to raring or are we expected to get all new and shiny kernels real soon there instead?
[19:39] <infinity> stgraber: The latter, according to ogasawara.
[19:39] <infinity> stgraber: If a security bug hits the Q kernels before we get new R ones, I'll revisit that.
[19:40]  * infinity decides to lunch a little bit.
[20:04]  * ScottK waves from 30,000 feet.
[20:05] <knome> hey ScottK :)
[20:06] <ScottK> Hey knome.
[20:09] <ScottK> Someone should figure out wifi on trans-oceanic flights.
[20:10] <knome> heh
[20:11] <stgraber> ScottK: you could probably do dialup on the sat phone and then share that over wifi, but you'd end up having to pay $5/minute for pretty unreliable very high latency dialup :)
[20:13] <ScottK> If it were part of the installed service and all passengers could share, it probably wouldn't be stunningly expensive.
[20:26] <ScottK> stgraber: The dial-up reference isn't bad though.  I'm download new packages at 47 kB/s.
[20:26] <ScottK>  ... downloading ...
=== yofel_ is now known as yofel
[22:45] <infinity> Hrm.
[22:46] <infinity> cjwatson: You may be interested in knowing that the async bug closure magic seems to have failed to close bug 1068224 with the linux release to quantal-updates.
[22:46] <ubot2`> Launchpad bug 1068224 in linux (Ubuntu Quantal) "linux: 3.5.0-18.29 -proposed tracker" [Medium,Fix released] https://launchpad.net/bugs/1068224
[22:46] <infinity> cjwatson: Clearly referenced in the changelog: https://launchpad.net/ubuntu/+source/linux/3.5.0-18.29
=== LordOfTime is now known as TheLordOfTime
[23:05] <cjwatson> infinity: Mind asking #launchpad-ops?  The log shows none of those bug-closing jobs processed at all today ...
[23:05] <cjwatson> (and it's 11pm here, running out of brainpower)
[23:06] <infinity> cjwatson: Oh, it was more an FYI than a "please hunt".  But yeah, I can ask LP folks to hunt.
[23:07] <cjwatson> the I is appreciated - just suspect it may need moderately urgent attention