RE: Release directory and Setup
-Original Message- From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: RE: Release directory and Setup Would it be a good idea to number the setup.exe's in the same manner as all other packages and keep them in the new release (under /setup?) directory? The download could then proceed as usual except the warning that there's a new setup moved to the end and the message changed in some manner to reflect this. Once setup is able to auto-update (wishlist Rob?) Alpha quality patch sent to cygwin-patches ~ 4-5 months ago. It needs feedback before this moves on. (It worked). Rob
RE: squid-2.4.stable6-1 dependent of regexp.dll
-Original Message- From: Lapo Luchini [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 3:59 AM To: CygWin Subject: squid-2.4.stable6-1 dependent of regexp.dll I don't know who is the mantainer (I can find no /usr/doc/Cygwin/squid* file),. but the 'prev' version is indeed linked against the old cygregexp.dll =) The prev version is just that. I've no intention of rebuilding it. Use the curr version if you don't have the old cygrexep.dll. Rob
RE: Release directory and Setup
From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] Would it be a good idea to number the setup.exe's in the same manner as all other packages and keep them in the new release (under /setup?) directory? The download could then proceed as usual except the warning that there's a new setup moved to the end and the message changed in some manner to reflect this. Once setup is able to auto-update (wishlist Rob?) this'll likely make perfect sense. Right now I'm not so sure. Now, if you downloaded and installed it as if it were another package, you'd get a You have to reboot message. I guess it could be argued that that's better than nothing, but IMHO time spent moving it and dealing with the ramifications thereof would be better spent on auto-update and getting it solved permanent-like. :) I was just thinking about downloading it for you, auto-update would have been the next step :) The setup program (initially) wouldn't have to change to using the new version, just tell you it exists. Glad it's all in hand though :) J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: squid-2.4.stable6-1 dependent of regexp.dll
I don't know who is the mantainer (I can find no /usr/doc/Cygwin/squid* file),. but the 'prev' version is indeed linked against the old cygregexp.dll =) The prev version is just that. I've no intention of rebuilding it. Use the curr version if you don't have the old cygrexep.dll. I must had some intellective problem yesterday... I wrote prev while I was thinking test... 0_o BTW: prev had config in /etc while current has them in /usr/etc, it's normal? moreover at least squid.conf contains ^M at and of line in both versions Lapo -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: squid-2.4.stable6-1 dependent of regexp.dll
I must had some intellective problem yesterday... I wrote prev while I was thinking test... 0_o Oh, ok that I will do something about. Must have had an old environment when I built it. [prev] version: 2.4.STABLE6-1 Well no it's actually the prev release, but I tought it was the test one so this is why I wrote that message =) BTW: setup.ini structure can manage divverent requires for different version? this is a case where the 'prev' version requires a package and the current doesn't... but it could be others..? This is normal. Squid is fully cygwinised, and uses text mode for config files (which means that ^M is not important either way). Good, easier to edit =) -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Please upload: (was: Re: enscript-1.6.3-2 bugfix release)
configuration files should be handled in a nondestructive manner. Rather than including /etc/enscript.cfg in the tarball, instead modify your postinstall script to do something like: Of course, I did, in the tarball is just /etc/enscript.cfg.default included and gets copied to endcript.cfg if it is not present in /etc. http://62.138.63.18/cywgin/enscript/ http://62.138.63.18/cywgin/enscript/enscript-1.6.3-2.tar.bz2 http://62.138.63.18/cywgin/enscript/enscript-1.6.3-2-src.tar.bz2 setup.hint didn't changed. Gerrit -- =^..^=
UCL and UPX ready
BTW: in creating UPX package it'll have the strange erquirement that UPX source package needs also UCL source package (the installed binary isn't enough). Can that precedence be used, maybe documenting it in the Cygwin-doc/upx-...-1.txt o I shoul better include the sources needed to compile it also in UPC src directory to need only UCL library installed only? don't bother that rant.. I was just blind.. it's not completely documented but it's quite easy to let it work ^_^ http://www.lapo.it/tmp/ucl-1.01-1-src.tar.bz2 http://www.lapo.it/tmp/ucl-1.01-1.tar.bz2 http://www.lapo.it/tmp/upx-1.20-1-src.tar.bz2 http://www.lapo.it/tmp/upx-1.20-1.tar.bz2 @ ucl sdesc: The UCL compression and decompression library ldesc: UCL is a portable lossless data compression library written in ANSI C. UCL implements a number of compression algorithms that achieve an excellent compression ratio while allowing *very* fast decompression. Decompression requires no additional memory. category: Libs requires: cygwin @ upx sdesc: UPX is a free, portable, extendable, high-performance executable packer ldesc: UPX is a free, portable, extendable, high-performance executable packer for several different executable formats. It achieves an excellent compression ratio and offers very fast decompression. Your executables suffer no memory overhead or other drawbacks. UPX is copyrighted software distributed under the terms of the GNU General Public License, with special exceptions granting the free usage for commercial programs as stated in the UPX License Agreement. UPX uses the NRV compression library for compression services. A compatible but somewhat less efficient OpenSource implementation is available through the UCL compression library. UPX aims to be Commercial Quality Freeware. This version uses the UCL library. category: Utils requires: cygwin Now there's the little problem: UPX executable doesn't need UCL binary package, but UPX source needs it (it's statically linked). Maybe a dinamically linked version would be better? it would need UCL library both for compiling and for using... -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) smime.p7s Description: S/MIME Cryptographic Signature
Re: strange source packaging?
Currently, there are three dominant -src packaging standards. 1. As detailed on http://cygwin.com/setup.html#package_contents foo-VER-REL-src.tar.bz2 unpacks thus: foo-VER[-REL]/ foo-VER[-REL]/source files foo-VER[-REL]/subdirs foo-VER[-REL]/subdirs/source files foo-VER[-REL]/CYGWIN-PATCHES foo-VER[-REL]/CYGWIN-PATCHES/the-patch (*) (*) already applied to the source tree. Use this to REVERT to the pristine source. 2. packages which have cygwin-adapted source maintained in a cygwin-hosted CVS repository (e.g. gcc, cygwin itself, binutils, make, a few others). foo-VER-REL-src.tar.bz2 unpacks thus: foo[-VER[-REL]]/ foo[-VER[-REL]]/source files foo[-VER[-REL]]/subdirs foo[-VER[-REL]]/subdirs/source files In this scheme, there is no cygwin patch -- the cygwin version is basically a fork. If you want to know how the cygwin-specific source differs from the official version, you must get both sources and do the diff yourself. 3. A method hashed out on the cygwin-apps list last november: patches to vendor source trees - discussion: http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00046.html -src package standard: proposal #5 and #5a: http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00490.html foo-VER-REL-src.tar.bz2 unpacks thus: foo-VER.tar.[bz2|gz] -- original source code foo-VER-REL.patch-- the cygwinization patch foo-VER-REL.sh -- a script to drive the whole unpack/patch/configure/build/re-package procedure. As to why the .gz(or.bz2) compressed original source code tarball is included inside an .bz2 -src package, when the internal tarball can't really be compressed further: it's the original. If I ungzip it, and then bzip it, then it isn't the original version EXACTLY as distributed by the upstream folks... Hope that helps explain it. --Chuck Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? This is pretty peculiar and mroeover defeats any additional compression .bz2 could have versus .gz (compressed data is uncompressable even if it could be comperssed better with another compressor ^_^)? Just for curiosity =) BTW: in creating UPX package it'll have the strange erquirement that UPX source package needs also UCL source package (the installed binary isn't enough). Can that precedence be used, maybe documenting it in the Cygwin-doc/upx-...-1.txt o I shoul better include the sources needed to compile it also in UPC src directory to need only UCL library installed only? -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: strange source packaging?
As to why the .gz(or.bz2) compressed original source code tarball is included inside an .bz2 -src package, when the internal tarball can't really be compressed further: it's the original. If I ungzip it, and then bzip it, then it isn't the original version EXACTLY as distributed by the upstream folks... Hope that helps explain it. Thanks for the long explanation (it seems that there is always some part of this ML that doesn't hit my eyes, even if I read it all ^_^)... anyway the base is exact original is preferred upon size if I got it right.. right? (even if a gunzip source | bzip2 dest would alter in no way the tar and I see no diffrence between 'dest' and 'source' in any pratical way (uhm.. people )... but inter-programmer politics is not my concern, your answer fully satisfied my curiosity) Thanks, Lapo PS: I can see at least a motivation for using exact original package now: so that people can use md5sum and get convinced that the included file is really exactly the original... -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: strange source packaging?
Lapo Luchini wrote: PS: I can see at least a motivation for using exact original package now: so that people can use md5sum and get convinced that the included file is really exactly the original... Bingo. --Chuck
Re: strange source packaging?
On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? cgf
Re: strange source packaging?
Christopher Faylor wrote: On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? ??? Chris, are you disagreeing with this post http://cygwin.com/ml/cygwin-apps/2002-04/msg00298.html, or repudiating the packaging method used by the packages listed below (and maybe others I missed), or merely asserting that when gzip -dc foo.tar.gz | bzip2 foo.tar.bz2, then foo.tar.bz2 is still just as original as foo.tar.gz? --Chuck autoconf-devel autoconf-stable autoconf automake-devel automake-stable automake bzip2 cygutils gdbm gettext jbigkit jpeg libbz2_0 libintl libintl1 libncurses5 libncurses6 libpng libpng2 libreadline4 libreadline5 libtool-devel libtool-stable libtool libxml2 libxslt mktemp ncftp ncurses pkgconfig popt readline terminfo tiff units wget which xpm-nox zlib
Re: strange source packaging?
On Wed, Apr 17, 2002 at 03:12:00PM -0400, Charles Wilson wrote: Christopher Faylor wrote: On Wed, Apr 17, 2002 at 06:58:55PM +0200, Lapo Luchini wrote: Why the wget-1.8.1-1-src.tar.bz2 package does contain wget-1.8.1.tar.gz ? That would be what is called in the software community a mistake. Can this be corrected, asap, Hack? ??? Chris, are you disagreeing with this post http://cygwin.com/ml/cygwin-apps/2002-04/msg00298.html, or repudiating I'm referring to this passage in http://cygwin.com/setup.html: * Source packages are extracted in /usr/src. On extraction, the tar file should put the sources in a directory with the same name as the package tar ball minus the -src.tar.bz2 part: boffo-1.0-1/Makefile.in boffo-1.0-1/README boffo-1.0-1/configure boffo-1.0-1/configure.in etc... That is not the case for wget. cgf
Re: strange source packaging?
On Wed, Apr 17, 2002 at 04:31:04PM -0400, Charles Wilson wrote: As I recall, the your final word on the matter -- before the thread degenerated into yet another We need an 'install all' option in setup discussion -- was (more or less) whatever. All these proposals sound fine. As long as it makes sense to the maintainer himself: http://cygwin.com/ml/cygwin-apps/2001-11/msg00510.html Wow. Insightful email. Since last November, ALL of my packages, and most of Robert's and a few others, have been like this: foo-VER-REL-src.tar.bz2 contains foo-VER.tar.[gz|bz2] -- whatever the upstream folks distribute foo-VER-REL.patch foo-VER-REL.sh and that's it. I'm even a mildly annoyed when Corinna insists that (oldstyle) -src packages MUST unpack into foo-VER-REL/ instead of foo-VER/ since MY packages -- as agreed last November -- contain the pristine upstream sources. And the upstream maintainers know *nothing* about our release numbers. Well, I guess I haven't been paying much attention to your and Robert's packages. I'd forgotten that I'd suggested that we package as we see fit and foolishly looked to what I supposed was the final word on the subject. I'll just leave the documentation as is so we can have this truly delightful conversation again in a couple of months. If gzip -dc foo.tar.gz | bzip2 foo.tar.bz2 is a marginal is it 'pristine' or not case, then tar xvzf foo-VER.tar.gz mv foo-VER foo-VER-REL tar cvjf foo-VER???.tar.bz2(*) foo-VER-REL/ tar cvjf foo-VER-REL-src.tar.bz2 foo-VER???.tar.bz2 foo-VER-REL.patch foo-VER-REL.sh (*)foo-VER???.tar.bz2 is definitely NOT the pristine source. Its internal dirname has changed, as well as the tarball name, and compression type. And what the hell do I call it? I can't name it 'foo-VER-REL.tar.bz2' because that's the name of the binary package. I can't call it 'foo-VER.tar.bz2' because then I'll have multiple versions: the 'original' upstream one -- unpacks into foo-VER/ two or three somewhat modified ones, depending on how many releases I create: -1's foo-VER.tar.bz2 unpacks into foo-VER-1/, -2's foo-VER.tar.bz2 unpacks into foo-VER-2, etc. But, each contains exactly the same code. I can't call it 'foo-VER-REL-src.tar.bz2' because that's the name of my larger -src tarball, which contains the pristine(hah!) tarball + .patch and .sh. So I leave it foo-VER.tar.[bz2|gz], leave it so that it unpacks into foo-VER, just like the upstream folks made it in the first place. Yeah, yeah. I don't need another 183 line justification message, thanks. I've got it. The wget packaging is just peachy. cgf
Re: extra apache shared module DLLs
What about modules that do change/patch Apache's source tree to hook on certain structures that can not be accessed using the normal API? I'm thinking espacially about mod_ssl and mod_snmp, which both need to patch Apache's core to be applied? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: strange source packaging?
http://cygwin.com/ml/cygwin-apps/2001-11/msg00510.html Wow. Insightful email. as usual... Well, I guess I haven't been paying much attention to your and Robert's packages. I'd forgotten that I'd suggested that we package as we see fit and foolishly looked to what I supposed was the final word on the subject. It's been a bit of a mess. In my original email to this thread, I summarized the three packaging styles (I won't call them standards) that are currently, actually, in use. That doesn't mean I think having 3 different styles -- only one of which is actually documented somewhere official -- is a good idea. OTOH, since the longwinded discussion last November (and its resolution sans an actual standard), Robert and I (and a few others) have been standardizing one way (which was a compromise in and of itself). So there are only 3 extant styles, not 47. Which is something. I'll just leave the documentation as is so we can have this truly delightful conversation again in a couple of months. Actually, if there's no opposition (hah!) I'll update the documentation to reflect the current situation (e.g. 3 styles) -- but I'd like to mark one of them as the preferred style for new packages. Hopefully mine and robert's style. ;-) Yeah, yeah. I don't need another 183 line justification message, thanks. I've got it. Chris, in private mail I would've just sent you the one link and I *know* that would've been sufficient. However, on a public list a little more info, background, and justification is needed -- if only to forestall the inevitable hue and cry. The wget packaging is just peachy. g --Chuck
Re: extra apache shared module DLLs
What about modules that do change/patch Apache's source tree to hook on certain structures that can not be accessed using the normal API? I'm thinking espacially about mod_ssl and mod_snmp, which both need to patch Apache's core to be applied? Well, you can run an mod_ssl-modified apache without having the mod_ssl stuff on. (e.g. the .conf file doesn't load_module it). I'd assume that the same is true for mod_snmp. So, I'd distribute the core apache package with those modifications -- but without the modules (mod_ssl.dll) themselves, and with the corresponding load_module statements commented out of the .conf. Then, the user could install the mod_ssl package, which would install the module .dll and related stuff, have a postinstall script to generate some dummy, self-signed server keys, and create an includable ssl-conf file. It would still be up to the user to add include mod_ssl.conf and uncomment the load_module statement in the main apache conf file. Similar for mod_snmp. Now, MOST modules don't require intrusive changes to the core apache. So most mod_ packages don't need this special treatment. BUT, of those modules that DO require it, which ones should you, Stipe, include pre-modified in the main apache package? The ones you as maintainer FEEL like including. I gather that means mod_ssl and mod_snmp, right now. :-) --Chuck
[ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages available for comments and testing
I have setup an anonymous ftp site with preliminary Cygwin/XFree86 setup.exe packages: ftp://huntharo-4.user.msu.edu/pub/cygwin/ These is based entirely off of Ian Burrell's work. My primary concerns that I don't know how to resolve are: 1) I didn't do the XFree86-base meta package properly. setup.exe does not list XFree86-base as a package and it doesn't enforce the dependencies of the other packages on XFree86-base. 2) I'm not sure why, but uninstalling packages often leaves files around. For example, uninstalling XFree86-f100 delete all files from /usr/X11R6/lib/X11/fonts/100dpi/ except for UTRG__24.pcf.gz. Weird. 3) We may need a short post-install script, based off of Xinstall.sh, that runs mkfontdir in the /usr/X11R6/lib/X11/fonts/local and /usr/X11R6/lib/X11/fonts/misc font directories. Xinstall.sh says it does this to make sure that these directories are up to date. I guess that every font package has the right to install fonts in local or misc, but it seems that none of them do. Perhaps this won't matter. That's it for now. I'm awaiting feedback, Harold
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Thu, Apr 18, 2002 at 01:02:51AM -0400, Harold Hunt wrote: Looks like you figured out upset. Sorry about not responding. Actually, I did the same thing that Ian did and reverted to the upset from: [EMAIL PROTECTED]:/cvs/src in the directory: winsup/cinstall/temp I'd forgotten about that directory. It's nuked now. The syntax for upset should just be upset dir where `dir' is the directory containing the distribution. setup.ini will go to stdout. upset -u setup.ini dir will update an existing setup.ini. cgf
RE: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
The syntax for upset should just be upset dir where `dir' is the directory containing the distribution. setup.ini will go to stdout. upset -u setup.ini dir will update an existing setup.ini. I beg to differ. From my packages directory that contains contrib, release, etc. I have run: upset . upset ./ upset ../packages upset contrib/ You get the idea. Every single time I get: $ ../upset/infra/bin/cygwin/upset . # This file is automatically generated. If you edit it, your # edits will be discarded next time the file is generated. # See http://cygwin.com/setup.html for details. # setup-timestamp: 1019106912 setup-version: 2.194.2.24 The new upset doesn't seem to work for me. Perhaps it is just a problem with the structure of our package tree. Harold
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Thu, Apr 18, 2002 at 01:18:19AM -0400, Harold Hunt wrote: The syntax for upset should just be upset dir where `dir' is the directory containing the distribution. setup.ini will go to stdout. upset -u setup.ini dir will update an existing setup.ini. I beg to differ. Try setting it up like sourceware then. The directory defaults to 'release'. Just do 'upset -u setup.ini' in a directory containing a the 'release' directory. cgf
[ANNOUNCEMENT] Cygwin/XFree86 setup.exe packages with dependencies
I just updated the packages at ftp://huntharo-4.user.msu.edu/pub/cygwin/ to have a working dependency between XFree86-base and the base XFree86 packages, such as XFree86-xserv, XFree86-fnts, etc. There were two changes required: 1) 'touch contrib/XFree86/XFree86-base/XFree86-base-4.2.0-1.tar.bz2' 2) upset took the list of requirements from XFree86-base/setup.hint and put them in quotes (cygwin ...) when it created setup.ini. upset didn't do this for any other packages and the Cygwin setup.ini doesn't have quotes around dependency lists, so I guess that the quotes were peculiar to this version of upset, perhaps combined with a list of dependencies that is longer than one line. I removed the quotes from the 'requires' list from XFree86-base and all is now well. Dependencies work for installing. The behavior I noticed when uninstalling is that dependencies are ignored. I'm guessing that setup.exe was designed that way because there isn't really a good way to handle dependencies when uninstalling. Harold
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages with dependencies
On Thu, Apr 18, 2002 at 01:30:22AM -0400, Harold Hunt wrote: 2) upset took the list of requirements from XFree86-base/setup.hint and put them in quotes (cygwin ...) when it created setup.ini. upset didn't do this for any other packages and the Cygwin setup.ini doesn't have quotes around dependency lists, so I guess that the quotes were peculiar to this version of upset, perhaps combined with a list of dependencies that is longer than one line. I removed the quotes from the 'requires' list from XFree86-base and all is now well. That version of upset is an obsolete, buggy version. That's why I removed it. cgf
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
On Thu, Apr 18, 2002 at 01:37:08AM -0400, Harold Hunt wrote: Try setting it up like sourceware then. The directory defaults to 'release'. Just do 'upset -u setup.ini' in a directory containing a the 'release' directory. I just moved contrib to release and the new upset works like a dream! Good. I think I fixed the bug with reading directories, too. That was a feature that I added in the last week. Never tested it and, surprise!, it didn't work. cgf
Re: info: single install xfree86 + minimal cygwin?
On Tue, Apr 09, 2002 at 11:00:23PM -0400, Christopher Faylor wrote: On Tue, Apr 09, 2002 at 07:50:04PM -0700, Ian Burrell wrote: Christopher Faylor wrote: Name? Do you mean version? If you put a version in setup.hint it is currently ignored. The name from the line and the version header could be used to override the parsing of file names into name and version. No, the name doesn't override this, currently. But now it does. If you have something like this: foo/ foo-bob-27-1.tar.bz2 Then the version of the package will be bob27-1 where previously it would have been 27-1. cgf
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available forcomments and testing
Christopher Faylor wrote: On Thu, Apr 18, 2002 at 01:02:51AM -0400, Harold Hunt wrote: Looks like you figured out upset. Sorry about not responding. Actually, I did the same thing that Ian did and reverted to the upset from: [EMAIL PROTECTED]:/cvs/src in the directory: winsup/cinstall/temp I'd forgotten about that directory. It's nuked now. Where is the real version? That was the only upset in that CVS repository. Is there some other CVS repository? - Ian -- [EMAIL PROTECTED] http://www.znark.com/
