Is the key fingerprint posted anywhere on cygwin.com or sourceware.org?
I can't
find it. If not, would someone mind adding it to the Uploading Packages
to
cygwin.com page
(https://sourceware.org/cygwin-apps/package-upload.html), so
people can verify it?
Good idea.
On 5/29/2015 9:26 PM, Achim Gratz wrote:
Achim Gratz writes:
[…]
The upstream release of Perl 5.22.0 is still scheduled for June 1st.
This means that again Yaakov as well as Marco and Volker need to
re-release those.
I need to hear from you three when you are ready to do these updates,
Corinna Vinschen writes:
Can somebody please remove it directly on sourceware so that the
setup.ini files can be generated correctly?
Is this fixed? I don't see a perl-Term-ReadKey-debuginfo dir.
John Turney was on IRC yesterday and removed it. All is well now.
:-)
Regards,
Achim.
--
Marco Atzeri writes:
perl-Graphics-Magick and perl-Image-Magick are available in test.
Thanks.
I don't think postgresql-plperl is urgent, so I will wait upstream 9.4.3
that should arrive in one week to make the double update.
If you need it now let me know.
I don't need it. But if anybody
Andrew Schulman writes:
I show the SFTP key fingerprint for cygwin.com as
SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM
Can anyone please confirm that?
ssh-keygen -lvf cygwin.com.pub
1024 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23 [MD5] cygwin.com (RSA)
+--[ RSA 1024]+
|
On May 31 09:15, Achim Gratz wrote:
Andrew Schulman writes:
I show the SFTP key fingerprint for cygwin.com as
SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM
Can anyone please confirm that?
ssh-keygen -lvf cygwin.com.pub
1024 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23
On May 30 10:33, Achim Gratz wrote:
Yaakov Selkowitz writes:
This looks like it has been done already. Am I missing something?
I seem to be unable to remove the debuginfo directory of the obsoleted
package:
upset: x86_64 release in unstable state: couldn't move
On May 29 21:37, Achim Gratz wrote:
The new SHA512 checksums are rather lengthy. Could we switch them to
Base64 (perhaps the URL and file safe variant) instead of the current
hex encoding instead (maybe with an SHA512: prefix if we want to support
both)?
Not for the time being. Sombody
