[64bit] Updated: {nettle/libnettle4/libhogweed2/libnettle-devel}-2.7-1: A cryptographic library that is designed to fit easily in more or less any context
Hi New 64bit versions of 'nettle/libnettle4/libhogweed2/libnettle-devel' have been uploaded to a server near you. o Update to latest upstream release o Build for cygwin 1.7.19 with gcc-4.8.0 nettle NEWS: === This release includes an implementation of elliptic curve cryptography (ECC) and optimizations for the ARM architecture. This work was done at the offices of South Pole AB, and generously funded by the .SE Internet Fund. Bug fixes: * Fixed a bug in the buffer handling for incremental SHA3 hashing, with a possible buffer overflow. Patch by Edgar E. Iglesias. New features: * Support for ECDSA signatures. Elliptic curve operations over the following curves: secp192r1, secp224r1, secp256r1, secp384r1 and secp521r1, including x86_64 and ARM assembly for the most important primitives. * Support for UMAC, including x86_64 and ARM assembly. * Support for 12-round salsa20, salsa20r12, as specified by eSTREAM. Contributed by Nikos Mavrogiannopoulos. Optimizations: * ARM assembly code for several additional algorithms, including AES, Salsa20, and the SHA family of hash functions. * x86_64 assembly for SHA256, SHA512, and SHA3. (SHA3 assembly was included in the 2.6 release, but disabled due to poor performance on some AMD processors. Hopefully, that performance problem is fixed now). The ARM code was tested and benchmarked on Cortex-A9. Some of the functions use neon instructions. The configure script decides if neon instructions can be used, and the command line options --enable-arm-neon and --disable-arm-neon can be used to override its choice. Feedback appreciated. The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.6 and libhogweed.so.2.4, with sonames still libnettle.so.4 and libhogweed.so.2. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: [RFC] vim-minimal in Base?
On 5/13/2013 21:28, Yaakov (Cygwin/X) wrote: As these utilities are required by POSIX[1], should the vim-minimal package be added to Base? As long as when I install vim-kitchensink setup.exe knows how to quietly replace vim-minimal, I'm happy to see Vim in Base. Yes, truly happy. Gone are the days when I forget to install an editor on a new Cygwin install, then have to go re-run setup to fix that. I expect I'll now find myself running vim-minimal for months on some boxes, purely because I got it by default and it's good enough.
Re: [RFC] vim-minimal in Base?
On May 14 01:07, Warren Young wrote: On 5/13/2013 21:28, Yaakov (Cygwin/X) wrote: As these utilities are required by POSIX[1], should the vim-minimal package be added to Base? As long as when I install vim-kitchensink setup.exe knows how to quietly replace vim-minimal, I'm happy to see Vim in Base. Yes, truly happy. Gone are the days when I forget to install an editor on a new Cygwin install, then have to go re-run setup to fix that. I expect I'll now find myself running vim-minimal for months on some boxes, purely because I got it by default and it's good enough. In theory I agree. Still... What bugs me with vim-minimal on Fedora is usually that it's lacking basic vim functionality, even if it does not rely on external packages. I'm not quite sure if I remember correctly, but in the past I think I even had problems with color settings for syntax decoration, which forced me to use the vim-enhanced package. And I'm really not using any complicated stuff, like text folding or so... So my question is, is vim-minimal at least more or less feature complete as far as the feature doesn't require external dependencies? Apart from that, yes, vim-minimal should be a Base package, finally ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] vim-minimal in Base?
2013/5/14 Warren Young wrote: On 5/13/2013 21:28, Yaakov (Cygwin/X) wrote: As these utilities are required by POSIX[1], should the vim-minimal package be added to Base? As long as when I install vim-kitchensink setup.exe knows how to quietly replace vim-minimal, I'm happy to see Vim in Base. And the other way around? On existing installations it should not replace the full vim with the minimal one when it is added to Base. I expect I'll now find myself running vim-minimal for months on some boxes, purely because I got it by default and it's good enough. I had to do a clean installation today and installed vim-minimal. It worked fine for the occasional editing I needed to do. Thanks! Regards, Frank
Re: [RFC] vim-minimal in Base?
On 2013-05-14 02:59, Corinna Vinschen wrote: What bugs me with vim-minimal on Fedora is usually that it's lacking basic vim functionality, even if it does not rely on external packages. I'm not quite sure if I remember correctly, but in the past I think I even had problems with color settings for syntax decoration, which forced me to use the vim-enhanced package. And I'm really not using any complicated stuff, like text folding or so... So my question is, is vim-minimal at least more or less feature complete as far as the feature doesn't require external dependencies? I followed Fedora's lead and compiled vim-minimal --with-features=small, which excludes many features and avoids the need for vim-common (which requires perl and xxd, the former of which being what started this discussion), which e.g. syntax highlighting would require. But this affects *only* ex/vi; vim/view/vimdiff/vimtutor and evim/gvim/etc. are fully loaded, and now more than ever with the (dynamically loaded) lua/perl/python/python3/ruby interfaces. Apart from that, yes, vim-minimal should be a Base package, finally ;) Done. Yaakov
Re: [RFC] vim-minimal in Base?
2013/5/14 Yaakov (Cygwin/X): Apart from that, yes, vim-minimal should be a Base package, finally ;) Done. It overrides the symlink from vi to vim.exe and so this breaks my current setup: $ vi Error detected while processing /home/Frank/.vimrc: line1: E319: Sorry, the command is not available in this version: syntax on Press ENTER or type command to continue Any thought other then fixing the symlink manually? Regards, Frank
Re: [RFC] vim-minimal in Base?
2013/5/14 Frank Fesevur: It overrides the symlink from vi to vim.exe and so this breaks my current setup: $ vi Error detected while processing /home/Frank/.vimrc: line1: E319: Sorry, the command is not available in this version: syntax on Press ENTER or type command to continue Raspbian and Ubuntu install vim.tiny and vi.basic executables and then use alternatives to avoid the conflict. I don't very little about alternatives, but I guess something similar must be possible on cygwin as well. Install them as vim.tiny.exe and vim.basic.exe (or whatever the right name is) and add a postinstall script to vim-minimal and update the existing postinstall script for vim. The /etc/postinstall/vim.sh.done currently on my system uses update-alternatives and refers to /usr/bin/vim-nox.exe but that is not in /usr/bin. The postinstall of vim.common refers to vim-nox.exe as well. And I assume the order of running the postinstall scripts is important. Regards, Frank
Re: [RFC] vim-minimal in Base?
On May 14 04:35, Yaakov (Cygwin/X) wrote: On 2013-05-14 02:59, Corinna Vinschen wrote: What bugs me with vim-minimal on Fedora is usually that it's lacking basic vim functionality, even if it does not rely on external packages. I'm not quite sure if I remember correctly, but in the past I think I even had problems with color settings for syntax decoration, which forced me to use the vim-enhanced package. And I'm really not using any complicated stuff, like text folding or so... So my question is, is vim-minimal at least more or less feature complete as far as the feature doesn't require external dependencies? I followed Fedora's lead and compiled vim-minimal --with-features=small, :( which excludes many features and avoids the need for vim-common (which requires perl and xxd, the former of which being what started this discussion), which e.g. syntax highlighting would require. Er... what? Since when does syntax highlighting require perl? The old vim package I compiled when I maintained it was built with the --with-features=huge setting but didn't pull in any of the possible dependencies. No perl, no python, no ruby. But syntax highlighting worked fine. Apart from that, I guess calling vi (and that's what *many* users are used to) will now result in the same error Frank reported. Any chance to build vim-minimal with a bigger default set of features which is only based on avoiding external deps? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] vim-minimal in Base?
On 5/14/2013 04:19, Frank Fesevur wrote: Any thought other then fixing the symlink manually? I fixed it with alias vi=vim in my .bashrc. I've had to do that on assorted Linuxes before, too.
Re: [64bit] autoconf test for GetConsoleScreenBufferInfo
Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto: On May 14 20:30, marco atzeri wrote: I fear you might not like my answer: The problem here is NOT that the linking works, the problem is that, if the configure test is used to find out if we're running on Windows or not, it's simply not feasible anymore when taking x86_64 Cygwin into account. This has to be solved differently, for instance by not performing this test if configure already knows the target is Cygwin. not a big problem in this case I can split the check and add a conditional tests from AC_CHECK_FUNCS([_getvideoconfig gettextinfo GetConsoleScreenBufferInfo]) to AC_CHECK_FUNCS([_getvideoconfig gettextinfo ]) case $host_os in CYGWIN*) ;; *) AC_CHECK_FUNCS([GetConsoleScreenBufferInfo]) ;; esac the problem is to identify such issue on other softwares. Corinna Thanks Marco
Re: [64bit] autoconf test for GetConsoleScreenBufferInfo
On 5/14/2013 3:05 PM, Corinna Vinschen wrote: I fear you might not like my answer: The problem here is NOT that the linking works, the problem is that, if the configure test is used to find out if we're running on Windows or not, it's simply not feasible anymore when taking x86_64 Cygwin into account. This has to be solved differently, for instance by not performing this test if configure already knows the target is Cygwin. cygutils uses a similar check in its configury to figure out if it should build the windows-only getclip/putclip programs... AC_CHECK_STDCALL_FUNC([OpenClipboard],[void *]) AM_CONDITIONAL(WITH_WINDOWS_PROGRAMS, test $ac_cv_func_OpenClipboard = yes) But this still works for both 32- and 64- bit cygwin because those lines are *preceded* by AC_CHECK_HEADERS([... windows.h]) which insures that future test programs have #include windows.h in them (assuming the header is found), so the proper declaration/decorations are present for OpenClipboard. -- Chuck
