Re: Base Cygwin now requires Python?
On 16 May 2013 07:41, Steven Penny wrote: Because of this dependency line mintty cygutils Hmm, mintty doesn't depend on cygutils anymore since setup.exe creates the Cygwin Terminal shortcut for it, and its setup.hint reflects that. Yet setup.ini does indeed contain the following line for mintty: requires: bash cygutils cygwin Is the problem that the setup.hint doesn't contain a 'requires:' line at all (since mintty has no dependencies apart from the implicit 'cygwin')? Does upset keep previous dependencies in that case? Andy
Re: Base Cygwin now requires Python?
On 16 May 2013 23:59, Christopher Faylor wrote: On Thu, May 16, 2013 at 07:39:59PM +0100, Andy Koppe wrote: On 16 May 2013 07:41, Steven Penny wrote: Because of this dependency line mintty cygutils Hmm, mintty doesn't depend on cygutils anymore since setup.exe creates the Cygwin Terminal shortcut for it, and its setup.hint reflects that. Yet setup.ini does indeed contain the following line for mintty: requires: bash cygutils cygwin Is the problem that the setup.hint doesn't contain a 'requires:' line at all (since mintty has no dependencies apart from the implicit 'cygwin')? Does upset keep previous dependencies in that case? What??? No! Of course it doesn't! What a daft notion! Oh. Actually, now that I think of it, the way upset is run, it's the union of an existing setup.ini and setup.hint. So, if there is no requires: line it would get pulled from setup.ini. I've taken the liberty of adding a requires: line to mintty's setup.hint. Thanks, I've updated the copy in mintty svn accordingly. Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 14 April 2013 04:45, Yaakov (Cygwin/X) wrote: On 2013-04-13 00:55, Andy Koppe wrote: Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. As Corinna already pointed out, this is a sign that the setup.hint generation succeeded, and in this case the requires: line is blank (and rightfully so, since mintty uses only cygwin1.dll and Win32 APIs). If it had failed, there would have been a warning about a missing .hint file instead. I've also tried installing cygport from git master but got this after running ./autogen.sh make: make: *** No rule to make target `data/gnuconfig/config.guess', needed by `all-am'. Stop. This is one quirk of git that I've never understood: git clone does not expand submodules by default without the --recursive flag. Run git submodule update --init to get these after a clone. Yep, that did it. BTW: _CYGPORT_RESTRICT_postinst_doc_=1 Variables beginning with an underscore are for internal use only. This should be RESTRICT=postinstall-doc. But what problem did you encounter to necessitate this? Took me a while to remember, but it's there to stop the LICENSE file from being installed, because that's the same as /usr/share/doc/common-licenses/GPL-3.0. RESTRICT=postinstall-doc didn't do this, but RESTRICT=postinst_doc does. Thanks, Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 13 April 2013 10:03, Corinna Vinschen wrote: On Apr 13 06:55, Andy Koppe wrote: On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:37, Charles Wilson wrote: #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works, and also handles inter-subpackage dependencies (e.g. apps in foo will dep libfooX, and implibs in libfoo-devel will dep the corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION (there are also subpackage-specific variants of these) and omit the hint files from $C; at the end of the package stage, cygport will show you the dependencies it computes for each package so you can check them. I'm struggling to get setup.hint generation to work. Is it supported with cygport 0.11.3 as currently in the distros? Below is the mintty.cygport I've got. Do I need to do anything else to trigger it? Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. Sure? Did you look into the dist subdir in your builddir after the install stage? It should contain a complete mintty dir for upload. You're right, there is, inside the working directory created by cygport, and it looks correct. I'd expected the setup.hint to appear next to the .cygport and the packaged .tar.bz2 files. Thanks, Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote:
On 2013-04-11 07:37, Charles Wilson wrote:
#2) Is it possible to use the auto-setup.hint-generator functionality
for multi-part package sets (e.g. which contain multiple separate
tarballs, in addition to -src and -debuginfo)? If so, how?
Yes; it just works, and also handles inter-subpackage dependencies (e.g.
apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION
(there are also subpackage-specific variants of these) and omit the hint
files from $C; at the end of the package stage, cygport will show you the
dependencies it computes for each package so you can check them.
I'm struggling to get setup.hint generation to work. Is it supported
with cygport 0.11.3 as currently in the distros? Below is the
mintty.cygport I've got. Do I need to do anything else to trigger it?
Cygport prints mintty requires: at the end, which is correct as
it doesn't require anything beyond the Cygwin DLL, but there's no
setup.hint.
I've also tried installing cygport from git master but got this after
running ./autogen.sh make:
make: *** No rule to make target `data/gnuconfig/config.guess', needed
by `all-am'. Stop.
Andy
mintty.cygport:
NAME=mintty
VERSION=1.2-beta1
RELEASE=1
CATEGORY=Base Shells
DEPEND=make gcc-core w32api
HOMEPAGE=http://mintty.googlecode.com;
SRC_URI=http://mintty.googlecode.com/files/mintty-${PV}-src.tar.bz2;
SUMMARY=Terminal emulator with native Windows look and feel
DESCRIPTION=\
Mintty is a terminal emulator for Cygwin. It is based on code
from PuTTY 0.60 by Simon Tatham and team.
Features include:
* Xterm-compatible terminal emulation.
* Full Unicode support.
* Native Windows user interface that tries to keep things simple.
* Graphical options dialog. Options stored in a text file.
* Drag drop and copy paste of text, files and folders.
* Extensive mouse support.
* Window transparency.
_CYGPORT_RESTRICT_postinst_doc_=1
src_compile() {
lndirs
cd ${B}
cygmake
}
src_install() {
cd ${B}
dobin mintty.exe
insinto /usr/share/man/man1
doins docs/mintty.1
dodoc COPYING
dodoc LICENSE.Oxygen
dodoc LICENSE.PuTTY
}
Re: [64bit RFU] emacs-24.3-3
On 6 April 2013 22:27, Corinna Vinschen wrote:
On Apr 6 16:50, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/emacs
wget -x -nH --cut-dirs=3 \
${D}/emacs-24.3-3-src.tar.bz2 \
${D}/emacs-24.3-3.tar.bz2 \
${D}/emacs-X11/emacs-X11-24.3-3.tar.bz2 \
${D}/emacs-X11/setup.hint \
${D}/emacs-debuginfo/emacs-debuginfo-24.3-3.tar.bz2 \
${D}/emacs-debuginfo/setup.hint \
${D}/emacs-el/emacs-el-24.3-3.tar.bz2 \
${D}/emacs-el/setup.hint \
${D}/emacs-w32/emacs-w32-24.3-3.tar.bz2 \
${D}/emacs-w32/setup.hint
Done.
People testing these packages should be aware that the postinstall
scripts will fail to set up the usual /usr/bin/emacs and
/usr/bin/emacsclient symlinks because the alternatives package is
not yet available. So you will have to create your own symlinks if
you want them.
Unfortunately I can't upload. The 64bit/release/emacs dir has only
write permissions for Andy Koppe.
The same goes for yasm and libggi, which are 755 for Marco Atzeri
only. This is weird, the release parent dir has 2775 permissions
and the subdirs should have the same permissions.
Sorry about that.
Andy, Marco, can you please chmod -R g+w the aforementioned directories
ASAP? Thank you.
Done, and umask adjusted in ~/.bashrc.
Andy
Re: [64bit RFU] alternatives-1.3.30c-10
On 6 April 2013 22:37, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/alternatives
wget -x -nH --cut-dirs=3 \
${D}/alternatives-1.3.30c-10-src.tar.bz2 \
${D}/alternatives-1.3.30c-10.tar.bz2 \
${D}/setup.hint
Done.
Thanks,
Andy
Re: 64bit: man misconfigured
On 30 March 2013 11:17, Thomas Wolff wrote: Due to changed /etc/man.conf, man64 uses escape sequences for bold display while man32 uses backspace combinations. Backspace combinations? However, the escape sequences are not by default interpreted by less (less -r would work), so that PAGER=less man ... produces garbage display. The 32-bit /etc/man.conf has this: PAGER /usr/bin/less -isrR Whereas the 64-bit one has this: PAGER /bin/less -is As Thomas alludes to, the -r option tells 'less' to pass escape characters through to the terminal rather than turn them into a highlighted ESC. The 32-bit man sources have a source patch that contains the following, so I guess that hasn't been applied in the 64-bit version. -DEFAULTLESSOPT=-is +DEFAULTLESSOPT=-isrR Andy
Re: 64bit: man misconfigured
On 1 April 2013 13:11, Thomas Wolff wrote: Am 01.04.2013 14:03, schrieb Andy Koppe: On 30 March 2013 11:17, Thomas Wolff wrote: Due to changed /etc/man.conf, man64 uses escape sequences for bold display while man32 uses backspace combinations. Backspace combinations? The traditional Unix way to indicate bold, by explicit overprinting, like B^HBO^HOL^HLD^HD. Compare man ls ls.man.out with 32/64 bit versions. Oh, I see. Apparently that's due to another change in the 32-bit source patch, where the -c option is added to the 'nroff' command line. (Note besides: confused as to how that overprinting trick could possibly work in a terminal, I learned that it is implemented by 'less', by translating it to SGR sequences. If you send ls.man.out directly to the terminal, you don't see any bold or underline because a backspace followed by a character will simply replace the previous character rather than do anything special.) Andy
Re: 64bit package: mined
On 30 March 2013 19:44, Thomas Wolff wrote: wget http://towo.net/mined/cygwin/64/mined-2012.22-0.tar.bz2 wget http://towo.net/mined/cygwin/64/mined-2012.22-0-src.tar.bz2 Done. # is this needed? (identical to 32 bit source package) 'fraid so, as it's a completely separate distro. A setup.hint is also needed. I've copied the one from the 32-bit distro. Andy
Re: [64bit RFU] emacs-24.3-2
On 29 March 2013 23:55, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/emacs
wget -x -nH --cut-dirs=3 \
${D}/emacs-24.3-2-src.tar.bz2 \
${D}/emacs-24.3-2.tar.bz2 \
${D}/setup.hint \
${D}/emacs-debuginfo/emacs-debuginfo-24.3-2.tar.bz2 \
${D}/emacs-debuginfo/setup.hint
Done. GEN-sware reported no errors against this.
Andy
Re: RFU: cppcheck-1.59-1
On 29 March 2013 22:14, Chris Sutcliffe ir0nh...@gmail.com wrote: Please upload: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-1.59-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-1.59-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.59-1.tar.bz2 --- Please feel free to remove anything older than 1.58-1. Done. Andy
Re: building 64 bit packages
On 28 March 2013 13:36, Corinna Vinschen wrote: Hi guys, right now it's only possible to build a 64 bit package using the native toolchain. Yaakov is working on a 32 bit cross toolchain, but this may take another couple of days. Anyway, the latest 64 bit Cygwin DLL seems to be stable enough to call it post-alpha or pre-beta or something like that. So I'd like to invite all of you maintainers to participate in building 64 bit packages, foremost those packages other packages rely upon, like libraries. If you have a 64 bit machine, please try the test release and see if you can build your packages. For the time being, just download ftp://cygwin.com/pub/cygwin/64bit/setup64.exe, install the test distro (what's already existing of it) and do your worst ;) Great stuff. Thanks to the kind person who contributed a mintty package. Andy
Re: building 64 bit packages
On 28 March 2013 14:12, Corinna Vinschen wrote: On Mar 28 15:09, Corinna Vinschen wrote: On Mar 28 14:05, Andy Koppe wrote: On 28 March 2013 13:36, Corinna Vinschen wrote: Hi guys, right now it's only possible to build a 64 bit package using the native toolchain. Yaakov is working on a 32 bit cross toolchain, but this may take another couple of days. Anyway, the latest 64 bit Cygwin DLL seems to be stable enough to call it post-alpha or pre-beta or something like that. So I'd like to invite all of you maintainers to participate in building 64 bit packages, foremost those packages other packages rely upon, like libraries. If you have a 64 bit machine, please try the test release and see if you can build your packages. For the time being, just download ftp://cygwin.com/pub/cygwin/64bit/setup64.exe, install the test distro (what's already existing of it) and do your worst ;) Great stuff. Thanks to the kind person who contributed a mintty package. That's your package ;) I just added a source package for licensing reasons. To be more clear, I simply took the mintty binary you provided a couple of days ago and tar'ed it up. It's not *really* a serious mintty binary package. I've now uploaded a cygport-built mintty 1.2-beta1-1 package. (I've also run ./GEN-sware in /sourceware/ftp/anonftp/pub/cygwin/64bit. This threw a bunch of errors such as not enough package files in 64bit/release/gcc, but the resulting setup.ini looks ok, so I guess those errors are expected?) Andy
Re: RFU: mksh-42b-1
On 15 February 2013 23:13, Chris Sutcliffe ir0nh...@gmail.com wrote: Upstream found a regression in 42 so 42b was released. Please upload: wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-42b-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-42b-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-debuginfo/mksh-debuginfo-42b-1.tar.bz2 Please remove 42-1 and leave 41-1 as previous. Done, Andy
Re: Possible changes to setup.exe interface and name
On 20 September 2012 16:11, Michael Benford wrote: I would like to change the setup.exe so that it loads the package selection page when it starts. Better have a look at its -M/--package-manager option first. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 09:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Fair enough. I just highlighted it in case it's unexpected. Btw have you checked size with debugging-information, or without? Without. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:18, Corinna Vinschen wrote: On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? I had to look it up: Fails To Build From Source. /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ windef.h:23: typedef unsigned __LONG32 ULONG; It doesn't like the __LONG32. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
Andy
Re: Opinions sought on TeX Live packaging
On 30 June 2012 23:38, Ken Brown wrote: TeX Live upstream has thousands of packages, grouped into collections. Cygwin's TeX Live distribution, as originally packaged by Yaakov, has one texlive-collection-* package for each upstream collection. I've just discovered that about 1800 of the upstream packages, falling into about 40 collections, have documentation that is currently not included in the Cygwin packages. I don't know if this was on oversight on Yaakov's part or a deliberate decision to omit most of the documentation. In any case, I think that the documentation is an integral part of TeX Live and needs to be part of the Cygwin distribution. If I simply add it to the texlive-collection-* packages, however, some of them drastically increase in size. For example, the installation tarball for texlive-collection-latex would increase from about 1MB to about 40MB. And for texlive-collection-latexextra it would increase from under 10MB to over 300MB. Out of curiosity: what makes the documentation that outragreously big? Is it provided in every format known to mankind? Andy
Re: [RFU] subversion-1.7.5-1 and subversion-1.7.5-2
On 21 May 2012 18:30, David Rothenberger wrote: On 5/20/2012 9:10 PM, Andy Koppe wrote: On 20 May 2012 02:22, David Rothenberger wrote: Please upload subversion-1.7.5-1 as the new current release and -2 as the new test release (built against the test Perl). Please delete 1.7.4-1 and leave 1.6.17-1 as prev. I'm getting error 403 (not authorized) for these. This should be fixed now. Uploaded. Thanks, Andy
Re: [RFU] {emacs,emacs-X11,emacs-el}-{23.4-2,24.0.96-2}
On 16 May 2012 16:57, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/release/emacs
wget -x -nH --cut-dirs=2 \
${D}/emacs-23.4-2-src.tar.bz2 \
${D}/emacs-23.4-2.tar.bz2 \
${D}/emacs-24.0.96-2-src.tar.bz2 \
${D}/emacs-24.0.96-2.tar.bz2 \
${D}/setup.hint \
${D}/emacs-X11/emacs-X11-23.4-2.tar.bz2 \
${D}/emacs-X11/emacs-X11-24.0.96-2.tar.bz2 \
${D}/emacs-X11/setup.hint \
${D}/emacs-el/emacs-el-23.4-2.tar.bz2 \
${D}/emacs-el/emacs-el-24.0.96-2.tar.bz2 \
${D}/emacs-el/setup.hint
Please delete the 23.4-1 and 24.0.96-1 packages, leaving 23.3-3 as previous,
23.4-2 as current, and 24.0.96-2 as test.
Done.
Thanks,
Andy
Re: [RFU] fftw-3.3.2-1
On 19 May 2012 08:59, marco atzeri wrote: new upstream release to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/fftw3/index.html rm ./fftw3-doc/index.html \ ./index.html \ ./libfftw3-devel/index.html \ ./libfftw3_3/index.html \ ./fftw3-doc/md5.sum \ ./libfftw3-devel/md5.sum \ ./libfftw3_3/md5.sum | ./md5.sum File list: fftw3-3.3.2-1-src.tar.bz2 fftw3-3.3.2-1.tar.bz2 fftw3-doc/fftw3-doc-3.3.2-1.tar.bz2 fftw3-doc/setup.hint libfftw3-devel/libfftw3-devel-3.3.2-1.tar.bz2 libfftw3-devel/setup.hint libfftw3_3/libfftw3_3-3.3.2-1.tar.bz2 libfftw3_3/setup.hint setup.hint Done. Thanks, Andy
Re: [RFU] cyrus-sasl-2.1.25-1
On 20 May 2012 02:19, David Rothenberger wrote: Please leave cyrus-sasl-2.1.23-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.25-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/libsasl2-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/libsasl2-ldap-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/libsasl2-sql-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/setup.hint Done. Thanks, Andy
Re: [RFU] subversion-1.7.5-1 and subversion-1.7.5-2
On 20 May 2012 02:22, David Rothenberger wrote: Please upload subversion-1.7.5-1 as the new current release and -2 as the new test release (built against the test Perl). Please delete 1.7.4-1 and leave 1.6.17-1 as prev. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-2-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/subversion-gnome-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/subversion-gnome-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.7.5-2.tar.bz2 I'm getting error 403 (not authorized) for these. Andy
Re: A momentous day (was Re: Setup and Mintty)
On 22 November 2011 10:57, Andrew Schulman wrote: On Fri, Nov 18, 2011 at 08:58:49PM +, Andy Koppe wrote: On 18 November 2011 20:57, Andy Koppe wrote: On 18 November 2011 10:59, Corinna Vinschen wrote: On Nov 18 05:36, Andy Koppe wrote: On 17 November 2011 17:17, Corinna Vinschen wrote: the latest setup sources implement the mintty desktop and start menu shortcuts. ??So, afaics, if you would just change the mintty package so that it doesn't install its own shortcuts, we could update setup on sourceware to the new version. A shortcut-less mintty package is here: http://mintty.googlecode.com/files/mintty-1.0.1-2.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.1-2-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.1-2/cygport/setup.hint Thanks. Actually, it's time for a minor mintty update anyway. Please use this lot instead: http://mintty.googlecode.com/files/mintty-1.0.2-1.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.2-1-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.2-1/cygport/setup.hint D'oh, that last one should be: http://mintty.googlecode.com/svn/tags/1.0.2/cygport/setup.hint setup.exe has been updated and the above files have been uploaded. Gold stars all around! cgf Awarded: Andy http://cygwin.com/goldstars/#AK Corinna http://cygwin.com/goldstars/#CV Jon http://cygwin.com/goldstars/#JTy Sorry to be so late in pointing this out, but Warren Young missed out here. I think he deserves a gold star for redesigning the Cygwin logo. Andy
Re: [RFU] base-files-4.1-2
On 2 March 2012 23:10, David Sastre Medina wrote: Hello, Please upload base-files-4.1-2. I'd like to release 4.1-2 as a test release, so setup.hint has changed, too. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2.sig http://crapsteak.org/cygwin/release/base-files/setup.hint I've left 4.1-1 as current and 4.1-2 as test. Please delete any older releases. Done. Thanks, Andy
Re: Cygwin Terminal icon broken on case-sensitive systems
On 24 November 2011 16:10, Andy Koppe wrote: On 24 November 2011 15:42, Andy Koppe wrote: I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. Actually, I take it all back. I'd confused myself by still having a 'cygwin-terminal.ico' lying around from earlier experiments. Setup.exe does create it with the correct name. Apparently at least two users have fallen foul of this already: http://georgik.sinusgear.com/2011/11/23/mintty-resizable-terminal-for-windows/ Still leaves the question what's going on there. I think I found what triggered this: with a non-default dpi setting, for some reason the ExtractIconEx function used to load the icon doesn't return a small version of the icon along with the normal one. I (somewhat accidentally) fixed this in 1.0.3 by no longer insisting on a small icon being returned, as it's optional when creating a window class anyway. Andy
Cygwin Terminal icon broken on case-sensitive systems
I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. Apparently at least two users have fallen foul of this already: http://georgik.sinusgear.com/2011/11/23/mintty-resizable-terminal-for-windows/ Andy
Re: Cygwin Terminal icon broken on case-sensitive systems
On 24 November 2011 15:42, Andy Koppe wrote: I'm afraid there's a problem with the new Cygwin Terminal icon (which I'm sorry not to have spotted when reviewing the change). Setup.exe creates the mintty shortcuts with '-i /Cygwin-Terminal.ico', yet the icon file it creates is called 'cygwin-terminal.ico', i.e. all lowercase. This means that users of systems with case sensitivity enabled just get to see a dialog box saying /usr/bin/mintty: could not load icon from '/Cygwin-Terminal.ico'. Actually, I take it all back. I'd confused myself by still having a 'cygwin-terminal.ico' lying around from earlier experiments. Setup.exe does create it with the correct name. Apparently at least two users have fallen foul of this already: http://georgik.sinusgear.com/2011/11/23/mintty-resizable-terminal-for-windows/ Still leaves the question what's going on there. Andy
Re: Setup and Mintty
On 18 November 2011 10:59, Corinna Vinschen wrote: There's the faq entry My application prints international characters but I only see gray boxes. The entry about the console is still valid, even after changing to mintty on the desktop. That answer seems out of date actually, since the Cygwin console charset is determined at the start of each process rather than at the start of each process tree, so it should always match what a process thinks it is. Do you think it makes sense to add words about mintty here? If so, I guess the problem more often occurs with Win32 apps running in a UTF-8 mintty. Do you have a suggestion for an addition related to mintty? How about this: Index: faq-using.xml === RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v retrieving revision 1.37 diff -u -r1.37 faq-using.xml --- faq-using.xml 18 Nov 2011 11:39:31 - 1.37 +++ faq-using.xml 20 Nov 2011 19:53:25 - @@ -370,18 +370,17 @@ questionparaMy application prints international characters but I only see gray boxes/para/question answer -paraVery likely you didn't set your console character set to the preferred -character set before the first Cygwin application was started in the -console. To make sure the console is using the desired character set, -make sure that one of the internationalization environment variables -LC_ALL, LC_CTYPE, or LANG is set before the first Cygwin process starts. -You can do that, for instance, by setting the variable in your -literalCygwin.bat/literal file from which you start your Cygwin shell. -/para - -para -For a more detailed explanation see the section -ulink url=http://cygwin.com/cygwin-ug-net/setup-locale.html#setup-locale-console;The Windows Console character set/ulink in the Cygwin User's Guide./para +paraIn the case of Cygwin programs, this likely means that the +character set as determined by the LC_ALL, LC_CTYPE or LANG environment +variables does not match the one set on the Text page of the Cygwin Terminal's +options. Setting the locale in the terminal's options will set the LANG +variable accordingly./para +paraNon-Cygwin programs in the Cygwin Terminal do not usually take +heed of the locale environment variables. Instead, they often use the +so-called console codepage, which can be determined with the command +commandcmd /c chcp/command followed by the appropriate Windows +codepage number. The codepage number for Cygwin's default UTF-8 character +set is 65001./para /answer/qandaentry qandaentry id=faq.using.multiple-copies Andy
Re: Setup and Mintty
On 18 November 2011 21:11, Thomas Wolff wrote: Am 18.11.2011 11:59, schrieb Corinna Vinschen: On Nov 18 05:36, Andy Koppe wrote: On 17 November 2011 17:17, Corinna Vinschen wrote: ... Is there anything else missing? I suspect the manual and FAQ need a few tweaks. There's the faq entry My application prints international characters but I only see gray boxes. The entry about the console is still valid, even after changing to mintty on the desktop. Do you think it makes sense to add words about mintty here? If so, I guess the problem more often occurs with Win32 apps running in a UTF-8 mintty. Do you have a suggestion for an addition related to mintty? This problem could at least be partially solved as has been discussed in http://www.cygwin.com/ml/cygwin-apps/2010-06/msg00033.html: test case: touch bäh cmd /c dir chcp 65001 (or cmd /c chcp 65001) - the corresponding API call could be issued by mintty, or cygwin1.dll cmd /c dir Unfortunately that can't be done by mintty, because the SetConsoleCP() API requires the calling process to be connected to a console, but mintty doesn't have one. The hidden console is only created when mintty's child process calls exec() to start the shell, and of course that doesn't return unless it fails. So short of duplicating the Cygwin DLL's hidden console magic in mintty, I see the following possibilities: - Implement the codepage setting as part of the hidden console magic. This would require a mapping of each Cygwin charset to the most closely matching codepage. - Make the hidden console magic available separately from exec(), e.g. through cygwin_internal(), so that the mintty child process can invoke that, followed by SetConsoleCP() and exec(). (Mintty already has the necessary charset-to-codepage mapping.) - Implement a utility that does the charset mapping and codepage setting, and invoke that from shell startup scripts. Andy
Re: Setup and Mintty
On 18 November 2011 20:57, Andy Koppe wrote: On 18 November 2011 10:59, Corinna Vinschen wrote: On Nov 18 05:36, Andy Koppe wrote: On 17 November 2011 17:17, Corinna Vinschen wrote: the latest setup sources implement the mintty desktop and start menu shortcuts. So, afaics, if you would just change the mintty package so that it doesn't install its own shortcuts, we could update setup on sourceware to the new version. A shortcut-less mintty package is here: http://mintty.googlecode.com/files/mintty-1.0.1-2.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.1-2-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.1-2/cygport/setup.hint Thanks. Actually, it's time for a minor mintty update anyway. Please use this lot instead: http://mintty.googlecode.com/files/mintty-1.0.2-1.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.2-1-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.2-1/cygport/setup.hint D'oh, that last one should be: http://mintty.googlecode.com/svn/tags/1.0.2/cygport/setup.hint
Re: Setup and Mintty
On 17 November 2011 17:17, Corinna Vinschen wrote: the latest setup sources implement the mintty desktop and start menu shortcuts. So, afaics, if you would just change the mintty package so that it doesn't install its own shortcuts, we could update setup on sourceware to the new version. A shortcut-less mintty package is here: http://mintty.googlecode.com/files/mintty-1.0.1-2.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.1-2-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.1-2/cygport/setup.hint As I'd mentioned before, I think the changeover needs to go like this: 1. Add Base category to mintty's setup.hint. 2. Wait a day for mirrors to catch up. 3. Upload new setup.exe. 4. Upload shortcut-less mintty package. Without step 2, setup.exe might end up creating shortcuts to a non-existent mintty.exe. Is there anything else missing? I suspect the manual and FAQ need a few tweaks. Andy
Re: [RFU] octave-3.4.2-3
On 1 October 2011 17:10, Marco Atzeri wrote: On 9/23/2011 4:59 PM, Christopher Faylor wrote: On Fri, Sep 23, 2011 at 07:26:06AM +0200, Marco Atzeri wrote: package error on previous test, scrap 3.4.2-2 and replace with this prev: 3.4.0-3 curr: 3.4.2-1 test: 3.4.2-3 Done. cgf I had confirmation that is effective also on W7, so please promote to prev: 3.4.2-1 curr: 3.4.2-3 Done, by dropping the explicit versions from the setup.hints, in which case the two latest ones are picked up automatically. and drop 3.4.0-3 Deleted. Andy
Re: [RFU] subversion-1.7.0rc4-1
On 30 September 2011 01:40, David Rothenberger wrote: This is an experimental version, so please delete 1.7.0rc3-1 and leave 1.6.16-1 and 1.6.17-1. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.0rc4-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.7.0rc4-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.7.0rc4-1.tar.bz2 Done. Thanks, Andy
Re: [RFU] libogg-1.3.0-1
On 24 September 2011 17:49, Christopher Faylor wrote: On Sat, Sep 24, 2011 at 06:14:46AM +0100, Andy Koppe wrote: On 18 September 2011 18:24, David Rothenberger wrote: Please delete 1.2.0-1 and leave 1.2.1-1 as the previous version. Thanks! wget -x -nH --cut-dirs=2 \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/setup.hint \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/setup.hint \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/libogg0-1.3.0-1.tar.bz2 \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/setup.hint \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/libogg-devel-1.3.0-1.tar.bz2 \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.0-1.tar.bz2 \ ??http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.0-1-src.tar.bz2 Done. AFAIK, I did both this and the libserf upload and announcments have already gone out for them. I had email problems but there definitely were announcements for them. Apologies, I hadn't read all the mail nor did I check whether the new version was already there before doing the wget. 1.2.0-1 was still there though, so I deleted it as requested. Similarly for libserf. Andy
Re: [RFU] serf-1.0.0-1
On 18 September 2011 17:54, David Rothenberger wrote: Please remove 0.7.0-1, but leave 0.3.1-1 and 0.7.1-1. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1-devel/libserf1-devel-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1_0/libserf1_0-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1_0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-1.0.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint Done. Andy
Re: [RFU] libogg-1.3.0-1
On 18 September 2011 18:24, David Rothenberger wrote: Please delete 1.2.0-1 and leave 1.2.1-1 as the previous version. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/libogg0-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/libogg-devel-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.0-1-src.tar.bz2 Done. Andy
Re: [RFU] task-1.9.4-2
On 3 September 2011 22:17, Federico Hernandez wrote: A new cygwin package version of task is available (due core dumps of the current version with newer cygwin versions). It is a required update. The old version should be removed from the repositories. Please upload. --- wget -x -nH --cut-dirs=3 \ http://taskwarrior.org/download/cygwin17/task/setup.hint \ http://taskwarrior.org/download/cygwin17/task/task-1.9.4-2.tar.bz2 \ http://taskwarrior.org/download/cygwin17/task/task-1.9.4-2-src.tar.bz2 Done. I've removed 1.9.4-1, which leaves 1.9.3-1 as previous. Can older versions be removed? Thanks, Andy
Re: [RFU] task-1.9.4-2
On 4 September 2011 17:19, Federico Hernandez wrote: Done. I've removed 1.9.4-1, which leaves 1.9.3-1 as previous. Can older versions be removed? Andy, thanks for the fast upload. Yes, please remove also old versions. Done. Andy
Re: RFU: libsigc2.0-2.2.10-1
On 3 September 2011 05:21, Chris Sutcliffe wrote: Please upload: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.10-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.10-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0_0/libsigc2.0_0-2.2.10-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-devel/libsigc2.0-devel-2.2.10-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-doc/libsigc2.0-doc-2.2.10-1.tar.bz2 The existing directory for the package is called 'libsigc2.0' rather than 'libsigc', so I put the files in there. Hope that's as intended. Andy
Re: RFU: libtorrent-0.12.9-1 / rtorrent-0.8.9-1
On 3 September 2011 05:31, Chris Sutcliffe wrote: Please upload: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.9-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.9-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent14/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent14/libtorrent14-0.12.9-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.9-1.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-1.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.9-1-src.tar.bz2 Done. Thanks, Andy
Re: 256x256 px icons
On 16 August 2011 10:08, Corinna Vinschen wrote: On Aug 15 20:46, Andy Koppe wrote: On 14 August 2011 12:12, Corinna Vinschen wrote: Your attempts at 16x16, 24x24, and 32x32 definitely look better than mine. Also, somehow I seem to have broken the terminal frame in 32x32. I didn't notice that before, but in direct comparison with your 32x32 it's quite obvious. As for 48x48 and 64x64, it seems the thicker original stroke results in a washed-out looking stroke in the inner part of the C, just below the wedge. Can you get rid of that washed-out look? I see what you mean. I think it's because the scaled-down stroke is less than a pixel wide in theory, but due to its position it ends up being divided between two pixel lines, so you get a two-pixel darkish grey instead of a one-pixel light grey. Fixing this would require redrawing the C at the high resolution in such a way that it maps to whole pixels when scaling down. I'm afraid that's beyond my pay grade though. Warren, if you've got any more spare time to spend on this ... Meanwhile, attached is the same again but with the 48x48 from your current icon, and a 64x64 scaled down from your 256x256, because I didn't like the C in the current 64x64 being bigger in relation to the terminal frame than at the other sizes. The stroke probably is a bit too dark though ... I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Fair enough. Compared to mine though it looks a bit rougher around the edges when used in a mintty window frame with dark background. In particular, some of the corner pixels stick out and the wedge has more pronounced stepping. (See attached pic.) I wonder whether this is due to resizing algorithm. Can you be bothered to try different scaling algorithms, or send me the orignal so I can have a go with Paint.net (which says it uses supersampling)? Andy compare.png.gz Description: GNU Zip compressed data
Re: 256x256 px icons
On 16 August 2011 15:31, Corinna Vinschen wrote: On Aug 16 15:16, Andy Koppe wrote: On 16 August 2011 10:08, Corinna Vinschen wrote: I created a new 64x64 icon with smaller C. Other than that I made a longish comparison of the small 16x16 and 24x24 icons on various backgrounds, and in contrast to what I said above, I think I prefer the slightly darker frames. Fair enough. Compared to mine though it looks a bit rougher around the edges when used in a mintty window frame with dark background. In particular, some of the corner pixels stick out and the wedge has more pronounced stepping. (See attached pic.) Sorry, but I really don't see that. Not in that size. Do I need specs? Aliasing is in the eye of the beholder. Or something. ;) I wonder whether this is due to resizing algorithm. Can you be bothered to try different scaling algorithms, or send me the orignal so I can have a go with Paint.net (which says it uses supersampling)? I don't have an original other that what Warren sent: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf http://etr-usa.com/cygwin/logo/beveled-for-small-composites.xcf Everything I did with the C I did from there. Sorry, I meant the image before scaling, but including your changes. I'm not sure I could recreate them exactly (and it would take more time). Andy
Re: 256x256 px icons
On 15 August 2011 18:52, Warren Young wrote: I present to you now, my magnum opus: http://etr-usa.com/cygwin/logo/boxed-hippo.ico Now *that*, my friends, is an angry hippo. :) That is rather impressive, and yep, that's not a happy hippo. Is this just for fun or are you proposing this at the setup.exe icon, in which case of course it would need further effort to make it work at small sizes. Andy
Re: 256x256 px icons
On 27 July 2011 18:30, Warren Young wrote: - Do we need more sizes? I've seen reference to odd sizes like 64x64 and 96x96, but surely we can trust Vista+ to scale the 256x256 to these sizes without needing hand-tweaked versions? Picking up on an old point here. As Warren suggests, the 64x64 doesn't actually seem to be used if 256x256 is present. For example, when setting the desktop icon size to large, a downscaled 256x256 is used. Shall we drop the 64x64s for a bit of a size saving (particularly as they're in BMP rather than PNG format)? Andy
Re: [PATCH] Remove Prev button from setup.exe's chooser page
On 13 August 2011 08:52, Corinna Vinschen wrote: Andy, On Jul 17 20:26, Andy Koppe wrote: Attached is a patch for removing the Prev radio button from setup.exe's chooser page. As previously discussed at [1], that button doesn't really serve any useful purpose. It might mislead people into thinking that it delivers a somewhat outdated but proven Cygwin, when in fact it delivers a rather random mix of packages of widely varying age that is unlikely to actually work together. Also attached is a documentation change to go with this. Andy [1] http://cygwin.com/ml/cygwin/2010-08/msg00890.html cygwin-apps/setup/ChangeLog: * res.rc: Remove Prev button from chooser page. * resource.h: Reflect removal of Prev button. * package_meta.h (trustp): Ditto. * choose.cc: Ditto. winsup/doc/ChangeLog: * setup-net.sgml (setup-packages): Reflect removal of Prev button. Also document Keep button and improve description of Exp button. please apply. I checked that in at the time, but forgot to confirm here, sorry. (Also, I notice I put 2010 instead of 2011 in the ChangeLog entry ...) Andy
Re: 256x256 px icons
On 12 August 2011 07:59, Corinna Vinschen wrote: On Aug 11 15:06, Warren Young wrote: On 8/11/2011 4:38 AM, Corinna Vinschen wrote: New incarnation uploaded. Same URL. Is that better? Yes, thanks. I didn't feel up to the task to resize the stroke, btw., so I just made it slightly darker before resizing. This seems to have to do the trick. I haven't forgotten about my attempt, by the way. It's just become a bigger project than anticipated. I guess you're not waiting on me, which is fine. No, no, I'm curious. There's no rush. Even if I check in the current icons to the setup repository, we're not quite finished anyway. Andy was trying to take another stab at the smaller icon sizes 24x24 and 16x16. I hope to get 'round to this this weekend. Then we must move mintty to Base, then we have to release setup. I think it would be best to do that as concurrently as possible, including the removal of the mintty postinstall and preremove scripts for creating and removing the 'mintty' start menu entry. That's to avoid an intermediate phase where the mintty entry appears in people's start menus without them asking for it, only for it to disappear again soon after. In preparation for that, I've repackaged mintty without those scripts: http://mintty.googlecode.com/files/mintty-1.0.1-2.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.1-2-src.tar.bz2 And here's a setup.hint with added Base category: http://mintty.googlecode.com/svn/tags/1.0.1-2/cygport/setup.hint Andy
Re: 256x256 px icons
On 12 August 2011 10:12, Corinna Vinschen wrote: On Aug 12 08:59, Corinna Vinschen wrote: Oh, and, I'd still *love* to use the 256x256 setup icon in the splash screen dialog, if I'd only know how to do that. Got it! If you specify SS_REALSIZEIMAGE in the ICON control statement, then the dialog uses the original size of the icon, rather than to resize it to something small. If the icon is an icon set, it uses the first icon in the set. Turns out, 256 is too big for the splash screen. Looking for a nice size, I found that 1064, the size of the rasterized original icon, dived by 7 is 152, which looks like the ideal size for the dialog icon. So I added a 152x152 icon to cygwin.ico, and made it the first icon in the set. Here's the result: http://cygwin.de/cygwin-standalone-beveled.ico Two examples: Classic Windows style: http://cygwin.de/splash-new-1.png Windows 7 non-Aero style: http://cygwin.de/splash-new-2.png Spiffy! Andy
Re: 256x256 px icons
On 6 August 2011 19:27, Corinna Vinschen wrote: On Aug 6 19:43, Corinna Vinschen wrote: On Aug 6 11:47, Andy Koppe wrote: On 6 August 2011 09:28, Corinna Vinschen wrote: On Aug 5 11:35, Warren Young wrote: However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf Thank you very much. I created an icon set from there. The fact that everything is layered is cool. You can simply change a single aspect of the picture. What I did: - In general the dark shadow of the wedge became too dark (IMHO) when resizing the image to smaller sizes. The wedge looked pretty asymmetrically when small. So I lightend the shadow quite a bit before scaling it down.cd - For the 256x256 icon I darkened the C stroke a bit, for 48x48 and below I used an entirely white stroke before scaling down. - For the 256x256 icon I kept the dark outer glow, for the smaller sizes I removed it. Makes sense. If the outline needs to be any brighter, it would need to be thickened before scaling down. The 16x16 icon looks blurry when magnified to 800% in gimp, but I'm surprised how good it looks in normal 100%. I agree. Is that one ok as default Cygwin icon? I think so. I'm going to work on the terminal icon based on Andy's blank-terminal icons and this beveled icon next, as well as on a new setup box icon. Looking forward to those. I seem to be in a minority of one regarding the logo-in-terminal approach, so I withdraw my objection to that. The terminal icon is attached to this mail. Downscaling the C to 18x18 and pasting it into the 32x32 terminal outline was a waste of time. For 32x32 I now created a C pixel by pixel so that it looks good on the XP desktop. For 24x24 and 16x16 I used the standalone C from my previous icon set as fallback. Now for the setup icon... Here it is. The 32x32 icon is the most tricky one and needed some convincing to look acceptable. 24x24 and 16x16 are agains the standalone icon. Nice work on both of them. GTG, as far as I'm concerned. I'd quite like to have another go at the small icons though, but that doesn't need to hold up anything. Warren, could you do a version of the C with a thicker stroke, say twice as thick? (If you think I could easily do that myself, just say so.) Andy
Re: SETUP: default to mintty
On 5 August 2011 21:45, Warren Young wrote: On 8/5/2011 2:04 PM, Andy Koppe wrote: Which leaves the question how the icon with the 256x256 became so big. I'd used a Cygwin build of 'icotool' from 'icoutils' for that, icotool's --help is confusing. The magic incantation is: $ icotool -c -o cygwin-term.ico -r cygwin-term.png where cygwin-term.png is the 256 px Vista icon. -r is the trick. You then append the PNG files for the smaller sizes to the list to have them translated to BMP style standard icons within the aggregate .ico. Thanks! (I'd only looked at the man page, where the -r option doesn't appear at all.) allows to embed PNGs directly, instead storing them in whatever less efficient bitmap format .ICOs have used before. .ico is originally based on BMP, which is a trivial uncompressed file format, basically a small header containing obvious things like width, height, color depth, pixel format and such, followed by raw pixel data. So, a 32 bit RGBA 256x256 .bmp or .ico will be 262,144 bytes plus header overhead. (I get 270,398 bytes here.) Your 300K+ file probably got a bit bigger due to having more icon sizes bundled in. That makes plenty of sense. How do you create icons including a 256x256 version? I use the ICO file plugin for Photoshop from Telegraphics, the same people that put out icobundl. You get a dialog on saving the icon, asking if you want a standard or Vista PNG .ico; I say Vista for the 256 px one, and standard for the smaller four sizes. Then, I use icobundl to take the resulting 5 .ico files and assemble them. I can do final compression and assembly if you need me to, but I think the icotool incantation will fix your problem. Right. Now we just need to work out what exactly to put in it. :) Andy
Re: 256x256 px icons
On 6 August 2011 09:28, Corinna Vinschen wrote: On Aug 5 11:35, Warren Young wrote: On 8/3/2011 11:49 PM, Andy Koppe wrote: Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. Sorry, there is currently no vector version. Effects like bevels and shadows are raster effects. However, based on this: https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects it does look like SVG's been extended with the raster effects needed to recreate my beveled icon. I am installing Inkscape now and will try to do that later, perhaps today, perhaps not. In the meanwhile, here's my new beveled Cygwin logo: http://etr-usa.com/cygwin/logo/beveled-noshadow.psd Changes from the original: - removed the big drop shadow (outer glow still present) - softened lighting on the wedge - dropped outer C stroke from white to a light gray - rebuilt as 1024 px square, not counting the outer glow, for finer editing control This should open in any version of Photoshop going back to the 90s. (v6 and up, I'm guessing.) While I realize not everyone will have even that, I'm providing it because it's based on easy-to-edit procedural effects, rather than flattened raster effects. However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf Thank you very much. I created an icon set from there. The fact that everything is layered is cool. You can simply change a single aspect of the picture. What I did: - In general the dark shadow of the wedge became too dark (IMHO) when resizing the image to smaller sizes. The wedge looked pretty asymmetrically when small. So I lightend the shadow quite a bit before scaling it down.cd - For the 256x256 icon I darkened the C stroke a bit, for 48x48 and below I used an entirely white stroke before scaling down. - For the 256x256 icon I kept the dark outer glow, for the smaller sizes I removed it. Makes sense. If the outline needs to be any brighter, it would need to be thickened before scaling down. The 16x16 icon looks blurry when magnified to 800% in gimp, but I'm surprised how good it looks in normal 100%. I agree. Is that one ok as default Cygwin icon? I think so. I'm going to work on the terminal icon based on Andy's blank-terminal icons and this beveled icon next, as well as on a new setup box icon. Looking forward to those. I seem to be in a minority of one regarding the logo-in-terminal approach, so I withdraw my objection to that. Andy
Re: 256x256 px icons
On 4 August 2011 15:29, Corinna Vinschen wrote: On Aug 4 09:19, Charles Wilson wrote: On 8/4/2011 4:39 AM, Corinna Vinschen wrote: Sure! I would be more happy with the fatbuttlarry icon if it would be available in a nice 256x256 variation, though. That's really a big plus of Warren's version. Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). Nice, thank you. Ditto. Where did you find that? There isn't a vector version of this, is there? I'm asking because that would allow to remove the shadow under the C without impacting the edge of the C which has a bit of a fade-out on it. I realised that I'd used the 24bpp version of cygicons-0.dll,9, which doesn't have the shadow, but only because it doesn't have an alpha channel. Do you know how to convert the green glow around the C to grey, by any chance? Here's what I did, in Paint.net. I very much suspect there are better ways. - Select the green arrow with the rectangular select tool. - Invert the selection, thereby selecting everything but the green arrow. - Go to Adjustments-Hue/Saturation: Turn the hue to -60 (yellow) and the saturation to 200 (maximum). OK. - Adjustments-Black and White. (The point of turning it bright yellow before the Black and White step is to make the resulting grey as light as possible.) Andy
Re: 256x256 px icons
On 5 August 2011 18:35, Warren Young wrote: On 8/3/2011 11:49 PM, Andy Koppe wrote: Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. Sorry, there is currently no vector version. Effects like bevels and shadows are raster effects. However, based on this: https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects it does look like SVG's been extended with the raster effects needed to recreate my beveled icon. I am installing Inkscape now and will try to do that later, perhaps today, perhaps not. Don't worry too much about that. The below sounds like the Photoshop version should be entirely sufficient. In the meanwhile, here's my new beveled Cygwin logo: http://etr-usa.com/cygwin/logo/beveled-noshadow.psd Changes from the original: - removed the big drop shadow (outer glow still present) - softened lighting on the wedge - dropped outer C stroke from white to a light gray - rebuilt as 1024 px square, not counting the outer glow, for finer editing control This should open in any version of Photoshop going back to the 90s. (v6 and up, I'm guessing.) While I realize not everyone will have even that, I'm providing it because it's based on easy-to-edit procedural effects, rather than flattened raster effects. However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf I also made a 256 px .ico, for those who just want to see it in action: http://etr-usa.com/cygwin/logo/beveled-noshadow.ico I like this a lot. Thanks very much for responding so positively to my whinging. Andy
Re: 256x256 px icons
On 5 August 2011 16:57, Charles Wilson wrote: On 8/5/2011 11:05 AM, Andy Koppe wrote: On 4 August 2011 15:29, Corinna Vinschen wrote: On Aug 4 09:19, Charles Wilson wrote: Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). Nice, thank you. Ditto. Where did you find that? It's at the same place I got the original windows icon: http://kde-look.org/content/show.php?content=36393 It's the 'Fedora' download. There isn't a vector version of this, is there? Not that I could see. There's contact info for fatbuttlarry at the link, but it's several years old, so no telling if it is still accurate, or if fbl would respond, or if he still HAS any original vector artwork, or if he'd be willing to share it... I sent a request to the email address given there. At least it hasn't yet come back as undeliverable ... Thanks, Andy
Re: SETUP: default to mintty
On 3 August 2011 15:43, Corinna Vinschen wrote: On Jul 27 17:52, Corinna Vinschen wrote: On Jul 27 16:15, Andy Koppe wrote: On 27 July 2011 10:43, Corinna Vinschen wrote: On Jul 27 09:07, Andy Koppe wrote: On 27 July 2011 08:46, Corinna Vinschen wrote: On Jul 27 08:24, Andy Koppe wrote: I meant cygicons-0.dll,9. Yes, I like that one, too. we could use it as the default 48x48 and 64x64 icons. Per the MSFT guidelines in http://msdn.microsoft.com/en-us/library/aa511280.aspx#size, smaller sizes should stick to a 2D look. Maybe we can simply use the old icon for these sizes? The way I understand it, I think it's just that they shouldn't use perspective. Compare for example the drive icons in the Computer window, where they appear tilted in the main part of the window, but straight-on at 16x16 in the sidebar. The small icons do still have some depth to them. Well, ok. I was just thinking that at 16x16 there's no such thing as edginess. And at that size an icon should make a rather clear, simple impression. FWIW, 'cygicons-0.dll,9' looks better to me even at 16x16, not least because of the anti-aliasing. Also, it's this size that appears in the upper-left corner of windows, and I think it's good to have this correspond closely to the 32x32 icon appearing in the Windows 7 taskbar. Fine with me. Ok, here's my final(?) patch to make setup install mintty as Cygwin Terminal desktop and start menu entries. Apart from the cygwin.ico file, there's now also a cygwin-terminal.ico file and a cygwin-setup.ico file. The latter is used as the default application icon. Only the first two are installed into / as Cygwin.ico and Cygwin-Terminal.ico. See below for the patch. Attached are the new ico files for the setup repository. The Cygwin-Terminal.ico isn't good enough IMNSHO, and I'm disappointed with how this has suddenly become the official proposal, riding roughshod over much of the previous discussions. - Above you'd agreed that fatbuttlarry's bulgy icon was fine in the 16x16 version, and that was before making it bigger and turning its outline grey to lose that eerie look. Yet here we are with a murky flat effort that looks no better than ye olde Cygwin.ico. (This size is used for the window icon, so arguably this is the most important one.) - The terminal frame at the 32..64 sizes isn't as sharp as it could be, because it's copied from one of my attempts before I worked out how to render it like in the original Konsole icon. - The 256x256 version still has Warren's dark border around the terminal. Not only is this spoiling the KDE Oxygen team's work, but it also makes it pointlessly different from the smaller versions. Furthermore, the C still has rough corners due to the bottom line being too low, and its shadow makes little visual sense inside the terminal frame. - The Cygwin-symbol-in-terminal approach remains a dodgy compromise. It doesn't fit into 16x16, and as Warren pointed out, the removal of the prompt means that the terminal is hard to recognise as such. I can't remember a case for why this compromise is preferable over the Cygwin symbol on its own. To avoid being entirely negative, here's my proposal: forget about Cygwin-terminal.ico and just use Cygwin.ico. I like the setup.exe parcel idea, but this also needs improvements. In particular, the 16x16 version doesn't work, with the parcel just an ill-defined grey blob behind the C. Also, the shadow behind the C on the 256x256 makes even less visual sense here than in the terminal frame. Andy will also have to change the mintty postinstall script so that the mintty entry is not added to the start menu anymore. Yep. (That should make for a fair few complaints about how mintty has suddenly disappeared from the start menu though.) Andy
Re: 256x256 px icons
On 2 August 2011 16:24, Corinna Vinschen wrote: On Aug 2 15:49, Andy Koppe wrote: On 1 August 2011 21:05, Andy Koppe wrote: On 1 August 2011 09:07, Corinna Vinschen wrote: On Jul 31 21:21, Andy Koppe wrote: On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. Thanks. But, hmm. The longer I play with it, the less I like the green glow. It adds an eerie touch to the C Now what's wrong with that? Cygwin - mean and a bit eerie. ;) and it still doesn't set the C really apart on dark backgrounds. I disagree, looking at a desktop with a darkish picture and dark grey taskbar and window borders. I think we should go with a grey outline. I did eventually work out how to turn the outline of fatbuttlarry's icon grey. See attachments. Having used both variants for a while, I agree that a grey outline does look better. I tried your icons on my desktop and the standalone icon looks good. In the terminal icons the beveled C looks better than the fatbuttlarry C, cleaner, crisper. I think it would be better to stick to one. I don't particularly mind which, in principle anyway. Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. It does need to lose that shadow though, and have the bottom edge fixed. Also, the bottom half of the green triangle is a bit on the dark side. It's also easier to distinguish from the dark background, but that's probably just because you used a darker shade of grey for the frame. In the terminal window, a lighter grey really doesn't hurt. It's pretty much the same grey actually (~220), at full size anyway. But the border is thinner and/or partially transparent in larry's. Therefore, when scaling it down, it blends into the background more. Generally it looks like your C's are a pixel or two smaller, except in the smallest sizes. Gimp shows that you're always leaving a transparent frame of at least one pixel. Any reason for that? Not really. Just seemed a prudent thing to do when cutting it out of the original, but you're right, there's no need for this, and I'd be happy to redo it. Andy
Re: 256x256 px icons
On 1 August 2011 21:05, Andy Koppe wrote: On 1 August 2011 09:07, Corinna Vinschen wrote: On Jul 31 21:21, Andy Koppe wrote: On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. Thanks. But, hmm. The longer I play with it, the less I like the green glow. It adds an eerie touch to the C Now what's wrong with that? Cygwin - mean and a bit eerie. ;) and it still doesn't set the C really apart on dark backgrounds. I disagree, looking at a desktop with a darkish picture and dark grey taskbar and window borders. I think we should go with a grey outline. I did eventually work out how to turn the outline of fatbuttlarry's icon grey. See attachments. Having used both variants for a while, I agree that a grey outline does look better. Andy
Re: 256x256 px icons
On 2 August 2011 17:06, Corinna Vinschen wrote: On Aug 2 11:45, Charles Wilson wrote: On 8/2/2011 11:24 AM, Corinna Vinschen wrote: I guess we're getting close to the end result now. So, how are you (Andy, Corinna) planning to handle the .ico file(s) themselves? Are you 1. (Andy) planning to put it/them into the mintty executable as resource(s), 2. ship the .ico file(s) in '/' as part of the main cygwin package, as we have long done with cygwin.ico 3. Incorporate it/them into cygicon*.dll as part of the cygutils package or some combination? I'm open to #3, but I'll need provenance and licensing info (see the end of /usr/share/doc/cygutils/cygicons/README ) I would stick to the standard terminal icon for mintty(*), except in the case of the Cygwin Terminal desktop and start menu icons. Sounds good to me. Both files will be installed into / just as today. I thought the desktop and start menu icons would be the same. (Setup.exe's icon might be different.) Andy
Re: 256x256 px icons
On 29 July 2011 15:11, Warren Young wrote: Here's a version with heavy chiseled bevels and shadows added: http://etr-usa.com/cygwin/logo/beveled.ico The bevel depth and style can of course be varied, as can the shadow angle, opacity, etc. If you don't like it but can describe what you'd like better, I'll take a shot at creating it. Could you do that one without the shadow, or perhaps just a small shadow below? That appears to be the done thing elsewhere. Also, Corinna's idea of toning down the edge to light grey seems a good one. Light green might be worth trying as well. Also, does this originate in a vector format, i.e. could you make it available as an SVG? Or otherwise as a hires PNG? (768 seems good because it's divisible by both 256 and 48.) Finally, the white edge line at the bottom seems to be slightly too low, because there are a couple of rough corners there. Andy
Re: 256x256 px icons
On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. (256x256 versions of these aren't really worth doing, because the original fatbuttlarry icon was only 96x96, and that had a fair bit of space around the C.) Andy attachment: cygwin-symbol.ico
Re: 256x256 px icons
On 29 July 2011 15:11, Warren Young wrote: On 7/29/2011 3:42 AM, Corinna Vinschen wrote: On Jul 29 03:14, Warren Young wrote: Is there official vector logo art I can use? I don't think so, sorry. Okay, here's my take: http://etr-usa.com/cygwin/logo/traced-icon.svg This should probably be archived somewhere on cygwin.com. I won't guarantee hosting for it. I'd prefer to go for a lone C in the = 32x32 sizes. Here's a combined icon -- same 5 sizes as before -- based on the new vector logo, with the two parts individually stroked for contrast against both light and dark backgrounds: http://etr-usa.com/cygwin/logo/stroked.ico Here's a version with heavy chiseled bevels and shadows added: http://etr-usa.com/cygwin/logo/beveled.ico It only includes a 256 px version, since it's too much detail to work at small sizes. You'd want to fill in the smaller sizes with a simpler style, like the stroked C or the plain Konsole. The bevel depth and style can of course be varied, as can the shadow angle, opacity, etc. If you don't like it but can describe what you'd like better, I'll take a shot at creating it. Here are some 3-D variants of the Cygwin logo, one inside the Konsole terminal frame for MinTTY, and one with the logo alone for broader purposes: http://etr-usa.com/cygwin/mintty-icon/3d.ico http://etr-usa.com/cygwin/logo/3d.ico Again, 256 px only, for detail reasons. What if the green glow around the black C glows a bit more? Try this on: http://etr-usa.com/cygwin/logo/glowing.ico It's not bad, but I prefer the stroked variants. Incidentally, while doing that, I went and made a layered, rasterized Konsole icon from the original SVG. This is how the 3D Cygwin logo in the Konsole frame has the same glare overlay as the original icon. http://etr-usa.com/cygwin/mintty-icon/konsole-icon-layered.psd I checked, and Gimp does seem to render it correctly, even though it wasn't created that way. Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Andy attachment: cygwin-terminal.ico
Re: SETUP: default to mintty
On 26 July 2011 20:52, Charles Wilson wrote: On 7/26/2011 3:36 PM, Andy Koppe wrote: What about modernizing the Cygwin icon? I quite like Chuck's take on this. Err...what's my take, again? g I meant cygicons-0.dll,9. Andy
Re: SETUP: default to mintty
On 27 July 2011 08:08, Corinna Vinschen wrote: On Jul 26 20:36, Andy Koppe wrote: On 26 July 2011 09:17, Corinna Vinschen wrote: What about modernizing the Cygwin icon? I quite like Chuck's take on this. Or, what about having a mintty terminal icon with a small C in it? The only problem with this is, I'm anything but an artist... Me neither, which is why I just picked an existing generic terminal icon that I liked. Regarding Warren's effort, the challenge is that it still needs to look good at 16x16. (Btw, mintty's --icon/-i option can be used to stick any icon on its window.) So setup could create the default shortcuts with the -i option and just use the Cygwin icon? Yep. (I might also have a go at making mintty automatically pick up the icon of the shortcut it's invoked from, if any. Won't happen quickly though.) Andy
Re: SETUP: default to mintty
On 27 July 2011 08:46, Corinna Vinschen wrote: On Jul 27 08:24, Andy Koppe wrote: On 26 July 2011 20:52, Charles Wilson wrote: On 7/26/2011 3:36 PM, Andy Koppe wrote: What about modernizing the Cygwin icon? I quite like Chuck's take on this. Err...what's my take, again? g I meant cygicons-0.dll,9. Yes, I like that one, too. we could use it as the default 48x48 and 64x64 icons. Per the MSFT guidelines in http://msdn.microsoft.com/en-us/library/aa511280.aspx#size, smaller sizes should stick to a 2D look. Maybe we can simply use the old icon for these sizes? The way I understand it, I think it's just that they shouldn't use perspective. Compare for example the drive icons in the Computer window, where they appear tilted in the main part of the window, but straight-on at 16x16 in the sidebar. The small icons do still have some depth to them. Andy
Re: 256x256 px icons
On 27 July 2011 18:30, Warren Young wrote: On 7/27/2011 1:41 AM, Corinna Vinschen wrote: You say you already have created such icon files before. Would you have fun to create a new official cygwin.ico? Here you go: http://etr-usa.com/cygwin/mintty-icon/combined.ico That file contains a 256 px 32 bpp (RGBA) Vista (PNG) icon plus standard BMP icons in 48 px 32 bpp, 32 px 8 bpp, 24 px 8 bpp, and 16 px 8 bpp sizes and depths. If you look at the directory view, you can see the source files that went into this. Thanks very much for putting in this effort. However, there are a number of problems. In increasing order of subjectivity: - The 16x16 has white dots in the corners. - There are black edges around the icons. Those need to be transparent. - Contrast and saturation are rather low. I think it would be better to overlay the Cygwin symbol on top of the terminal rather than blending them. - The terminal's screen is too busy with both the prompt and the 'C'. I think the _ would need to go. - Even then, I'm not convinced this will be as good as either of the original icons, because it will still look like a compromise, with the glossy Cygwin symbol sticking out of the more matte terminal screen in the bigger versions and getting squashed in the 16x16 version. Andy
Re: 256x256 px icons
On 27 July 2011 22:11, Warren Young wrote: On 7/27/2011 2:04 PM, Andy Koppe wrote: - The 16x16 has white dots in the corners. That was a feature. But you no like it, I make go 'way. Thanks. - There are black edges around the icons. Those need to be transparent. Why? I purposely redrew the edges in the smaller icons for contrast and clarity. (Among other things.) Because the Konsole icon edges are black, I made the semitransparent pixels you get from simple downsampling pure black. If all you want is the blurry mess you get from a direct downsample, there's no point in having the smaller icons at all. Maybe a dark gray would make you happier? Something that approximates the appearance of a thin black line blending into the background the icon is being matted on, without trying to make use of alpha blending? My old skool heritage is showing. I've been trained not to use alpha blending a 32 px and below. When I was a boy, all we had was 8 bpp with one color reserved for yes/no transparency, AND WE LIKED IT. Is this outmoded? Will XP do the right thing with RGBA for 16 px icons? Is that a good idea regardless, or is old skool the only skool? I don't know about that. What I do know is that the Konsole icon looks fine to me, including at 16px, and that I haven't had any complaints about it. To me, the black/grey border just looked like something went wrong with transparency during the conversion. Also, at 16px, the left and right sides of the terminal screen's frame have actually gone. - Contrast and saturation are rather low. I think it would be better to overlay the Cygwin symbol on top of the terminal rather than blending them. Here it is: http://etr-usa.com/cygwin/mintty-icon/no-text.ico That looks a lot better, thanks. Nice work removing the prompt. Did you go back to the original SVG to do that? It also has the gray edges on the smaller icons instead of black, and transparent corners in the 16x16. I had to remove the text, which makes the result not as clearly a terminal. At 256 and arguably at 48 px, you can figure out that it might be a terminal, especially if you've seen the icon in its previous incarnation. At 32 px and below, I challenge anyone to honestly tell me that there is any sense of terminal left in this version. Fair point. One could make an argument for going back to the plain old Konsole icon. Maybe one icon cannot serve two masters. Just to be clear: I'd be happy with the modernized Cygwin icon too. I still prefer both that and the Konsole icon over the combined one (even ignoring the issue with the non-transparent border). Thanks again for putting in this effort to have something tangible to compare with. Andy
Re: 256x256 px icons
On 27 July 2011 23:26, Charles Wilson wrote: the fatbuttlarry icon is GPL. not sure about the KDE Konsole icon. It's LGPL. Andy
Re: SETUP: default to mintty
On 26 July 2011 09:17, Corinna Vinschen wrote: On Jul 25 21:18, Andy Koppe wrote: On 25 July 2011 12:49, Andy Koppe wrote: On 25 July 2011 10:11, Corinna Vinschen wrote: [This time *with* patch...] Hi guys, we discussed this back in May already, but somehow we didn't get a final result. The thread was kind of confusing, so I re-open a new one now. We talked about using mintty as our default shell. I created a setup patch which I attached to this mail again. Instead of Cygwin Bash Shell in the start menu and Cygwin on the desktop, it creates Cygwin Terminal shortcuts in both of them. Is that ok? If I remember correctly, we were going to go with just Cygwin on the desktop. I'll have a proper look later. Problem: the shortcuts have the classic Cygwin icon whereas the resulting terminal window has the mintty (née Konsole) icon. Worse, on Windows 7 at least, the Cygwin icon also appears in the taskbar. Not on my W7. But it does here. Cygwin icon on shortcut, Konsole icon on window, Cygwin icon in taskbar. I'm afraid I've got no idea what determines this. Could be to do with pinning, although I haven't got it pinned at the moment. It needs to be the same icon throughout. Why? Because they're meant to help users identify stuff. Perhaps the window icon being different from the shortcut icon the user clicked on to start it is just about tolerable, but the taskbar icon not matching the window is very very wrong. I have no problems with either. I like the mintty icon, but I also don't want to remove the Cygwin icon entirely since, as ugly as it may be, it's kind of a brand and has a recognition value, collected over the years. What about modernizing the Cygwin icon? I quite like Chuck's take on this. Or, what about having a mintty terminal icon with a small C in it? The only problem with this is, I'm anything but an artist... Me neither, which is why I just picked an existing generic terminal icon that I liked. Regarding Warren's effort, the challenge is that it still needs to look good at 16x16. (Btw, mintty's --icon/-i option can be used to stick any icon on its window.) Andy
Re: SETUP: default to mintty
On 25 July 2011 10:11, Corinna Vinschen wrote: [This time *with* patch...] Hi guys, we discussed this back in May already, but somehow we didn't get a final result. The thread was kind of confusing, so I re-open a new one now. We talked about using mintty as our default shell. I created a setup patch which I attached to this mail again. Instead of Cygwin Bash Shell in the start menu and Cygwin on the desktop, it creates Cygwin Terminal shortcuts in both of them. Is that ok? If I remember correctly, we were going to go with just Cygwin on the desktop. I'll have a proper look later. Apart from that, why is mintty still not in the Base category? Just laziness on our side? I kept on putting it off because there was always that one more bug to fix. No excuses now that I've bumped it to 1.0. Some really important reason? My one remaining concern is the postinstall script, which would create the Cygwin/mintty start menu entry for every Cygwin user, whether they want it or not. Deleting it wouldn't help either, as it would come back at the next mintty update. Andy
Re: SETUP: default to mintty
On 25 July 2011 12:49, Andy Koppe wrote: On 25 July 2011 10:11, Corinna Vinschen wrote: [This time *with* patch...] Hi guys, we discussed this back in May already, but somehow we didn't get a final result. The thread was kind of confusing, so I re-open a new one now. We talked about using mintty as our default shell. I created a setup patch which I attached to this mail again. Instead of Cygwin Bash Shell in the start menu and Cygwin on the desktop, it creates Cygwin Terminal shortcuts in both of them. Is that ok? If I remember correctly, we were going to go with just Cygwin on the desktop. I'll have a proper look later. Problem: the shortcuts have the classic Cygwin icon whereas the resulting terminal window has the mintty (née Konsole) icon. Worse, on Windows 7 at least, the Cygwin icon also appears in the taskbar. It needs to be the same icon throughout. That raises the obvious question: which one? I vote for mintty's, but of course I'm biased. I don't think the classic Cygwin icon is fit for purpose anymore, because of its jagged lines and because the black 'C' is invisible on dark backgrounds. Andy
[PATCH] Remove Prev button from setup.exe's chooser page
Attached is a patch for removing the Prev radio button from setup.exe's chooser page. As previously discussed at [1], that button doesn't really serve any useful purpose. It might mislead people into thinking that it delivers a somewhat outdated but proven Cygwin, when in fact it delivers a rather random mix of packages of widely varying age that is unlikely to actually work together. Also attached is a documentation change to go with this. Andy [1] http://cygwin.com/ml/cygwin/2010-08/msg00890.html cygwin-apps/setup/ChangeLog: * res.rc: Remove Prev button from chooser page. * resource.h: Reflect removal of Prev button. * package_meta.h (trustp): Ditto. * choose.cc: Ditto. winsup/doc/ChangeLog: * setup-net.sgml (setup-packages): Reflect removal of Prev button. Also document Keep button and improve description of Exp button. no_prev.patch Description: Binary data no_prev_doc.patch Description: Binary data
Re: Opinions solicted for changes to tty names in 1.7.10
On 14 June 2011 21:36, Christopher Faylor wrote: After some discussion with Corinna, I'm thinking about making a change to the tty naming in Cygwin as part of the removal of CYGWIN=tty. (In case you haven't noticed, CYGWIN=tty, is no longer supported in snapshots. If you do have the tty option set you get one warning per session telling you to unset it.) Since the only thing using Cygwin's tty layer will now be ptys, I'd like to rename /dev/ttyN to /dev/ptyN. I've already added /dev/consN support for consoles but I'd like to change that so that consoles are represented as /dev/ttyN instead. Makes plenty of sense. The only concern I see is that BSD PTYs (as previously used on Linux as well, IIRC) are called pty[p-za-e][0-9a-f] on the master side, whereas they're tty[p-za-e][0-9a-f] on the slave side. Therefore calling the slave side ptyN could conceivably cause issues. Is the Unix98 scheme (/dev/pts/N) that's used on Linux these days out of the question? Corinna suggested that I should send a query here to see if anyone knows if this proposed change will affect any existing applications which use ptys like mintty, emacs, xterm, rxvt, or screen. Mintty currently only looks for tty when cutting down the device name to fill in the utmp.ut_id field, but that's trivial to change (and utmp isn't on by default anyway). Andy
Re: Opinions solicted for changes to tty names in 1.7.10
On 15 June 2011 15:55, Christopher Faylor wrote: On Wed, Jun 15, 2011 at 01:28:55PM +0100, Andy Koppe wrote: On 14 June 2011 21:36, Christopher Faylor wrote: After some discussion with Corinna, I'm thinking about making a change to the tty naming in Cygwin as part of the removal of CYGWIN=tty. (In case you haven't noticed, CYGWIN=tty, is no longer supported in snapshots. ??If you do have the tty option set you get one warning per session telling you to unset it.) Since the only thing using Cygwin's tty layer will now be ptys, I'd like to rename /dev/ttyN to /dev/ptyN. ??I've already added /dev/consN support for consoles but I'd like to change that so that consoles are represented as /dev/ttyN instead. Makes plenty of sense. The only concern I see is that BSD PTYs (as previously used on Linux as well, IIRC) are called pty[p-za-e][0-9a-f] on the master side, whereas they're tty[p-za-e][0-9a-f] on the slave side. Therefore calling the slave side ptyN could conceivably cause issues. Is the Unix98 scheme (/dev/pts/N) that's used on Linux these days out of the question? No. I considered that but adding an arbitrary directory structure under out /dev kludge seemed wrong. I would prefer to make it look more like Linux though. The man reason why I didn't implement that is that I thought someone would report that ls /dev/pts doesn't work Good point. Unlike ls /dev/pty*, it would actually be useful as it's supposed to contain the currently used ptys. not that it couldn't be made to work. That would be nice. Corinna suggested that I should send a query here to see if anyone knows if this proposed change will affect any existing applications which use ptys like mintty, emacs, xterm, rxvt, or screen. Mintty currently only looks for tty when cutting down the device name to fill in the utmp.ut_id field, but that's trivial to change (and utmp isn't on by default anyway). Shouldn't it just be using basename(3)? The terminal is supposed to cut off all of /dev/tty, especially as Cygwin's ut_id is only 2 chars, whereas Linux's is 4. Andy
Re: [RFU] smartmontools-5.41-1
On 10 June 2011 18:49, Christian Franke wrote: New upstream release wget \ http://franke.dvrdns.org/cygwin/release/smartmontools/setup.hint \ http://franke.dvrdns.org/cygwin/release/smartmontools/smartmontools-5.41-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/smartmontools/smartmontools-5.41-1-src.tar.bz2 Please remove 5.38-1, 5.39-1 and keep 5.40-1 as prev. Done. Thanks, Andy
Re: RFU: mksh-40-1
On 13 June 2011 02:35, Chris Sutcliffe wrote: Please upload mksh-40-1: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/mksh/mksh-40-1.tar.bz2 \ http://emergedesktop.org/cygwin/mksh/mksh-40-1-src.tar.bz2 Done. Thanks, Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 26 May 2011 13:09, Andy Koppe wrote: On 26 May 2011 12:51, Corinna Vinschen wrote: On a closely related note, there's the issue of the mintty postinstall script. Simply dropping the mintty shortcut creation when setup.exe is changed would mean that the shortcut would disappear without replacement for people updating with a not-quite-up-to-date setup.exe or who habitually untick the Add start menu item checkbox. Therefore I think I should change the postinstall script such that it continues to create the mintty shortcut, but only if Cygwin Terminal isn't there. However, since setup.exe creates its shortcuts *after* running the postinstall script, people would end up with both mintty and Cygwin Terminal until the mintty package is next updated. Avoiding that requires setup.exe to nuke the mintty shortcut when it creates Cygwin Terminal. Hmm. That begs for the question why the start menu entry isn't managed entirely by mintty's postinstall/preremove scripts. In theory we can reduce setup to ask for the desktop icon. The start menu entry is always created, and it's always created by mintty. That would make the entire affair much easier, isn't it? Good point. The only argument against that I can think of is that the postinstall script shortcut is non-optional. There have been some minor complaints about that before. Another point worth noting here is that the mintty postinstall script requires mkshortcut, hence cygutils will be pulled into the default installation. I think that's a good idea anyway though, not least because a standard answer to [Random native console program] doesn't work in mintty is Run it through cygstart. Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 28 May 2011 11:47, szgyg wrote: 2011.05.28. 10:53, Andy Koppe wrote: Another point worth noting here is that the mintty postinstall script requires mkshortcut, hence cygutils will be pulled into the default installation. Cygutils is already pulled by cygwin-doc. http://szgyg.web.elte.hu/cygwin/base.png Oh, good. I thought I'd had to select it explicitly in the past, but maybe I'm confusing it with util-linux. Andy ps: Interesting diagram. What's with the circular dependency?
Re: setup and mintty (was Re: New setup.exe release?)
On 25 May 2011 16:51, Corinna Vinschen wrote: On May 25 09:54, Thomas Wolff wrote: Am 25.05.2011 09:43, schrieb Andy Koppe: ... Ah, sorry, I didn't realise that the desktop shortcut at the moment was simply called Cygwin rather than Cygwin Bash Shell. I suppose that could just stay like that actually. Also, since the start menu shortcut already is inside the Cygwin folder, just Terminal rather than Cygwin Terminal would be nice and crisp there. I think common usage is to give shortcuts rather a complete name. That's also better if people move them around, placing a copy on the desktop etc. And since bash shell runs in both command windows (is that a common name?), I think the previous proposal Cygwin Console and Cygwin Terminal is the best to distinguish them. I'm wondering if renaming the shortcuts is wise. New users should get the new shortcuts, but what about users who just update Cygwin? If we rename the shortcuts, existing users will have both check buttons in the last dialog checked again, even if they already had installed the old shortcuts before. Alternatively setup could test for the old and the new shortcut names, and only install if neither the old, nor the new ones exist. Gah, this is surprisingly difficult. How about: - Don't rename the desktop shortcut, leaving it as Cygwin. This means that it won't change for users that already have one, nor will they get another desktop shortcut. Only newly created desktop shortcuts would point at mintty, resulting in a somewhat more phased introduction instead of springing it on users, which seems a prudent thing to do. - Offer the start menu item creation unless either Console or Terminal is present in the Cygwin folder. If requested, remove Cygwin Bash Shell and create Console and Terminal. (Add Cygwin prefixes according to taste. I think anyone who moves the shortcuts elsewhere would be quite capable of renaming them if they feel the need to.) Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 26 May 2011 09:07, Corinna Vinschen wrote: On May 26 08:00, Andy Koppe wrote: On 25 May 2011 16:51, Corinna Vinschen wrote: On May 25 09:54, Thomas Wolff wrote: Am 25.05.2011 09:43, schrieb Andy Koppe: ... Ah, sorry, I didn't realise that the desktop shortcut at the moment was simply called Cygwin rather than Cygwin Bash Shell. I suppose that could just stay like that actually. Also, since the start menu shortcut already is inside the Cygwin folder, just Terminal rather than Cygwin Terminal would be nice and crisp there. I think common usage is to give shortcuts rather a complete name. That's also better if people move them around, placing a copy on the desktop etc. And since bash shell runs in both command windows (is that a common name?), I think the previous proposal Cygwin Console and Cygwin Terminal is the best to distinguish them. I'm wondering if renaming the shortcuts is wise. New users should get the new shortcuts, but what about users who just update Cygwin? If we rename the shortcuts, existing users will have both check buttons in the last dialog checked again, even if they already had installed the old shortcuts before. Alternatively setup could test for the old and the new shortcut names, and only install if neither the old, nor the new ones exist. Gah, this is surprisingly difficult. How about: - Don't rename the desktop shortcut, leaving it as Cygwin. This means that it won't change for users that already have one, nor will they get another desktop shortcut. Only newly created desktop shortcuts would point at mintty, resulting in a somewhat more phased introduction instead of springing it on users, which seems a prudent thing to do. Agreed. - Offer the start menu item creation unless either Console or Terminal is present in the Cygwin folder. If requested, remove Cygwin Bash Shell and create Console and Terminal. (Add Cygwin prefixes according to taste. I think anyone who moves the shortcuts elsewhere would be quite capable of renaming them if they feel the need to.) Ooh, no. I really don't like the idea to offer two start menu entries by default. I'm not sure a lot of people even have a vague understanding what the difference between console and terminal is. If in doubt, I bet most people will choose the alphabetically first entry without reading or thinking, quite along the lines of http://www.joelonsoftware.com/uibook/chapters/fog62.html Fair point. If we really do that, the name of the console entry should be last, and ugly, so that people choose the Cygwin Terminal entry with a higher probability. Windows Console window with a bash within, only use if you must or something. :) That's possibly worse and certainly uglier than not having it at all, so let's leave it. On a closely related note, there's the issue of the mintty postinstall script. Simply dropping the mintty shortcut creation when setup.exe is changed would mean that the shortcut would disappear without replacement for people updating with a not-quite-up-to-date setup.exe or who habitually untick the Add start menu item checkbox. Therefore I think I should change the postinstall script such that it continues to create the mintty shortcut, but only if Cygwin Terminal isn't there. However, since setup.exe creates its shortcuts *after* running the postinstall script, people would end up with both mintty and Cygwin Terminal until the mintty package is next updated. Avoiding that requires setup.exe to nuke the mintty shortcut when it creates Cygwin Terminal. Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 26 May 2011 12:51, Corinna Vinschen wrote: On a closely related note, there's the issue of the mintty postinstall script. Simply dropping the mintty shortcut creation when setup.exe is changed would mean that the shortcut would disappear without replacement for people updating with a not-quite-up-to-date setup.exe or who habitually untick the Add start menu item checkbox. Therefore I think I should change the postinstall script such that it continues to create the mintty shortcut, but only if Cygwin Terminal isn't there. However, since setup.exe creates its shortcuts *after* running the postinstall script, people would end up with both mintty and Cygwin Terminal until the mintty package is next updated. Avoiding that requires setup.exe to nuke the mintty shortcut when it creates Cygwin Terminal. Hmm. That begs for the question why the start menu entry isn't managed entirely by mintty's postinstall/preremove scripts. In theory we can reduce setup to ask for the desktop icon. The start menu entry is always created, and it's always created by mintty. That would make the entire affair much easier, isn't it? Good point. The only argument against that I can think of is that the postinstall script shortcut is non-optional. There have been some minor complaints about that before. (Setup.exe would still need to nuke Cygwin Bash Shell). Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 26 May 2011 13:17, Corinna Vinschen wrote: On May 26 13:09, Andy Koppe wrote: On 26 May 2011 12:51, Corinna Vinschen wrote: That begs for the question why the start menu entry isn't managed entirely by mintty's postinstall/preremove scripts. In theory we can reduce setup to ask for the desktop icon. The start menu entry is always created, and it's always created by mintty. That would make the entire affair much easier, isn't it? Good point. The only argument against that I can think of is that the postinstall script shortcut is non-optional. There have been some minor complaints about that before. (Setup.exe would still need to nuke Cygwin Bash Shell). I'm willing to ignore both problems. Mintty isn't the only package to fill the Cygwin or Cygwin/X menu. Removing an existent Cygwin Bash Shell seems a bit harsh. Ah, alright, I thought was the intention, but leaving it is fine by me. Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 24 May 2011 10:50, Corinna Vinschen wrote:
On May 24 11:15, Corinna Vinschen wrote:
On May 23 21:14, Andy Koppe wrote:
On 23 May 2011 12:50, Corinna Vinschen wrote:
And who's going to create the patches?
I suppose that should be me, but my spare time is rather limited at
the moment and I still owe a patch or two for other things.
I'm just trying a setup.exe patch which creates Cygwin Terminal
desktop and start menu entries which point to mintty -. I just
have to get rid of my build environment problems...
Ok, here's my patch. It just replaces the Desktop and Start Menu
entries with Cygwin Terminal entries pointing to mintty - and
leaves Cygwin.bat untouched. Is that ok with everyone?
Index: desktop.cc
===
RCS file: /cvs/cygwin-apps/setup/desktop.cc,v
retrieving revision 2.55
diff -u -p -r2.55 desktop.cc
--- desktop.cc 19 Nov 2010 15:49:54 - 2.55
+++ desktop.cc 24 May 2011 09:47:51 -
@@ -78,7 +78,8 @@ DesktopSetupPage::DesktopSetupPage ()
static void
make_link (const std::string linkpath,
const std::string title,
- const std::string target)
+ const std::string target,
+ const std::string arg)
{
std::string fname = linkpath + / + title + .lnk;
@@ -93,10 +94,10 @@ make_link (const std::string linkpath,
std::string exepath;
std::string argbuf;
- if (!is_legacy)
+ if (IsWindowsNT ())
{
exepath = target;
- argbuf = ;
+ argbuf = arg;
}
else
{
@@ -105,6 +106,8 @@ make_link (const std::string linkpath,
GetWindowsDirectory (windir, sizeof (windir));
exepath = std::string(windir) + \\command.com;
argbuf = /E:4096 /c + target;
+ if (arg.size ())
+ argbuf += + arg;
}
msg (make_link_2 (%s, %s, %s, %s),
@@ -115,7 +118,8 @@ make_link (const std::string linkpath,
}
static void
-start_menu (const std::string title, const std::string target)
+start_menu (const std::string title, const std::string target,
+ const std::string arg)
{
LPITEMIDLIST id;
int issystem = (root_scope == IDC_ROOT_SYSTEM) ? 1 : 0;
@@ -137,11 +141,12 @@ start_menu (const std::string title, co
}
// end of Win95 addition
path += /Cygwin;
- make_link (path, title, target);
+ make_link (path, title, target, arg);
}
static void
-desktop_icon (const std::string title, const std::string target)
+desktop_icon (const std::string title, const std::string target,
+ const std::string arg)
{
char path[MAX_PATH];
LPITEMIDLIST id;
@@ -161,7 +166,7 @@ desktop_icon (const std::string title,
msg (Desktop directory for deskop link changed to: %s, path);
}
// end of Win95 addition
- make_link (path, title, target);
+ make_link (path, title, target, arg);
}
static void
@@ -243,15 +248,17 @@ do_desktop_setup ()
make_cygwin_bat ();
+ std::string target;
+
+ target = is_legacy ? batname : backslash (cygpath (/bin/mintty));
+
if (root_menu)
- {
- start_menu (Cygwin Bash Shell, batname);
- }
+ start_menu (is_legacy ? Cygwin Bash Shell : Cygwin Terminal, target,
+ is_legacy ? : -);
if (root_desktop)
- {
- desktop_icon (Cygwin, batname);
- }
+ desktop_icon (is_legacy ? Cygwin : Cygwin Terminal, target,
+ is_legacy ? : -);
}
static int da[] = { IDC_ROOT_DESKTOP, 0 };
@@ -425,8 +432,11 @@ DesktopSetupPage::OnActivate ()
else
{
root_menu =
- check_startmenu (Cygwin Bash Shell,
- backslash (cygpath (/cygwin.bat)));
+ is_legacy
+ ? check_startmenu (Cygwin Bash Shell,
+ backslash (cygpath (/cygwin.bat)))
+ : check_startmenu (Cygwin Terminal,
+ backslash (cygpath (/bin/mintty)));
}
if (NoDesktopOption)
@@ -436,7 +446,10 @@ DesktopSetupPage::OnActivate ()
else
{
root_desktop =
- check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)));
+ is_legacy
+ ? check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)))
+ : check_desktop (Cygwin Terminal,
+ backslash (cygpath (/bin/mintty)));
}
}
Ah, sorry, I didn't realise that the desktop shortcut at the moment
was simply called Cygwin rather than Cygwin Bash Shell. I suppose
that could just stay like that actually.
Also, since the start menu shortcut already is inside the Cygwin
folder, just Terminal rather than Cygwin Terminal would be nice
and crisp there.
Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 24 May 2011 10:15, Corinna Vinschen wrote: On May 23 21:14, Andy Koppe wrote: I also think the console's start menu entry in the Cygwin folder should be kept, perhaps with a new name. Console vs Terminal? Why? As a straightforward answer to questions along these lines: - I loved the old Cygwin Bash Shell with its endearingly quirky scrolling and copy'n'paste. Where did it go? - Mysql/Python/Java/Cmd.exe/other_interactive_non_cygwin_program doesn't work properly in this crappy new terminal. Can you make them work again please. Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 24 May 2011 19:42, Corinna Vinschen wrote: On May 24 13:21, Christopher Faylor wrote: I had a quick look: dosfilewarning Sets a bool. Has immediate effect. envcache Ditto. error_start Sets a string. Has immediate effect. export Sets a bool. Has effect on exec'ed child processes. glob Sets two bools. Has effect on exec'ed child processes. proc_retry Sets number. Has immediate effect. reset_com Sets bool. Has immediate effect. However, per the comment in fhandler_serial::open this works around a problem in Windows 9x! Maybe we should kill the setting? Yep. It's always fun to nuke those. Talking about nuking CYGWIN settings, I have at least two more candidates: envcache Did we ever had a problem which could be attributed to this setting? export Does anybody really set CYGWIN settings in the registry? Shouldn't we drop fetching CYGWIN settings from the registry entirely? proc_retry Does it really help? Personally I would also remove strip_title, display_title, and upcaseenv, but that's just me. The options remaining after such a cull are fairly obscure too, hence I think the CYGWIN variable is the appropriate interface, in particular if it will now be possible to set it in ~/.profile or similar. Adding a field to the mintty options dialog would of course be possible, but I'd rather not, because those settings have nothing to do with the terminal. Also, it looks suspiciously like the start of a slippery slope towards options for all sorts of things. Andy
Re: setup and mintty (was Re: New setup.exe release?)
On 23 May 2011 17:04, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
Uhm, maybe? :-)
Here's the deal: run the following program from the ncurses-demo package:
/usr/lib/ncurses/test/lrtest.exe
in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.
In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.
Why?
I suspect the reason is the terminfo settings for mintty (e.g. for
xterm-256color) specifies
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
(inherited via terminfo 'use' statements from xterm-basic), while the
terminfo settings for cygwin specify
acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)
Something. I don't know how mintty works, but the Cygwin console knows
the switch to/from alternate charset command ESC [ 11 m, ESC [ 10
m. The alternate charset is always codepage 437 which has the line
drawing chars at known single-byte positions in the = 128 region.
This is apparently used by ncurses when running in a console window,
but perhaps not when running in mintty.
Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.
Mintty does support that already. The feature was introduced by a
certain three-letter PC Unix company, and the Linux console supports
it too.
The DEC vtXXX series did not have that, however, which is why xterm
doesn't either. Instead, they have the DEC Special Character and Line
Drawing Set. When activated, character codes 0x60 to 0x7E map to
those special characters, as shown here:
http://vt100.net/docs/vt102-ug/table5-13.html. Mintty supports that
one too.
My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.
Chuck, what font are you using in mintty? It could just be that it
doesn't have glyphs for the relevant codepoints, in which case mintty
falls back to ASCII replacements. The default Lucida Console does have
the linedrawing glyphs needed for the vt100 set.
If it's not that, then the xterm terminfo entry would indeed need a closer look.
You can test support for the CP437 alternate charset, the vt100
graphics, and also direct Unicode line drawing by catting the attached
file created by Thomas Wolff.
Andy
xgraphics
Description: Binary data
Re: setup and mintty (was Re: New setup.exe release?)
On 23 May 2011 12:50, Corinna Vinschen wrote: On May 20 17:09, Yaakov (Cygwin/X) wrote: The setup.exe download is still 2.738. Could it be updated to 2.749 to include jturney's recent bug fixes? I'd like to fix the mintty issue first. So, do we swtch to mintty as default terminal, yes or no? If we switch to mintty we don't need the Cygwin.bat file anymore. But, shouldn't we keep it anyway for people who maintain some handmade symlink to it? Yes, I think so. If so, should we stick to the content of Cygwin.bat as is, or should we change it to call mintty, too? Better not, so as not to change people's existing setup. And because it would flash up a console for the .bat. And who's going to create the patches? I suppose that should be me, but my spare time is rather limited at the moment and I still owe a patch or two for other things. Last but not least, shouldn't we add mintty to the Base package anyway, independently of what we do to setup? Seems sensible. Further all this, if the change to mintty as the default is going ahead, there's the question of what the desktop shortcut should do and what it should be called. What it should do: 1) Invoke the user's default shell as set in /etc/passwd as a login shell. (This is what the mintty start menu shortcut currently does) 2) Invoke bash as a login shell. What it should be called: a) mintty: Few are going to know what that is. b) Cygwin Bash Shell: That's the current name of course. Not compatible with option 1 above. c) Cygwin Shell: Shell-neutral, but encourages the confusion between terminal and shell. d) Cygwin Terminal: Linux desktops usually have Terminal entries in their menus. e) something else? I also think the console's start menu entry in the Cygwin folder should be kept, perhaps with a new name. Console vs Terminal? Andy
Re: RFU: astyle-2.02-1
On 20 May 2011 23:15, Chris Sutcliffe wrote: Please upload astyle-2.02-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/astyle/astyle-2.02-1.tar.bz2 \ http://emergedesktop.org/cygwin/astyle/astyle-2.02-1-src.tar.bz2 Please leave 2.01-1 as previous and all other releases can be removed. Done. Thanks, Andy
Re: RFU: mksh-39c-5
On 27 March 2011 18:24, Chris Sutcliffe wrote:
Which of mksh-39c-{1,2,3,4}, if any, do you want to keep as
previous?
I think keep '-2' as previous and remove '-3' and '-4' as they have partial
patches.
Done.
Andy
Re: RFU: mksh-39c-5
On 26 March 2011 22:28, Chris Sutcliffe wrote:
Sigh, ran in to another corner case when testing, so had to roll a new
patch. This should be the last patch before the next official release
(which will handle all these scenarios without the need of a local patch).
Done. Which of mksh-39c-{1,2,3,4}, if any, do you want to keep as previous?
Thanks,
Andy
Re: [ ITA ] base-files
On 12 March 2011 09:14, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Andy, I don't see the change in cygwin-pkg-maint. Did you forget to checkin? Yep, sorry. Now done. Andy
Re: RFU: w32api-3.17-1
On 12 March 2011 04:41, Chris Sutcliffe wrote: Please upload w32api-3.17-1: Done. I've also nuked 3.11 to 3.15. Cheers, Andy
Re: [ ITA ] base-files
On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Can versions before 3.9-3 be deleted? Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Thanks for your patience! Andy
Re: [PATCH 1/4] Add the last element of URL path to site chooser, if interesting.
On 29 November 2010 12:57, Corinna Vinschen wrote: On Nov 26 13:48, Jon TURNEY wrote: Currently, for example, if I manually add the site http://mirrors.kernel.org/sources.redhat.com/cygwinports/ to setup's mirror list, I get two indistinguishable entries named http://mirrors.kernel.org. Furthermore, because the code to ensure the site just added is selected uses the string inside the list control to locate elements, we end up with a random one of those two indistinguishable entries selected (usually the previously existing one). This problem also prevents the selected sites being correctly saved and restored for the next setup run. So, to make the site chooser list entries unique and distinguishable, add the last element of the URL path to the site chooser, if it exists and isn't 'cygwin' (or some other alternatives used by current mirrors) That sounds a bit problematic. So two URLs on the same machine might again end up as the same string, undistinguishable, just because they both end in the same directory name? And there are (right now) four such directory names, which are treated identically. Don't get me wrong. It's certainly better than what we have today, and the full URL is almost unreadable. Nevertheless, I'd be more happy with a solution which fixes this problem even for such border cases... In the apparent absence of further work on this, it would be nice to see Jon's patch going in anyway, which most importantly addresses the issue for Cygwin Ports mirrors, without making anything worse. Andy
Re: [ITA] - base-files
On 7 March 2011 13:05, Andy Koppe wrote: On 6 March 2011 17:19, David Sastre wrote: - Not that it makes a great difference, but I think the interactive checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc from /etc/profile and ~/.profile, respectively, rather than doing it in the rc files. That would save opening the rc files in non-interactive login shells and unnecessary checks in interactive non-login shells. That's true, but the check also serves the purpose of avoiding those files to be sourced in non-interactive sesions, regardless who's calling. You mean from users' scripts? That's up to them, isn't it? The important thing is that it isn't sourced automatically for non-interactive sessions. On third thoughts, there is a very good reason for doing the interactive checks in the bashrc files rather than the profile files: the ~/.bash_profile from base-files 3.9 sources them both unconditionally, and existing users will continue to use that. Objection withdrawn. Andy
Re: [ITA] - base-files
On 6 March 2011 17:19, David Sastre wrote: - Not that it makes a great difference, but I think the interactive checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc from /etc/profile and ~/.profile, respectively, rather than doing it in the rc files. That would save opening the rc files in non-interactive login shells and unnecessary checks in interactive non-login shells. That's true, but the check also serves the purpose of avoiding those files to be sourced in non-interactive sesions, regardless who's calling. You mean from users' scripts? That's up to them, isn't it? The important thing is that it isn't sourced automatically for non-interactive sessions. - I think the commented-out CVS stuff in /etc/profile would be better placed in ~/.bash_profile, to allow non-admin users to uncomment it. Or perhaps just delete it altogether; since CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src isn't what's recommended at http://cygwin.com/cvs.html anymore anyway. Done. I've dropped it. Cheers. And a question: - Can we do away with ~/.bash_profile, and move the commented-out PATH, MANPATH, and INFOPATH setting from there into ~/.profile? I see the latter sources .bashrc anyway for bash shells, which makes sense. I'd rather keep .bash_profile around, because it has higher precedence in case both files exist. Sourcing .bashrc from .profile only exists as a fallback mechanism. Fair enough. In case you are about to upload this, could you please apply this patch to your local 4.0-3 copy? If you think these changes deserve a release bump, I'd roll a 4.0-4 version. Yeah, sorry, better do another one, I wouldn't trust myself to repackage this correctly. Also, I'm afraid I've stumbled across another possible issue regarding the unsetting of TMP and TEMP. I'll raise that in the relevant thread. Andy
Re: RFU: w32api-3.16-1
On 6 March 2011 07:13, Andy Koppe wrote: On 5 March 2011 21:16, Chris Sutcliffe wrote: Please upload w32api-3.16-1 I would, but I keep on getting 'Connection closed by 209.132.180.131' when trying to connect to sourceware.org. It's working again, so that's now uploaded. Can old versions (3.11 through 14) be deleted? Cheers, Andy
Re: RFU: mscgen-0.20-1
On 5 March 2011 15:25, Michael McTernan wrote: Hi, Please upload mscgen-0.20-1 which follows a new upstream release: wget -nd -P mscgen \ http://www.mcternan.me.uk/mscgen/cygport/mscgen-0.20-1.tar.bz2 \ http://www.mcternan.me.uk/mscgen/cygport/mscgen-0.20-1-src.tar.bz2 And leave 0.19-1 as previous, removing 0.18-1. Done. Thanks, Andy
Re: [ITA] - base-files
On 24 February 2011 10:14, David Sastre wrote: 2011/2/24, Corinna Vinschen: Hi David, On Feb 23 19:02, David Sastre wrote: Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig I can't download: wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org... 87.217.145.147 Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. Weird. I checked it out early this morning. Sometimes it doesn't work for me either due to dyndns (or my router's ddclient client, I can't tell for sure) not refreshing properly. (...calls home and requests a whatsmyip query...) OK. I've manually refreshed the IP and checked it out, it should be working now. The problem appears to be back: $ wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 --2011-03-05 17:01:20-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org (crapsteak.org)... 87.217.144.185 Connecting to crapsteak.org (crapsteak.org)|87.217.144.185|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. ... Sorry for not getting round to this sooner. Andy
