Re: [ITP] libgpg-error-1.0-2
On Sep 30 10:00, Volker Quetschke wrote: http://www.scytek.de/cygwin/release/libgpg-error/setup.hint http://www.scytek.de/cygwin/release/libgpg-error/libgpg-error-1.0-2.tar.bz2 http://www.scytek.de/cygwin/release/libgpg-error/libgpg-error-1.0-2-src.tar.bz2 3 votes, a GTG review. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ITP] libgcrypt-1.2.0-2
On Sep 30 13:25, Volker Quetschke wrote: http://www.scytek.de/cygwin/release/libgcrypt/setup.hint http://www.scytek.de/cygwin/release/libgcrypt/libgcrypt-1.2.0-2.tar.bz2 http://www.scytek.de/cygwin/release/libgcrypt/libgcrypt-1.2.0-2-src.tar.bz2 And another 3 votes + GTG review. Uploaded with Volker's patch to setup.hint. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: setup: current setup version crashes on XP
Gerrit schrieb: Gerrit schrieb: Gary R. Van Sickle wrote: I'm running XP SP2, setup.exe crashes, I cannot install the latest packages. So currently I cannot use my XP box to work on new packages. I've been running SP2 for quite a while now at work and home and haven't had any trouble with setup. I ran it under dependency walker and it succeeds to install the packages I'm currently missing. I have Visual Studio .NET installed at the XP PC, maybe that makes a difference? Nope, it is getting weird, I got the same error on the server (NT4 same executable), maybe it has s.th. to do with the .NET framework? I have updated it recently at the XP box. I have version 1.1 and the update was the latest SP for the framework. Does XP or some other MS 'services' modify executables? Since it fails also at the NT4 it must be s.th. different with the executable. I deleted the executable and refetched it and now it runs again on the NT4 server. Unfortunately setup.exe doesn't even start anymore at the XP box. I also noted that I cannot run another setup.exe named file, but I can run 'normal' executables. Gerrit -- =^..^=
Re: [ITP] libgcrypt-1.2.0-2
Reini schrieb: monster patch (gerrit-style) Hey, all the great packages outside are including libtool-1.4 and require automake-1.4 and autoconf-2.13, why should we depend on five years old packages which are buggy and unusable most of the time? but +1 I'd rather run ./autogen.sh style scripts in the conf step. That would give the same patch size (usually it runs also aclocal, libtoolize, autoconf, automake). Gerrit -- =^..^=
Re: [ITP] libgcrypt-1.2.0-2
Reini schrieb: monster patch (gerrit-style) BTW, do you want to review my kaffe patch (4 MB bzip2 compressed)? Gerrit -- =^..^=
Re: upset errors for libopenldap2
Corinna Vinschen schrieb: On Sep 21 10:06, Christopher Faylor wrote: Gerrit please fix this ASAP: upset: *** warning package libopenldap2 refers to non-existent external-source: openldap Sorry, my bad. I removed version 2.1.whatever of openldap but I didn't know that libopenldap2 has this external-source ref. Fixed. still errors in setup.ini for libopenldap2-2-15 @ libopenldap2-2-15 sdesc: Lightweight Directory Access Protocol runtime ldesc: Lightweight Directory Access Protocol runtime category: Libs Net requires: cygwin minires openssl @ libopenldap2_2_7 and the Current version line in setup.exe has a nice endless recursion. at least it looks like so. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
libtool-devel-1.5.10-1-src download/install fails
just a short notice, that you apparently cannot install/download src packages for the test version of libtool-devel-1.5.10-1-src trying to get libtool-devel-1.5.10-1-src via setup.exe always gets me libtool-devel-1.5.6-3-src but I couldn't verify that it fails generally: libungif test src was possible. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: [ITP] libgcrypt-1.2.0-2
Gerrit P. Haase schrieb: Reini schrieb: monster patch (gerrit-style) Hey, all the great packages outside are including libtool-1.4 and require automake-1.4 and autoconf-2.13, why should we depend on five years old packages which are buggy and unusable most of the time? by using our own autotool 1.5 scripts in the prep or conf step. Lapo does in prep (see libungif), I do it in conf. (prep might be better as I think of it) I'd rather run ./autogen.sh style scripts in the conf step. That would give the same patch size (usually it runs also aclocal, libtoolize, autoconf, automake). no, do it in the .sh script. That keeps the patch to the bare and readable minimum, and you only have to persuade the maintainers upstream to use the newer 1.5 autotools. (just for our dll's, but what the heck.) with the monster patch (new libtool, .in files, ...) they might get frightened. And our src dependencies in the README must list the -devel autotool 1.5 requirements of course, otherwise it will fail, and your explicit patch must be used. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Re: [ITP] libgcrypt-1.2.0-2
Hi Reini, I'd rather run ./autogen.sh style scripts in the conf step. That would give the same patch size (usually it runs also aclocal, libtoolize, autoconf, automake). no, do it in the .sh script. That keeps the patch to the bare and readable minimum, I cannot confirm that it reduces the patch sizes. It will always be huge, even if you use automake-1.8 where the upstream package includes automak-1.79 generated files. and you only have to persuade the maintainers upstream to use the newer 1.5 autotools. (just for our dll's, but what the heck.) with the monster patch (new libtool, .in files, ...) they might get frightened. I don't submit those patches upstream, the only patches I submit upstream are against Makefile.am and configure.in files and of course source fixes. And our src dependencies in the README must list the -devel autotool 1.5 requirements of course, otherwise it will fail, and your explicit patch must be used. Yes, that is the reason why I include the patch, otherwise, Iwe could add lines like: /usr/autotool/devel/bin/autoreconf -fiv to the script, but then it will fail as soon as newer autotool version are avaiable or the user has older versions installed. Additionally I need to use a pacthed libtool which is also included with the patch, if I would not patch libtool I would have to patch at least ten Makefile.am of GLib Co. and probably other packages too. Gerrit -- =^..^=
Re: [ITP] libgcrypt-1.2.0-2
Gerrit schrieb: Hi Reini, I'd rather run ./autogen.sh style scripts in the conf step. That would give the same patch size (usually it runs also aclocal, libtoolize, autoconf, automake). no, do it in the .sh script. That keeps the patch to the bare and readable minimum, I cannot confirm that it reduces the patch sizes. It will always be huge, even if you use automake-1.8 where the upstream package includes automak-1.79 generated files. Sorry, my fault, misread your repliy. I already described why I don't do it dynamically. Anyway, what is the problem with the great patches? You can open an editor and search for +++ and you'll see that the interesting files are always Makefile.am configure.in. Patchfiles are not for reading, though. What you can do is: open the buildscript of any package and add the following to the mkpatch function: -x 'Makefile.am' -x 'configure' \ -x 'ltmain.sh' -x 'aclocal.m4' -x 'config.sub' -x 'missing' and so on, then you'll get a patchfile with only the relevant changes. What about including a function in the g-b-s to create such a small patch in CYGWIN-PATCHES and deliver this minimal patch too? Gerrit -- =^..^=
Re: netpbm?
On Fri, 1 Oct 2004, Charles Wilson wrote: Igor Pechtchanski wrote: Chuck, if you could dig it up, that'd be great. Did you adapt it to use the generic-build-script? If so, how did you deal with the weird configure? It uses a variant of the gbs, IIRC. I'm on dailup right now, so I'll let you download it... http://users.ece.gatech.edu/~cwilson/cygutils/testing/index.php?dir=release%2Fnetpbm/ Thanks. I was hoping for a less invasive set of changes to the GBS, but most of them seem unavoidable. I'll see what I can do, though. The division into libnetpbm* and netpbm is good -- I hadn't thought of that. I'll get it working for myself first, and then see if I can find the time to ITP it properly. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw
Re: [ITP] libgcrypt-1.2.0-2
Hi all, What you can do is: open the buildscript of any package and add the following to the mkpatch function: -x 'Makefile.am' -x 'configure' \ -x 'ltmain.sh' -x 'aclocal.m4' -x 'config.sub' -x 'missing' and so on, then you'll get a patchfile with only the relevant changes. What about including a function in the g-b-s to create such a small patch in CYGWIN-PATCHES and deliver this minimal patch too? And don't miss to add -x 'CYGWIN-PATCHES' in the new mkrawpatch() function. Gerrit -- =^..^=
Re: [GTG Review] Re: [ITP] libgcrypt-1.2.0-2
On Fri, Oct 01, 2004 at 08:33:28AM +0200, Dr. Volker Zell wrote: Volker Quetschke writes: As advertised, I would like to maintain the cygwin-port of the libgcrypt library. This one is GTG with the following patch to setup.hint. URLs: http://www.scytek.de/cygwin/release/libgcrypt/setup.hint --- setup.hint.orig 2004-10-01 08:30:45.494182400 +0200 +++ setup.hint 2004-10-01 08:30:58.082283200 +0200 @@ -2,4 +2,4 @@ ldesc: Libgcrypt is a general purpose crypto library based on the code used in GnuPG. category: Libs -requires: cygwin libgpg-error +requires: cygwin libgpg-error _update-info-dir You don't need to do this. I went to great effort to make sure that this gets added automatically to the setup.ini entry of anything which uses info files. I see that the usage has crept into a bunch of setup.hint files. I've nuked these instances. cgf
Re: [ITP] libgcrypt-1.2.0-2
Hi! Sorry, my fault, misread your repliy. I already described why I don't do it dynamically. Anyway, what is the problem with the great patches? You can open an editor and search for +++ and you'll see that the interesting files are always Makefile.am configure.in. Patchfiles are not for reading, though. What you can do is: open the buildscript of any package and add the following to the mkpatch function: -x 'Makefile.am' -x 'configure' \ -x 'ltmain.sh' -x 'aclocal.m4' -x 'config.sub' -x 'missing' and so on, then you'll get a patchfile with only the relevant changes. What about including a function in the g-b-s to create such a small patch in CYGWIN-PATCHES and deliver this minimal patch too? At least for libgcrypt, libgpg-error and gnupg you can do: $ ./package-name.sh prep $ ./package-name.sh conf $ ./package-name.sh devspkg In package-name-src.dev.tar.bz2 you will then find the bare, short patch without the autotool stuff. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
Re: [GTG Review] Re: [ITP] libgcrypt-1.2.0-2
Christopher Faylor writes: You don't need to do this. I went to great effort to make sure that this gets added automatically to the setup.ini entry of anything which uses info files. Well, gmp-4.1.3-3 for example has info files, but they definitly do not show up in my dir file after installation. I see that the usage has crept into a bunch of setup.hint files. I've nuked these instances. cgf Ciao Volker
Re: [ITP] cdrtools-2.01
Quoting Corinna Vinschen: The author provides a ProDVD edition, which is based on the same source as cdrecord, but contains proprietary code to access DVD drives. By providing a closed source application in binary only form linked against Cygwin, he's infringing the GPL. I've contacted Joerg by mail to solve this issue but until then, I'm not happy with providing the tool in the net distro. It feels wrong. Corinna, Any response from Joerg? It would make my life a little easier if cdrtools was an offical package. -Ross
rsync news (upstream patch + please upload) [3rd try]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Last 2 messages seems not to have reached the ML.. retrying for the second time... (it was HTML by error, I guess that's why it was filtered out?) Wayne Davison wrote: On Fri, Oct 01, 2004 at 12:31:55AM +0200, Lapo Luchini wrote: I don't think there is any reason not to ask for binary mode on non-Windows hosts, anyway (it's already done also in do_open(...), also). It has to be configured around the presence of the setmode() function and only done if O_BINARY isn't 0 (which it is on systems that don't need it). So, I'll add it with the appropriate conditional compilation code wrapping it up. Thanks! OK, so in next version the patch won't be needed anymore on our side. (I still wonder why it didn't show in earlier build, really): Probably because something recently changed in the cygwin support functions. (That code-path wouldn't have been used if HAVE_FCHMOD or HAVE_SECURE_MKSTEMP was zero.) Is that so? Did cygwin just add/change support of one of those two functions? Anyway... now it's patches so that's not a real problem anymore. What to say? Ready for next release, I'd say! URL: http://www.lapo.it/cygwin/rsync-2.6.3-1-src.tar.bz2 http://www.lapo.it/cygwin/rsync-2.6.3-1.tar.bz2 Size: 594393 146864 MD5: 3b114d672f3e0fc727a3157a2368c404 3fd17049658428ec923ddc0e66aea7d4 SHA-1: 52aa37d24e4aef4590a408efa3a86652349556b7 2b2bf8773b102fd72da0bc7aef5a37c7b9f6d80d Ah, some past version (by error) did use the internal popt instead of the shared one, now it uses the shared one again. Lapo - -- Lapo Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkFdf+4ACgkQaJiCLMjyUvuzyQCgv+o/FWNS377Tofb0Mj+I4BCz e80AoLgFGSZ4Xq4w3SnrXrEBaZ7e9vwC =AB1g -END PGP SIGNATURE-
Re: upset errors for libopenldap2
On Fri, Oct 01, 2004 at 02:41:08PM +0200, Reini Urban wrote: Corinna Vinschen schrieb: On Sep 21 10:06, Christopher Faylor wrote: Gerrit please fix this ASAP: upset: *** warning package libopenldap2 refers to non-existent external-source: openldap Sorry, my bad. I removed version 2.1.whatever of openldap but I didn't know that libopenldap2 has this external-source ref. Fixed. still errors in setup.ini for libopenldap2-2-15 @ libopenldap2-2-15 sdesc: Lightweight Directory Access Protocol runtime ldesc: Lightweight Directory Access Protocol runtime category: Libs Net requires: cygwin minires openssl @ libopenldap2_2_7 and the Current version line in setup.exe has a nice endless recursion. at least it looks like so. This should be fixed now. cgf
Re: [ITP] cdrtools-2.01
On Oct 1 08:59, Ross Smith II wrote: Quoting Corinna Vinschen: The author provides a ProDVD edition, which is based on the same source as cdrecord, but contains proprietary code to access DVD drives. By providing a closed source application in binary only form linked against Cygwin, he's infringing the GPL. I've contacted Joerg by mail to solve this issue but until then, I'm not happy with providing the tool in the net distro. It feels wrong. Corinna, Any response from Joerg? No, I'm sorry. I didn't get a reply so far. It's two weeks now. There's a good chance that Joerg is just on vacation or so, so I'll repeat my posting on Monday. Corinna P.S: Please don't Cc me. I'm reading the mailing list. I'm setting the Reply-To for a reason. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
