[07:45] <eest> I would like someone from the bugs team to nominate https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1472510 to trusty
[07:45] <eest> i am sorry if this is not the correct order, just trying to follow https://wiki.ubuntu.com/StableReleaseUpdates
[08:08] <rbasak> eest: done. Thank you for driving this.
[08:09] <rbasak> eest: your patch for Wily looks good, but needs some dep3 headers: http://dep.debian.net/deps/dep3/
[08:09] <rbasak> eest: they help us track where patches come from so we can drop them as soon as we can
[08:17] <eest> rbasak: hmm... you mean i should revisit the changelog file and add more fields?
[08:23] <eest> if you could be a bit more secific what is missing i would much appreciate it, the only think i can really think of is to mention the debian/patches/increase-max_sent_count file
[08:23] <eest> *thing
[08:24] <eest> based on previous entries
[08:26] <rbasak> eest: no the changelog is fine
[08:27] <rbasak> eest: I'm asking for some descriptive headers in unbound-1.4.22/debian/patches/increase-max_sent_count please
[08:27] <rbasak> eest: see "A patch cherry-picked from upstream" example in http://dep.debian.net/deps/dep3/
[08:28] <rbasak> eest: an "Origin: upstream, ..." header and a "Bug-Ubuntu: " header would in particular be useful
[08:28] <eest> ah
[08:28] <rbasak> eest: oh, also please mention "(LP: #1472510)" in the changelog so it auto-closes.
[08:29] <eest> ill see what i can do
[08:29] <eest> thanks
[08:29] <rbasak> eest: no problem. Note that particular example from Ulrich Drepper is a convenient for to use when cherry-picking from git, as you can mostly use the upstream commit message.
[08:30] <eest> rbasak: it seems "closes: #number" is what is used previously
[08:30] <eest> should i still use the "LP: #number" syntax for my entry?
[08:31] <rbasak> eest: Use LP: please. closes: is for Debian, LP: for Ubuntu.
[08:31] <eest> ah
[08:31] <eest> roger that
[09:08] <hjd> Just curious, is there any information on the bugproxy bugs somewhere, like for instance bug 1468606? I've seen a couple of such reports, but I haven't found any information on where they might be coming from. Is there a bug tracker somewhere syncing/forwarding issues to Launchpad?
[09:11] <rbasak> hjd: they come from IBM. I think they have some kind of internal system that their employees use to track issues that reports them to Launchpad or something.
[09:11] <rbasak> I've been treating them just as normal bugs.
[09:24] <hjd> Ah, ok. :)
[10:01] <eest> rbasak: i have supplied an updated debdiff based on your feedback, see https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1472510
[10:01] <eest> i removed the old attachement as well
[10:14] <hjd> Could someone please mark bug 1364503 as Triaged/High. The service fails to start and installation of the package fails.
[10:15] <rbasak> eest: thanks. I don't have time to look right now but will look this afternoon.
[10:15] <eest> sure
[10:24] <rbasak> eest: just about had time. Looks good, thank you for the updated patch. Uploaded.
[10:24] <eest> :)
[10:24] <rbasak> eest: next, for Trusty, can you create a debdiff in the same way but base it on the latest packaging from Trusty?
[10:25] <eest> basically replace my initial debdiff?
[10:25] <eest> sure
[10:25] <rbasak> Yep. Base it on packaging from unbound 1.4.22-1ubuntu4.14.04.1, so the debdiff should be against that
[10:25] <eest> will have to reinstall the build machine, but im on it
[10:25] <rbasak> The version you will create is unbound 1.4.22-1ubuntu4.14.04.2
[10:26] <rbasak> The debdiff should end up looking pretty much the same, except that the top line in the changelog will read 1.4.22-1ubuntu4.14.04.2 and trusty
[10:26] <rbasak> (instead of 1.4.22-1ubuntu6 and wily)
[10:26] <eest> sure, ill use the same message and patch
[10:26] <eest> let dch -i handle the other stuff
[10:26] <rbasak> That presumes the patch still applies of course
[10:26] <eest> ill create it using quilt
[10:26] <rbasak> I don't think dch will be able to guess the version number right, I don't know
[10:27] <rbasak> I've really run out of time now, but I'll take a look this afternoon if you have it ready by then.
[10:28] <eest> ill make sure it is ready by then
[11:15] <eest> rbasak: the trusty debdiff is up
[13:04] <rbasak> eest: thanks! Looks good, uploaded. Next the SRU team need to review it. This usually takes about a week. Once accepted please follow the steps they'll post in the bug for SRU verification to get the update landed.
[13:24] <eest> rbasak: cool :). yeah i recall adding some testing repo and verifying the bug was solved for previous debdiffs i have commited