Achim Gratz | 26 Nov 19:17 2015

AVX on Cygwin

You may have noted that the recent gmp update makes problems on some
machines and two of the three reports come from Broadwell CPU.  There is
one thing that did indeed change with the update and that is use of the
AVX ADC instruction on Broadwell/Skylake.  Is it possible that somehow
the stack model or some register save/restore is different on Cygwin
that would produce that problem?  I can only test on SandyBridge and
IvyBridge for Intel and these have no problem.


+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:

[Bug setup.exe/19290] New: Setup failed to start properly

            Bug ID: 19290
           Summary: Setup failed to start properly
           Product: cygwin
           Version: 1.7.0
            Status: NEW
          Severity: normal
          Priority: P2
         Component: setup.exe
          Assignee: cygwin-apps at cygwin dot com
          Reporter: loctdse61622 at fpt dot
  Target Milestone: ---

Created attachment 8812

Step 1: Double click setup.exe
Step 2: Nothing happens


You are receiving this mail because:
You are the assignee for the bug.
Aaron Schneider | 23 Nov 10:02 2015

Python not reading result from bash command

Trying to read an argument as string, however doesn't work on python for cygwin. Tested on Python 3.5.0
(32-bit) from Python Software Foundation and works perfectly.
import datetime
import sys
my_date = str(sys.argv[1])
temp_date = datetime.datetime.strptime(some_date, "%Y%m%d%H%M%S")

$ python $(adb shell 'su 0 date +"%Y%m%d%H%M%S"')
Traceback (most recent call last):
  File "", line 32, in <module>
    temp_date = datetime.datetime.strptime(some_date, "%Y%m%d%H%M%S")
  File "/usr/lib/python2.7/", line 328, in _strptime
ValueError: unconverted data remains: 		 	   		  
Jon Turney | 20 Nov 17:18 2015

Updated: xorg-server-1.18.0-1 (TEST)

The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.18.0-1

These packages contain XWin and the other X.Org X11 servers.

This is the first release of the xserver 1.18 series.  It is currently 
available as a test release, and will be made stable in approximately 
two weeks, if no major regressions are reported.

Please try test releases and report problems to the Cygwin mailing list. 
  Testing helps ensure good releases!

In addition to upstream fixes and improvements [1][2][3], the following 
cygwin-specific changes have been made since 1.17.4-1:

* The internal window manager for multiwindow mode has been converted 
from libX11 to xcb
* The obsolete, undocumented -internalwm option is accepted but ignored.
* In multiwindow mode, _NET_WM_WINDOW_TYPE_SPLASH_SCREEN, used by some 
clients in error, is accepted as equivalent to the correct 
* In multiwindow mode, gtk+ applications with client-side decorations 
but a window manager frame (e.g. gedit 3.14) should now be given a 
resizeable frame, when appropriate.
* Remove the "Applications" submenu from the default XWinrc for new 
installations, as redundant to xwin-xdg-menu.
* In multiwindow mode, handle _NET_WM_STATE messages to maximize, 
iconify and restore.
(Continue reading)

Alexey Sokolov | 18 Nov 11:59 2015

Perl and crypt.h

Hi Achim,
I think perl package should depend on libcrypt-devel on x86_64.
Otherwise, here's error while embedding perl:

> In file included from /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/op.h:635:0,
>                  from /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/perl.h:3736,
>                  from /home/q/KVIrc/src/modules/perlcore/libkviperlcore.cpp:68:
> /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/reentr.h:104:26: fatal error: crypt.h: No such
file or directory
>  #       include <crypt.h>
>                           ^

It seems to works without libcrypt-devel on i686 though.

Corinna Vinschen | 16 Nov 10:43 2015

Re: [ITA] cygutils

Hi Mark,

On Nov 15 22:02, Mark Geisert wrote:
> I think my ITA is sorted out well enough to be reviewed.  If you find a
> sharp edge somewhere, please don't assume it's maintainer preference; it's
> more likely maintainer ignorance so please do fill me in.
> --------
> --------
> [...]

Packaging looks good.  Just one nit:  While this is as Chuck did it way
back when, I think the files under /usr/share/doc should go into the
base cygutils package, rather than the cygutils-extra package, i.e.

(Continue reading)

Aaron Schneider | 13 Nov 17:02 2015

Perl: fails to install CPAN PBKDF2 module

Just running the usual:

perl -MCPAN -e shell

cpan[1]> install  Crypt::OpenSSL::PBKDF2
Reading '/home/Aaron/.cpan/Metadata'
  Database was generated on Thu, 12 Nov 2015 21:17:02 GMT
