Clojurians Log v2
clojars
@corasaurus-hex They are based on the Maven LATEST and RELEASE metaversions, described here: https://www.baeldung.com/maven-dependency-latest-version#1-deprecated-syntax
So latest_version corresponds to LATEST, and is the most recent snapshot or non-snapshot. latest_release is always the latest non-snapshot, and corresponds to RELEASE.
ooooh thanks!! do you mean latest_release in that last sentence?
Yes :) It was too early! I'll edit it.
I'm having trouble deploying to Clojars:
Created: target/pretty-1.4.jar
Sending io/aviso/pretty/1.4/pretty-1.4.jar (25k)to ): Authorization failed for 403 Forbidden - no checksums provided for pretty-1.4.jar.asc
{:clojure.main/message
"Execution error (AuthorizationException) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon/put (AbstractHttpClientWagon.java:806).\nAuthorization failed for 403 Forbidden - no checksums provided for pretty-1.4.jar.asc\n",
:clojure.main/triage
{:clojure.error/class
org.apache.maven.wagon.authorization.AuthorizationException,
:clojure.error/line 806,
:clojure.error/cause
"Authorization failed for 403 Forbidden - no checksums provided for pretty-1.4.jar.asc",
:clojure.error/symbol
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon/put,
:clojure.error/source "AbstractHttpClientWagon.java",
:clojure.error/phase :execution},
:clojure.main/trace
{:via slipset/deps-deploy {:mvn/version "0.2.0"} to deploy, which appears to be upto date.
Do you have CLOJARS_PASSWORD env var set to a valid deploy token? (not a password)
(and CLOJARS_USERNAME)
It should be, let me double check.
Yes to both, not changed since last time I did some deploys.
Hmm, that's the only thing I can think of right now...
I've been using this token since Jun 2020 AFAIK.
And slipset did create .asc files for the pom and jar as normal.
So I wonder if something's changed recently at clojars?
https://github.com/slipset/deps-deploy/issues/11 seems similar...?
"Determined that the bug is only present when signing jars."
Odd, been using the same version of slipset, and the build tool does rename the pom.
`
Authorization failed for 403 Forbidden - no checksums provided for pretty-1.4.jar.asc" This is the validation on the clojars side expecting every file uploaded to have either an md5 or sha1 checksum file uploaded for each file. It runs the validations when the maven-metadata.xml file is uploaded, and throws on the first failure. Looking at the output, I don't see any sha1 or md5 files being uploaded, so that would cause this. I've never used deps-deploy, so don't know how to configure it/what it is supposed to do. I would think that aether would handle that for you though. I'll check the logs to see if any checksum files were uploaded, but not reported in the output.
There haven't been any recent changes to clojars that would effect this
It is sending md5 sums for the jar & pom, but not for the asc files;
50.220.102.134 - hlship [27/Mar/2023:22:15:37 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:15:39 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:17:38 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:17:40 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:44:01 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.jar.md5 HTTP/1.1" 201 5 "-" "Aether"
50.220.102.134 - hlship [27/Mar/2023:22:44:03 +0000] "PUT /repo/io/aviso/pretty/1.4/pretty-1.4.pom.md5 HTTP/1.1" 201 5 "-" "Aether"Do you normally sign pretty releases @hlship?
https://github.com/slipset/deps-deploy/commit/fd8ff2de9c4bda82a1c69c387d56217473b394be appears to be the fix for this (found via https://github.com/slipset/deps-deploy/pull/53), but it doesn't look like it is released.
Great advice; I can tackle this tomorrow.
And, yes I GPG sign my uploads to all projects. I don’t get why I haven’t hit this before though.
Even using latest deps-deploy, I had to turn artifact signing off to deploy.
I’ll try to find some time to look into this. Out of curiosity, where do you publish your public signing key @hlship ? Reason I’m asking is that I’m also signing stuff, but haven’t published my key anywhere, so it’s basically useless. Likewise, I would have no idea how to go about verifying any of your things if I were so inclined. Basically what I’m saying is that I find that there are some missing pieces of infrastructure which would make the signing of artifacts so more useful if it existed.
FWIW, I just published deps-deploy 0.2.1, signed:
erik@keep deps-deploy % env CLOJARS_USERNAME=erik CLOJARS_PASSWORD=CLOJARS_<redacted> clj -X:deploy
gpg passphrase:
gpg passphrase:
Deploying slipset/deps-deploy-0.2.1 to repository clojars as erik
Sending slipset/deps-deploy/0.2.1/deps-deploy-0.2.1.pom (2k)
to I think I did a signing exchange at Apachecon once, maybe 20 years ago. I think I'm still using the same GPG key.
Good point about uploading the key somewhere so that the signing is actually useful.
I'm using deps-deploy-0.2.1 but still getting the error, but probably because of how I'm using it. To hack around the prompt for the GPG passphrase, I sign the file before calling aether/deploy. https://github.com/hlship/build-tools/blob/main/src/net/lewisship/build/jar.clj#L103
Hm. Maybe I can use some combination of these instead:
:username - username to log in with
:password - password to log in with
:passphrase - passphrase to log in wth
:private-key-file - private key file to log in with@hlship I remember Phil (technomancy) encouraging folks to do key signing exchanges in person at Clojure/conj events many years ago, when he was trying to get artifact-signing on Clojars more widespread...