Re: RFU: wcd 5.1.2-1
On Jun 23 19:57, Jari Aalto wrote: New upstream release. wget -nH -r --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/wcd/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.1.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.1.2-1.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New openssl package layout (was Re: Remove PINE from distro)
On Jun 23 14:38, Yaakov S wrote: On Wed, 2010-06-23 at 11:38 +0200, Corinna Vinschen wrote: Can you please have a look if that's ok? wget -nH -r \ http://www.vinschen.de/openssl/libopenssl098/libopenssl098-0.9.8o-2.tar.bz2 \ http://www.vinschen.de/openssl/libopenssl098/setup.hint \ http://www.vinschen.de/openssl/openssl-0.9.8o-2-src.tar.bz2 \ http://www.vinschen.de/openssl/openssl-0.9.8o-2.tar.bz2 \ http://www.vinschen.de/openssl/openssl-devel/setup.hint \ http://www.vinschen.de/openssl/openssl-devel/openssl-devel-0.9.8o-2.tar.bz2 \ http://www.vinschen.de/openssl/setup.hint openssl-devel should requires: libopenssl098 now, not openssl. I did that deliberately. the -devel package is supposed to pull in the base package as well, which in turn requires the correct versioned libopenssl* package. This way the -devel tools also pull in the user tools and man pages, and there's only the openssl package's setup.hint which has to be changed if the version number of the lib changes. Besides that, this looks alright. Thanks! Btw., if that's ok, I have the openssl-1.0.0a-1 package ready as well. So, after we uploaded the above 0.9.8o-2 package and converted all setup.hint files in the release area accordingly, we can switch over to openssl 1.0.0. For starters I have an openssh release based on openssl 1.0.0 waiting in the loop, too. You'll make a separate lib package for 1.0.0 as well with that release, right? Yes, sure. Wasn't the idea of the change to get versioned runtime libs? I'm going to upload this new package now. Then we have to change all dependencies throughout the release area from openssl to libopenssl098 and inform the maintainers. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New openssl package layout (was Re: Remove PINE from distro)
Yaakov (Cygwin/X) yselkowitz-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org writes: On Wed, 2010-06-23 at 13:35 +0300, Jari Aalto wrote: Could you package the latest 0.6.13? The layout of the binary package doesn't look right, but that may have to do with the older version. Sure. I can't rebuild the package from source, nor am I interested in wading through an entire script to figure out what's wrong. It's a generated script, no intended to be edited. Could you point me to the full log, so that I can take a look. It may be some enviroment issue. Jari
Re: New openssl package layout (was Re: Remove PINE from distro)
On Jun 24 11:03, Jari Aalto wrote: Yaakov (Cygwin/X) yselkowitz-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org writes: On Wed, 2010-06-23 at 13:35 +0300, Jari Aalto wrote: Could you package the latest 0.6.13? The layout of the binary package doesn't look right, but that may have to do with the older version. Sure. I can't rebuild the package from source, nor am I interested in wading through an entire script to figure out what's wrong. It's a generated script, no intended to be edited. Could you point me to the full log, so that I can take a look. It may be some enviroment issue. Something's broken with your MUA, Jari. Your mail is in the entirely wrong thread, including the subject and the reference to my mail with the message ID 20100623120055.gm8...@calimero.vinschen.de. Wasn't that intended to be a reply to Re: ITP: python-setuptools 0.6.10-1 (Python 2.6), message ID 1277320759.5452.39.ca...@yaakov04 ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
HEADSUP maintainers: Change in openssl package requires change in setup.hint
Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Here's the list of affected packages including their maintainers. Unfortunately the list also contains four orphaned packages. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? apache2 ORPHANED (Max Bowsher) aria2 Kostya Altukhov bind/libdns-devel Yaakov S bind/libdns50 Yaakov S ctorrent Yaakov S curl/libcurl-develYaakov S curl/libcurl3 ORPHANED (Brian Dessent) curl/libcurl4 Yaakov S cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-devel ORPHANED (Gareth Pearce) email Ross Smith II exim Pierre A. Humblet fetchmail Jason Tishler git Eric Blake gnome-vfs2/libgnomevfs2-devel Yaakov S gnome-vfs2/libgnomevfs2_0 Yaakov S gqDr. Volker Zell httping Jari Aalto irssi Kostya Altukhov lftp Andrew Schulman libarchive/libarchive-devel Charles Wilson libarchive/libarchive2Charles Wilson libQtNetwork4 Yaakov S libQtNetwork4-devel Yaakov S libssh2/libssh2-devel Yaakov S libssh2/libssh2_1 Yaakov S links Jari Aalto lynx Corinna Vinschen msmtp Jari Aalto mutt Christopher Faylor neon/libneon-develDr. Volker Zell neon/libneon25Dr. Volker Zell neon/libneon26Dr. Volker Zell neon/libneon27Dr. Volker Zell openldap/libopenldap2 Dr. Volker Zell openldap/libopenldap2_2_7 Dr. Volker Zell openldap/libopenldap2_3_0 Dr. Volker Zell openldap/openldap-devel Dr. Volker Zell openssh Corinna Vinschen parrotReini Urban parrot/parrot-devel Reini Urban postgresqlReini Urban postgresql/libecpg-devel Reini Urban postgresql/libpq-develReini Urban postgresql/libpq3 Reini Urban postgresql/libpq4 Reini Urban postgresql/libpq5 Reini Urban postgresql/postgresql-client Reini Urban postgresql/postgresql-devel Reini Urban pure-ftpd Kostya Altukhov pythonJason Tishler ruby Corinna Vinschen serf/libserf0-devel David Rothenberger serf/libserf0_0 David Rothenberger socat Andrew Schulman squid Dr. Volker Zell ssmtp Charles Wilson stunnel Andrew Schulman suck Jari Aalto suite3270/c3270 Peter A. Castro suite3270/pr3287 Peter A. Castro suite3270/s3270 Peter A. Castro suite3270/tcl3270 Peter A. Castro suite3270/x3270 Peter A. Castro SWI-PrologCorinna Vinschen syslog-ng Corinna Vinschen uw-imap/c-client Dr. Volker Zell uw-imap/uw-imap-imapd Dr. Volker Zell uw-imap/uw-imap-util Dr. Volker Zell w3m Bob Heckel wget Eric Blake xorg-server Yaakov
ITP: python-setuptools 0.6.13-1 (Python 2.6)
Could you package the latest 0.6.13? The layout of the binary package doesn't look right, but that may have to do with the older version. wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/setup.hint setup.hint sdesc: Python Library providing distutils enhancements ldesc: A rewrite of the orignal setuptools project under library name 'Distribute'. This package is intended to replace original Setuptools as the standard method for working with Python module distributions. category: Libs Python requires: python To test after *-src unpack: ./*.sh --color --verbose all | almostall 21 | tee /tmp/build.log Plese send build.log to my email if there are any problems, Jari
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. Done.
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. URLs: (use guest/guest as login/password for the site below): fixes: http://rt.openssl.org/Ticket/Display.html?id=2234 compat feature: http://rt.openssl.org/Ticket/Display.html?id=2272 HTH -- Matthias Andree
RFU: links 2.2-1
New upstream release: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/links/links-2.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/links/links-2.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/links/setup.hint NOTE: setup.hint includes new libopenssl098 Jari
RFU: zsync 0.6.1-1
New upstream release: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/zsync/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/zsync/zsync-0.6.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/zsync/zsync-0.6.1-1.tar.bz2 Jari
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 15:55, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. There are no plans. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: links 2.2-1
On Jun 24 17:19, Jari Aalto wrote: New upstream release: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/links/links-2.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/links/links-2.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/links/setup.hint NOTE: setup.hint includes new libopenssl098 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: zsync 0.6.1-1
On Jun 24 17:34, Jari Aalto wrote: New upstream release: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/zsync/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/zsync/zsync-0.6.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/zsync/zsync-0.6.1-1.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: New openssl package layout (was Re: Remove PINE from distro)
Wasn't that intended to be a reply to Re: ITP: python-setuptools 0.6.10-1 (Python 2.6), message ID 1277320759.5452.39.ca...@yaakov04 ? Yes. Something's broken with your MUA, Jari. Your mail is in the entirely wrong thread, including the subject and the reference to my mail with the message ID 20100623120055.GM8163-gFVU/9lprby7j6wt5svu1orpfetaz...@public.gmane.org Indeed. I'll have to monitor where the probleme might be in Gnus Jari.
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: On Jun 24 15:55, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: Hi guys, according to the discussion starting here http://cygwin.com/ml/cygwin-apps/2010-06/msg00101.html the layout of the openssl package has changed so that the runtime libraries are now in the libopenssl098 package, rather than in the openssl base package. The openssl package will be switched from 0.98 to 1.0.0 really soon now, and that switch will also introduce the new runtime package libopenssl100. This package is slightly backward incompatible with 0.9.8. What are the plans to deal with the hash vs. oldhash for the CApath directories? All the directories hosting single-cert-per-file stuff will have to be rehashed. There are no plans. Are the openssl maintainers aware there have been c_rehash fixes post-1.0.0 release? I've filed one, and one other to generate dual symlinks with a special c_rehash option which TTBOMK has not been accepted upstream yet, but can also help with sharing such directories between -0.9.8 and 1.0.0+ installations, should that be necessary -- and I guess that would be the case from the existence of separate packages for 0.9.8X and 1.0.0X. I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. RECOMMENDATION: - if the *default* version moves from 0.9.8o to 1.0.0a, c_rehash should be run on /usr/ssl/certs, so that existing certificate configurations just continue to work. HOWEVER: - while the 0.9.8 library has to be c_rehash (without the second patch I posted from ticket 2278, and unless you run the patched version with the extra compatibility argument) removes all old symlinks from /usr/ssl/certs, so if you run 1.0.0's c_rehash, the 0.9.8 library no longer finds certificates. I can fancy the following solutions: A - coordinate efforts so that *all* ssl-dependent packages have been recompiled against to 1.0.0a, and then upgrade openssl and all users in one giant leap, all at the same time. alternatively, if you must keep 0.9.8, B - patch c_rehash as I'd proposed to OpenSSL with the patch so as to get two symlinks for each certificate for a transition period (i. e. until 0.9.8 is gone) - also put prominent notices that users that rely on applications that use 0.9.8 need to run c_rehash with the compatibility option Or: B2 - use my patch against (the 2278 ticket, see previous email) but further modify it to always run compatibility mode, until 0.9.8 is gone Independent of all that, consider a holistic approach to consolidate and manage all certificates for all TLS packages (gnutls, and nss if shipped - dunno) into these flat-file storages. GnuTLS always uses flat files, and perhaps should share the default /usr/ssl/cert.pem location (unless it already does, I didn't check). Samples could be taken from Debian/Ubuntu with the /usr/sbin/update-ca-certificates script found in their ca-certificates package. Regardless of the path chosen, please make sure there are PROMINENT NOTICES that users need to rehash their private certs directories after the upgrade. I'd even propose to patch setup.exe so it can pop up such package-specific notices, or print them at the end of the installation if in non-interactive modes, and bump the setup.ini version to encourage setup.exe upgrades. Hoping for a smooth 1.0.0 transition (after having seen some fail...) -- Matthias Andree
Re: ITP: python-setuptools 0.6.13-1 (Python 2.6)
Jari, your MUA is still responding to the wrong thread. On Thu, 2010-06-24 at 14:37 +0300, Jari Aalto wrote: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/setup.hint $ wget http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 --2010-06-24 14:19:27-- http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 Resolving cante.net... 84.231.58.63 Connecting to cante.net|84.231.58.63|:80... failed: Connection timed out. Retrying. setup.hint sdesc: Python Library providing distutils enhancements ldesc: A rewrite of the orignal setuptools project under library name 'Distribute'. This package is intended to replace original Setuptools as the standard method for working with Python module distributions. category: Libs Python requires: python Again: please use category: Devel Python; it's not a general-purpose library. There is also a misspelling of 'original'. Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 20:13, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. Openssl does not come with any certificate and there's no certificate package in Cygwin either. AFAICS it would be sufficient to move to another ssl directory like, say, /usr/share/ssl instead of /usr/ssl. The user can copy and rehash any certificates manually, or install root certificates from scratch for 1.0.0. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 21:41 +0200, Corinna Vinschen wrote:
Openssl does not come with any certificate and there's no certificate
package in Cygwin either. AFAICS it would be sufficient to move to
another ssl directory like, say, /usr/share/ssl instead of /usr/ssl.
The user can copy and rehash any certificates manually, or install
root certificates from scratch for 1.0.0.
1.0.0 would be a good opportunity to FHS-ize the openssl package.
Move /usr/ssl to /usr/share/{open}ssl, but careful with /usr/ssl/man;
moving that to /usr/share/man would clobber some man1pages. Also,
could /usr/lib/engines be moved to /usr/lib/openssl/engines? The
current path is quite ambiguous as to its purpose.
Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Jun 24 14:55, Yaakov S wrote:
On Thu, 2010-06-24 at 21:41 +0200, Corinna Vinschen wrote:
Openssl does not come with any certificate and there's no certificate
package in Cygwin either. AFAICS it would be sufficient to move to
another ssl directory like, say, /usr/share/ssl instead of /usr/ssl.
The user can copy and rehash any certificates manually, or install
root certificates from scratch for 1.0.0.
1.0.0 would be a good opportunity to FHS-ize the openssl package.
Move /usr/ssl to /usr/share/{open}ssl, but careful with /usr/ssl/man;
moving that to /usr/share/man would clobber some man1pages.
Openssl's configuration only allows two location options, --prefix,
which is set to /usr, and --openssldir, which is set to /usr/ssl
by default. So, if we change --openssldir to /usr/share/ssl, all
files will move there, including the man pages.
Also,
could /usr/lib/engines be moved to /usr/lib/openssl/engines? The
current path is quite ambiguous as to its purpose.
I didn't look into the patches applied by Linux distros, but the
upstream, vanilla openssl package does not allow to move directories
other than with --prefix and --openssldir. The engines path is, like
others, hardcoded into the Makefile, like this:
install_sw:
@$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/bin \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/pkgconfig \
$(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl \
$(INSTALL_PREFIX)$(OPENSSLDIR)/misc \
$(INSTALL_PREFIX)$(OPENSSLDIR)/certs \
$(INSTALL_PREFIX)$(OPENSSLDIR)/private
[...]
Being able to build from the vanilla sources is a pretty high priority
for me.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 22:25 +0200, Corinna Vinschen wrote: Openssl's configuration only allows two location options, --prefix, which is set to /usr, and --openssldir, which is set to /usr/ssl by default. So, if we change --openssldir to /usr/share/ssl, all files will move there, including the man pages. Which is probably better, as long as you change the profile.d scripts accordingly to fix MANPATH. I didn't look into the patches applied by Linux distros, but the upstream, vanilla openssl package does not allow to move directories other than with --prefix and --openssldir. The engines path is, like others, hardcoded into the Makefile, like this: Yuck. I suppose you better leave it then, as ambiguous as it is. Yaakov
Re: ITP: python-setuptools 0.6.13-1 (Python 2.6)
Yaakov (Cygwin/X) yselkowitz-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org writes: Jari, your MUA is still responding to the wrong thread. On Thu, 2010-06-24 at 14:37 +0300, Jari Aalto wrote: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/setup.hint Connecting to cante.net|84.231.58.63|:80... failed: Connection timed Should be up now. category: Libs Python use category: Devel Python ... There is also a misspelling of 'original'. Done. Please sned full build.log in case of probelems: ./*.sh --color --verbose all | almostall Jari
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On Thu, 2010-06-24 at 11:36 +0200, Corinna Vinschen wrote: So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? You are correct; I fixed this in CVS. apache2 ORPHANED (Max Bowsher) This desperately needs to be ITA'd. I have a version in Ports if anyone who actually uses this wants to pick it up: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-devel ORPHANED (Gareth Pearce) As previously discussed, these actually use libopenssl097. Yaakov
Re: ITP: python-setuptools 0.6.13-1 (Python 2.6)
On Thu, 2010-06-24 at 23:41 +0300, Jari Aalto wrote: wget -r --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/python-setuptools-0.6.13-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/python-setuptools/setup.hint The package layout is still incorrect, and the package still does not build from source. Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
Corinna Vinschen wrote on 2010-06-24: On Jun 24 20:13, Matthias Andree wrote: Corinna Vinschen wrote on 2010-06-24: I have no idea about this stuff. I'm maintaining openssl primarily since it's required for openssh. If there's anything which isn't fixed upstream, it won't be fixed for Cygwin. The Cygwin 1.0.0a-1 package is from the vanilla sources. The 0.9.8 runtime libs will only be kept in place until all packages using it have been converted to 1.0.0. I have no incentive to keep old runtime libs indefinitely. Then please hold your horses. Do it wrong and the upgrade breaks OpenSSL on lots of installations. And: if the upgrade isn't done properly, bug reports about this will often be misfiled with the application programmers as regressions. http://www.fetchmail.info/fetchmail-FAQ.html#R14 and http://www.fetchmail.info/ bear testimonies of such misfilings :) Here's the short scoop: - OpenSSL 1.0.0 uses a different hash for /usr/ssl/certs than 0.9.8 did, so after the default ssl version is upgraded to 1.0.0, c_rehash needs to be run on that directory. Openssl does not come with any certificate and there's no certificate package in Cygwin either. AFAICS it would be sufficient to move to another ssl directory like, say, /usr/share/ssl instead of /usr/ssl. The user can copy and rehash any certificates manually, or install root certificates from scratch for 1.0.0. I see you are taking this upgrade far too lightly. You are *massively* underestimating the dangers and importance of this particular upgrade to 1.0.0 is. It's very different from the 0.9.6-0.9.7-0.9.8 path which was barely noticable to users. SSL in Cygwin has so far just worked, users could install certs in the usual places and things would just work. The 1.0.0 upgrade the way you are (not) planning it is going to break users' setups in spectacular ways, and create considerable astonishment and frustration. Not shipping certs by default is no excuse for stomping over and breaking user setups. If you change the ssldir to /usr/share, the postinstall script should move the contents from /usr/ssl to /usr/share/ssl. At least users should be told there is manual intervention (move certs, rehash) required BEFORE they can proceed to installation. For the rehashing issues, see my previous mail. This really should be done from postinstall, too, if the majority of packages moves to 1.0.0 at the same time. For c_rehash, do consider my two patches, it will help. This was my last unsolicited warning on this matter. You have been warned. -- Matthias Andree
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On 6/24/2010 5:02 PM, Yaakov (Cygwin/X) wrote: Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. When I built it for (a cygwin fork that shall not be named), they were: lib/openssl/engines-1.0.0/libubsec.so lib/openssl/engines-1.0.0/libsureware.so lib/openssl/engines-1.0.0/libpadlock.so lib/openssl/engines-1.0.0/libnuron.so lib/openssl/engines-1.0.0/libgost.so lib/openssl/engines-1.0.0/libgmp.so lib/openssl/engines-1.0.0/libcswift.so lib/openssl/engines-1.0.0/libchil.so lib/openssl/engines-1.0.0/libcapi.so lib/openssl/engines-1.0.0/libatalla.so lib/openssl/engines-1.0.0/libaep.so lib/openssl/engines-1.0.0/lib4758cca.so lib/openssl/engines-1.0.0/ bin/msys-ssl-1.0.0.dll bin/msys-crypto-1.0.0.dll (obviously those last two would be cygssl-1.0.0.dll and cygcrypto-1.0.0.dll) Now, that build used the following patches make-dummy-cert* Makefile.certificate openssl-0.9.6-x509.patch openssl-0.9.7-beta5-version-add-engines.patch openssl-0.9.8a-defaults.patch-1.0.0 openssl-0.9.8a-enginesdir.patch-1.0.0 openssl-0.9.8-beta6-icpbrasil.diff openssl-0.9.8e-crt.patch derived/taken from Mandriva. But at most those patches only affected the engine path, not the DLL names. -- Chuck
Re: [RFU - test] flk, fltk_gdi
On Mon, 2010-05-10 at 17:57 -0500, Yaakov (Cygwin/X) wrote: On 2010-05-10 15:52, A.R. Burgers wrote: I would like to have the following packages uploaded as test package: Whoa, there are a few problems here. 1) libfltk1.1-devel should be unversioned (libfltk-devel), as this package will eventually be updated to 1.3 versions (which are NOT parallel-installable to 1.1) if and when that branch goes stable. IOW there cannot be both libfltk1.1-devel and libfltk1.3-devel, as the files they provide will collide. 2) For a similar reason, we can't have both X11 and GDI versions of fltk because there can only be one libfltk-devel (ot, and I think we agreed that it would be X11. The libfltk1.1-gdi (for compatibility with packages already built for the GDI FLTK) is okay, as those library names include nox and won't collide with the X11 versions. This also removes the need for a libfltk1.1-include, which would be part of libfltk-devel. Ping? Any reason you can't use my version from Ports? Yaakov
Re: HEADSUP maintainers: Change in openssl package requires change in setup.hint
On 25/06/2010 7:02 AM, Yaakov (Cygwin/X) wrote: On Thu, 2010-06-24 at 11:36 +0200, Corinna Vinschen wrote: So, what we have to do is to convert *ALL* existing package dependencies from openssl to libopenssl098. I'm going to do this in the setup.hint files on cygwin.com, but, please do this in your local copy of your setup.hint files as well. As soon as I upgraded to openssl-1.0.0a-1, make sure that you keep your package dependencies in shape when building a new package. That means to change from libopenssl098 to libopenssl100. Do you know yet what the actual DLL names are going to be? libkio dlopen()s these instead of linking against them, so I want to fix these for my next KDE release. However, isn't libcurl3 OBSOLETE, rather than ORPHANED? You are correct; I fixed this in CVS. apache2 ORPHANED (Max Bowsher) This desperately needs to be ITA'd. I have a version in Ports if anyone who actually uses this wants to pick it up: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ cyrus-sasl/libsasl2 ORPHANED (Gareth Pearce) cyrus-sasl/libsasl2-develORPHANED (Gareth Pearce) As previously discussed, these actually use libopenssl097. Yaakov I have no expectation that I will look at repackaging sasl ever - my motivation for that package is Long gone. --Gareth
[ITA] e2fsprogs, e2fsimage
Continuing my mission to remove the overlaps between distro and Ports, I'll take e2fsprogs. This release features, with some hacking, shared libraries. It depends on a simultaneous (and long-overdue) update to util-linux, as libuuid and libblkid which were previously provided by e2fsprogs are now provided by util-linux. ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/e2fsprogs-1.41.12-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/e2fsprogs-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libcom_err-devel/libcom_err-devel-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libcom_err-devel/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libcom_err2/libcom_err2-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libcom_err2/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libe2p-devel/libe2p-devel-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libe2p-devel/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libe2p2/libe2p2-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libe2p2/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libext2fs-devel/libext2fs-devel-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libext2fs-devel/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libext2fs2/libext2fs2-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libext2fs2/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libss-devel/libss-devel-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libss-devel/setup.hint ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libss2/libss2-1.41.12-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsprogs/libss2/setup.hint For rebuilding from source, the aforementioned util-linux update can be found here for now: ftp://sourceware.org/pub/cygwinports/release-2/util-linux/ While I'm at it, I'll go ahead and take the closely-related e2fsimage: ftp://sourceware.org/pub/cygwinports/release-2/e2fsimage/e2fsimage-0.2.2-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsimage/e2fsimage-0.2.2-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/e2fsimage/setup.hint Yaakov
[ITA] cppunit
I asked for cppunit to be updated for gcc4 back in January[1], pinged in February[2], resulting in a very generous offer from cgf[3]. For lack of response from the previous maintainer (Ross Smith II), I request permission to consider the package orphaned, to which I hereby ITA: ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/setup.hint Yaakov [1] http://cygwin.com/ml/cygwin/2010-01/msg00483.html [2] http://cygwin.com/ml/cygwin/2010-02/msg00031.html [3] http://cygwin.com/ml/cygwin/2010-02/msg00054.html
[ITA] cppunit
I asked for cppunit to be updated for gcc4 back in January[1], pinged in February[2], resulting in a very generous offer from cgf[3]. For lack of response from the previous maintainer (Ross Smith II), I request permission to consider the package orphaned, to which I hereby ITA: ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/setup.hint Yaakov [1] http://cygwin.com/ml/cygwin/2010-01/msg00483.html [2] http://cygwin.com/ml/cygwin/2010-02/msg00031.html [3] http://cygwin.com/ml/cygwin/2010-02/msg00054.html
Re: [ITA] cppunit
On Thu, Jun 24, 2010 at 10:23:16PM -0500, Yaakov (Cygwin/X) wrote: I asked for cppunit to be updated for gcc4 back in January[1], pinged in February[2], resulting in a very generous offer from cgf[3]. For lack of response from the previous maintainer (Ross Smith II), I request permission to consider the package orphaned, to which I hereby ITA: ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/setup.hint Yaakov [1] http://cygwin.com/ml/cygwin/2010-01/msg00483.html [2] http://cygwin.com/ml/cygwin/2010-02/msg00031.html [3] http://cygwin.com/ml/cygwin/2010-02/msg00054.html I'm glad to see that you're finally starting to take me up on my generous offer. cgf
