SSH key for upload access
Name: Marcos Vives Del Sol Package: libnfc5 BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQC2V6d+dnmA4Ln2NF+4yridNJeRKtFjtrEiw7spzd nErLpN99lXRl3uRFpDvPaIMzFqeVvycmb2LPaYaiWoRl5ngb7TCBQUIssSWGjVLSjhIvPk vGR+4exM/OonwY9DljCkCXoHMTsAJbqva0AlESLwbSQdahoqoWAbrY9wHNi0mK3G+w5H7Y eV1d3/ZwQjyXow8/y1CGB/k27wj9CHDaSZLCNm2Njshkhr5CMICsf6sWPEvIIkqzo8gA8x q61WPlO0FkTfEx6jl7hz7nRMUP8WZnqw7Ya7vAASTr0vVARXcGi2JzynMI+dVbcPj5NZ3I F9cWBCzVXUgNwpQqR0eibL END SSH2 PUBLIC KEY
Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2
On 25/02/2015 07:27, Thomas Wolff wrote: Am 19.02.2015 um 00:05 schrieb David Stacey: The following package has been updated in the Cygwin distribution: * mscgen-0.20-2 Mscgen is a small programme that parses Message Sequence Chart descriptions and produces PNG, SVG, EPS or server side image maps (ismaps) as the output. This release has been built with libgd3 and three patches from Fedora. Please rebuild the package with configure --with-freetype so the font selection option -F can be used. I tried rebuilding with '--with-freetype'. mscgen builds but always exits with an error code. This is because gdImageStringFT() always returns the string 'Could not set character size'. By default, the code is trying to use the 'helvetica' font. I have a goodly selection of font packages installed. Any ideas? Dave.
Re: SSH key for upload access
On Wed, 2015-02-25 at 21:28 +0100, Marcos Vives Del Sol wrote: Name: Marcos Vives Del Sol Package: libnfc5 This is incorrect. Please review the instructions at https://sourceware.org/cygwin-apps/package-upload.html and resend. -- Yaakov
SSH key for upload access
Name: Marcos Vives Del Sol Package: libnfc BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQC2V6d+dnmA4Ln2NF+4yridNJeRKtFjtrEiw7spzd nErLpN99lXRl3uRFpDvPaIMzFqeVvycmb2LPaYaiWoRl5ngb7TCBQUIssSWGjVLSjhIvPk vGR+4exM/OonwY9DljCkCXoHMTsAJbqva0AlESLwbSQdahoqoWAbrY9wHNi0mK3G+w5H7Y eV1d3/ZwQjyXow8/y1CGB/k27wj9CHDaSZLCNm2Njshkhr5CMICsf6sWPEvIIkqzo8gA8x q61WPlO0FkTfEx6jl7hz7nRMUP8WZnqw7Ya7vAASTr0vVARXcGi2JzynMI+dVbcPj5NZ3I F9cWBCzVXUgNwpQqR0eibL END SSH2 PUBLIC KEY
Re: UTF32 crash in poco-1.6.0 - Request for help
On 18/02/15 12:09, David Stacey wrote: The test causing the crash is the UnicodeConverterTest (Foundation/testsuite/src/UnicodeConverterTest.cpp). This is templated, and is instantiated with both UTF16 and UTF32 strings. The UTF16 case works correctly; it is the UTF32 instantiation that is crashing. I'm still trying to get to the bottom of this. The UTF16 test (the one that works) uses std::wstring, but the UTF32 test (the one that crashes) uses a custom string made with a 32-bit integer and corresponding traits class. If the UTF16 test is switched from using std::wstring to a similar custom string type then this also crashes. It would be easy to blame the custom string types, except that I can isolate the code in a stand-alone example that works fine. Plus, I've compiled Poco on Fedora 21 with the two custom string types, and again everything works fine. I tried compiling with all optimisation turned off, and now the code still crashes, just more slowly :-) I was hoping that I might get something more sensible out of gdb with -O0, but alas no. The next step is to produce a static build (again with all optimisation disabled) and then cut bits out of it until I come up with a minimal programme that exhibits the bug. Dave.
Re: UTF32 crash in poco-1.6.0 - Request for help
David Stacey writes: I'm still trying to get to the bottom of this. The UTF16 test (the one that works) uses std::wstring, but the UTF32 test (the one that crashes) uses a custom string made with a 32-bit integer and corresponding traits class. If the UTF16 test is switched from using std::wstring to a similar custom string type then this also crashes. It would be easy to blame the custom string types, except that I can isolate the code in a stand-alone example that works fine. Plus, I've compiled Poco on Fedora 21 with the two custom string types, and again everything works fine. I tried compiling with all optimisation turned off, and now the code still crashes, just more slowly :-) I was hoping that I might get something more sensible out of gdb with -O0, but alas no. The next step is to produce a static build (again with all optimisation disabled) and then cut bits out of it until I come up with a minimal programme that exhibits the bug. Is that code trying to switch encoding in any way? There's a bug in Perl (only 64bit) that throws a SEGV when doing that… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: UTF32 crash in poco-1.6.0 - Request for help
On 25/02/15 23:07, Achim Gratz wrote: David Stacey writes: I'm still trying to get to the bottom of this. The UTF16 test (the one that works) uses std::wstring, but the UTF32 test (the one that crashes) uses a custom string made with a 32-bit integer and corresponding traits class. If the UTF16 test is switched from using std::wstring to a similar custom string type then this also crashes. It would be easy to blame the custom string types, except that I can isolate the code in a stand-alone example that works fine. Plus, I've compiled Poco on Fedora 21 with the two custom string types, and again everything works fine. I tried compiling with all optimisation turned off, and now the code still crashes, just more slowly:-) I was hoping that I might get something more sensible out of gdb with -O0, but alas no. The next step is to produce a static build (again with all optimisation disabled) and then cut bits out of it until I come up with a minimal programme that exhibits the bug. Is that code trying to switch encoding in any way? There's a bug in Perl (only 64bit) that throws a SEGV when doing that… Thanks for your reply. I'll keep that in mind, but the crash I'm seeing occurs on both architectures. Dave.
Re: Upload fails with connection closed
Here it comes... put task-2.4.1-1.tar.xz Uploading task-2.4.1-1.tar.xz to /x86_64/release/task-2.4.1-1.tar.xz task-2.4.1-1.tar.xz 0%0 0.0KB/s --:-- ETAdebug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype e...@openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open - closed debug2: channel 0: rcvd eof debug2: channel 0: output open - drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain - closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug1: fd 0 clearing O_NONBLOCK debug3: fd 1 is not O_NONBLOCK Transferred: sent 36752, received 4384 bytes, in 62.9 seconds Bytes per second: sent 583.9, received 69.7 debug1: Exit status 1 Connection closed On Wed, Feb 25, 2015 at 9:41 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Hi Federico, On Feb 24 22:58, Federico Hernandez wrote: Hi, I am trying to upload the 64bit package for task. I can get into the sftp server. And the upload of the setup.hint file works. But when it comes to the package itself the upload fails with a connection closed right at the beginning of the file itself. Any ideas what the problem could be? Not really, no. In your upload dir I saw a tmp file of size 0, task-2.4.1-1-src.tar.xz.SftpXFR.53401 from your upload tries. I removed it. Can you run sftp with -oLogLevel=DEBUG3? This might give a clue what happens. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: SSH key for upload access
On Wed, 2015-02-25 at 23:17 +0100, Marcos Vives Del Sol wrote: Name: Marcos Vives Del Sol Package: libnfc Key installed, you may proceed with uploading. -- Yaakov
Re: Upload fails with connection closed
Hi Federico, On Feb 24 22:58, Federico Hernandez wrote: Hi, I am trying to upload the 64bit package for task. I can get into the sftp server. And the upload of the setup.hint file works. But when it comes to the package itself the upload fails with a connection closed right at the beginning of the file itself. Any ideas what the problem could be? Not really, no. In your upload dir I saw a tmp file of size 0, task-2.4.1-1-src.tar.xz.SftpXFR.53401 from your upload tries. I removed it. Can you run sftp with -oLogLevel=DEBUG3? This might give a clue what happens. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4X3t7zpJGt.pgp Description: PGP signature
