On 19 Oct 2016, at 7:02 PM, Guillem Jover <gjover@sipwise.com> wrote: > > Hi! > > On Wed, 2016-10-19 at 01:40:02 +0000, Potter, Tim (HPE Linux Support) wrote: >> On 18 Oct 2016, at 1:21 AM, Guillem Jover <gjover@sipwise.com> wrote: >>> Attached a working and tested packaging, where only the ITP bug number >>> needs to be filled in the debian/changelog. The other patch is required >>> to get the git repository back to a proper upstream version, because it >>> was at v2 now. >> >> Which repo were you looking at for the first patch? The one at golang-gopkg-dancannon-gorethink.v1 >> was never at v2. Maybe there was a split into v1 and v2 but that could have >> happened before my time. > > The repo I was working against was: > > https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-dancannon-gorethink.v1.git > > which does contain an import of the v2 branch version v2.0.1 into the > v1.4.1 tag. Take a look at commit 1ec608b3e9473da10b35ddfa5afc40a137df6f32 > and you'll see. Gah - I didn't look to closely at the contents and believed the tags and contents of the changelog. (-: I ended up importing the v1.4.1 tarball rather than applying the patch so that the pristine-tar and upstream branches are up to date. >> The second patch applies just fine. I pushed it but the remark about >> changing the build directory to _build that Martin Ferrari made about >> golang-dns applies here as well. Technically it could mess up >> multi-platform builds but I'm not aware of packages that do this. > > My same reply applies here as well, I find it more pleasing to have > the same directory regardless of the host system, because it makes it > easier to debug, or instruct people to do so. It certainly should have > no visible effect to the build machinery, as long as there's no need > to explicitly point to files underneath the build directory, but I > think it's still better. But do as you prefer, or your group policies > dictate, I don't really mind. ;) I left it as is. >> I added a missing build-dependency (why does v1 of the package require v2? >> that's weird) and added a few tweaks. > > It does not depend on v2, the problem is that it *is* v2, but the > package gets installed as v1 due to the "unmatched" XS-Go-Import-Path > field, so go cannot find the real module and complains that it's > missing. The reversion patch really needs to be applied. :) I guess > having the tag point to the incorrect contents will be confusing, but > fixing that would require rewriting history. Perhaps in this case it's > worth it, and instead of the patch, just rebasing and force pushing > might be better, up to you. Fixed and uploaded to the NEW queue. Tim. > > Thanks, > Guillem
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail