[01:14] <quidnunc> How do I verify which DIST pdebuild is using?
[01:39] <quidnunc> god damn you pbuilder
[07:34] <dholbach> good morning
[07:39] <_nullthree> morning
[10:50] <tumbleweed> jtaylor: from #debian-ubuntu:
[10:50] <tumbleweed> 12:46 < sgnb> unison has been synchronized in precise, but not unison2.32.52
[10:50] <tumbleweed> 12:47 < sgnb> unison2.32.52 should be imported to precise as well, to keep  compatibility with previous ubuntu releases
[17:26] <jtaylor> wtf is that for a source package name oO
[17:36] <tumbleweed> compatibility package :)
[17:37] <jtaylor> do you know what exactly its needed for?
[17:37] <jtaylor> because I'm guessing it will fail to build + needs patching for the log
[17:38] <tumbleweed> the reason in the debian upload was "to maintain compatibility with squeeze"
[17:38] <tumbleweed> I'm assuming the network protocol has changed
[17:38] <tumbleweed> but I left finding that out to you :P
[17:39] <jtaylor> I already inquired in #debubu
[17:39]  * tumbleweed saw
[18:26] <geser> jtaylor: why to you expect it to FTBFS?
[18:27] <jtaylor> rsvg has disappeared in ubuntu
[18:27] <geser> ah
[18:32] <geser> jtaylor: see also bug #941836 and bug #937596 requesting that version too
[18:33] <jtaylor> meh forgot to subscribe to the package
[18:33] <jtaylor> is there a tool for that btw?
[18:33] <jtaylor> only know of pts-subscribe
[18:34] <geser> I don't know of any for LP
[18:34] <lifeless> CLI tool? you could add one to lp-dev-tools
[18:34] <lifeless> but the only events LP knows about for a per-package-subscription today are bug mail
[18:34] <geser> you might also want to ask sgnb if we really need 3 version of unison in the archive (there is also unison2.27.57)
[18:35] <jtaylor> hm and it does not look patched for the log dir change
[18:36] <jtaylor> why was that done without debian in a package that forks so often :(
[18:52] <jtaylor> tumbleweed: I'll merge the unison package, do I need an ffe for that?
[18:53] <jtaylor> 2.32
[18:54] <geser> as it's a new source package you'll need a FFe
[18:55] <jtaylor> its not really new ;)
[19:56] <ScottK> It takes an archive admin to review it, so you need an FFe.
[19:57] <jtaylor> k I'll reuse the existing unison ffe
[20:00] <ScottK> Please don't
[20:04] <jtaylor> k new one then
[20:25] <jtaylor> bug 937596
[21:25] <jtaylor> whats the SRU version number when the same XYbuildZ version is in a later release and is not affected?
[21:30] <ScottK> How about XY0.1
[21:30] <jtaylor> buildX.11.04.1?
[21:30] <ScottK> Oh, wait.
[21:31] <ScottK> Same version in a later release is not affected?
[21:31] <micahg> jtaylor: you're in trouble, you have to rebuild the later release in any event, for versioning: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[21:31] <ScottK> How does that work out?
[21:31] <micahg> and the same question as ScottK ^^ :)
[21:31] <jtaylor> the cause is actually a library, but the broken packages declares its dependencies in a broken way, fixing that fixes the issue
[21:31] <jtaylor> the broken package is a leaf package, the library not
[21:32] <jtaylor> so its safer to just fix the leaf package
[21:32] <jtaylor> the library is not actually broken, it just behaves in a way not expected by the broken leaf package
[21:32] <jtaylor> it does in a later release so no fix necessary
[21:32] <jtaylor> but I could fix the leaf package in the later release too, it does not even declare a dependency on libc
[21:33] <ScottK> That would solve the versioning problem.
[21:53] <jtaylor> can armel and armhf do unaligned memory access? if no how is that handled in qemu armel?
[21:58] <jtaylor> hm no to the first according to http://wiki.debian.org/ArmEabiFixes but my qemu question still stands