Hi Reinhard,
thanks for your quick reply!
The package was created with dh-make-golang 0.3.3-1, so it should match the latest best practice from the Go team. Note that I can build the package with the command 'gbp buildpackage --git-builder=sbuild' (in other words, I never used dgit, I go with gbp and sbuild).
> How to get the original tarball?
So, indeed, origtargz fails to fetch it, I just tried. It seems that origtargz doesn't know what to do with the version string. ' 0.4.0+git20190919.681d7bb-1' roughly means "git commit 681d7bb, from 2019/09/19, after the tag 0.4.0". This kind of version string is more or less standard for Go packages, when we package a git commit. This particular version string was created by dh-make-golang, I didn't invent it :)
Note that for this package, I chose to package the latest commit because there was not much activity upstream after the tag 0.4.0, and it's not sure that there will be a new release any time soon (quite unlikely). So better stick with latest commit on master.
To answer your question: gbp can recreate the origtargz with the command `gbp export-orig`. gbp will create the orig tarball from the git tree. Then running dgit should work.
I don't know what should be done to accommodate dgit in this case...
> please target 'experimental' in debian/changelog for NEW packages
Up to now I would target UNRELEASED, and let the Debian Developer who uploads the package finalize the changelog. So it would be his decision to decide between experimental or unstable.
But I would be surprised to target experimental, from my understanding experimental is not for new packages, it's for, well, experiments, either things that might break the system, or that are definitely not ready for unstable, or any other good reason.
This package is just a small command-line tool to parse HTML, it has no interaction whatsoever with the system, it's quite safe.
In any case, I let the uploader decide on that, I'm fine if the package ends up in experimental.
EDIT: I just read in my notes that for Bullseye, it was suggested to go through experimental, it was mentioned on debian devel announce a while ago. I understand your comment now :)
Do you want me to change it, or are you fine doing it yourself (assuming you'd upload the package)?
> The maintainer field is not set to the team
I don't understand, I have that in the control file:
Is it correct?
> debian/copyright is (license-reconcile) clean, thanks!> debian/{rules,control} is clean
Cool :)
Best,
Arnaud