[08:07] <KRF> debfx: related to https://bugs.launchpad.net/ubuntu/+source/zsh/+bug/1029337 - could request another merge for 5.0.0-2,  i am especially looking for the patch "[0b3b271c] Do not use echoti {smkx,rmkx} unconditionally".
[08:08] <KRF> see http://packages.debian.org/changelogs/pool/main/z/zsh/zsh_5.0.0-2/changelog
[08:27] <infinity> KRF: Done.
[08:27] <infinity> debfx: I grabbed that zsh merge for you.
[08:28] <KRF> nice one!
[08:28] <KRF> thanks
[10:53] <pabs3> with the email interface on launchpad, is it possible to link a bug to a Debian bug? how would I do that?
[10:55] <Laney> I don't see (from the documentation) that you can do that :(
[11:08] <tumbleweed> you can add a task through the e-mail interface, and add a bug watch, by linking to the debian bug, but can't associate the task with the watch (that I can see)
[11:09] <tumbleweed> in fact, bug 244630
[12:02] <pabs3> thanks tumbleweed
[14:33] <alexbligh1> If I have package foo and package bar, and foo depends on a ppa version of bar (with a patch in), who do I specify that in a Depends: line in foo's debian/control?
[14:36] <pabs3> Depends: bar (>= 1.2.3.4...)
[14:41] <alexbligh1> pabs3 but if I have bar_1.0.1-1ubuntu2alex1_amd64.deb which is a patched version of bar_1.0.1-1ubuntu2_amd64.deb, and the repo publishes a bar_1.0.2-1ubuntu2_amd64.deb, I want my package foo to ensure that bar does not get upgraded because it's (somehow) dependent on the local 'alex' version.
[14:42] <infinity> alexbligh1: Then make it an exact relationship (= 1.2.3)
[14:42] <infinity> alexbligh1: Not ideal, and makes upgrade ordering a bit of a pain.
[14:43] <infinity> alexbligh1: The real answer is "teach your users how to use apt pinning to prefer packages from your repository".
[14:43] <alexbligh1> So can I do bar (=1.0.1-1ubuntu2alex1)?
[14:43] <infinity> alexbligh1: Alternately, "if your patches are suitable for upstream or Ubuntu, submit them".
[14:43] <alexbligh1> Oh the patch is already upstream, in fact it's a backport of a patch which is upstream (and did not make Precise). I just don't want a security upgrade to wipe out the patch.
[14:44] <infinity> If it's suitable for an SRU, you could still submit a patch for precise.
[14:44] <ogra_> you could just ask for an SRU if the patch isnt to intrusive
[14:44] <alexbligh1> nah it's a feature upgrade.
[14:44] <infinity> Fair enough.
[14:44] <infinity> Then yeah, either apt pinning, or use exact depdendencies.
[14:44] <infinity> dependencies, too.
[14:45] <ogra_> or ask for a backport ;)
[14:45] <alexbligh1> Well, the patch concerned is a patch to libfreerdp to access hyper-v VMs. Would you take that as an SRU? I'm guessing not.
[14:45] <infinity> It's possible.  We did a lot of last-minute work for precise on hyperv in other areas.
[14:46]  * infinity decides to go have a birthday nap.
[14:46] <Laney> rock and roll
[14:46] <alexbligh1> Hmm, interesting. I thought SRU was pretty much strictly only for bugfixes and security issues? I can't just use a newer libfreerdp as they appear to have done 'interesting things' to the ABI in the mean time.
[14:47] <alexbligh1> In fact 'interesting things' to the API as well.
[14:48] <penguin42> infinity: Happy birthday!