Re: Upload fails with connection closed
On 2/27/2015 12:59 PM, Federico Hernandez wrote: Hi again. No problem. I will prepare some URLs and mail you them this evening. I will also try alternativ clients. Thanks for your efforts. /F lftp works fine for me. Regards Marco
Re: [ITP] gtkperf 0.40
On Fri, 2015-02-27 at 08:49 -0500, Michael DePaulo wrote:
The benefit to Cygwin is that we will have a commonly used[1]
benchmark for testing Cygwin/X performance.
Thank you Jon Turney for helping me package this.
https://github.com/mikedep333/gtkperf-cygport
Currently at commit e707eaa
Why the NO_AUTOPOINT=1?
You should also change the following:
-SRC_URI=http://downloads.sourceforge.net/gtkperf/gtkperf_0.40.tar.gz
+HOMEPAGE=http://gtkperf.sourceforge.net/;
+SRC_URI=mirror://sourceforge/gtkperf/gtkperf_${VERSION}.tar.gz
${VERSION} should be used in SRC_URI to prevent mistakes when (if?) this
package gets a new version upstream.
--
Yaakov
[ITP] gtkperf 0.40
The benefit to Cygwin is that we will have a commonly used[1] benchmark for testing Cygwin/X performance. Thank you Jon Turney for helping me package this. https://github.com/mikedep333/gtkperf-cygport Currently at commit e707eaa https://apps.fedoraproject.org/packages/gtkperf https://packages.debian.org/jessie/gtkperf [1] It is included in the Phoronix Test Suite: http://openbenchmarking.org/test/pts/gtkperf Note that 1.2.1 is their version number for their packaging and benchmarking scripts, not a new upstream gtkperf version. category: X11 requires: libatk1.0_0 libgdk_pixbuf2.0_0 libglib2.0_0 libgtk2.0_0 libintl8 libpango1.0_0 font-adobe-dpi75 sdesc: GTK+ performance test ldesc: GtkPerf is an application designed to test GTK+ performance. The point is to create common testing platform to run predefined GTK+ widgets and this way define the speed of device/platform.
Re: Upload fails with connection closed
Hi Federico, On Feb 26 11:38, Corinna Vinschen wrote: On Feb 26 00:44, Federico Hernandez wrote: 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 Means: Write Failed I can reproduce this. I tried to upload to my staging dir as well as to your staging dir. I can't upload normally either. Given the latest uploads, it was no problem two days ago at least. This only affects the Cygwin package upload, which uses a perl module NET::SFTP::SftpServer. If I use a normal sftp server, uploading works. The directory permissions are looking perfectly normal, too. I can upload short files but nothing bigger than about 12K. In the meantime I set up the same perl stuff on my local machine and even there I can reproduce this problem. I'm trying to debug this, but I'm not a perl wizard at all. Is somebody available for help? Via IRC, perhaps (freenode #cygwin-developers)? I haven't fond a solution to this problem yet. Given that most people don't seem to be affected, it might have something to do with a setting on the client side, bot for the life of me I can figure out what the difference might be. For the time being, can you just provide URLs to the 32 and 64 bit packages and we'll upload them using other means. Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTlbFCrljfE.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2
On 26.02.2015 23:56, David Stacey wrote: On 26/02/2015 11:58, Thomas Wolff wrote: On 25.02.2015 21:34, David Stacey wrote: 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? I had similar problems until I found out how to configure fonts. This is very poorly documented. With /etc/fonts/fonts.conf pointing to ~/.fonts, it is actually sufficient to link your font directory to ~/.fonts and you can address all fonts contained therein (including subfolders) by their name like in mscgen -T png -F Droid Sans I'm not sure you need to edit /etc/fonts/fonts.conf. No, because it already lists ~/.fonts which gives a user an easy opportunity to make his/her favourite fonts available without digging into fontconfig (if only this option were documented...). By default, this includes /usr/share/fonts, so any font therein should be accessible to mscgen. You would only need to do this if you wanted to use fonts in non-standard locations - such as those from texlive-collection-fontsextra. I wonder if this is a problem with font types? 'fc-match helvetica' matches a PCF font, and that might explain the error, if libgd3 is trying to scale a bitmap font. But a TrueType Font such as 'Luxi Sans' works. Should I just patch mscgen so that the default font is a TrueType font? That might be a good idea. Be sure to include a dependency to the font package you choose for default, e.g. font-bh-ttf for Luxi Sans, or font-bitstream-vera-ttf for Bitstream Vera Sans; font-cantarell-otf for Cantarell is also a good choice. (I'd suggest not to choose a default from a texlive font package because they are too big for a dependency.) -- Thomas
Re: [ITP] gtkperf 0.40
On Fri, Feb 27, 2015 at 12:37 PM, Yaakov Selkowitz
yselkow...@cygwin.com wrote:
On Fri, 2015-02-27 at 08:49 -0500, Michael DePaulo wrote:
The benefit to Cygwin is that we will have a commonly used[1]
benchmark for testing Cygwin/X performance.
Thank you Jon Turney for helping me package this.
Now at revision c81e08d
https://github.com/mikedep333/gtkperf-cygport
https://github.com/mikedep333/gtkperf-cygport
Currently at commit e707eaa
Why the NO_AUTOPOINT=1?
Otherwise, you run into this problem with the very old autotools:
make all-recursive
make[1]: Entering directory '/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build'
Making all in intl
make[2]: Entering directory
'/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build/intl'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build/intl'
Making all in po
make[2]: Entering directory
'/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build/po'
make[2]: *** No rule to make target 'Makevars', needed by 'Makefile'. Stop.
make[2]: Leaving directory
'/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build/po'
Makefile:363: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/src/gtkperf-cygport/gtkperf-0.40-1.i686/build'
Makefile:273: recipe for target 'all' failed
make: *** [all] Error 2
*** ERROR: make failed
I added a 3 line comment about this.
You should also change the following:
-SRC_URI=http://downloads.sourceforge.net/gtkperf/gtkperf_0.40.tar.gz
+HOMEPAGE=http://gtkperf.sourceforge.net/;
+SRC_URI=mirror://sourceforge/gtkperf/gtkperf_${VERSION}.tar.gz
${VERSION} should be used in SRC_URI to prevent mistakes when (if?) this
package gets a new version upstream.
Done.
-Mike
Re: Upload fails with connection closed
Hi again. No problem. I will prepare some URLs and mail you them this evening. I will also try alternativ clients. Thanks for your efforts. /F On Fri, Feb 27, 2015 at 9:47 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Hi Federico, On Feb 26 11:38, Corinna Vinschen wrote: On Feb 26 00:44, Federico Hernandez wrote: 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 Means: Write Failed I can reproduce this. I tried to upload to my staging dir as well as to your staging dir. I can't upload normally either. Given the latest uploads, it was no problem two days ago at least. This only affects the Cygwin package upload, which uses a perl module NET::SFTP::SftpServer. If I use a normal sftp server, uploading works. The directory permissions are looking perfectly normal, too. I can upload short files but nothing bigger than about 12K. In the meantime I set up the same perl stuff on my local machine and even there I can reproduce this problem. I'm trying to debug this, but I'm not a perl wizard at all. Is somebody available for help? Via IRC, perhaps (freenode #cygwin-developers)? I haven't fond a solution to this problem yet. Given that most people don't seem to be affected, it might have something to do with a setting on the client side, bot for the life of me I can figure out what the difference might be. For the time being, can you just provide URLs to the 32 and 64 bit packages and we'll upload them using other means. Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
