Re: [RFU] subversion-1.8.0-1
Hi David,
On Jun 19 18:07, David Rothenberger wrote:
Please upload subversion-1.8.0-1 as the new current release. Please
delete 1.6.17-1 and leave 1.7.10-1 as prev.
Thanks!
D=http://home.comcast.net/~david.rothenberger/cygwin
wget -x -nH --cut-dirs=2 \
${D}subversion/setup.hint \
${D}subversion/subversion-1.8.0-1-src.tar.bz2 \
${D}subversion/subversion-1.8.0-1.tar.bz2 \
${D}subversion/subversion-apache2/setup.hint \
${D}subversion/subversion-apache2/subversion-apache2-1.8.0-1.tar.bz2 \
${D}subversion/subversion-debuginfo/setup.hint \
${D}subversion/subversion-debuginfo/subversion-debuginfo-1.8.0-1.tar.bz2 \
${D}subversion/subversion-devel/setup.hint \
${D}subversion/subversion-devel/subversion-devel-1.8.0-1.tar.bz2 \
${D}subversion/subversion-gnome/setup.hint \
${D}subversion/subversion-gnome/subversion-gnome-1.8.0-1.tar.bz2 \
${D}subversion/subversion-perl/setup.hint \
${D}subversion/subversion-perl/subversion-perl-1.8.0-1.tar.bz2 \
${D}subversion/subversion-python/setup.hint \
${D}subversion/subversion-python/subversion-python-1.8.0-1.tar.bz2 \
${D}subversion/subversion-ruby/setup.hint \
${D}subversion/subversion-ruby/subversion-ruby-1.8.0-1.tar.bz2 \
${D}subversion/subversion-tools/setup.hint \
${D}subversion/subversion-tools/subversion-tools-1.8.0-1.tar.bz2
I'm getting a 404 error in both cases, 32 and 64 bit.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
noarch packages
TeX Live 2013 has been officially released, and I'll be sending an RFU soon for the 32bit distro. The packages are already in the 64bit distro. The vast majority of the texlive-collection-* packages are noarch packages. Should I still send the standard RFU, or is it easier for the uploader to copy the files from the 64bit release area? Ken
Re: [RFC] libexecdir
On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote: Conflicts like this will happen. If we change libexec, we have to be prepared for this kind of stuff. Is it worth it? I certainly have gone through this pain when the changeover was made on Linux. If we want to provide the real Linux look-and-feel I don't think we have any choice. :-) But, seriously, I think that the change makes sense in the long run. If we don't do this we'll eventually just have to be tweaking more and more configurations to put things in /usr/libexec rather than /usr/lib. On a similar note, what about Fedora (and others) fusion of /usr/bin /bin and /usr/sbin /sbin? Do we want to think about that too? It would certainly make sense for Cygwin. We could get rid of /usr/bin entirely. cgf
[RFU] stow
Please upload. Thanks, Andrew. # 64-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin64/stow/setup.hint \ http://home.comcast.net/~andrex2/cygwin64/stow/stow-2.2.0-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/stow/stow-2.2.0-1-src.tar.bz2
[RFU] atool
Please upload. Thanks, Andrew. # 64-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin64/atool/setup.hint \ http://home.comcast.net/~andrex2/cygwin64/atool/atool-0.39.0-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/atool/atool-0.39.0-1-src.tar.bz2
Re: [RFC] libexecdir
On Jun 20 10:19, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote: Conflicts like this will happen. If we change libexec, we have to be prepared for this kind of stuff. Is it worth it? I certainly have gone through this pain when the changeover was made on Linux. If we want to provide the real Linux look-and-feel I don't think we have any choice. :-) But, seriously, I think that the change makes sense in the long run. If we don't do this we'll eventually just have to be tweaking more and more configurations to put things in /usr/libexec rather than /usr/lib. Yeah, probably. Me and my lawn... On a similar note, what about Fedora (and others) fusion of /usr/bin /bin and /usr/sbin /sbin? Do we want to think about that too? It would certainly make sense for Cygwin. We could get rid of /usr/bin entirely. No, we can't. Fedora has /usr/bin, /usr/lib and /usr/sbin, while the /bin, /lib, and /sbin paths are just symlinks to their /usr counterparts. This is necessary to maintain hardcode paths, and this will not go away in Fedora for a long time. For Cygwin we did this fusion anyway since version 1.1 or so, just as mount points and in the other direction. We were far ahead of time :) Having said that, we could do the same for /sbin vs. /usr/sbin and create an automatic mount point for it as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] stow
On Jun 20 10:22, Andrew Schulman wrote: Please upload. Thanks, Andrew. # 64-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin64/stow/setup.hint \ http://home.comcast.net/~andrex2/cygwin64/stow/stow-2.2.0-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/stow/stow-2.2.0-1-src.tar.bz2 Thanks, uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] atool
On Jun 20 10:23, Andrew Schulman wrote: Please upload. Thanks, Andrew. # 64-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin64/atool/setup.hint \ http://home.comcast.net/~andrex2/cygwin64/atool/atool-0.39.0-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/atool/atool-0.39.0-1-src.tar.bz2 Ditto. ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] libexecdir
On Thu, Jun 20, 2013 at 05:10:57PM +0200, Corinna Vinschen wrote: On Jun 20 10:19, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote: Conflicts like this will happen. If we change libexec, we have to be prepared for this kind of stuff. Is it worth it? I certainly have gone through this pain when the changeover was made on Linux. If we want to provide the real Linux look-and-feel I don't think we have any choice. :-) But, seriously, I think that the change makes sense in the long run. If we don't do this we'll eventually just have to be tweaking more and more configurations to put things in /usr/libexec rather than /usr/lib. Yeah, probably. Me and my lawn... I see you got what I meant even though I got the sense wrong. On a similar note, what about Fedora (and others) fusion of /usr/bin /bin and /usr/sbin /sbin? Do we want to think about that too? It would certainly make sense for Cygwin. We could get rid of /usr/bin entirely. No, we can't. Fedora has /usr/bin, /usr/lib and /usr/sbin, while the /bin, /lib, and /sbin paths are just symlinks to their /usr counterparts. This is necessary to maintain hardcode paths, and this will not go away in Fedora for a long time. I guess I should have checked before sending the email but my point was if we should be eschewing the use of whichever Fedora has gotten rid of. You're right that /bin is a symlink. So should cygport and others now be forcing everything into /usr/whatever? For Cygwin we did this fusion anyway since version 1.1 or so, just as mount points and in the other direction. We were far ahead of time :) Having said that, we could do the same for /sbin vs. /usr/sbin and create an automatic mount point for it as well. Although I think they were my idea, I have never really liked the automatic mount points. Couldn't we just use a symlink? cgf
Re: [RFC] libexecdir
On Jun 20 11:17, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 05:10:57PM +0200, Corinna Vinschen wrote: On Jun 20 10:19, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 10:20:51AM +0200, Corinna Vinschen wrote: Conflicts like this will happen. If we change libexec, we have to be prepared for this kind of stuff. Is it worth it? I certainly have gone through this pain when the changeover was made on Linux. If we want to provide the real Linux look-and-feel I don't think we have any choice. :-) But, seriously, I think that the change makes sense in the long run. If we don't do this we'll eventually just have to be tweaking more and more configurations to put things in /usr/libexec rather than /usr/lib. Yeah, probably. Me and my lawn... I see you got what I meant even though I got the sense wrong. On a similar note, what about Fedora (and others) fusion of /usr/bin /bin and /usr/sbin /sbin? Do we want to think about that too? It would certainly make sense for Cygwin. We could get rid of /usr/bin entirely. No, we can't. Fedora has /usr/bin, /usr/lib and /usr/sbin, while the /bin, /lib, and /sbin paths are just symlinks to their /usr counterparts. This is necessary to maintain hardcode paths, and this will not go away in Fedora for a long time. I guess I should have checked before sending the email but my point was if we should be eschewing the use of whichever Fedora has gotten rid of. You're right that /bin is a symlink. So should cygport and others now be forcing everything into /usr/whatever? By default prefix is /usr anyway when building packages with cygport. I don't see a reason to disable packages from specifing /bin as installation path. After all, it's dumped into the same place anyway. For Cygwin we did this fusion anyway since version 1.1 or so, just as mount points and in the other direction. We were far ahead of time :) Having said that, we could do the same for /sbin vs. /usr/sbin and create an automatic mount point for it as well. Although I think they were my idea, I have never really liked the automatic mount points. Couldn't we just use a symlink? I'm not really loving them either, but the original reason to have /usr/bin and /usr/lib mount points rather than symlinks is performance. That was already the case in pre-1.7 Cygwin when we had the automatic generation of the /usr/bin and /usr/lib mount points in the registry. Handling mount points is noticably faster than handling symlinks. Symlinks require to read file content and since /usr/bin is first in $PATH by default, you get lots and lots of open/read/close calls on the /usr/bin symlink. Even if the file is cached, it's probably still slower than just fetching the mount point from the internal mount table. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: noarch packages
On 6/20/2013 6:49 AM, Ken Brown wrote: TeX Live 2013 has been officially released, and I'll be sending an RFU soon for the 32bit distro. The packages are already in the 64bit distro. The vast majority of the texlive-collection-* packages are noarch packages. Should I still send the standard RFU, or is it easier for the uploader to copy the files from the 64bit release area? Never mind. I'll just go ahead and send the RFU, but I'll separate out the noarch packages so that the uploader can do what he or she wants. Ken
[RFU] TeX Live 2013
I'm giving four separate wget commands below to make it clear what's happening:
The first is for noarch packages that are already in the 64bit distro; you can
simply copy them from the 64bit release area instead of using wget if that's
easier.
The second is for arch-dependent packages.
The third makes a bunch of packages obsolete, due to upstream reorganization.
Please check one or two to make sure I've done it right.
And the fourth is to remove the obsolescent texlive-collection-texinfo from the
dependencies of some already obsolete tetex packages (see
http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html).
texlive-collection-texinfo should also be removed from the dependencies of lyx.
D=http://sanibeltranquility.com/cygwin/release/TeX
TL=texlive
TC=texlive-collection
TD=texlive-collection-documentation
noarch:
wget -x -nH --cut-dirs=2 \
${D}/${TC}-basic/${TC}-basic-20130529-1.tar.bz2\
${D}/${TC}-basic/${TC}-basic-20130529-1-src.tar.bz2\
${D}/${TC}-basic/setup.hint\
${D}/${TC}-basic-doc/${TC}-basic-doc-20130529-1.tar.bz2\
${D}/${TC}-basic-doc/${TC}-basic-doc-20130529-1-src.tar.bz2\
${D}/${TC}-basic-doc/setup.hint\
${D}/${TC}-bibtexextra-doc/${TC}-bibtexextra-doc-20130529-1.tar.bz2\
${D}/${TC}-bibtexextra-doc/${TC}-bibtexextra-doc-20130529-1-src.tar.bz2\
${D}/${TC}-bibtexextra-doc/setup.hint\
${D}/${TC}-binextra/${TC}-binextra-20130529-1.tar.bz2\
${D}/${TC}-binextra/${TC}-binextra-20130529-1-src.tar.bz2\
${D}/${TC}-binextra/setup.hint\
${D}/${TC}-binextra-doc/${TC}-binextra-doc-20130529-1.tar.bz2\
${D}/${TC}-binextra-doc/${TC}-binextra-doc-20130529-1-src.tar.bz2\
${D}/${TC}-binextra-doc/setup.hint\
${D}/${TC}-context/${TC}-context-20130529-1.tar.bz2\
${D}/${TC}-context/${TC}-context-20130529-1-src.tar.bz2\
${D}/${TC}-context/setup.hint\
${D}/${TC}-context-doc/${TC}-context-doc-20130529-1.tar.bz2\
${D}/${TC}-context-doc/${TC}-context-doc-20130529-1-src.tar.bz2\
${D}/${TC}-context-doc/setup.hint\
${D}/${TC}-fontsextra/${TC}-fontsextra-20130529-1.tar.bz2\
${D}/${TC}-fontsextra/${TC}-fontsextra-20130529-1-src.tar.bz2\
${D}/${TC}-fontsextra/setup.hint\
${D}/${TC}-fontsextra-doc/${TC}-fontsextra-doc-20130529-1.tar.bz2\
${D}/${TC}-fontsextra-doc/${TC}-fontsextra-doc-20130529-1-src.tar.bz2\
${D}/${TC}-fontsextra-doc/setup.hint\
${D}/${TC}-fontsrecommended/${TC}-fontsrecommended-20130529-1.tar.bz2\
${D}/${TC}-fontsrecommended/${TC}-fontsrecommended-20130529-1-src.tar.bz2\
${D}/${TC}-fontsrecommended/setup.hint\
${D}/${TC}-fontsrecommended-doc/${TC}-fontsrecommended-doc-20130529-1.tar.bz2\
${D}/${TC}-fontsrecommended-doc/${TC}-fontsrecommended-doc-20130529-1-src.tar.bz2\
${D}/${TC}-fontsrecommended-doc/setup.hint\
${D}/${TC}-fontutils/${TC}-fontutils-20130529-1.tar.bz2\
${D}/${TC}-fontutils/${TC}-fontutils-20130529-1-src.tar.bz2\
${D}/${TC}-fontutils/setup.hint\
${D}/${TC}-fontutils-doc/${TC}-fontutils-doc-20130529-1.tar.bz2\
${D}/${TC}-fontutils-doc/${TC}-fontutils-doc-20130529-1-src.tar.bz2\
${D}/${TC}-fontutils-doc/setup.hint\
${D}/${TC}-formatsextra/${TC}-formatsextra-20130529-1.tar.bz2\
${D}/${TC}-formatsextra/${TC}-formatsextra-20130529-1-src.tar.bz2\
${D}/${TC}-formatsextra/setup.hint\
${D}/${TC}-games/${TC}-games-20130529-1.tar.bz2\
${D}/${TC}-games/${TC}-games-20130529-1-src.tar.bz2\
${D}/${TC}-games/setup.hint\
${D}/${TC}-genericextra/${TC}-genericextra-20130529-1.tar.bz2\
${D}/${TC}-genericextra/${TC}-genericextra-20130529-1-src.tar.bz2\
${D}/${TC}-genericextra/setup.hint\
${D}/${TC}-genericextra-doc/${TC}-genericextra-doc-20130529-1.tar.bz2\
${D}/${TC}-genericextra-doc/${TC}-genericextra-doc-20130529-1-src.tar.bz2\
${D}/${TC}-genericextra-doc/setup.hint\
${D}/${TC}-genericrecommended/${TC}-genericrecommended-20130529-1.tar.bz2\
${D}/${TC}-genericrecommended/${TC}-genericrecommended-20130529-1-src.tar.bz2\
${D}/${TC}-genericrecommended/setup.hint\
${D}/${TC}-genericrecommended-doc/${TC}-genericrecommended-doc-20130529-1.tar.bz2\
${D}/${TC}-genericrecommended-doc/${TC}-genericrecommended-doc-20130529-1-src.tar.bz2\
${D}/${TC}-genericrecommended-doc/setup.hint\
${D}/${TC}-htmlxml/${TC}-htmlxml-20130529-1.tar.bz2\
${D}/${TC}-htmlxml/${TC}-htmlxml-20130529-1-src.tar.bz2\
${D}/${TC}-htmlxml/setup.hint\
${D}/${TC}-humanities/${TC}-humanities-20130529-1.tar.bz2\
${D}/${TC}-humanities/${TC}-humanities-20130529-1-src.tar.bz2\
${D}/${TC}-humanities/setup.hint\
${D}/${TC}-humanities-doc/${TC}-humanities-doc-20130529-1.tar.bz2\
${D}/${TC}-humanities-doc/${TC}-humanities-doc-20130529-1-src.tar.bz2\
${D}/${TC}-humanities-doc/setup.hint\
${D}/${TC}-langafrican/${TC}-langafrican-20130529-1.tar.bz2\
${D}/${TC}-langafrican/${TC}-langafrican-20130529-1-src.tar.bz2\
${D}/${TC}-langafrican/setup.hint\
${D}/${TC}-langarabic/${TC}-langarabic-20130529-1.tar.bz2\
${D}/${TC}-langarabic/${TC}-langarabic-20130529-1-src.tar.bz2\
${D}/${TC}-langarabic/setup.hint\
Re: [RFU] subversion-1.8.0-1
Hi Corinna,
I think I was missing a slash in my emails.
Here's the 32-bit RFU again:
D=http://home.comcast.net/~david.rothenberger/cygwin
wget -x -nH --cut-dirs=2 \
${D}/subversion/setup.hint \
${D}/subversion/subversion-1.8.0-1-src.tar.bz2 \
${D}/subversion/subversion-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-apache2/setup.hint \
${D}/subversion/subversion-apache2/subversion-apache2-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-debuginfo/setup.hint \
${D}/subversion/subversion-debuginfo/subversion-debuginfo-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-devel/setup.hint \
${D}/subversion/subversion-devel/subversion-devel-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-gnome/setup.hint \
${D}/subversion/subversion-gnome/subversion-gnome-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-perl/setup.hint \
${D}/subversion/subversion-perl/subversion-perl-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-python/setup.hint \
${D}/subversion/subversion-python/subversion-python-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-ruby/setup.hint \
${D}/subversion/subversion-ruby/subversion-ruby-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-tools/setup.hint \
${D}/subversion/subversion-tools/subversion-tools-1.8.0-1.tar.bz2
And here's the 64-bit:
D=http://home.comcast.net/~david.rothenberger/cygwin64
wget -x -nH --cut-dirs=2 \
${D}/subversion/setup.hint \
${D}/subversion/subversion-1.8.0-1-src.tar.bz2 \
${D}/subversion/subversion-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-apache2/setup.hint \
${D}/subversion/subversion-apache2/subversion-apache2-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-debuginfo/setup.hint \
${D}/subversion/subversion-debuginfo/subversion-debuginfo-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-devel/setup.hint \
${D}/subversion/subversion-devel/subversion-devel-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-gnome/setup.hint \
${D}/subversion/subversion-gnome/subversion-gnome-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-perl/setup.hint \
${D}/subversion/subversion-perl/subversion-perl-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-python/setup.hint \
${D}/subversion/subversion-python/subversion-python-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-ruby/setup.hint \
${D}/subversion/subversion-ruby/subversion-ruby-1.8.0-1.tar.bz2 \
${D}/subversion/subversion-tools/setup.hint \
${D}/subversion/subversion-tools/subversion-tools-1.8.0-1.tar.bz2
Sorry about that!
--
David Rothenbergerspammer? - s...@daveroth.dyndns.org
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734
Truth never comes into the world but like a bastard, to the ignominy
of him that brought her birth.
-- Milton
Re: [RFU] subversion-1.8.0-1
On Jun 20 09:39, David Rothenberger wrote: Hi Corinna, I think I was missing a slash in my emails. Ah, I didn't realize that. Thanks for the new links. Uploaded and 1.6.17-1 remove. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] TeX Live 2013
On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[64bit] Updated: subversion-1.8.0-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.0/CHANGES for more details about the changes in 1.8.0. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. -- David Rothenbergerspammer? - s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Karmageddon: It's like, when everybody is sending off all these really bad vibes, right? And then, like, the Earth explodes and it's like, a serious bummer.
Re: [RFU] TeX Live 2013
On 6/20/2013 2:42 PM, Corinna Vinschen wrote: On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) OK, I'll do that. What email address should I use for you? The one in the Cygwin ChangeLogs? And is there a document with guidelines for uploading packages? Ken
Re: [RFU] TeX Live 2013
On Jun 20 15:07, Ken Brown wrote: On 6/20/2013 2:42 PM, Corinna Vinschen wrote: On Jun 20 12:10, Ken Brown wrote: I'm giving four separate wget commands below to make it clear what's happening: The first is for noarch packages that are already in the 64bit distro; you can simply copy them from the 64bit release area instead of using wget if that's easier. The second is for arch-dependent packages. The third makes a bunch of packages obsolete, due to upstream reorganization. Please check one or two to make sure I've done it right. And the fourth is to remove the obsolescent texlive-collection-texinfo from the dependencies of some already obsolete tetex packages (see http://cygwin.com/ml/cygwin-apps/2013-05/msg00113.html). texlive-collection-texinfo should also be removed from the dependencies of lyx. Gosh. Ken, would you like to have upload privileges? The list of TexLive packages always give me a mild stroke. If you fill out http://sourceware.org/cgi-bin/pdw/ps_form.cgi with me as approver, you can upload your packages as you see fit (and maybe help uploading other maintainer's packages once in a while...) OK, I'll do that. What email address should I use for you? The one in the Cygwin ChangeLogs? Yep. And is there a document with guidelines for uploading packages? Not really. The 32 bit release is in /sourceware/ftp/pub/cygwin/release, the 64 bit in /sourceware/ftp/pub/cygwin/64bit/release. Just upload your files to some subdir of your homedir and copy the files over to where they belong. The home dirs are on the same drive, so a cp -rplf will do (albeit you get error messages concerning the timestamps, nothing to worry about). Other than that, there's no upset yet running for the 64 bit release, so you have to create the setup64.ini files manually. You can do that like this: $ cd /sourceware/ftp/pub/cygwin/64bit ./GEN-sware Feel free to ask any question until you feel comfortable. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
setup in cvs head by early june 2013 does not run on xp
setup built from cvs at -D20130228 WILL run on xp setup built from cvs at -D20130331 will NOT run on xp (likewise at HEAD early june 2013) setup in cvs at -D20130331 will NOT run on xp because it has a static link to _vswprintf in ntdll.dll _vswprintf is not an exported symbol in ntdll.dll in xp (sp3 nor sp2) in -D20130228 version links to _vswprintf in msvcrt.dll cvs log for Makefile.am indicate ntdll and wininet were added on mar 4, 2013 in revision 2.94 builds of both were done with a version of cygwin installed around june 3, 2013, with a v2.774 setup.exe downloaded around that time. cygwin install was done from mirrors.kernel.org onto a windows xp sp3 acer netbook Is this a move toward not supporting cygwin on XP (W2K3 server) at all, or a mistake? (I tried searching the cygwin-apps maillist archives, but did not spot any items appearing related to this. The cvs log entry did not enlighten me as to why those two items were added then either, wasn't sure where else to research.) Without checking, I'd guess windows server 2003 might also be missing that export. Is it known that the prototype of the _vswprintf in ntdll.dll matches what is expected by the setup code (in iostream_cygfile and io_stream_file.cc)? (search for hieroglyphics and see it and item after it in http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-notifymax_rows=50style=nestedviewmonth=200903;) Regards, David Hoke
Re: setup in cvs head by early june 2013 does not run on xp
On Thu, Jun 20, 2013 at 09:04:26PM +, d_h...@hotmail.com wrote: setup built from cvs at -D20130228 WILL run on xp setup built from cvs at -D20130331 will NOT run on xp? (likewise at HEAD early june 2013) setup in cvs at -D20130331 will NOT run on xp because it has a static link to _vswprintf in ntdll.dll _vswprintf is not an exported symbol in ntdll.dll in xp (sp3 nor sp2) in -D20130228 version links to _vswprintf in msvcrt.dll cvs log for Makefile.am indicate ntdll and wininet were added on mar 4, 2013 in revision 2.94 builds of both were done with a version of cygwin installed around june 3, 2013, with a v2.774 setup.exe downloaded around that time. cygwin install was done from mirrors.kernel.org onto a windows xp sp3 acer netbook Is this a move toward not supporting cygwin on XP (W2K3 server) at all, or a mistake?? (I tried searching the cygwin-apps maillist archives, but did not spot any items appearing related to this.? The cvs log entry did not enlighten me as to why those two items were added then either, wasn't sure where else to research.)? Without checking, I'd guess windows server 2003 might also be missing that export. Is it known that the prototype of the _vswprintf in ntdll.dll matches what is expected by the setup code (in iostream_cygfile and io_stream_file.cc)?? (search for hieroglyphics and see it and item after it in http://sourceforge.net/mailarchive/forum.php?forum_name=mingw-notifymax_rows=50style=nestedviewmonth=200903;) You need to build with the newest version of mingw from the mingw64-i686 package. It seems like yours is out of date. Corinna and I build with the i686-w64-mingw32 target.
Re: cygwin and xwin and super and hyper
On 19/06/2013 22:27, J. David Boyd wrote: I can get my capslock key to be super with the command line 'setxkbmap -option caps:super', but I can't get 'setxkbmap -option altwin:hyper_win' to do anything. Running 'setxkbmap -print' shows both options as being set, but the win keys still act as the win key. Is there something else I need to do so windows lets go of these keys? Yes. Again, let me refer you to [1]. The operative sentence is: (Note that mapping the Windows keys to hyper also requires the -keyhook option, so that the X server sees those keys before the Windows shell) One thing I failed to mention there is that without any keymap options the keymap should give you super on the windows keys, but you will still need -keyhook X server option to enable the X server to see the key. [1] http://cygwin.com/ml/cygwin/2012-03/msg00427.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Make error when compiling xserver-cygwin-1.14.1-1
On 16/06/2013 15:25, Jon TURNEY wrote: On 16/06/2013 13:37, Matt D. wrote: /usr/src/xorg-server-1.14.1-1/src/xserver-cygwin-1.14.1-1/hw/xwin/glx/indirect.c:467: undefined reference to `_wglSwapIntervalEXTWrapper' These undefined references are a bit mysterious. These wgl*Wrapper functions should by defined in the generated_wgl_wrappers.c generated file. Ah, this is probably due to needing python to generate these files, despite not having an autoconf check for that. I've added one. Yes, I do. On that note, the prerequisites are missing: libpixman1-devel libx11-devel libgl-devel libxkbfile-devel libxcb-image-devel lib-icccm-devel (detected during configure) and glapi-devel (detected at compile-time) Thanks for the list. I'll update the documentation appropriately. I've added libglapi-devel, libxcb-icccm-devel and libxcb-image-devel. The others seem to be already on that page. They may not be getting installed by the setup invocation you give, I think package name is case sensitive, and setup doesn't diagnose attempts to install non-existent packages. There is also no sanity check for flex, although it is listed as a prerequisite. Ok. I guess I need to add one then :-) We already have a AC_PROG_LEX check. Unfortunately, even with this autoconf assumes that lex will not actually be needed to build as lex generated files will be shipped in the tarball made by 'make dist', and no error is reported if it isn't found. Also unfortunately, the xserver tarball included in the source package violates this assumption as it is generated by cygport directly from a git tag, not using 'make dist', so doesn't include these generated files. I've made a change so that the configure script in the xserver tarball included in the source package will now require lex and yacc to be found. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug with Cygwin's 'quilt' is actually in 'patch'
I'm building from Linux source from the X2Go git repository. The patches are being applied downstream to the last base nx libraries provided by NoMachine. It can't be helped if the original source has CRLF in this case. I understand that Cygwin is trying to emulate Linux here, but I don't believe that is the appropriate response regarding tools like 'patch' which should not have this kind of limitation. The fact that it thinks: \r\n \r\n but.. \r\n == \n As I mentioned previously, patch does NOT have this issue on Linux using the EXACT SAME test case. This is definitely a bug. On 6/20/2013 1:47 AM, Christopher Faylor wrote: On Wed, Jun 19, 2013 at 11:31:48PM -0400, Matt D. wrote: I've been looking further into this and it appears as though the problem is in 'patch' not 'quilt'. quilt is actually a collection of bash scripts and calls patch to do the actual patching. Using the same example I provided earlier in the thread, the same error occurs when calling patch directly: $ patch Imakefile patches/test.patch Running dos2unix on test.patch will allow the patch to apply successfully. However, this is WRONG. Imakefile and the initially created test.patch both use CRLF line endings. The patch should definitely NOT apply by introducing actual disparity. To summarize, the patch to Imakefile (CRLF) will apply if it is converted to LF line endings. Using the '--binary' switch seems to be a workaround for this issue. Sorry but we're emulating Linux here. You shouldn't have CRLF endings on your text file if you want the tools to work reliably. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with FAQ heading
On Jun 20 03:30, Buchbinder, Barry (NIH/NIAID) [E] wrote: http://cygwin.com/faq/faq.html#faq.programming.msvs-mingw 6.19. How do I use cygwin1.dll with Visual Studio or MinGW? This section doesn't actually mention MinGW except in its heading. Thanks for the heads up. There's also the later chapter faq.programming.win32-no-cygwin which mentions the old mingw.org but not the more modern mingw-w64 toolchain. I try to look into that, but I would be very grateful if somebody else could take a heart and update these chapters a bit. Patches most welcome! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug with Cygwin's 'quilt' is actually in 'patch'
On Jun 19 23:31, Matt D. wrote: I've been looking further into this and it appears as though the problem is in 'patch' not 'quilt'. quilt is actually a collection of bash scripts and calls patch to do the actual patching. Using the same example I provided earlier in the thread, the same error occurs when calling patch directly: $ patch Imakefile patches/test.patch Running dos2unix on test.patch will allow the patch to apply successfully. However, this is WRONG. Imakefile and the initially created test.patch both use CRLF line endings. The patch should definitely NOT apply by introducing actual disparity. To summarize, the patch to Imakefile (CRLF) will apply if it is converted to LF line endings. Using the '--binary' switch seems to be a workaround for this issue. I can reproduce this problem on 32 bit Cygwin but not on 64 bit Cygwin. The 64 bit version has a newer patch version 2.7.1, while I so far neglected to update the 32 bit version which is still on 2.6.1. I'll build a new patch 2.7.1 for 32 bit today. I hope that fixes it for 32 bit as well. Stay tuned for the announcement. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Different Result using ps -efW (Manual Cron)
Hi, I made a simple script that should detect if a certain service is running or not. Said script will run via cron. When I tested it and executed it manually in the command prompt, it list all Cygwin and Windows processes. But when I put it in cron, the number of services detected were not the same. Account used is the same during manual execution and also on cron. To get the list of services, I use this command /usr/bin/ps -efW. Do you have any idea why such behavior? Help is very much appreciated. Thanks. Regards, Jun Result via manual run UID PID PPID TTY STIME COMMAND jvi3147 5804 2192 pty2 16:12:50 /usr/bin/ps cyg_serv 4304 4844 ? 17:53:46 /usr/sbin/sshd cyg_serv 5964 4304 ? 10:16:27 /usr/sbin/sshd jvi3147 2192 5964 pty2 10:16:41 /usr/bin/bash jvi3147 5204 1 ? 11:41:02 /usr/bin/mintty jvi3147 4880 5204 pty0 11:41:02 /usr/bin/bash cyg_serv 4024 4304 ? 15:09:27 /usr/sbin/sshd cyg_serv 1652 4304 ? 09:08:35 /usr/sbin/sshd cyg_serv 2108 6088 ? 17:55:14 /usr/sbin/cron cyg_serv 4844 1 ? 17:53:46 /usr/bin/cygrunsrv cyg_serv 6088 1 ? 17:55:14 /usr/bin/cygrunsrv 0 4 0 ? Mar 28 System 0 412 0 ? Mar 28 C:\Windows\System32\smss.exe 0 480 0 ? Mar 28 C:\Windows\System32\csrss.exe 0 532 0 ? Mar 28 C:\Windows\System32\wininit.exe 0 608 0 ? Mar 28 C:\Windows\System32\services.exe 0 620 0 ? Mar 28 C:\Windows\System32\lsass.exe 0 628 0 ? Mar 28 C:\Windows\System32\lsm.exe 0 788 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 852 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 932 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 984 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1000 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1024 0 ? Mar 28 C:\Windows\System32\SLsvc.exe 0 1068 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1128 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1484 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1628 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 1728 0 ? Mar 28 C:\Windows\System32\spoolsv.exe 0 2008 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2020 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 300 0 ? Mar 28 C:\Program Files\Sophos\Remote Management System\ManagementAgentNT.exe 0 424 0 ? Mar 28 C:\Program Files\Sophos\AutoUpdate\ALsvc.exe 0 796 0 ? Mar 28 C:\Program Files\Sophos\Remote Management System\RouterNT.exe 0 680 0 ? Mar 28 C:\Windows\System32\taskeng.exe 0 2060 0 ? Mar 28 C:\Program Files\VMware\VMware Tools\vmtoolsd.exe 0 2184 0 ? Mar 28 C:\Program Files\VERITAS\VxPBX\bin\pbx_exchange.exe 0 2260 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2296 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\vnetd.exe 0 2500 0 ? Mar 28 C:\Program Files\VMware\VMware Tools\VMUpgradeHelper.exe 0 2532 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\bpinetd.exe 0 2704 0 ? Mar 28 C:\Program Files\VERITAS\NetBackup\bin\bpcd.exe 0 2928 0 ? Mar 28 C:\Windows\System32\dllhost.exe 0 3028 0 ? Mar 28 C:\Windows\System32\msdtc.exe 0 3360 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 3700 0 ? Mar 28 C:\Windows\System32\svchost.exe 0 2224 0 ? Apr 1 C:\Windows\System32\csrss.exe 0 1956 0 ? Apr 1 C:\Windows\System32\winlogon.exe 0 944 0 ? Apr 1 C:\Windows\System32\LogonUI.exe 0 3292 0 ? Jun 4 C:\Program Files\OCS Inventory Agent\OcsService.exe 0 4856 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\SavService.exe 0 6120 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\SAVAdminService.exe 0 4372 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\sdcservice.exe 0 4400 0 ? Jun 12 C:\Program Files\Sophos\Sophos Anti-Virus\Web Intelligence\swi_service.exe 0 4424 0 ? 18:10:12 C:\Windows\System32\csrss.exe 0 2440 0 ? 18:10:12
[ANNOUNCEMENT] Updated: patch-2.7.1-1
I just updated the patch utility to upstream version 2.7.1. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leadercygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git svn fork() problems on cygwin 1.7.20
Hi, I also noticed the perl package errors and did a reinstall of all perl packages with setup.exe. Did not help. Then in desperation I did a few reboots and rebaseall's and suddenly the problem is gone. Sigh. Somehow this is triggered by Windows 7 security updates but now again everything with cygwin is working. -Mikko -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Different Result using ps -efW (Manual Cron)
On Jun 20 01:22, Jun Iriola wrote: Hi, I made a simple script that should detect if a certain service is running or not. Said script will run via cron. When I tested it and executed it manually in the command prompt, it list all Cygwin and Windows processes. But when I put it in cron, the number of services detected were not the same. Account used is the same during manual execution and also on cron. To get the list of services, I use this command /usr/bin/ps -efW. Do you have any idea why such behavior? Help is very much appreciated. Thanks. It's probably related to your user token's permissions. See http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview Try using method 3, it should give full, equivalent access as in interactive mode. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote: I assume that, eventually and as-needed, a *small* number of additional hooks could be added to other code paths than exec/spawn/etc -- such as the aforementioned uname(3) thing. (One of the deltas between cygwin and msys was msys used a really stupid ownership/permission model -- pretend current user owns everything; check the DOS R/O bit for +w; check the file extension for +x; -- but this can be approximated with existing $CYGWIN entries or mount options. I think. So reimplementing that feature of MSYS would not require any additional hooks). IIRC that stupid ownership/permission model was a part of the original Cygwin 1.3 and was not modified. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On Jun 20 09:07, Earnie Boyd wrote: On Wed, Jun 19, 2013 at 4:25 PM, Charles Wilson wrote: I assume that, eventually and as-needed, a *small* number of additional hooks could be added to other code paths than exec/spawn/etc -- such as the aforementioned uname(3) thing. (One of the deltas between cygwin and msys was msys used a really stupid ownership/permission model -- pretend current user owns everything; check the DOS R/O bit for +w; check the file extension for +x; -- but this can be approximated with existing $CYGWIN entries or mount options. I think. So reimplementing that feature of MSYS would not require any additional hooks). IIRC that stupid ownership/permission model was a part of the original Cygwin 1.3 and was not modified. CYGWIN=ntsec ruled way back when... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/14/2013 5:39 PM, Nogin, Aleksey wrote: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 debug1: Delegating credentials debug1: Delegating credentials debug1: Enabling compression at level 6. debug1: Authentication succeeded (gssapi-with-mic). Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. MechType 1.3.6.1.4.1.311.2.2.10 is Microsoft's NTLM SSP. The sshd does not support NTLM and so rejects it. The next GSS mechanism is negotiated within the gssapi-with-mic exchange. That is probably Kerberos5 and it succeeds. Jeffrey Altman -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote: On 2013-06-19 12:57, Warren Young wrote: You're not talking about anything different than the sort of thing Cygwin package maintainers go through, sometimes needing to arm-twist odd build systems to behave according to cygport's expectations? I think you mean Cygwin's expectations? Not really, no. I'm assuming everyone is using cygport now to create packages, or can't because of one of these violated expectations. My ctags package is one of the latter, because although it ships with a configure script, it isn't an autoconf configure script. When I tried migrating the package to cygport 3.5 years ago, cygport failed to DTRT because the ctags build system doesn't know how to configure and build outside the source tree. I ended up falling back on my custom build script, which simply builds in-tree, then overrides some make(!) variables to force it to install into a temp directory, which I then pack up by hand. This is tolerable because ctags is a relatively simple package. I think I see how to get cygport to build this package now, but it wouldn't buy me much, because I'd be overriding so much of its default behavior. All I'd be doing is pushing it into this next category. That second category of packages are those that are built using cygport despite the fact that it requires a highly customized .cygport file. The more customizations you add, the more of cygport's base assumptions you are violating with your package. The last doxygen package I shipped was a good example of this: 1. I had to pass --platform linux-g++ to configure to get it to build correctly. (It might have been one of those cases where it saw #if WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS didn't exist when I wrote that, but for some reason I felt compelled to override the src_compile rule to pass this flag. 2. Though I now know about CYGCONF_ARGS, if I picked the package back up for some reason, I don't think I could get rid of my src_compile() override because of a second build problem: Doxygen's own documentation has a primitive and completely separate build system. Not only does make at the top level not cd doc make, but doc/Makefile also doesn't understand things like DESTDIR. I ended up needing to override src_install(), too. I don't mean to impugn cygport's capabilities, or yours, Yaakov. I prefer to use cygport, and don't like it when I can't. My point is, cygport's default assumptions about how software gets built and installed aren't always correct. Sometimes it has enough flexibility to cope with those differences (e.g. my doxygen case) and other times it's just not worth the bother (e.g. my ctags case). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
On Jun 20 11:43, Warren Young wrote: On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote: On 2013-06-19 12:57, Warren Young wrote: You're not talking about anything different than the sort of thing Cygwin package maintainers go through, sometimes needing to arm-twist odd build systems to behave according to cygport's expectations? I think you mean Cygwin's expectations? Not really, no. [...] My point is, cygport's default assumptions about how software gets built and installed aren't always correct. Sometimes it has enough flexibility to cope with those differences (e.g. my doxygen case) and other times it's just not worth the bother (e.g. my ctags case). My point is, it's always worth to switch packages to cygport: - cygport is the closest we have to a unified build system (like rpm). If every maintainer would use cygport, it would allow us to change the build method to one along the lines of most Linux distros. In Linux distros, the maintainer provides only the spec file and the source archive. The actual build for all supported platforms could be done on a machine which creates the distro from there. - Cygport does cope with most problems you can come up with and if it doesn't, you can tweak it. Your ctags problem could have been easily solved by the lndirs method, for instance. And if cygport still doesn't cope, there's an active maintainer and a cygwin-apps mailing list for questions. - Cygport is pretty easy to use and other people can easily pick up your package and build another version using your Cygwin build settings, or even take over maintainership should the need arise. Of course, the better is the foe of the good, but unless somebody comes up with another build system which integrates nicely into Cygwin and is easier to use than cygport, cygport is the best system we have and I advocate for using it throughout. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations
On 2013-06-20 12:43, Warren Young wrote:
I'm assuming everyone is using cygport now to create packages, or can't
because of one of these violated expectations.
My ctags package is one of the latter, because although it ships with a
configure script, it isn't an autoconf configure script. When I tried
migrating the package to cygport 3.5 years ago, cygport failed to DTRT
because the ctags build system doesn't know how to configure and build
outside the source tree. I ended up falling back on my custom build
script, which simply builds in-tree, then overrides some make(!)
variables to force it to install into a temp directory, which I then
pack up by hand. This is tolerable because ctags is a relatively simple
package.
This is explained in the manual wrt cygconf:
* cygconf is intended for configure scripts generated by, or compatible
with, autoconf. Packages with handwritten configure scripts may not
accept allthe flags used by cygconf, in which case a direct call to
the configure script is in order.
In this case, not having looked at ctags, you'll probably need something
along the lines of:
src_compile() {
lndirs
cd ${B}
./configure --prefix=/usr || error configure failed
cygmake
}
That second category of packages are those that are built using cygport
despite the fact that it requires a highly customized .cygport file. The
more customizations you add, the more of cygport's base assumptions you
are violating with your package.
The last doxygen package I shipped was a good example of this:
1. I had to pass --platform linux-g++ to configure to get it to build
correctly. (It might have been one of those cases where it saw #if
WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS
didn't exist when I wrote that, but for some reason I felt compelled to
override the src_compile rule to pass this flag.
FWIW, CYGCONF_ARGS has been around for a *long* time.
2. Though I now know about CYGCONF_ARGS, if I picked the package back up
for some reason, I don't think I could get rid of my src_compile()
override because of a second build problem: Doxygen's own documentation
has a primitive and completely separate build system. Not only does
make at the top level not cd doc make, but doc/Makefile also
doesn't understand things like DESTDIR. I ended up needing to override
src_install(), too.
There's nothing wrong with that. src_compile(), src_test(), and
src_install() are intended to be provided by cygport(5)s; the provided
*defaults* of those are NOT opaque APIs (hence they are actually shown
in the docs) and are meant to be overridden whenever necessary.
I don't mean to impugn cygport's capabilities, or yours, Yaakov. I
prefer to use cygport, and don't like it when I can't.
There should NEVER be a reason that you can't use cygport for your
packages. If you're having an issue, just provide your (draft)
cygport(5) and ask.
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: subversion-1.8.0-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.0/CHANGES for more details about the changes in 1.8.0. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenbergerspammer? - s...@daveroth.dyndns.org GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Karmageddon: It's like, when everybody is sending off all these really bad vibes, right? And then, like, the Earth explodes and it's like, a serious bummer. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations
On 20/06/13 18:43, Warren Young wrote: The last doxygen package I shipped was a good example of this: 1. I had to pass --platform linux-g++ to configure to get it to build correctly. (It might have been one of those cases where it saw #if WINDOWS == true and did the wrong thing.) I don't know if CYGCONF_ARGS didn't exist when I wrote that, but for some reason I felt compelled to override the src_compile rule to pass this flag. 2. Though I now know about CYGCONF_ARGS, if I picked the package back up for some reason, I don't think I could get rid of my src_compile() override because of a second build problem: Doxygen's own documentation has a primitive and completely separate build system. Not only does make at the top level not cd doc make, but doc/Makefile also doesn't understand things like DESTDIR. I ended up needing to override src_install(), too. In defence of cygport, it does a great job of subscribing to the Alan Kay principle: simple things are simple, and hard things are possible. If you think about just how many software packages there are in the Linux world, there are also a great many different techniques for building them. Cygport is really easy for most modern packages that adhere to (or are fairly close to) a standard install, and at least the packages that have, ahem, specialist installation mechanisms can be built with cygport too. The other great thing about cygport is that it has become the standard for building Cygwin packages, so all (or at least most of) the Cygwin maintainers can read and understand cygport files. This means it's much easier when the time comes to hand a package on to a new maintainer. Maybe this is straying into the [RFC] cygport documentation thread from the apps ML, but perhaps we could do with a cygport gallery: a selection of cygport files ranging from the deliciously simple three or four line affairs through to the more stubborn and difficult cases. I know that I've picked up some handy techniques by looking at other maintainers' cygport files. Dave. PS: As the current doxygen maintainer, I am sad to report that the cygport file isn't any smaller now that I'm building doxywizard, doing a test for libclang-devel (so that I can enable or disable clang assisted parsing), and forcing it to make a debuginfo package :-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
Jeffrey Altman wrote: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 debug1: Delegating credentials debug1: Delegating credentials debug1: Enabling compression at level 6. debug1: Authentication succeeded (gssapi-with-mic). Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. The issue that despite the Delegating credentials message, credentials are not being delegated. Aleksey
Broken MPIR 2.6.0 on Cygwin64
Dear all,
First thanks a lot for your hard work on the Cygwin project and the
Cygwin64 project.
I've begun to try to build Sage (http://www.sagemath.org) on Cygwin64
to provide some Windows support without the need of a virtual machine
running Linux and now have some trouble compiling a working MPIR 2.6.0
(http://www.mpir.org) library.
Note that I have no problems building a proper static or shared
version of GMP 5.1.2 with the GCC 4.8.1 toolchain currently provided
with Cygwin64, and it passes its complete testsuite.
At some point we should be able to switch to GMP, but we still have
some dependencies relying on MPIR's internals, so we have (and want,
even in the future by default) to stick with MPIR.
Also note we have no problem using MPIR on 32 bit Cygwin.
So my problem with MPIR are as follow:
* the ./configfsf.[guess|sub] and yasm/config/config.[guess|sub] file
within the upstream tarball are too old and failed to recognize
Cygwin64, replacing them with up-to-date version easily solves that,
* I have no problem building a static lib, but running make check
fails when linking any test executable, e.g. the first one
t-bswap.exe:
{{{
/bin/sh ../libtool --tag=CC--mode=link gcc -std=gnu99 -m64 -O2
-march=corei7-avx -mtune=corei7-avx-o t-bswap.exe t-bswap.o
libtests.la ../libmpir.la
libtool: link: gcc -std=gnu99 -m64 -O2 -march=corei7-avx
-mtune=corei7-avx -o t-bswap.exe t-bswap.o ./.libs/libtests.a
/home/jp/mpir-2.6.0/.libs/libmpir.a ../.libs/libmpir.a
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
Makefile:503: recipe for target `t-bswap.exe' failed
}}}
A 0 byte t-bswap.exe is created and the content of the stackdump is
{{{
$ cat tests/ld.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=03E
rax=0001004C3FA0 rbx=00060018DCB0 rcx=00060018DCB0
rdx=00060018ECA8 rsi=00C2A580 rdi=0025
r8 =00C2A590 r9 =BFFF r10=00C3
r11=0001004B111E r12=0001 r13=00060018ECA9
r14=000100534780 r15=00060018ECA8
rbp=00C2A590 rsp=00C2A528
program=C:\cygwin64\usr\x86_64-pc-cygwin\bin\ld.exe, pid 6744, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
FrameFunctionArgs
0C2A590 03E (000, 0130001, 00100512180, 000)
0C2A590 00100493B54 (000, 006000F4B30, 023, 000)
0C2A650 00100433783 (00100534780, 00600057550, 001800C0C2C, 000)
000 0010040E82C (00600022D10, 00600023CF8, 00100436389, 000)
001 0010040F2E0 (001802DE300, 00600019870, 001800C0C2C, 00600017A30)
001004DDD08 001004113FB (00100520580, 000, 001802E3E9D, 001802DF658)
001004DDD08 001004BF4C0 (0C2A9B0, 0C2AA46, 001801691B1, 000)
0C2AB80 0018004836E (000, 000, 000, 000)
000 0018004618B (000, 000, 000, 000)
000 0018004634F (000, 000, 000, 000)
000 001004BDD31 (000, 000, 000, 000)
000 00100401010 (000, 000, 000, 000)
000 00076B7652D (000, 000, 000, 00076BF9300)
000 0007726C521 (000, 000, 000, 00076BF9300)
End of stack trace
}}}
* I have no problem building a shared lib, nor the test programs in
that case, but many (but not all) of them segfaults when they are run.
In the two above cases, I was not able to retrieve useful information
when attaching gdb to the segfaulting process.
I just saw that three threads were launched and the backtrace only
involved Cygwin/Windows dlls.
Did anyone among the Cygwin folk tried to build MPIR on Cygwin64 and
got more success than I had?
Or has any advice to solve these issues?
Thanks in advance for your help,
Best,
--
Jean-Pierre Flori
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Heimdal 1.5.2: unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
On 6/20/2013 6:31 PM, Nogin, Aleksey wrote: Jeffrey Altman wrote: debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10 debug1: Delegating credentials debug1: Delegating credentials debug1: Enabling compression at level 6. debug1: Authentication succeeded (gssapi-with-mic). Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22). I'm not sure what the issue is here. The authentication succeeded. The issue that despite the Delegating credentials message, credentials are not being delegated. Aleksey I still do not understand what does that has to do with the subject of this message? The credentials that will be deleted are the credentials of the type that was accepted by the ssh gssapi-with-mic mechanism. At the verbosity level that you are using it does not state what that is. In any case, I am quite sure that if your ssh client states that it has delegated credentials that it has done so. You need to debug the server side to determine where the sshd environment or gssapi library has determined the credentials have been stored. For Kerberos it will need to be a credential cache. Heimdal defaults to using a non-FILE based cache but I suspect that Cygwin does not provide a non-FILE based cache implementation. Jeffrey Altman -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
If every maintainer would use cygport, it would allow us to change the build method to one along the lines of most Linux distros. In Linux distros, the maintainer provides only the spec file and the source archive. The actual build for all supported platforms could be done on a machine which creates the distro from there. That would be cool. Let's do it! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport limitations
On 6/20/2013 12:44, Yaakov (Cygwin/X) wrote: There should NEVER be a reason that you can't use cygport for your packages. If you're having an issue, just provide your (draft) cygport(5) and ask. Thanks for the offer. I've left myself a note to try this again for the next ctags release. I have no idea if there ever will be a new Exuberant Ctags. The last release came out 4 years ago, and activity to the ctags-devel list has been under 1 post per month[*] for the past 6 months. I'd be willing to convert 5.8 to cygport if this plan of Corinna's for an automated build server goes through. [*] http://sourceforge.net/mailarchive/forum.php?forum_name=ctags-devel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: patch-2.7.1-1
I just updated the patch utility to upstream version 2.7.1. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leadercygwin AT cygwin DOT com Red Hat
