[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: Bug#953403: ITP: golang-k8s-sigs-structured-merge-diff -- Test cases and implementation for "server-side apply"



On Sat, May 16, 2020 at 9:46 AM Tong Sun
<suntong001@users.sourceforge.net> wrote:
[...]
>
> - it had bee upstream/3.0.0 before, but
> - It gave me `3.0.0+ds1` today, instead of the `3.0.0` as expected.
> - I don't know where this v3.0.0 comes from so I don't know where to check.
>
> Does this look normal? thx.

Your upstream/3.0.0 tag is created by dh-make-golang, when you package
it from scratch.
And upstream/3.0.0+ds1 is created by git-buildpackage, when you import
a new version from uscan.

dh-make-golang and git-buildpackage are two different tools. It looks
like a bug that the behaviour is not aligned.
So I recorded it at https://github.com/Debian/dh-make-golang/issues/141

Actually the +ds1 version is correct. ds means you have repacked
upstream tarball, by removing the vendor directory.
Otherwise it will trigger repackaged-source-not-advertised[1]. However
you can ignore this, as it's not a big deal.

[1] https://lintian.debian.org/tags/repackaged-source-not-advertised.html

And I looked your repo at salsa. It looks like you created
upstream/1.0.1 tag with vendor not removed[2].
Then you remove the vendor dir in later commit in debian branch. It's
not correct.
The debian branch should only have commits that modifie debian directory.

As I think you don't have permission to force-push tags, so I decide
to remove this repo.

[2] I know it's bug in dh-make-golang, but please correct it before we
fix it in dh-make-golang.

PS, I know it's painful to use dh-make-golang for new contributors currently.
Maybe you should learn the normal packaging methods, and then let dh-make-golang
only assist you in writing files inside debian directory?

-- 
Shengjing Zhu


Reply to: