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 <gjo...@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.

> 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 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.

Thanks,
Guillem

Reply via email to