Bug#841081: [pkg-go] Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Potter, Tim (HPE Linux Support)]

On 19 Oct 2016, at 7:02 PM, Guillem Jover  wrote:
> 
> Hi!
> 
> On Wed, 2016-10-19 at 01:40:02 +, Potter, Tim (HPE Linux Support) wrote:
>> On 18 Oct 2016, at 1:21 AM, Guillem Jover  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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#841081: [pkg-go] Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Guillem Jover]

Hi!

On Wed, 2016-10-19 at 01:40:02 +, Potter, Tim (HPE Linux Support) wrote:
> On 18 Oct 2016, at 1:21 AM, Guillem Jover  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

Bug#841081: [pkg-go] Bug#841081: RFP: golang-gopkg-dancannon-gorethink.v1 -- RethinkDB driver for Go

[Potter, Tim (HPE Linux Support)]

On 18 Oct 2016, at 1:21 AM, Guillem Jover  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 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.

I added a missing build-dependency (why does v1 of the package require v2?
that's weird) and added a few tweaks.


Tim.

> 
> Thanks,
> Guillem
> <0001-Revert-import-of-v2.0.1-back-to-v1.4.1.patch><0002-Update-packaging.patch>___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



signature.asc
Description: Message signed with OpenPGP using GPGMail