=== cpg is now known as cpg|away === cpg|away is now known as cpg === cpg is now known as cpg|away === cpg|away is now known as cpg === dendrobates is now known as dendro-afk [08:07] 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:07] Launchpad bug 1029337 in zsh (Ubuntu) "Merge zsh 5.0.0-1 (main) from Debian experimental (main)" [Undecided,Fix released] [08:08] see http://packages.debian.org/changelogs/pool/main/z/zsh/zsh_5.0.0-2/changelog [08:27] KRF: Done. [08:27] debfx: I grabbed that zsh merge for you. [08:28] nice one! [08:28] thanks === cpg is now known as cpg|away === dendro-afk is now known as dendrobates === imbrando1 is now known as imbrandon === hyperair is now known as Guest14260 === christoffer is now known as Guest90929 === fisted is now known as Guest61403 === jbicha is now known as Guest21308 === blaze is now known as Guest20426 === Claudinux is now known as Guest14284 === Guest90929 is now known as Christoffer [10:53] with the email interface on launchpad, is it possible to link a bug to a Debian bug? how would I do that? [10:55] I don't see (from the documentation) that you can do that :( === dendrobates is now known as dendro-afk [11:08] 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] in fact, bug 244630 [11:09] Launchpad bug 244630 in Launchpad itself "Ability to link to bugs in other bug trackers from the email interface" [Low,Triaged] https://launchpad.net/bugs/244630 === tuomasjj1asanen is now known as tuomasjjrasanen [12:02] thanks tumbleweed === Guest21308 is now known as jbicha === doko_ is now known as doko [14:33] 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] Depends: bar (>= 1.2.3.4...) [14:41] 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] alexbligh1: Then make it an exact relationship (= 1.2.3) [14:42] alexbligh1: Not ideal, and makes upgrade ordering a bit of a pain. [14:43] alexbligh1: The real answer is "teach your users how to use apt pinning to prefer packages from your repository". [14:43] So can I do bar (=1.0.1-1ubuntu2alex1)? [14:43] alexbligh1: Alternately, "if your patches are suitable for upstream or Ubuntu, submit them". [14:43] 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] If it's suitable for an SRU, you could still submit a patch for precise. [14:44] you could just ask for an SRU if the patch isnt to intrusive [14:44] nah it's a feature upgrade. [14:44] Fair enough. [14:44] Then yeah, either apt pinning, or use exact depdendencies. [14:44] dependencies, too. [14:45] or ask for a backport ;) [14:45] 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] 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] rock and roll [14:46] 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] In fact 'interesting things' to the API as well. [14:48] infinity: Happy birthday! === cpg|away is now known as cpg === AlanBell is now known as zAlanBell === zAlanBell is now known as AlanBell === Caesar_ is now known as Caesar