On May 31 17:08, Andrew Schulman wrote:
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),
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5
On 5/30/2015 8:01 AM, Achim Gratz wrote:
Marco Atzeri writes:
TeXLive had the same problem, that's one of the reasons perpetual
postinstall scripts were introduced. You can look at that to see how
Ken deals with that.
..
Regards,
Achim.
Hi Achim,
if I understood correctly a script called
Andrew Schulman writes:
OK, here you go. The patch is a bit large, because I took the opportunity to
reorganize the text a bit and add a new section showing how to upload packages
the automated way using cygport up. The complete revised page is at
On Jun 1 18:17, Achim Gratz wrote:
Andrew Schulman writes:
OK, here you go. The patch is a bit large, because I took the opportunity
to
reorganize the text a bit and add a new section showing how to upload
packages
the automated way using cygport up. The complete revised page is at
Marco Atzeri writes:
if I understood correctly a script called
/etc/postinstall/zp_octave_finish.dash
will be always executed at the end of the postinstall script
sequence and never renamed as .done.
Yes.
I am moving the octave update script in
/var/lib/octave/update_packages_list
Corinna Vinschen writes:
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
Corinna Vinschen writes:
Running your commands on sourceware itself shows the exact same
results when accessing the public host RSA key:
$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
1024 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23
/etc/ssh/ssh_host_rsa_key.pub (RSA)
$ awk '{print
On Sat, 2015-05-30 at 12:21 +0100, David Stacey wrote:
pugixml is a lightweight C++ XML processing library. It is present in
most Linux distros [1] and is a dependency of mkvtoolnix. Fedora and
Centos both name the library package pugixml rather than libpugixml, and
that naming has been
On Sat, 2015-05-30 at 12:14 +0100, David Stacey wrote:
libmatroska is a C++ library to parse Matroska files (*.mkv, *.mka). It
requires libebml [1].
libmatroska is present in most Linux distros [2]. It's also present in
Cygwin Ports, albeit at an earlier version, so Yaakov should have
On Jun 1 20:11, Achim Gratz wrote:
Corinna Vinschen writes:
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:
On Sat, 2015-05-30 at 12:05 +0100, David Stacey wrote:
libebml is a library for reading and writing files with the Extensible
Binary Meta Language, a binary pendant to XML. It is a dependency of
mkvtoolnix.
And they were even nice enough to finally use a real build system.
libebml is
Corinna Vinschen writes:
Since it seems you plan to use libcrypto from OpenSSL anyway:
https://gist.github.com/barrysteyn/7308212#file-base64decode-c
I don't. Why do you think so?
Because of the openssl branch in Git.
This was a drop-in replacement for Digest::MD5. Anything else I'll
let
On Sat, 2015-05-30 at 12:31 +0100, David Stacey wrote:
mkvtoolnix is a collection of tools for manipulating Matroska files
(*.mkv, *.mka). It features command line utilities and a GUI front end.
It requires libebml [1], libmatroska [2] and pugixml [3].
This would be a nice addition.
The 5.22.0 release of Perl has happened on schedule. The Cygwin
packages are building at the moment, I will need another day or two for
the distribution rebuilds.
The current plan is that the packages should be available on my server
by the end of the week latest. Depending on how the
On Jun 1 21:49, Achim Gratz wrote:
Corinna Vinschen writes:
Since it seems you plan to use libcrypto from OpenSSL anyway:
https://gist.github.com/barrysteyn/7308212#file-base64decode-c
I don't. Why do you think so?
Because of the openssl branch in Git.
Oh, that was a bad idea. I
Marco,
PostgreSQL 9.4.2 contains fixes for three security vulnerabilities:
http://www.postgresql.org/about/news/1587/
--
Yaakov
Corinna Vinschen writes:
Because of the openssl branch in Git.
Oh, that was a bad idea. I won't remove the branch for historical
reasons, but we don't really want to link agaionst OpenSSL when we
already link against gcrypt.
OK, makes sense.
This was a drop-in replacement for
On 6/2/2015 12:20 AM, Yaakov Selkowitz wrote:
Marco,
PostgreSQL 9.4.2 contains fixes for three security vulnerabilities:
http://www.postgresql.org/about/news/1587/
--
Yaakov
I know, I built last week and immediately I received the announce of
coming 9.4.3 so I postponed the upload.
Today
19 matches
Mail list logo