Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notice: PGP key changed / Release automation #173

Closed
Cloudef opened this issue May 20, 2021 · 8 comments
Closed

Notice: PGP key changed / Release automation #173

Cloudef opened this issue May 20, 2021 · 8 comments

Comments

@Cloudef
Copy link
Owner

Cloudef commented May 20, 2021

The PGP key used now is 29317348D687B86B, I've signed this with the old key. The key can also be found from my website https://cloudef.pw/bemenu-pgp.txt

Also since the git archive doesn't seem to produce bit-by-bit compatible tarball to github generated one, the releases now include a tarball generated by the CI, thus if you want to verify the source tarball, do not download the github generated one. Instead get the bemenu-<version>.tar.gz and bemenu->version>.tar.gz.asc files.

@maximbaz
Copy link

This does produce a bit-by-bit compatible tarball for me, I'm using this command in many projects 😉

$ git archive -o "bemenu-0.6.0.tar.gz" --format tar.gz --prefix "bemenu-0.6.0/" "0.6.0"

You are free to create your own tarball, just sharing in case you are curious 🙂

@Cloudef
Copy link
Owner Author

Cloudef commented May 23, 2021

https://github.com/Cloudef/bemenu/blob/master/GNUmakefile#L151
I guess the only difference here is that prefix should be bemenu-$(VERSION) I'll try that!

Tried it, sadly doesn't seem to work either

@maximbaz
Copy link

Tried it, sadly doesn't seem to work either

When I download these two files, they are identical for me, so I guess it did work? 🙂

image

@Earnestly
Copy link
Contributor

Why have both GIT_TAG and VERSION in the sign target? Is there any chance for these two values to be different given the initial test condition?

@Cloudef
Copy link
Owner Author

Cloudef commented May 24, 2021

@Earnestly it's to make sure the tag matches VERSION. I did mistake last time by not bumping VERSION file. Releases are automatically generated on tag pushes. #130

@Cloudef
Copy link
Owner Author

Cloudef commented May 24, 2021

Tried it, sadly doesn't seem to work either

When I download these two files, they are identical for me, so I guess it did work? 🙂

image

Weird, it might be on my local machine it only differs but the github runner works 🤔

@Earnestly
Copy link
Contributor

Earnestly commented May 24, 2021

@Earnestly it's to make sure the tag matches VERSION.

This should be covered by the test condition; my point was more about the git archive command using a mixture of both VERSION and GIT_TAG instead of just using VERSION throughout. It shouldn't matter though as both would be the same value at this point, just odd. I thought it may be causing the issue seen here but it turns out to be harmless.

@Cloudef
Copy link
Owner Author

Cloudef commented May 24, 2021

That's true. I guess my brain semantically mapped the GIT_TAG variable as a better candidate as a argument for git archive for a "git tag" :) Though it doesn't matter as both of them should be same the time the test passes.

@Cloudef Cloudef closed this as completed Feb 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants