Re: Subversion 1.14.2 up for testing/signing
On Sat, Apr 02, 2022 at 09:28:15AM -0400, Mark Phippard wrote: > The 1.14.2 release artifacts are now available for testing/signing. > > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. Summary: +1 to release Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf] swig bindings javahl bindings Test results: All passed. Platform: OpenBSD 7.0 amd64 Dependencies: bdb:4.7.25 GNU-iconv: 1.15 apr:1.7.0 apr-util: 1.6.1 httpd: 2.4.37 serf: 1.3.9 cyrus-sasl: 2.1.25 sqlite: 3160200 lz4:1.7.5 libssl: LibreSSL 3.4.1 swig: 4.0.2 python: 3.7.5 perl: 5.32.1 ruby: 2.7.4 java: 11.0.12 Signatures: subversion-1.14.2.tar.gz -BEGIN PGP SIGNATURE- iQEzBAABCAAdFiEEi8Ta4MWk1l9ARAEHT326qZpZuXMFAmJK9doACgkQT326qZpZ uXNQvQf/bLxThHqK1pbHkej4vKyzM+siMyQPoYN5JiGFKs8Mxht/Bf+6Gq9Kopr6 XMRl3vDU7WWW9E3sS5ygH0JKkm+BaF41ahPzirM7m+dDNb4UdSpWcT7WjG+O3DAV lMzojsshu9T9/KRcjIAO0el/cCyrOFmj2LXxRgHVYBCozJU8uFl+971og7hNeO0v R+NYtdUo9AzvUzbDNrFRsViisyfrjgxD7LQw1V74tiNwPPuPmIUDmktqzWM0AJ2v syPfSNx+pkLlt0ej8c9reiJC+ngduQQEuBwqljsxDf3MTS2dQkxq3IeVlB38RyRx tFvtSbzWKuMGWRpi1QmgdKHnU/c4ug== =6zzL -END PGP SIGNATURE- subversion-1.14.2.tar.bz2 -BEGIN PGP SIGNATURE- iQEzBAABCAAdFiEEi8Ta4MWk1l9ARAEHT326qZpZuXMFAmJK9doACgkQT326qZpZ uXNxqAf+PtDGZD4Qd1fJCns6eK18lIU8xBMy1Q+TxRp/RqtnSg075osJGevvCsmZ syn8JcoPFzc+EzX94bOLAFbcnxC+FZTyAiMMCcnmLO+uGUfMMGxUTiXV8Vkc9VHJ WDKqKfzjDbmSGBmb4nKMyChbpfWFyw5INnPxxCA4GDjYqavlA+RsDx2efwtD3zWz SNa0Ww8aQyWD9hSY8MU/iVNkajEE1fVIxHjAuHlvyTYPZr7jEavpQoMLMiKKiJJG mLpEpPvfud92D4TaxKK/nFbdn2XKfEVZ61/0hstj7B/BZnufBFsWVNmU6fXbfnGg RgLNgPYXMeozlwq2d6eh340NKcSrCQ== =hC7u -END PGP SIGNATURE-
Re: Subversion 1.10.8 up for testing.signing
On Sat, Apr 02, 2022 at 09:27:18AM -0400, Mark Phippard wrote: > The 1.10.8 release artifacts are now available for testing/signing. > > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thanks! Summary: +1 to release Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf] swig bindings javahl bindings Test results: All passed. Platform: OpenBSD 7.0 amd64 Dependencies: bdb:4.7.25 GNU-iconv: 1.15 apr:1.7.0 apr-util: 1.6.1 httpd: 2.4.37 serf: 1.3.9 cyrus-sasl: 2.1.25 sqlite: 3160200 lz4:1.7.5 libssl: LibreSSL 3.4.1 swig: 3.0.12 python: 3.7.5 perl: 5.32.1 ruby: 2.7.4 java: 1.8.0_302 Signatures: subversion-1.10.8.tar.gz -BEGIN PGP SIGNATURE- iQEzBAABCAAdFiEEi8Ta4MWk1l9ARAEHT326qZpZuXMFAmJK9eMACgkQT326qZpZ uXPIhAgAzR/pWjYONFN30R31/bJx10iodiERbjuS3G8ZqEQQAs1nT4vSHSH1pgub dyoF/q3+iDbpvgqeigMm5Fp+iOchDU/8bG9b5rWdXkeEn88r4de2lw+ioEywcmv0 CMa7nrxwnEPpd+IVBQ/BmWA9TqZhQK2IIRZ9trljX8ssva14J6YaJ7PhSaUWttgs Qvf76mfW7N5t/2cW9jbdUEm9H+dIUwir2M/AwK3Utmb3MPSw6PCEFL+H7tCY1G6p qPkkdxrzyglt5Lt/D2S3+nuCOzhmczQwG1IF6FNbyvW2Bf30xJPit54+3ISivS4k yDJn4bplBOhtYnD4cEJjmhwirCm18A== =qWf/ -END PGP SIGNATURE- subversion-1.10.8.tar.bz2 -BEGIN PGP SIGNATURE- iQEzBAABCAAdFiEEi8Ta4MWk1l9ARAEHT326qZpZuXMFAmJK9eMACgkQT326qZpZ uXOlAggAnhDjYRDBmaembQAOMEo7GEuoCVSWnmTGOfktmrqZMPEce7nDrOOqcQW1 mxz6eruHf4R30CC/uKRsQbq9j5qDP/N/MbPAOlWUvkZiMWwbwMuiEOoMm1JYlG/s DbLSF3SUwS8r5ofoBVv+AN3vg1//XnOTAH/Wh5HVVwOnyNL08yMVIqVyZ3Nfz8Vx gLhybFK1hHIBpf5rad6B6IFabxuqV5C9G4TGJu7wZa4NIW7eRRY+eqO88D70T06D n3dMoonkoCabpuiUVqMB9q66HCnEZVryf4878hfVvYQFjU34zZAXEQsv3Q0VxJaS hluoyxXWqIJCxKlJGKuCQhzZrgKtGg== =Zytq -END PGP SIGNATURE-
Re: Website prep work and questions (mainly about the 1.15 release notes)
On Mon, Apr 4, 2022 at 4:46 AM Julian Foad wrote: > Mark Phippard wrote: > > Julian Foad wrote: > >> Me too. It appears I need to update my configured keyserver. Then > >> maybe fetch keys and then maybe the checking will work. That's based > >> on, so far, finding that checking existing keys fails due to > >> unreachable key server, and then reading [...] > > OK, unpicking what I was doing: I started from a script I wrote years > ago that goes through the steps of fetching, testing, signing etc. It > checks existing sigs before signing my sig. It was erroring out at the > checking your sig (which was the only sig in the releases' *.asc files, > at that time): > > $ tools/dist/release.py --target=. check-sigs 1.10.8 > INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc > BAD SIGNATURE: Key 1 in ./subversion-1.10.8.tar.bz2.asc > key id: C4416167349A3BCB > ERROR! > > So I first tried refreshing my local GPG keyring, and hit the obsolete > keyserver problem I mentioned. I fixed that by changing the keyserver > entry in my ~/.gnupg/gpg.conf to say "keyserver > hkp://keyserver.ubuntu.com". Then "gpg --refresh-keys" succesfully > fetched updates including your new key. > > Then the checking got further but still errored out: > > $ tools/dist/release.py --target=. check-sigs 1.10.8 > INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc > INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.gz.asc > INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.zip.asc > Traceback (most recent call last): > File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line > 1916, in > main() > File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line > 1912, in main > args.func(args) > File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line > 1458, in check_sigs > output = get_siginfo(args) > File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line > 1420, in get_siginfo > formatter = PUBLIC_KEY_ALGORITHMS[keytype] > KeyError: 22 > > I took a quick look at the source but couldn't quickly figure it out. I > see now (quoted below) that your new key is a newer EC type; maybe that > is why. But keytype 22 isn't listed in the table referenced from a > source code comment and I don't know where to turn next. > > Then I realised that checking existing keys need not block me from > adding my own, and so I proceeded with that. > > > [...] > > 1. The KEYS file is from the script that was shared. > > 2. I had to create a new GPG key. I noticed it gave me one of the > > newer elliptic curve keys. Maybe not all versions of OpenPGP can > > handle these? > > 3. I uploaded it to the MIT keyserver as per something I read in the > > ASF committer docs ... > > Actually looking at history I did this: gpg --send-key > > EC25FCC105618D04ADB43429C4416167349A3BCB > > 4. I updated my fingerprint in ASF LDAP > > > > Since I just created this key a couple weeks ago if it is better that > > I generate a new key, re-sign the release and upload new signatures > > just let me know what to do. > > At this point I don't have reason to suspect your key is bad, more > likely the scripting and/or my setup needs some update. But I don't > expect to spend more effort on this unless it becomes a blocker for > something. FWIW Mark's key did verify successfully for me (good signature but can't verify web of trust because it hasn't been cross-signed). I am using a relatively new build of GPG. Away from my computer so I can't show the exact output or version info at the moment. Cheers, Nathan
Re: Website prep work and questions (mainly about the 1.15 release notes)
On Mon, Apr 4, 2022 at 3:49 AM Daniel Sahlberg wrote: > > Den sön 3 apr. 2022 kl 20:46 skrev Mark Phippard : >> >> On Sun, Apr 3, 2022 at 2:43 PM Daniel Sahlberg >> wrote: >> > >> > Den sön 3 apr. 2022 kl 19:55 skrev Mark Phippard : >> >> >> >> On Sun, Apr 3, 2022 at 1:40 PM Daniel Sahlberg >> >> wrote: >> >> >> >> > It seems to be a problem mostly related to my key. I can't get the >> >> > committer signature list [1] to include my key (and thus the script >> >> > doesn't download it to the KEYS file). >> >> >> >> FWIW, I think you can sign the release even if you are not in KEYS. We >> >> can also add you manually. >> >> >> >> Could it be as simple as your fingerprint in Apache LDAP needs the spaces? >> > >> > >> > I can't find the reference again but there were stated somewhere that >> > spaces within the string was not required. For example danielsh has a >> > fingerprint without spaces. >> > >> >> >> >> I see dsahlberg 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 - key not found >> >> >> >> And most of the other people (but not all) have spaces in their >> >> fingerprint. >> >> >> >> FWIW, I could manually import your key using the server you indicated >> >> but not the MIT server. >> >> >> >> $ gpg --keyserver pgp.mit.edu --recv-key >> >> 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 >> >> gpg: keyserver receive failed: No data >> >> $ gpg --keyserver keys.openpgp.org --recv-key >> >> 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 >> >> gpg: key 28DB47329CFFDC63: public key "Daniel Sahlberg >> >> " imported >> >> gpg: Total number processed: 1 >> >> gpg: imported: 1 >> >> >> >> I am not sure how the ASF fetches the key. Maybe you need to upload it >> >> somewhere else? >> > >> > >> > Infra explicitly recommends using keys.openpgp.org [1]. >> > >> >> >> >> If it gets worked out I can update the KEYS file. >> >> >> >> Mark >> > >> > >> > Thanks for your help in resolving this issue. Let's see if there is any >> > change tonight when the list is updated again. >> >> Yeah, we have some time to try to find a solution. > > > The key is now available on people.apache.org, so re-running the script > should fetch it. I guess it was the missing e-mail address. Great .. I re-ran the script and updated the *.KEYS files in dist folder. Mark
Re: Should tarballs contain __pycache__ dirs?
Yasuhito FUTATSUKI wrote: >> ./build/__pycache__ >> ./build/generator/__pycache__ >> ./build/generator/swig/__pycache__ >> >> Are they supposed to be present in the tarball? > > I don't think they are supposed. Agreed. > Those directries should be cleaned in fast-clean and clean-swig-py > target in Makefile.in, like "*.pyc" files. > > Here is a patch against trunk, but can't be applied against 1.14.x. I haven't tested the patch but +1 in principle. - Julian
Re: Website prep work and questions (mainly about the 1.15 release notes)
Mark Phippard wrote: > Julian Foad wrote: >> Me too. It appears I need to update my configured keyserver. Then >> maybe fetch keys and then maybe the checking will work. That's based >> on, so far, finding that checking existing keys fails due to >> unreachable key server, and then reading [...] OK, unpicking what I was doing: I started from a script I wrote years ago that goes through the steps of fetching, testing, signing etc. It checks existing sigs before signing my sig. It was erroring out at the checking your sig (which was the only sig in the releases' *.asc files, at that time): $ tools/dist/release.py --target=. check-sigs 1.10.8 INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc BAD SIGNATURE: Key 1 in ./subversion-1.10.8.tar.bz2.asc key id: C4416167349A3BCB ERROR! So I first tried refreshing my local GPG keyring, and hit the obsolete keyserver problem I mentioned. I fixed that by changing the keyserver entry in my ~/.gnupg/gpg.conf to say "keyserver hkp://keyserver.ubuntu.com". Then "gpg --refresh-keys" succesfully fetched updates including your new key. Then the checking got further but still errored out: $ tools/dist/release.py --target=. check-sigs 1.10.8 INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.bz2.asc INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.tar.gz.asc INFO:root:Checking 1 sig(s) in ./subversion-1.10.8.zip.asc Traceback (most recent call last): File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line 1916, in main() File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line 1912, in main args.func(args) File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line 1458, in check_sigs output = get_siginfo(args) File "/home/julianfoad/src/subversion-c/tools/dist/release.py", line 1420, in get_siginfo formatter = PUBLIC_KEY_ALGORITHMS[keytype] KeyError: 22 I took a quick look at the source but couldn't quickly figure it out. I see now (quoted below) that your new key is a newer EC type; maybe that is why. But keytype 22 isn't listed in the table referenced from a source code comment and I don't know where to turn next. Then I realised that checking existing keys need not block me from adding my own, and so I proceeded with that. > [...] > 1. The KEYS file is from the script that was shared. > 2. I had to create a new GPG key. I noticed it gave me one of the > newer elliptic curve keys. Maybe not all versions of OpenPGP can > handle these? > 3. I uploaded it to the MIT keyserver as per something I read in the > ASF committer docs ... > Actually looking at history I did this: gpg --send-key > EC25FCC105618D04ADB43429C4416167349A3BCB > 4. I updated my fingerprint in ASF LDAP > > Since I just created this key a couple weeks ago if it is better that > I generate a new key, re-sign the release and upload new signatures > just let me know what to do. At this point I don't have reason to suspect your key is bad, more likely the scripting and/or my setup needs some update. But I don't expect to spend more effort on this unless it becomes a blocker for something. Thanks, - Julian
Re: Website prep work and questions (mainly about the 1.15 release notes)
Den sön 3 apr. 2022 kl 20:46 skrev Mark Phippard : > On Sun, Apr 3, 2022 at 2:43 PM Daniel Sahlberg > wrote: > > > > Den sön 3 apr. 2022 kl 19:55 skrev Mark Phippard : > >> > >> On Sun, Apr 3, 2022 at 1:40 PM Daniel Sahlberg > >> wrote: > >> > >> > It seems to be a problem mostly related to my key. I can't get the > committer signature list [1] to include my key (and thus the script doesn't > download it to the KEYS file). > >> > >> FWIW, I think you can sign the release even if you are not in KEYS. We > >> can also add you manually. > >> > >> Could it be as simple as your fingerprint in Apache LDAP needs the > spaces? > > > > > > I can't find the reference again but there were stated somewhere that > spaces within the string was not required. For example danielsh has a > fingerprint without spaces. > > > >> > >> I see dsahlberg 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 - key not > found > >> > >> And most of the other people (but not all) have spaces in their > fingerprint. > >> > >> FWIW, I could manually import your key using the server you indicated > >> but not the MIT server. > >> > >> $ gpg --keyserver pgp.mit.edu --recv-key > >> 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 > >> gpg: keyserver receive failed: No data > >> $ gpg --keyserver keys.openpgp.org --recv-key > >> 4FFCB55C0D0D9343CFB4611F28DB47329CFFDC63 > >> gpg: key 28DB47329CFFDC63: public key "Daniel Sahlberg > >> " imported > >> gpg: Total number processed: 1 > >> gpg: imported: 1 > >> > >> I am not sure how the ASF fetches the key. Maybe you need to upload it > >> somewhere else? > > > > > > Infra explicitly recommends using keys.openpgp.org [1]. > > > >> > >> If it gets worked out I can update the KEYS file. > >> > >> Mark > > > > > > Thanks for your help in resolving this issue. Let's see if there is any > change tonight when the list is updated again. > > Yeah, we have some time to try to find a solution. > The key is now available on people.apache.org, so re-running the script should fetch it. I guess it was the missing e-mail address. I think we should commit the script and update release procedures, but I will come back to this separately (replying to Nathan's mail). /Daniel
Re: Should tarballs contain __pycache__ dirs?
(I sent this message only for Nathan halfway by accident, so I resent
for the list)
Hello,
On 2022/04/04 8:47, Nathan Hartman wrote:
> Tarballs for prior versions (e.g., 1.14.0, 1.14.1) contain these
> (empty) directories:
>
> ./build/__pycache__
> ./build/generator/__pycache__
> ./build/generator/swig/__pycache__
>
> Are they supposed to be present in the tarball?
I don't think they are supposed.
Those directries should be cleaned in fast-clean and clean-swig-py
target in Makefile.in, like "*.pyc" files.
Here is a patch against trunk, but can't be applied against 1.14.x.
Cheers,
--
Yasuhito FUTATSUKI Index: Makefile.in
===
--- Makefile.in (revision 1899544)
+++ Makefile.in (working copy)
@@ -460,6 +460,7 @@
$(abs_srcdir)/build
$(top_srcdir)/subversion/tests/cmdline/svntest; \
do \
test -e $$d || continue; \
+ find $$d -name "__pycache__" -exec rm -rf {} ';' -prune; \
find $$d -name "*.pyc" -exec rm {} ';'; \
done
@@ -969,6 +970,7 @@
for d in $(SWIG_PY_SRC_DIR) $(SWIG_PY_DIR); \
do \
test -e $$d || continue; \
+ find $$d -name "__pycache__" -exec rm -rf {} ';' -prune; \
find $$d -name "*.pyc" -exec rm {} ';'; \
done