Running install for module 'Crypt::OpenSSL::PBKDF2'
Checksum for
/home/Aaron/.cpan/sources/authors/id/S/SK/SKUPSY/OpenSSL/Crypt-OpenSSL-PBKDF2-0.04.tar.gz ok
Scanning cache /home/Aaron/.cpan/build for sizes
Configuring S/SK/SKUPSY/OpenSSL/Crypt-OpenSSL-PBKDF2-0.04.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -lcrypto
Warning (mostly harmless): No library found for -lssl
Generating a Unix-style Makefile
Writing Makefile for Crypt::OpenSSL::PBKDF2
Writing MYMETA.yml and MYMETA.json
  /usr/bin/perl Makefile.PL -- OK
Running make for S/SK/SKUPSY/OpenSSL/Crypt-OpenSSL-PBKDF2-0.04.tar.gz
cp blib/lib/Crypt/OpenSSL/
AutoSplitting blib/lib/Crypt/OpenSSL/ (blib/lib/auto/Crypt/OpenSSL/PBKDF2)
Running Mkbootstrap for Crypt::OpenSSL::PBKDF2 ()
chmod 644 ""
"/usr/bin/perl.exe" "/usr/lib/perl5/5.22/ExtUtils/xsubpp"  -typemap
"/usr/lib/perl5/5.22/ExtUtils/typemap" -typemap "typemap"  PBKDF2.xs> PBKDF2.xsc && mv
(Continue reading)

Mark Geisert | 10 Nov 02:54 2015

Still unable to 'git push' or ssh to sourceware

Apologies for my continued stumbling around with this.  I'm enough of a 
newbie in several necessary skills that I can't seem to get a handle on 
what's going wrong.

I had assumed that having sent my "SSH key for upload access", it goes to 
the same location as my original key supplied on the form.  That original 
key I supplied always provoked an 'enter passphrase' prompt when ssh or 
git contacted sourceware even though I had never supplied a passphrase 
for it.  OK, maybe sourceware requires passphrases so I generated a new 
key with a passphrase.  That's the key I sent recently as "SSH key for 
upload access".

The only way I could think of to test authentication without doing 
anything potentially damaging was this command:
     ssh -v -v mgeisert@... appendkey < /dev/null

Here's the resulting debug log:
OpenSSH_6.9p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /home/Mark/.ssh/config
debug1: /home/Mark/.ssh/config line 1: Applying options for
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/Mark/.ssh/ type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/Mark/.ssh/ type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
(Continue reading)

Mark Geisert | 7 Nov 11:54 2015

SSH key for upload access

Name: Mark Geisert
Package: cygutils

Adam Dinwoodie | 5 Nov 22:08 2015

Cygport uploading different files to different arch directorys for noarch packages

I'm seeing what seems to be some very odd behaviour from Cygport when
uploading noarch packages: Cygport uploads all the packages for the
64-bit architecture, but only the main and source packages for 32-bit

Mostly I'm looking to know whether other people experience the same
behaviour when using Cygport to upload noarch packages -- the behaviour
I'm seeing is entirely reproducible on my system.

I've done some digging, and I'm utterly baffled, so I'm going to post
this here in case anyone else has any cunning theories; arguably this is
into the realms of an lftp/cygport/bash bug, so if folk want me to take
it to the main list, I'm happy to do that too.

Here's what I'm seeing (having commented out the !ready line in
pkg_upload.cygpart to allow testing, although I've checked both ways and
that doesn't make a difference):

    $ cygport fzf.cygport upload
    >>> Uploading fzf-0.10.8-1.noarch
    >>> Running lftp sftp://cygwin: <at>
    cd ok, cwd=/x86/release
    Transferring file `fzf-0.10.8-1-src.tar.xz'
    Transferring file `fzf-0.10.8-1.tar.xz'
    Transferring file `setup.hint'
    cd ok, cwd=/x86_64/release
    New: 3 files, 0 symlinks
    116628 bytes transferred in 1 second (84.4 KiB/s)
    Transferring file `fzf-0.10.8-1-src.tar.xz'
    Transferring file `fzf-0.10.8-1.tar.xz'
(Continue reading)

Yaakov Selkowitz | 3 Nov 09:06 2015

cygport: 'announce' feature branch

I just created a new 'announce' feature branch in cygport git:

The new 'announce' command generates an announcement template from
the .cygport file based on NAME/VERSION/RELEASE, PKG_NAMES, and
DESCRIPTION, to which you can easily add release-specific information,
and then sends the message via an SMTP server.  Note that this adds
dependencies on perl-Authen-SASL, perl-MIME-tools, and
perl-Net-SMTP-SSL, and requires several new SMTP_* configuration options
in cygport.conf.

Feedback and patches welcome.