[Pkg-giraffe-discuss] z-push: some signed tags missing on the repository

[Carsten Schoenert]

Hello Roel,

I started to have a look at your current state of the z-push git tree.
You probably have forgotten (or not pushed) to add some tags while
importing some of the new upstream versions. The following SHA1 ID's
missing the tags.

0517dc3b98cb639bc116bb72d64876c79cdc587d Imported Upstream version 2.3.4
ba4d4243d1d4921f8fdcad942e386964b801b52a Imported Upstream version 2.3.6
6ce681b81a0f0331cf39df082600be2a91803888 Imported Upstream version 2.3.7

I could tag them also, but as you have imported the source it's better
that you could tag them. By this two goals we have on the side, first
thing; you say by tagging them that the source was fine and complete and
as a second thing (more important from the technical side) the tagged
upstream commit is used to recreate the needed tarball later in case we
need to work again on some version.

Could you please add the missing tags and push them to your GitHub tree?

If you haven't done yet you can set up a global configuration for the
GPG key that git should use as your default key by the following
setting. Replace the matching GPG key id please.

> git config --global user.signingkey [0xDEADBEEF]

You could can then use the following stanza e.g. for doing the tagging +
signing in one shoot for each commit with adjusting the versions and
SHA1 ID's.

> git tag -s upstream/2.3.4 -m "Upstream version 2.3.4" 0517dc3b98cb639bc116bb72d64876c79cdc587d

One more thing, the upstream tag 'upstream/2.3.5' should be then also
signed. As the tag is already existing you would need to update the
existing one.

> $ git co 04a368016c99ee87d075fae3b01f903a3299da7c
> $ GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -f -s upstream/2.3.5 -m "Upstream version 2.3.5" && git co debian/sid

You will need to do force push as the tag already is existing on the
remote side.

> $ git push -f [your_remote] debian/sid --tags
If you don't want to do anything on that would be also o.k. I can adjust
that then before pushing some final state to Alioth.

For debian/patches, it seems you have chosen to work with quilt instead
of using more flexible usage of git patches by using git-buildpackage, I
or we wouldn't use quilt patch workflow.
Lintian is currently complaining about laking some description for two
patches you've added. And I don't see enough content why you have done
the changes, so some explanation what the patches are doing would be
helpful, no matter if quilt or git based.
Based on the also missed tags you seems not very familiar with the
workflow git-buidlpackage is providing. You need any suggestions or help?

The postrm and postinst script of z-push-common currently using some
unfortunate usage of a variable 'service" that lintian is showing as
error, this needs to be changed as the ftpmaster will probably will
complaining also about that.
I would simply drop $service and use only $1 here.

There are some other things I wouldn't do in that way they are but that
isn't something we need to sort out now. Anyway I think we start first
with a upload to experimental, as the package needs go through NEW we
have to wait on the ftpmasters at all.

-- 
Regards
Carsten Schoenert