Re: RFP: texmf
Jan Nieuwenhuizen wrote: [EMAIL PROTECTED] (Jerome BENOIT) writes: I will try to rebuild the tetex-beta package this week-end. To avoid any confusion, I plan to rename it `tetex-bin' as suggested in a previous email. Very nice. Be sure to also create a new 'tetex-beta' package that is empty, but carries a higher version number than the current tetex-beta package. You will also need to inform folks to update 'tetex-beta' FIRST, and then install 'tetex-bin' Package renaming is a pain (but sometimes necessary). Rest assured, you will see many many FAQs if you *do* rename your package -- make sure the benefit (reduced confusion?) is worth it. Sorry for the vagueness, I only heard some complaints when I sent the message. I've investigated a bit, and pdftex.exe doesn't run when libjpeg isn't installed (this was missing from my texmf requires: line). Also, texconfig doesn't run when libncurses5 is not installed, while the current default is libcurses6? libncurses5 package contains only the DLL's so that previously working executables that depend on those versions don't break (woulda been nice if I'd known to do that with libpng, right?) However, NEW package builds will link against libncurses6. But I really don't know, there were complaints on the list. Looking at it now, it seems to me that both problems would be fixed by adding these to tetex-beta/bin's setup.hint: requires: ash bash cygwin libncurses5 jpeg libpng tiff ncurses sed termcap texmf-base zlib Nope -- the libpng problem will remain. That was a goof -- but it wasn't my fault :-/ The binary interface of libpng changed, but they didn't bump the dll number -- and I didn't know the binary interface had changed until it was too late. a good idea in any case, but I don't know if there are other problems, or what the idea is with the ncurses5/6 libs. The idea is the same as on linux. You have runtime shared libs, and development libs. The various versions of the runtime libs (DLL's) stay around forever so that old executables will continue to work. (libncurses5, libncurses6). You can have many different sharedlib packages installed at the same time. BUT you can only have one development lib package (import libs) at a time -- unless you want to jump thru major hoops. Therefore, the development lib that is installed at any given time will induce a dependency on a SPECIFIC runtime-lib version in executables linked AT THAT TIME. Currently, the development libs (for [lib]ncurses) are in the ncurses package, and induce dependency on libncurses6. So: old apps will continue to work, and depend on libncurses5. New apps will depend on libncurses6. Both old apps, new apps, libncurses5, and libncurses6 can coexist on the same system. (Libpng is the counterexample. Call it a screwup) --Chuck
Re: new cygwin-cross-1.3.6.1
Christopher Faylor wrote: On Fri, Dec 07, 2001 at 04:30:12PM +0100, Jan Nieuwenhuizen wrote: Some people promised to have a look at my cross build scripts package so I've made some fixes. It should generate fully Cygwin compliant binary and source packages now, I hope. I wonder if these same people will look at the cross build package that I checked into cvs months ago. Nah. Probably not. Since the some people is probably me, no -- it's not the cross build aspect of Jan's work that I'm interested in. It's the auto-building (even native) aspect of his scripts, so I'm more interested in his foo example than in cygwin-cross itself. --Chuck
Re: Figlet-2.2 Experimental
Christopher Faylor wrote: On Sat, Dec 08, 2001 at 12:31:28AM +0100, Jan Nieuwenhuizen wrote: Christopher Faylor [EMAIL PROTECTED] writes: __ _ ___ _ _ _ _(_) |_ / _` / -_) '_| '_| | _| \__, \___|_| |_| |_|\__| |___/ Was there something you wanted to say, here? Just quoting other people's messages isn't very useful. In this case it was, look at his unusually big signature. 00:28:19 fred@appel:~$ dpkg --status figlet Package: figlet Status: install ok installed Description: Frank, Ian Glenn's Letters Figlet is a program that creates large characters out of ordinary screen characters. Which is really completely irrelevant and not what I asked for. Hmm. Pretty much like this message. No, not really. Gerrit was *demonstrating* rather than explaining what figlet was. That's fair -- but I prefer explanations WITH my demonstrations... --Chuck
Re: broken setup.hint files
Jan Nieuwenhuizen wrote:
Ummm...they are not broken. You just dislike some stylistic choices...
Well, setup.exe barfs on the. Quoting from inilex.l:
sdesc: return SDESC;
ldesc: return LDESC;
category:return CATEGORY;
requires:return REQUIRES;
So, after reading this and the setup.hint spec on cygwin.com, I
implemented hinting, in gen-ini.sh and it *broke* setup.exe. So, I
considered it a bug, and wanted you to know about it. But if you
don't care, fine.
You are right: the *setup.ini* grammar as parsed by *setup.exe* requires
colons. However, setup.ini is created on sourceware by a script
called upset. And, the *setup.hint* grammar as parsed by upset
doesn't require colons.
Also, blindly removing the prev/curr/test markers is not a good thing
either.
For me, it's *a lot* better than a barfing setup.exe.
Sometimes (when upset's automatic version parser fails)
Who is `upset'?
Ah -- upset is the setup.hint parser that creates setup.ini. You seem
to have written your own setup-ini builder and called it 'gen-ini.sh'.
I am not going to fix my setup.hint files to make your parser happy --
the only parser I care about is the REAL one, upset.
I haven't seen my version parser fail, but in general
one should not provide the same information from two sources. Which
do you trust when they do not match? Why not just have a sane
archive, or fix setup.ini by hand if you don't like it?
Because us normal maintainers CANNOT edit setup.ini! Only cgf can do
that. The *primary* information source is setup.hint -- therefore, if I
need to override the version parser, it must be done in the setup.hint.
Also, us normal cygwin maintainers CANNOT force the upstream
maintainers to use a sane naming scheme (see below). And when upset
creates setup.ini, it first uses the filenames of the archives -- but
then setup.hint can be used to OVERRIDE it when necessary.
Here's a (real life) example:
openssh-2.9p2-3 (released on Jul 26, 2001)
openssh-2.9.9p2-1 (released on Sep 28, 2001)
if you sort this using normal (computer) lexical sorting, you end up with:
prev: openssh-2.9.9p2-1
curr: openssh-2.9p2-3
Which is clearly wrong -- and the fault lies not with Corinna, but with
the OpenSSH group.
the new *recommendation* is to NOT specify curr/prev in setup.hint and
rely on upset's parsing of archive names -- unless you need to override
(cf. openssh above). but it isn't a requirement,and not following the
recommendation doesn't result in broken setup.ini's -- at least, when
the REAL setup.ini generator (upset) is used. If your parser doesn't
work, that's not my problem.
If a version parser fails, the offending package (filename) should be
fixed, imo.
But sometimes, we don't have that luxury. Also, since experimental
packages -- or real packages based off of cvs -- are versioned like
foo-20010531 and not foo-1.3.5
What happens when you graduate from a cvs-based, dated version to a
'real release' version? 2001 is always x.y.z
And, there is NO way for us normal maintainers to specify a test release
other than specifying it in the hint.
If your parser can't handle that, your parser is broken. Not my setup.hint.
the hints may just be old.
Yes, I guess that they're old. If old things don't get fixed, the get
bitrot.
No, if old things are BROKEN, then they need to be fixed. Since they
are NOT broken, there is no need to rush out and repackage and fix
everything. I *will* update to the latest *RECOMMENDATION* -- but
because it is a recommendation, and because nothing official is broken,
I'm not going to rush it. The only thing broken here is your gen-ini.sh
script.
In my case, I will update a given setup.hint to follow that new
*recommendation* (not requirement) the next time I update the package
controlled by it, and not until then.
Indeed, parts of the cygwin archive are a bit of a mess, but it's too
bad if it's by principle, and not for want of time.
It's not principle or want of time. AFAICT, there is no mess. What
specifically are you complaining about? setup.hints that YOUR parser
can't understand? Again, not my problem.
If it ain't broken (and it ain't) then don't fix it.
Well, sorry to bother you then. I can keep kludging around this small
thing too.
How about don't kludge around it -- try fixing your parser. Here is
the precursor to cgf's current upset. I haven't used it in a while, but
it ought to still work.
--Chuck
#!/usr/bin/perl
# -*- perl -*-
$ftptop = /sourceware/ftp/anonftp/pub/cygwin;
if (@ARGV 0) {
$ftptop = shift;
}
$setupdirs = contrib latest;
if (@ARGV 0) {
$setupdirs .= .@ARGV
}
$tmpfile = /tmp/setup.ini.tmp;
open (TMPFILE, $tmpfile);
select (TMPFILE);
chdir $ftptop;
$setup_version = '';
open (S, setup.exe);
while (S) {
if (/%%% setup-version (\S+)/) {
$setup_version = $1;
libtool packages
I've put three new packages here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ I am not yet ready to even ask for official inclusion. This is just a kind of here, heads up, what do you think? message. There's libtool-20010531-rc6.tar.bz2 libtool-20010531-rc6-src.tar.bz2 libtool-devel-20010531-rc6.tar.bz2 libtool-devel-20010531-rc6-src.tar.bz2 libtool-stable-1.4.2-1.tar.bz2 libtool-stable-1.4.2-1-src.tar.bz2 Just like the auto* packages, the libtool-devel package installs into /usr/autotool/devel/, and the libtool-stable package installs into /usr/autotool/stable/. The libtool package is a set of wrapper scripts that install into /usr/, and set the PATH and other ENV vars appropriately before exec'ing the correct real libtool. libtool-stable: contains libtool-1.4.2 (mostly OOB, patches are documentation only) works (more or less). Follow the goat book examples to build DLLs using this version. libtool-devel: Robert Collin's hacked version. (BTW, I recall that edward tailbert submitted a number of libtool fixes to cygwin@ and libtool@ lists back in March. Some (I think) were actually folded into libtool cvs and are part of libtool-1.4official. Do any of Robert's changes harken back to edward?) Anyway, it is based off of libtool-cvs on 20010531, with a 40k patch and then a bootstrap (redo the autoconf, automake, autoheader, etc). Now that I've parsed out the minimum changes, I'll submit that to Gary Vaughan -- hopefully he'll find that easier to deal with than the earlier 400k patch Anyway, this version seems to be able to build DLLs OOB, using the autoimport stuff. (Of course, you have to re-libtoolize your target package with the new version to get that to work -- which may also entail updating configure.in to work with the new autoconf, and re-autoconf'ing and re-automaking...) libtool: contains libtool-scripts-20010531' (I'm basing the versioning of my -scripts- packages off of the cygwin -devel- version that they are supposed to work with.) Again, the choice of whether to use -stable- or -devel- is based on configure.in: AC_PREREQ(X) X = 2.13, stable; X 2.13 or nonexistant, devel. Note that BOTH libtool-1.4.2 (1.4.1, 1.4) and hacked libtool do NOT use ltconfig.sh at all. They only need ltmain.sh. So, when re-libtoolizing, be sure to rm ltconfig.sh... packaging: As with the auto* packages, the -devel- version installs its info files into /usr/info as well as /usr/autotool/devel/info/. However, since libtool also ships a library, ltdl, I'm in a bit of a bind. The static lib can *probably* stay where it is (usr/autotool/*/lib) and ltdlized packages will link to it okay. (If not, most ltdlized packages ship with the source code anyway, and build it themselves locally if it wants to link statically. Kinda like gettext/libintl). However, both stable and devel versions ALSO ship a dll. And, since the source code hadn't changed, the libtool version is 3:0:0 for both, so both the stable and devel packages contain a 'cygltdl-3.dll'. But they are not interchangeable. One was linked the old way with __declspec's and everything, while the other is a new-style autoimport/autoexport library. (I *think* the new one can sub for the old one, but not vice versa) Anyway, since they can't BOTH be in /usr/bin, and you DON'T want to set PATH to /usr/autotool/*/bin (kinda defeats the whole wrapper script idea) -- I arbitrarily put the -devel- version of the ltdl libs into /usr Questions, comments, test reports? They seem to work okay for my minimal tests... --Chuck
RE: has anyone tried latest setup.exe from cvs ?
Sort of. The problem though is that I'm nearing the completion of some pretty extensive changes to the GUI code, so if there's problems with that in the cvs stuff I might not even know about it. I did however run across a problem in the INI-parsing code that does prevent it from working. The problem is with entries in setup.ini that look like this: @ jbigkit sdesc: Lossless image compression library ldesc: JBIG is a highly effective lossless compression algorithm for bi-level images (one bit per pixel), which is particularly suitable for document pages. category: Graphics Libs requires: cygwin i.e., that have no version: lines in them (what is such an entry supposed to mean, or is this actually a upset bug?). No, it's a too aggreesive cleanup bug. Chris deleted the jbigkit packages from sourceware, and I haven't had a chance to re-upload them yet. since the packages aren't there, upset can't figure out what version numbers to use. You're not ever supposed to have a setup.hint without any packages. --Chuck
Re: curl, libcurl, libcomprex, leakbug (was:Re: Packaging cURL for cygwin distribution ???)
Robert Collins wrote: The -x is the binary API compatability index. See the libtool documentation. Actually, I don't think the libtool docs explain DLL versioning on windows (the 'c - a' thing). They DO explain about libtool's versioning scheme on UNIX, and if you read that and think about it hard enough you can synthesize the 'c - a' thing, and convince yourself that 'c - a' represents a binary API compabitibility index AND that DLLs on windows should be named USING that index, but it ain't obvious. I posted an explanation of the 'c - a' thing -- in this very thread -- on Oct 12. --Chuck
Re: rebase
Jason Tishler wrote: I would like to contribute my rebase utility. Should it be a stand-alone package? Be added to another package (i.e., cygutils -- sorry to suggest this Chuck...)? Or, be added to winsup/utils? I think it should go in winsup/utils, but I've no objections to putting it in cygutils. --Chuck
Re: Contribution Package Proposal: JASSPA's MicroEmacs
I believe the commercial restrictions are problematic. If we're going to include an emacs, I'd prefer one that is completely free (speech) like FSF Emacs or XEmacs. However, with the soon-to-be-released features in setup.exe, there's no reason why Jon can't provide a cygwin-friendly download site (complete with his own setup.ini) -- folks could then explicitly add his download site to their own list, and the new setup will present a merged view of available packages. That is, folks who want JASSPA's MicroEmacs could get it via setup.exe, but it doesn't need to be distributed via the cygwin mirror system. --Chuck Jon Green wrote: Hi, I would like to contribute JASSPA's MicroEmacs to the Cygwin package list, a Emacs Text Editor. This is currently being distributed from http://www.jasspa.com. We are in the process of putting together the next release and have now resolved most of the problems in porting to the Cygwin environment (site contents are not current). Because we are encumbered with a license that was inherited from the original uEmacs then I though I had better check whether our license violates your distribution mechanism. We are (unfortunately) not under GPL, but all of the source is freely available. The license we currently run with is attached below. So before I take this any further (i.e. put together a complete package) then I need some sort of approval that we have a potentially valid submission. Also attached is the setup.hint - as per Web instructions. Thanks Jon. --- setup.hint # Set up for JASSPA's MicroEmacs @microemacs sdesc: JASSPA distribution of MicroEmacs text editor ldesc: Small footprint EMACS text editor, based on Danial Lawrences' uEmacs 3.8. Includes X-Windows and terminal support under Cygwin, integrated speller, undo, macro language, color syntax hilighting and comprehensive on-line help skip: curr: 20020101 category: Editors requires: cygwin --- License Terms --- COPYRIGHT MicroEmacs '02 JASSPA Distribution - www.jasspa.com The following copyrights apply from the original source code of version 3.8. No explicit copyrights were found with the original distribution apart from the following found in the main source code, (C)opyright 1987 by Daniel M. Lawrence MicroEMACS can be copied and distributed freely for any non-commercial purposes. Commercial users may use MicroEMACS inhouse. Shareware distributors may redistribute MicroEMACS for media costs only. MicroEMACS can only be incorporated into commercial software or resold with the permission of the current author. The following notices apply after 1988. Copyright (C) 1988 - 2002, JASSPA MicroEmacs '00 can be copied and distributed freely for any non-commercial purposes. Commercial users may use MicroEmacs '00 inhouse. Shareware distributors may redistribute MicroEmacs '00 for media costs only. MicroEmacs '99 can only be incorporated into commercial software or resold with the permission of the current author. Spelling Dictionary Copyrights The spelling dictionaries are converted from ispell dictionaries, each spelling dictionary has it's own copyright which is reproduced within the appropriate language spelling macro file. NO WARRANTY THIS PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS NOTICE MUST BE CARRIED IN ALL COPIES OF THE DISTRIBUTION
Re: Restructuring gettext
Okay, I've uploaded and announced the new gettext packages: gettext-0.10.40-1 libintl1-0.10.40-1 libintl-0.10.38-3 I also updated the setup.hint files on the server for the following packages: wget mutt nano vim sharutils The maintainers of those packages should make a note of this; the next time they rebuild, they will depend on libintl1 instead of libintl. For now, I changed each setup.hint from depending on gettext to libintl. --Chuck
Re: Restructuring gettext
Gerrit P. Haase wrote: What is the problem here? libintl and libintl1 are two different packages with different names. But there's only one nano. (sounds like an ad campaign) So, nano's setup.hint has a line like: requires: foo bar libintl Later, the (then-)current nano will requires: foo bar libintl1 but the prev: version of nano still requires libintl. The debate is whether, during that transition period where prev: and curr: have DIFFERENT requires, if we should say requires: foo bar libintl libintl1 to satisfy both prev and curr. --Chuck
Re: bash completion (was: RE: Units)
Morrison, John wrote: Thats not what the help file says... Note that category names may be multi-word, e.g., ASCII Games but, currently all categories are only a single word. I know that. category: Shell Utils is two categories. category: Shell Utils is one category. (Earnie's example was the former, not the latter -- hence, two categories) It is POSSIBLE to have a space in the category name, but you must quote properly. Just like it is POSSIBLE to have a space in a directory name (Program Files) -- but it causes no END of headaches. I am saying: please let us not do this. Stay with oneword category names. Hungarian-ize them if we must: ShellUtils --Chuck
Re: fortune-1.8-1 [was Re: bash completion (was: RE: Units)]
Corinna Vinschen wrote: I'd like to pour fuel into the fire of `usefulness' of a package. I'd like to contribute the NetBSD fortune package to Cygwin and therefore I'd even like to propose to add a Games section *gasp*. setup.hint: --- sdesc: Print a random, hopefully interesting, adage category: Games requires: cygwin Opinions? I like it. Games is fine -- didn't somebody or other port FreeCIV to cygwin about a year ago? FWIW, I'm planning to add ddate to my cygutils package eventually -- it's distributed on Linux systems as part of the util linux package along with the (already cygutils-assimilated) cal and namei programs, among others. ddate is the Druel Discordian Date program -- Today is Sweetmorn, the 42nd of Bureaucracy, 3161. etc. --Chuck
Re: libtool devel works nicely
Robert Collins wrote: Chuck, lovely wrapper scripts, they work beautifully (its what I used for libxml2 and libxslt - which I did so I could give you feedback). That's good to hear. So you exercised the whole automake/autoconf/libtool chain? If so, then how did you put together your -src package for libx*? (I ask merely because I'm curious: if you re-auto* a given source package, then there are LOTS of changes and your diff is very big. Alternatively, you can make minimum changes to high-level files like configure.in and Makefile.am -- resulting in a small diff -- and have your build script re-bootstrap during the 'prep' phase...but that complicates the 'mkpatch' phase. This latter approach is a real PITA -- but it's the only way to reliably generate a small patch that can be submitted to the upstream maintainers. NOT that they would accept such a patch if it's generated by a non-regulation libtool or when they're not ready to move up to the most recent autoconf/automake...sigh) --Chuck
Re: [ANN] apache_1.3.22 package available for setup inclusion
Earnie Boyd wrote: I'm confused. What's all this talk about needing new binutils? Yep, I'd say. My guess is that Stipe is using a cross buiold platform that doesn't include your change. Therefore he has to hard code the prefix in filename translations in the Makefile.in or what ever the configuration files are named. No, you're missing my point. You STILL have to hardcode the output filename of the DLL when you are CREATING the dll. Even WITH the new binutils. The ONLY time my --dll-search-prefix helps is when you are LINKING to a DLL and you do NOT have the import lib handy. That's all it was created for. When *creating* the DLL, 'gcc -shared' doesn't magically decide to add 'cyg' to the -o filename -- any more than it previously magically added 'lib'. It didn't and it doesn't. My point: he must muck with Makefile.in or whatnot in ANY case -- new binutils or old. Now, if you're talking about the .exe creation phase, when httpd.exe is linked against libhttpd.dll it might not work IF: a) old binutils b) AND dll is named cyghttpd.dll c) AND you don't have an import lib Well, my fix for that problem is: during the DLL build phase (since both libhttpd.dll and httpd.exe are both from the same package) generate an import lib and link against that instead. (Because you really shouldn't be linking directly against a DLL anyway except in emergency situations -- vitual implibs cannot provide the auto-import fixups, for instance, or static methods (libcygwin.a, libncurses++.dll.a)) --Chuck
Re: [ANN] apache_1.3.22-2
I'd like to put in a vote for NOT treating '_' and '-' identically. While it is easy to use apache1 and apache2 instead of apache_1 and apache_2 -- it isn't so easy for packages (like bzip2) that already end with a numeral. I'm specifically thinking of: splitting bzip2 into a bzip2 and libbzip2 package, to allow multiple libbzip2 (DLLs) to coexist. libbzip20 and libzip21 are misleading, whereas libbzip2_0 and libbzip2_1 are clear. In fact, I *thought* setup/upset didn't treat '_' any differently than 'a' but perhaps I was wrong... --Chuck Christopher Faylor wrote: On Sun, Jan 13, 2002 at 10:12:48AM +1100, Robert Collins wrote: If you want to be able to have both apoache 1.3 and 2 installed concurrently, then that is the only valid reason to use an underscore - and the result should look like apache_1-1.3.22-3 Actually, the setup.exe code seems to equate '_' and '-' the same way. Unfortunately, I don't think that 'upset' is quite as forgiving but that's not a permanent problem, of course. So that means that the above package name would still be apache if I am reading things correctly. cgf Rob === - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 13, 2002 5:13 AM Subject: Re: [ANN] apache_1.3.22-2 Corinna Vinschen schrieb: On Sat, Jan 12, 2002 at 06:53:43PM +0100, Stipe Tolj wrote: No I don't think so. I'll change the /etc path thing and re-package to apache_1.3.22-3, now! apache-1.3.22-3, please! A dash, no underscore. Apache distributions do use a underscore, BTW. I know this will make problems with setup.exe I guess, so I'll change the tarballs to use a dash instead. 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: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: Okay, I've renamed the devel package: libtool-devel-20010531-6 that should be libtool_devel-20010531-6 shouldn't it? (devel is a flavour and thus part of the name). I _think_ that the current upset and setup.exe logic actually starts at the right and owrks left, so that teh '-''d name will appear in setup correctly, but I don't think we should rely on this behaviour. Correct -- it does work from R to L. If we cannot depend on this behavior, then we must rename the following packages: autoconf-devel autoconf-stable automake-devel automake-stable tetex-beta Renaming is a bad thing...are you SURE we shouldn't rely on current behavior? --Chuck
Re: any chance...
Robert Collins wrote: Of getting automake 1.5b pacakged? Perhaps as a test version? It's got a key fix in it that drops som Makefile.in's down from Mb's to just Kb's. I forward ported the current patch, and rebuilt automake-devel from 1.5b. That seemed to go okay; I'm waiting for make check to complete. If successful, I'll post the packages for Corinna to do with as she wants. --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: Correct -- it does work from R to L. If we cannot depend on this behavior, then we must rename the following packages: Which is one of the implications of the thread where you said http://cygwin.com/ml/cygwin-apps/2002-01/msg00208.html. Well, consider it a thinko on my part. I was considering foo-alphabetic-version-release different from foo-numeric-version-release -- but of course, version can have alphabetic characters in it, and my bzip example had numerals in the extra field. So both cases really just boil down to: there are four pegs and only three slots. IMO, we should either mandate that: name field(s) cannot contain '-' so that we ALWAYS only have three '-'delimited fields (four in the case of -src packages), or setup/upset will always parse from R to L, so the FINAL two '-'delimited fields will always be considered REL and VER. (or '-src' and REL and VER in the -src case) autoconf-devel autoconf-stable automake-devel automake-stable tetex-beta We don't need to rename them immediately, but at the first opportunity IMO. And setup will need to be geared to handle the rename smoothly as well (which is on the long term plan anyway). Does '-' sort before or after '_' ? :]. '-' is 0x2d, '_' is 0x5f So, an empty, fake autoconf-devel update and a real autoconf_devel package can be installed during the same setup.exe run, and things should just work. Until setup.exe learns about package conflicts, at which point things become more complicated. I don't like having fragile behaviour in setup.exe - and this is potentially fragile - thus the desire to simplify the parsing rules. I think this is a social problem, not a software engineering problem. Either way you are imposing a requirement on packagers: a) only use the last two '-' delimited fields for VER and REL, or b) always use exactly two '-' characters in the package name, between the name field and the VER field, and between the VER field and the REL field. (src packages get an extra '-src' tacked onto the end). I think we are already doing (a) -- so why not just make that policy, and go with it...and force upset/setup to obey. I'm open to commentary - ideally, long term, setup will not care at all about file naming outside of local scanned installs, and that can be done via a preprocessor to generate a setup.ini. This however _requires_ setup.ini to be have more required fields than it does today. The other question, is - should '-' or '_' go between name, version and cygwin-version? '-' definitely. tetex-beta is more intuitive that tetex_beta, but doing it that way would require relabelling all the packages globally. Of course a transition period will exist before setup.exe and upset are changed... but that could be quite long :]. I don't really see a difference between tetex-beta and tetex_beta. Either is fine with me (actually, I believe it should be just 'tetex'. Doesn't the fact that it has a version number of 20001218 indicate that the source was taken from CVS and is therefore, by definition, beta?) -Chuck
Re: any chance...
Robert Collins wrote: - Original Message - From: Charles Wilson [EMAIL PROTECTED] I forward ported the current patch, and rebuilt automake-devel from 1.5b. That seemed to go okay; I'm waiting for make check to complete. If successful, I'll post the packages for Corinna to do with as she wants. automake-devel-1.5b-1[-src].tar.bz2 are here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ My 'make check' results were All 331 tests behaved as expected (4 expected failures) -- and 327 expected PASSes. Corinna - the ball's in your court...the packages can be rebuilt from source via `./automake-devel-1.5b-1.sh all' if you like. --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: AH yes - thus showcasing the point at hand: tetex - beta-20001218 - cygver is parsed as tetex-beta - 20001218 - cygver! Hmmm...I must spend too much time with computers. My human brain parsed tetex-beta-20001218-2 as tetex-beta 20001218 2. You have been using tetex as an example of how setup/upset *misparses* a string, while I thought it was a perfect example of good parsing. :-) --Chuck
Re: last package
How big are they? If they are only a single .c file each (killall.c, utmpdump.c, last.c) then they are candidates for addition to the cygutils package, if you'd prefer./. One of these days I'll get around to creating a sourceware-based CVS tree for cygutils...Chris, how do I do that? --Chuck Mark Bradshaw wrote: I don't mind. It's already done, actually. Now I'm eyeing up their version of killall too. Mark -Original Message- From: Corinna Vinschen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 12:47 PM To: '[EMAIL PROTECTED]' Subject: Re: last package On Tue, Jan 15, 2002 at 10:29:43AM -0500, Mark Bradshaw wrote: Takes lots of shoe-horning, but it can be done. It doesn't matter. If you don't like to port it, just forget it. I just thought it would be a good idea to borrow utmpdump from sysvinit as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: last package
Mark Bradshaw wrote: Very small. All source combined is 33KB. Executables are 23.5KB. This is just last and utmpdump. You want 'em? Dunno yet. I'm not really concerned about # kilobytes. My rule for cygutils is one .c file per application -- I want to limit cygutils to very simple, small apps. (I'm assuming that nobody would try to put the entire source code to MSWord into a single .c file). Take a look at the current cygutils -src archive and tell me what you think --Chuck
Re: RFC: updated package wget-1.7.1-1
It looks pretty good to me -- I rebuilt it from source right now and it seems okay. The *only* quibble I have is that the binary package contains this file: /etc/wgetrc Since it is just a copy of /usr/doc/wget-1.7.1/sample.wgetrc, you should probably just add some logic to your postinstall shell script: if [ ! -f /etc/wgetrc ]; then cp /usr/doc/wget-1.7.1/sample.wgetrc /etc/wgetrc fi Of course, future versions must take care to change the /usr/doc/wget-1.7.1/ path in that script... --Chuck Hack Kampbjørn wrote: I've updated the wget package to version 1.7.1. I didn't follow all the discussions about packaging structure so if a kind soul would check that I haven't overlooked anything it would be apreciated 8-) I've added a postinstall script to update the info dir file is the a way to update it too if/when wget is uninstalled ? The files are: http://hackdata.com/cygwin/setup.hint http://hackdata.com/cygwin/wget-1.7.1-1.tar.bz2 http://hackdata.com/cygwin/wget-1.7.1-1-src.tar.bz2 setup.hint: -- sdesc: Utility to retrieve files from the WWW via HTTP and FTP ldesc: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. category: Web requires: openssl libintl1 ash cygwin
Re: last package
Christopher Faylor wrote: I've just added you to the cygwin-apps group on sources.redhat.com: cvs -d :ext:sources.redhat.com:/cvs/cygwin-apps co . Feel free to add a cygutils directory. Okay -- I've added it and imported v0.9.7. Also, I've added Mark's last implementation and the supporting autotools changes so that last builds within cygutils. There is a licensing problem with Mark's changes to utmpdump so we're still waiting on that and his killall implementation. Mark -- to see the diff, do the following: $ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps $ cvs login (Logging in to [EMAIL PROTECTED]) CVS password: anoncvs $ cvs co cygutils $ cd cygutils $ cvs diff -r v0_9_7 my_patch Warning: Remote host denied X11 forwarding. cvs server: Diffing . cvs server: tag v0_9_7 is not in file bootstrap cvs server: Diffing licenses cvs server: Diffing src-bsd cvs server: Diffing src-gpl cvs server: tag v0_9_7 is not in file src-gpl/last.1 cvs server: tag v0_9_7 is not in file src-gpl/last.c cvs server: tag v0_9_7 is not in file src-gpl/lastb.1 cvs server: tag v0_9_7 is not in file src-gpl/oldutmp.h cvs server: Diffing src-pd Translation: I added the last.1, lastb.1, last.c and oldutmp.h files to the src-gpl subdirectory. I made additional changes to: AUTHORS (added Mark) ChangeLog (always a good idea...) PROGLIST (added last) README (mentioned last) src/Makefile.am ( This is the biggie ) src/Makefile.in (running bootstrap regenerates this based on the Makefile.am changes) That's the kind of thing that I'd expect as a large add a new program to cygutils patch. --Chuck
Re: for the brave
Gary R. Van Sickle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins I need a few testers: I've fixed the fault Corinna reported with in use files and upgrades. I'd like to know that it works on 9x (not tested properly just now), and if anyone can get it to fault - with reasonable behaviour. FWIW: Worked here (WinXP though) on an in-use cygwin1.dll (a hung bash process actually). HmmmW2K it reports REplaced in use file -- you need to reboot or some such. BUT: I had no cygwin processes running. a) what file did it THINK was in use? b) why did it erroneously thing so? On the plus side, it accurately upgraded my system from readline-4.2 to readline-4.2a/libreadline5-4.2a/libreadline4-4.1 all-at-once. (The older version would've screwed that up unless I did the two-step shuffle) --Chuck
Re: [ANN] rcs-5.7 package available
Earnie Boyd wrote: Hmm... OOTB? Did you take care to test it? In the past there've been issues with the way files are left opened while the temp files are being copied over them. That doesn't work with Win32 and therefore Cygwin. With CVS already working do we need RCS? Sure -- let a thousand flowers bloom. Besides, there are some client applications that expect to use RCS as the backend, not CVS. I'm more worried about the text/binary issues -- especially mixtures. E.g. if the revision files are stored on a binary mount, but the working files are stored on text mounts -- or vice versa. Do things still work? (AFAIRC, even CVS still has difficulty with this) --Chuck
Re: setup.exe command line options
Release early and often. Go ahead and publish what you have, against current CVS. You only need to #ifdef stuff out if it will actually BREAK something that is currently working. If it's, say, the handler for an incompletely implemented commandline option, then it won't break anything (unless someone actually tries to USE that commandline option.) - in that case, it doesn't need to be #ifdef'ed. But Robert has the final call, of course. --Chuck [EMAIL PROTECTED] wrote: I've made some progress, but it's still (infuriatingly) not at the stage where you can do a whole installation without dialog boxes (no offense - they're lovely dialog boxes!), but you can certainly have *fewer* dialog boxes! I'm wondering if I could submit what I have so far, and either leave some bits #ifdef'd out (how does the undefined macro COMMAND_LINE_OPTIONS_FULLY_IMPLEMENTED sound!?) or just miss those bits out completely from my diff. I was hoping to submit the final fully working diffs, but I'm only working in my spare time and everytime I have a look at the latest sources they've moved on so far I'm always playing catch up! I've done a lot of the grunt work; and I'd like some feedback on what I've done. Keith
Re: for the brave
Robert Collins wrote: IIRC this is reproducible for you Chuck, can you shoot me some logs please. Okay, this is from setup 2.188 (compiled just now) and I am trying to do a local install from //polgara/private/software/windows/cygwin-new/ which contains a standard tree structure and the attached setup.ini. Setup responds can't get setup.ini from setup.ini --Chuck 2002/01/27 14:08:56 Starting cygwin install, version 2.188 Current Directory: D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall 2002/01/27 14:08:56 Command line parameters 2002/01/27 14:08:56 0 - 'D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall\setup.exe' 2002/01/27 14:08:56 1 parameters passed source: from cwd root: D:/cygwin binary system Selected local directory: \\Polgara\private\software\windows\cygwin-new mbox note: Unable to get setup.ini from setup.ini 2002/01/27 14:09:09 Ending cygwin install 2002/01/27 14:08:56 Starting cygwin install, version 2.188 Current Directory: D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall 2002/01/27 14:08:56 Command line parameters 2002/01/27 14:08:56 0 - 'D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall\setup.exe' 2002/01/27 14:08:56 1 parameters passed source: from cwd root: D:/cygwin binary system Selected local directory: \\Polgara\private\software\windows\cygwin-new mbox note: Unable to get setup.ini from setup.ini 2002/01/27 14:09:09 Ending cygwin install # 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: 1012098462 setup-version: 2.125.2.10 @ bzip2 sdesc: A high-quality block-sorting file compressor - utilities ldesc: bzip2 is a freely available, patent free, high-quality data compressor. It typically compresses files to within 10% to 15% of the best available techniques (the PPM family of statistical compressors), whilst being around twice as fast at compression and six times faster at decompression. category: Utils requires: cygwin libbz2_0 version: 1.0.2-1 install: latest/bzip2/bzip2-1.0.2-1.tar.bz2 212144 source: latest/bzip2/bzip2-1.0.2-1-src.tar.bz2 679387 @ cygipc category: Misc version: 1.11-1 install: contrib/cygipc/cygipc-1.11-1.tar.bz2 84005 source: contrib/cygipc/cygipc-1.11-1-src.tar.bz2 70589 [prev] version: 1.10-1 install: contrib/cygipc/cygipc-1.10-1.tar.bz2 83134 source: contrib/cygipc/cygipc-1.10-1-src.tar.bz2 72147 @ cygutils sdesc: A collection of simple utilities ldesc: This package contains a collection of simple (single source file) utilities, including: ascii, banner, dump (no, not the ext2 backup utility; it's a hexdumper), DOS/UNIX line ending converters, Windows clipboard manipulation programs, and many more... category: Utils requires: cygwin popt version: 0.9.8-1 install: contrib/cygutils/cygutils-0.9.8-1.tar.bz2 56046 @ ispell category: Misc version: 3.2.06-1 install: contrib/ispell/ispell-3.2.06-1.tar.gz 712831 @ libbz2_0 sdesc: Shared libraries for bzip2 (runtime) ldesc: bzip2 is a freely available, patent free, high-quality data compressor. It typically compresses files to within 10% to 15% of the best available techniques (the PPM family of statistical compressors), whilst being around twice as fast at compression and six times faster at decompression. category: Utils requires: cygwin bzip2 version: 1.0.2-1 install: latest/bzip2/libbz2_0/libbz2_0-1.0.2-1.tar.bz2 24440 source: latest/bzip2/libbz2_0/libbz2_0-1.0.2-1-src.tar.bz2 528 @ libiconv category: Misc version: 1.7-1 install: contrib/libiconv/libiconv-1.7-1.tar.bz2 639633 source: contrib/libiconv/libiconv-1.7-1-src.tar.bz2 2257623 [prev] install: contrib/libiconv/libiconv-newfiles.tar.gz 6748 @ libtool sdesc: Wrapper scripts for libtool-devel and libtool-stable ldesc: GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. libtool contains libtool-scripts-20010531, and is meant to be installed alongside libtool-stable (which contains libtool-1.4.2) and alongside libtool-devel (which contains a hacked libtool-20010531). It exec's the appropriate version based on target package heuristics. category: Devel requires: ash libtool-devel libtool-stable version: 20010531a-1 install: latest/libtool/libtool-20010531a-1.tar.bz2 10081 source: latest/libtool/libtool-20010531a-1-src.tar.bz2 42759 @ libtool-devel sdesc: A shared library generation tool ldesc: GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. libtool-devel contains a modified version of libtool from cvs (20010531) and supports `transparent' dll-building using the new auto-import functionality of binutils. libtool-devel is meant to be installed alongside libtool-stable (which contains libtool-1.4.2), and alongside the `libtool' package, which contains wrapper scripts which
Re: for the brave
Charles Wilson wrote:
Robert Collins wrote:
IIRC this is reproducible for you Chuck, can you shoot me some logs
please.
Okay, this is from setup 2.188 (compiled just now) and I am trying to do
a local install from //polgara/private/software/windows/cygwin-new/
which contains a standard tree structure and the attached setup.ini.
Setup responds can't get setup.ini from setup.ini
AHA!
After applying the attached patch to setup 2.188, I got a clue that the
problem was that my 'local' repository was on a remote share
'//polgara/private/'. So, I copied the
//polgara/private/software/windows/cygwin-new tree over to my local disk
-- and things were kinda okay for a while.
I got to the chooser screen, and it listed the bzip2 package and
libbz2_0 package:
CURRENT NEW PACKAGE
1.0.1-6 1.0.2-1 bzip2: sdesc...
1.0.2-1 libbz2_0: sdesc...
When I said install, I briefly got the progress screen -- and then a
BSOD. memory dump sent separately. This is on W2K, McAfee *was* turned
*off*.
Sigh.
So, the problem with unable to get setup.ini from setup.ini seems to
be due to problems handling windows shares in the local_dir variable
within ini.cc.
Now, my problem list is;
BSOD
SEGV when clicking 'ADD' new site for internet installations. (null
pointer)
local_dir on a windows share
--Chuck
Index: filemanip.cc
===
RCS file: /cvs/src/src/winsup/cinstall/filemanip.cc,v
retrieving revision 2.2
diff -u -r2.2 filemanip.cc
--- filemanip.cc2002/01/26 04:21:34 2.2
+++ filemanip.cc2002/01/27 20:00:26
@@ -97,7 +97,7 @@
f.pkg[0] = f.what[0] = '\0';
p = base (fn);
for (ver = p; *ver; ver++)
-if (*ver == '-' || *ver == '_')
+if (*ver == '-')
if (isdigit (ver[1]))
{
*ver++ = 0;
Index: ini.cc
===
RCS file: /cvs/src/src/winsup/cinstall/ini.cc,v
retrieving revision 2.18
diff -u -r2.18 ini.cc
--- ini.cc 2002/01/20 13:31:04 2.18
+++ ini.cc 2002/01/27 20:00:27
@@ -68,7 +68,7 @@
io_stream *ini_file = io_stream::open (concat (file://, local_dir,/, path, 0),
rb);
if (!ini_file)
{
-note (NULL, IDS_SETUPINI_MISSING, path);
+note (NULL, IDS_SETUPINI_MISSING, (concat(file://, local_dir, /, path, 0) ) );
return;
}
Re: for the brave
Charles Wilson wrote: After applying the attached patch to setup 2.188, I got a clue that the problem was that my 'local' repository was on a remote share '//polgara/private/'. Forgot to include the setup.log.full data that gave me this clue: setup.exe is really trying to iostream::open() this file -- file:///Polgara/private/software/windows/cygwin-new/setup.ini If I paste into IE, it fails. But the following two pathnames work: file:/Polgara/private/software/windows/cygwin-new/setup.ini file:Polgara/private/software/windows/cygwin-new/setup.ini (Yes, those ARE forward slashes) Something to do with iostream::open() and slashifying, maybe? So, I copied the //polgara/private/software/windows/cygwin-new tree over to my local disk -- and things were kinda okay for a while. ... --Chuck 2002/01/27 14:46:23 Starting cygwin install, version 2.188 Current Directory: D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall 2002/01/27 14:46:23 Command line parameters 2002/01/27 14:46:23 0 - 'D:\cygwin\usr\src\kernel\obj\i686-pc-cygwin\winsup\cinstall\setup.exe' 2002/01/27 14:46:23 1 parameters passed source: from cwd root: D:/cygwin binary system Selected local directory: \\Polgara\private\software\windows\cygwin-new mbox note: Unable to get setup.ini from file:///Polgara/private/software/windows/cygwin-new/setup.ini 2002/01/27 14:46:47 Ending cygwin install
Re: for the brave
Earnie Boyd wrote: Charles Wilson wrote: file:/Polgara/private/software/windows/cygwin-new/setup.ini file:Polgara/private/software/windows/cygwin-new/setup.ini This makes sense. You need two // after file: and two // before Polgara. The extra fifth / was just ignored. Sure, I understand that. (Side note: file://Polgara/... also works, for whatever reason). But here's the question: local_dir (as I typed it) already contained two leading '/' chars the concat call prepended file:// with two more '/' chars 2+2 = 4 So why does the resulting filespec have only 3 '/' chars? Somewhere along the line, I don't know where, the local_dir I entered is having one of its leading '/' stripped... --Chuck
Re: base-files package needs a maintainer
Michael A Chase wrote: Shouldn't this be part of the ash package? Now that it's part of the Base category, there shouldn't be any problem creating /etc/profile when ash is installed. No. ash provides ash. base-files provides the data for a purely data-driven setup.exe. That is, the scripts (which require ash) to create /etc/.profile, /etc/.bashrc, etc. base-files may later do more stuff, like create the /usr/local/ tree and the /var tree -- why should setup.exe have that stuff hardcoded into it? Once the configuration tasks performed by base-files grows, why should it be part of the ash package? You don't want to redo the setup scripts when updating ash.exe, do you? --Chuck -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age. - Original Message - From: Robert Collins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 05:24 Subject: base-files package needs a maintainer Setup.hint: @ base_files sdesc: Core common files needed for correct operation of cygwin category: Base The entire package is attached. The /etc/profile generation is getting removed from setup.exe unless someone provides a _real good_ reason for it to remain. Setup.exe should be *data driven*, and in this area is not at the moment. This package can be released at any point, it shouldn't cause any problem with current setup.exe's, and will allow a future release of setup.exe to do away with the /etc/profile generation crud.
Re: moratorium on new setup.exe features, please?
Christopher Faylor wrote: Can we concentrate on releasing a new version of setup.exe, please? I'd like to eliminate the confusion that the current version of setup.exe is causing. It seems like we are in a standard add one more thing mode when people are experiencing real problems and real confusion with the currently released setup.exe. The only thing that I really wanted for the next release was clickable categories. We have quite a bit more than that so I assume there will be additional unforeseen headaches coming. This is standard when you add new features. The more features you add, the more headaches you'll get. So, lets just concentrate on getting something out the door which solves the known issues. The biggest known issue right now is the How do I install everything? There's one more urgent issue: I have a bzip2 and libbz2_0 package waiting for release, and the new setup must be able to handle that name(*)...I think most of these changes are in Robert's sandbox right now, but there's also a necessary pending patch to dump_setup.cc(?) in winsup/utils/ (*) sure, I could rename it, but I really would rather not... IMO, this change is a bugfix on the current setup.exe, and not a new feature. YOMV... --Chuck
Re: TCP Wrappers
Prentis Brooks wrote: Alright, finally read over the setup.html file and built up the src and binary packages. Writing up the setup.hint file now. I have the following: # TCP Wrappers @ tcp_wrappers_7.6 This line is not necessary -- it is created in setup.ini by the upset script; it doesn't need to appear in setup.hint sdesc: TCP Wrappers You don't need to put the name into the descriptions anymore; setup.exe will automatically add the name. I would suggest sdesc: Tool to provide host based access restrictions in tcp services ldesc: With this package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. The package provides tiny daemon wrapper programs that can be installed without any changes to existing software or to existing configuration files. The wrappers report the name of the client host and of the requested service; the wrappers do not exchange information with the client or server applications, and impose no overhead on the actual conversation between the client and server applications. ldesc: TCP Wrappers: Tool to provide host based access restrictions to tcp base d services skip: curr: 7.6 prev: test: You don't need to specify these at all. The upset script will figure it out and put the right thing into setup.ini. You only need to specify these manually within setup.hint if the upset parser gets it wrong. category: requires: category: Net requires: cygwin Does what I have look right, and what category should I put this into? I don't think this requires much beyond cygwin. Going to look at the setup.ini to see if there are other requirements that make sense. Feedback appreciated. --Chuck
Re: setup w/char* eliminated is big
Christopher Faylor wrote: On Thu, Feb 14, 2002 at 12:42:28PM -0500, Charles Wilson wrote: *please* make sure that the '-' vs. '_' fix is in before releasing the new setup. I've been sitting on the bzip2 update waiting on this... (Also, the localdir-is-on-remote-share fix would be nice, but it isn't as urgent as the '_' thing.) I just removed the special case for '_' in parse_filename. Oh -- well, I guess I coulda done that too, but I don't like unilaterally messing with code in someone else's kingdom (but since you're the Grand High Emperor Moppet, it's okay for YOU). I know that Robert has had the fix in his local sandbox for two weeks. I was just leaving it up to him to commit that fix -- and reminding him to do so before unleashing the new setup.exe upon the world. Thanks. --Chuck
Re: upset2
upset2 seems to work okay for me, on a few locally-constructed trees. In fact, discounting the tarball listings in html that upset generated, the output is identical to upset's...nice job. --Chuck Christopher Faylor wrote: I've moved 'upset' to a new home and have begun modularizing the upset perl code so that it will be possible to write a setup.hint 'linter'. The new home for upset is cvs -d :pserver:[EMAIL PROTECTED]:/cvs/sourceware co infra/bin/cygwin upset2 also lives there. It is a work in progress but it is already more flexible than 'upset' or 'update-setup'. I'll probably be switching over to using it on sourceware this week. cgf
Re: New file for winsup/utils
Joshua Daniel Franklin wrote: OK, here is a new util: Usage mkshortcut.exe [OPTION]... TARGET NOTE: All filename arguments must be in unix (POSIX) format -a|--arguments=ARGS use arguments ARGS -h|--help output usage information and exit -i|--icon icon file for link to use -j|--iconoffset offset of icon in icon file (default is 0) -n|--name name for link (defaults to TARGET) -v|--version output version information and exit -A|--allusers use 'All Users' instead of current user for -D,-P -D|--desktop create link relative to 'Desktop' directory -P|--smprograms create link relative to Start Menu 'Programs' directory Now that cygutils is part of the distribution, I think this belongs there, if Chuck is amenable. With the exception of regtool, all of the programs in winsup/utils are pretty cygwin-specific. While this looks like a very nice tool, I think it belongs elsewhere. cgf Looks like a discussion for cygwin-apps. The only thing I would be worried about is if cygutils is NOT installed but some packages use mkshortcut as part of their post-install script. Wasn't there some discussion of merging cygutils into the winsup CVS, or did I not catch that right? cygutils now has its own directory, hosted by the cygwin-apps repository. THAT is what the discussion was -- previously it was hosted on my laptop. :-) It was never considered for merging into winsup. Also, packages that use it in their postinstall script just need to include cygutils as a dependency. Chuck, do you want to grab the file from cygwin-patches and put it in cygutils? Sure, that sounds like a good addition. I'll need to write different documentation than utils.sgml also. Is there some automated tool that could convert your .sgml to .texinfo? That'd be good...'cause then the installation could create .info and we could use texi2roff to generate the man page(*) (*) this would not be part of an ordinary build process; as the maintainer, we'd use texi2roff to generate a man page, and ship that manpage.1 file as part of the sources. texi2roff is here: http://www.fido.de/kama/texinfo/texinfo-en.html I'm not sure how good a job it does; and the generated manfile would probably need some editing. Does anybody speak roff? --Chuck
ITP: pkgconfig
I've got pkgconfig ready for contribution to the cygwin distribution.
Since we're starting to get a few packages that include .pc files
(libxslt, libxml-2.0) we probably ought to have this. I've got version
0.10.0 (released 2002-02-02) ready to.
I think it should go in latest/pkgconfig/ alongside the autotools (and
not contrib).
Votes?
--Chuck
setup.hint:
---
category Devel
requires cygwin
sdesc A utility used to retrieve information about installed libraries
ldesc The pkg-config program is used to retrieve information about
installed libraries in the system. It is typically used to compile and
link against one or more libraries.
pkg-config retrieves information about packages from special metadata
files. These files are named after the package, with the extension .pc.
By default, pkg-config looks in the following directories:
${PREFIX}/libdata/pkgconfig, ${LOCALBASE}/libdata/pkgconfig and
${X11BASE}/libdata/pkgconfig for these files; it will also look in the
list of directories specified by the PKG_CONFIG_PATH environment variable.
The package name specified on the pkg-config command line is defined to
be the name of the metadata file, minus the .pc extension. If a library
can install multiple versions simultaneously, it must give each version
its own name (for example, GTK 1.2 might have the package name 'gtk+'
while GTK 2.0 has 'gtk+-2.0').
WWW: http://www.freedesktop.org/software/pkgconfig/
http://pkgconfig.sourceforge.net;
---
Re: pkgconfig
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 23, 2002 6:10 PM To: [EMAIL PROTECTED] Subject: ITP: pkgconfig I've got pkgconfig ready for contribution to the cygwin distribution. Since we're starting to get a few packages that include .pc files (libxslt, libxml-2.0) we probably ought to have this. I've got version 0.10.0 (released 2002-02-02) ready to. I think it should go in latest/pkgconfig/ alongside the autotools (and not contrib). Votes? For the package, yes. For the location, I think contrib. IMO *everything* thats not absolutely essential is contributed :}. I disagree. IMO, the distinction between contrib and latest is precisely zero. Is 'opengl' (latest) more essential than 'perl' (contrib)? Is 'ctags' (latest) more essential than 'gettext' (contrib)? cpio? mt? bc? clear? (all latest) -- these are hardly essential for most users. See this message: http://cygwin.com/ml/cygwin/2002-02/msg01153.html In fact, I'd go so far to suggest that we abolish latest and contrib altogether.. Well, yeah, me too -- but setup got confused, according to some users, the last time we tried moving packages around (ncurses). Lets verify that the soon-to-be-released setup can handle moving ONE package (gettext?) before advocating a wholesale rearrangement. (AND give everybody out there some time to switch from the old 'stable' setup to the new 2.194.2.x one). Wasn't Chris mumbling about rearranging stuff at some point? --Chuck
Re: New file for winsup/utils
Joshua Daniel Franklin wrote: OK, c file and man page attached. The copyright is updated and the version now reads 1.01. I assume you would rather mess with the Makefile since you're already familiar with the cygutils source; let me know if I need to provide patches for anything. This'll do... I'm not sure how good a job it does; and the generated manfile would probably need some editing. Does anybody speak roff? I speak a little roff, so since I don't have a sgml-texinfo translator I just made a mkshortcut.1 file. Maybe there's something to convert man to texinfo, so documentation can be created in either format and translated? I've used man2html quite a bit and it works well. Not necessary. If there is no .info file, info will display the man page. --Chuck
Re: setup.exe rebase patch
Jason Tishler wrote: (Or do you rebase cygwin1.dll as well :]]). Yes, I can rebase cygwin1.dll too. This is why I converted the stand-alone rebase to a Mingw app. Urk. If we follow Earnie's suggestion to include the output of 'objdump -S1' with cygwin1.dlll snapshots and the (main)cygwin package, then rebasing cygwin1.dll will break that. Seems like rebasing cygwin1.dll itself should never be the default behavior... http://cygwin.com/ml/cygwin-developers/2002-02/msg00029.html --Chuck
Re: setup.exe rebase patch
Robert Collins wrote: -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] However, I agree that rebasing shouldn't be the default behavior. In fact, I wonder if I should make cygwin non-rebaseable. It would load faster if I did that. Yes, and it would solve some of the nasty faults -auto-image-base. (The strange behaviour of often choosing a base that collides with cygwin). Rob Note: libtool-devel does not use auto-image-base. I don't THINK libtool-stable does, either. And all of my DLLs have been rebuilt over the last several months without auto-image-base. Just FYI. Also, there was some code passed back and forth a while ago (Rob, yours maybe?) that purported to add a non-relocatable option to binutils. I don't remember the specifics, but I think there were some problems with that particular implementation. A working version that added a non-relocatable option to ld when creating a DLL would be a nice addition to binutils. Anybody remember more about this? I'm drawing a blank... --Chuck
Re: ghostscript 6.51-4 now ready
Dario Alcocer wrote: I've finished testing and packaging the latest release of Ghostscript; the new release uses the libpng and zlib shared libraries, as suggested by Chuck Wilson. I've put the packages and MD5 sum file at: http://members.cox.net/dalcocer/gs If someone has upload capability to sources.redhat.com and can upload this package, please let me know. I'll wait until the package has been uploaded before I post my package update announcement. Thanks in advance, Uploaded. --Chuck
Re: ITP: pkgconfig
Anybody else want to weigh in, here? So far I've got one 'yay' vote
from Robert (but putting pkgconfig into contrib instead of latest)
Fine by me Any other votes?
--Chuck
Charles Wilson wrote:
I've got pkgconfig ready for contribution to the cygwin distribution
Since we're starting to get a few packages that include pc files
(libxslt, libxml-20) we probably ought to have this I've got version
0100 (released 2002-02-02) ready to
I think it should go in latest/pkgconfig/ alongside the autotools (and
not contrib)
Votes?
--Chuck
setuphint:
---
category Devel
requires cygwin
sdesc A utility used to retrieve information about installed libraries
ldesc The pkg-config program is used to retrieve information about
installed libraries in the system It is typically used to compile and
link against one or more libraries
pkg-config retrieves information about packages from special metadata
files These files are named after the package, with the extension pc
By default, pkg-config looks in the following directories:
${PREFIX}/libdata/pkgconfig, ${LOCALBASE}/libdata/pkgconfig and
${X11BASE}/libdata/pkgconfig for these files; it will also look in the
list of directories specified by the PKG_CONFIG_PATH environment variable
The package name specified on the pkg-config command line is defined to
be the name of the metadata file, minus the pc extension If a library
can install multiple versions simultaneously, it must give each version
its own name (for example, GTK 12 might have the package name 'gtk+'
while GTK 20 has 'gtk+-20')
WWW: http://wwwfreedesktoporg/software/pkgconfig/
http://pkgconfigsourceforgenet;
---
Re: [PATCH suggestion] aclocal wrapper script loops forever if automake-devel or automake-stable is missing
Pavel Tsekov wrote: Hey, there! :) Does the attached patch make any sense ? It prevents an infinite loop if either automake-devel or automake-stable is missing. Yes, it does -- of course, setup enforces that automake depends on automake-devel and automake-stable, so if you see this error it's because you've overridden setup.exe... Or you set the AUTO_STABLE / AUTO_DEVEL environment variables (incorrectly). I've incorporated your suggestions into the next version of the wrappers. However, as a general note, there are a few problems with your submission: 1) you patched a generated file, not a source file (aclocal is created from aclocal.in in the automake -src package). 2) you only patched one of the files -- but all scripts exhibit this behavior. You'd actually need to provide similar patches for automake: aclocal.in automake.in autoconf: autoconf.in autoupdate.in autoreconf.in autoheader.in autoscan.in ifnames.in libtool: libtool.in libtoolize.in 3) No ChangeLog entry I have done all of the above, so no worries this time. However, next time... --Chuck
Re: libtool devel auto-import broken
Hmmm...there's a line in ltmain.sh that says:
-allow-undefined)
# FIXME: remove this flag sometime in the future.
$echo $modename: \`-allow-undefined' is deprecated because it
is the default 12
continue
;;
Actually, libtool.m4 is an original file. It isn't generated from
anything AFAIK. Anyway, I updated to the most recent libtool CVS, and
whaddaya know -- almost all of your patches have made it in. The
attached patch is all that's left outside (and it also includes the
patch you just posted).
I'll whip up a new libtool-devel package soon. What's the story with
the automake-1.6 package I put up? Had a chance to play with it yet?
--Chuck
Robert Collins wrote:
the following patch (to the created file I know, sorry short of time)
corrects a recent regression, related to libtol tags I think, that
prevents libtool using auto-import in some cases.
Cheers,
Rob
? .build
? .inst
? .sinst
? COPYING
? CYGWIN-PATCHES
? INSTALL
? install-sh
? missing
? mkinstalldirs
? libltdl/config-h.in
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.250
diff -u -u -r1.250 libtool.m4
--- libtool.m4 14 Mar 2002 17:40:20 - 1.250
+++ libtool.m4 17 Mar 2002 09:06:29 -
-2566,7 +2566,7
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-_LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+_LT_AC_TAGVAR(allow_undefined_flag, $1)=
_LT_AC_TAGVAR(always_export_symbols, $1)=yes
if $LD --help 21 | egrep 'auto-import' /dev/null; then
-4366,6 +4366,9
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs $convenience | awk
'\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 == B)) ([substr](\[$]3,1,1)
!= .)) { print \[$]3 } }'\'' | sort -u $export_symbols'
fi
;;
+ cygwin*)
+_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
+$global_symbol_pipe | sed '\''s/.* //'\'' | sort | uniq $export_symbols'
+ ;;
mingw* | pw32*)
_LT_AC_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
;;
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.163
diff -u -u -r1.163 ltdl.c
--- libltdl/ltdl.c 3 Mar 2002 03:19:55 - 1.163
+++ libltdl/ltdl.c 17 Mar 2002 09:06:33 -
-911,11 +911,7
/* --- DLOPEN() INTERFACE LOADER --- */
-/* Older Cygwin dlopen implementations print a spurious error message to
- stderr if the call to LoadLibrary() fails for any reason. We can
- mitigate this by not using the Cygwin implementation, and falling
- back to our own LoadLibrary() wrapper. */
-#if HAVE_LIBDL !defined(__CYGWIN__)
+#if HAVE_LIBDL
/* dynamic linking with dlopen/dlsym */
-1734,7 +1730,7
handles = 0;
user_search_path = 0; /* empty search path */
-#if HAVE_LIBDL !defined(__CYGWIN__)
+#if HAVE_LIBDL
errors += lt_dlloader_add (lt_dlloader_next (0), sys_dl, dlopen);
#endif
#if HAVE_SHL_LOAD
Index: mdemo/Makefile.am
===
RCS file: /cvsroot/libtool/libtool/mdemo/Makefile.am,v
retrieving revision 1.45
diff -u -u -r1.45 Makefile.am
--- mdemo/Makefile.am 3 Mar 2002 03:19:55 - 1.45
+++ mdemo/Makefile.am 17 Mar 2002 09:06:33 -
-14,10 +14,10
libfoo2_la_SOURCES = foo2.c
libfoo2_la_LIBADD = $(LIBM) libsub.la
-libfoo2_la_LDFLAGS = -no-undefined -module -export-symbols-regex libfoo2.*
+libfoo2_la_LDFLAGS = -module -export-symbols-regex libfoo2.*
libsub_la_SOURCES = sub.c
-libsub_la_LDFLAGS = -no-undefined
+## libsub_la_LDFLAGS = -no-undefined
noinst_HEADERS = foo.h
Re: Link for MORE
Christopher Faylor wrote: If someone wants to contribute, I think it should just be a standard package. Chuck, I hate to say this, but I don't see a real reason for growing cygutils. The more packages we add to cygutils, the more we go back to the old way of installing cygwin packages -- with less fine-grained control. A very good point. This is why both of the latest additions to cygutils were 'vetted' on the list before I added them: mkshortcut: recall the big discussion about whether it should be added to winsup/utils or cygutils... cygstart: this was also thrashed out on the list...although discussion centered on whether it should be called 'start' or 'cygstart' -- but the idea that it should be added to cygutils was part of the ongoing discussion (nobody objected, so...) However, perusing the code it appears that more is fairly complex (even if it is all contained in a single file). For some reason, it offends my sensibilities to create a giant autotool'ed project with all the overhead (INSTALL, configure.ac, configure, Makefile.am, mkinstalldirs, ...) for just a single-file program. OTOH, turning cygutils into full.exe isn't a good idea, either. It makes more sense to answer the Where's more? question with In the 'more' package than In the cygutils package. So, in this case I think you are right. Maybe there is a good reason to have a general purpose utils package that I'm missing. It just seems to me that this is adding a focus for the cygwin package release on you -- a single point of contact. Theoretically, we could be sharing the load if the contributed pieces of cygutils were made into true cygwin packages. I have no objection if the original contributors want to take the cygutils source package, rip out everything that isn't (for instance) 'mkshortcut'-related, and release a standalone autotool'ed mkshortcut. (However, I'm not pushing for that.) Tell you what, Chris: unless it is a single-source-file program that I personally wrote or ported, I won't add anything else to cygutils unless it meets with list approval (heck, that was pretty much my modus operandi, anyway). --Chuck
Re: release setup now?
Robert Collins wrote: 2) It seems that when uninstalling (or upgrading), if the uninstalled package leaves behing a directory that is empty, the directory is not removed. Not a big deal, and certainly not a showstopper. Hmm, has that behaviour changed? I'll add a TODO for it. Actually, now that I think about it, this problem may be related to 0x00 problem. The only packages I noticed this on were local updates of the auto-* and libtool* packages that I was testing. But I had been installing these updates using setup-snapshots. So all of my .lst file had 0x00 -- and then when I tried to upgrade, the uninstall didn't work exactly right... That's my story and I'm sticking to it. --Chuck
Re: tcp wrappers
Prentis Brooks wrote: Hmm. I wonder if it would be worthwhile to make the wrapper library a DLL. I would rather we didn't, primarily because the modification to make tcp wrappers work with Cygwin was simplistic. In fact, at this point the modification is only to the Makefile, plus a line in one another file. It is my understanding from Mumit Khan that the tcp wrappers author is going to incorporate this patch into the next release of tcp wrap. Taking that into consideration, wouldn't turning the libwrap into a DLL cause a (kind of) branch? Not really. re-libtoolizing the source dir (tcp is libtoolized, I think) using our cygwinized devel version of libtool is a builder issue, not really a source code issue. (In the old days, making a DLL required intrusive and exhausting changes to lots and lots of source files -- __declspec(dllexport) this, __declspec(dllexport that)... -- but no longer.) With auto-import binutils, and the libtool-devel package, you merely: rm ldconfig.sh rm ltmain.sh edit configure.in and make sure that it AC_PREREQ's 2.50 or greater libtoolize --force -c aclocal ( possibly need to add '-I some-subdir') automake --force -a autoconf And then configure/make as usual -- an poof! DLL AND static lib. Okay, maybe it's not QUITE that easy, but it's close. You do need to understand the autotools and maybe read a few man pages, but... Still, this is a maintainer decision. If you don't want to DLLize, that is your prerogative. No complaints from me. --Chuck
Re: tcp wrappers
Prentis Brooks wrote: Hrmmm I will look into it, I am sure there is some efficiency gained from making it a DLL. Would packages that are built against libwrap automatically use the DLL if it is available, or would they need to be tweaked as well (ie sshd is compiled such that if libwrap.a is available it will use it to make use of host.allow files). If an import lib is found during the link step (say when building sshd.exe), then the linker will use that in preference to a static lib. Import libs are usually named /usr/lib/libfoo.dll.a While static libs are typically /usr/lib/libfoo.a And of course, the DLL is usually /usr/bin/cygfoo-N.dll where 'N' is the interface number (see libtool docs for more info; on cygwin, N = c - a (interface - age) libtool knows about these rules (on cygwin) when building the library (say libtcpwrap) so a properly libtoolized/autoconfiscated tcpwrappers package will automagically generate /usr/lib/libtcpwrap.dll.a /usr/lib/libtcpwrap.a /usr/bin/cygtcpwrap-N.dll When linking a client (say sshd.exe) the linker will use libtcpwrap.dll.a, and your sshd.exe will have a runtime dependency on cygtcpwrap-N.dll. (In the past, you had to #define special stuff when compiled sshd's .c files; this is no longer necessary thanks to auto-import). It just works (tm). However, if tcpwrapper is not yet libtoolized (nor autoconfiscated), then autoconfiscating and libtoolizing it yourself from scratch is a pretty big undertaking... --Chuck
Re: pager in default install
Joshua Daniel Franklin wrote: Did you see the 'more' source code I posted the other day -- it came from the util-linux distribution (http://freshmeat.net/releases/72929/) --Chuck Yes, I already had the util-linux source on my HD from looking at the source to kill. The problem is that it doesn't ./configure properly since I (obviously) don't have linux/foo includes. Take a look at the modifications I made for 'cal', 'ddate' etc, in the cygutils package. Those where taken from the util-linux package as well, but heavily modified to build in the cygutils tree instead of in the util-linux tree. That may give you some hints. Also, you're more than welcome to copy the cygutils infrastructure (libsupport.a, common.h, etc) and use it with your 'more' package. I'm thinking of taking just the essentials for branching a Cygwin-only 'more' package. Actually, I'd like to start out with that and then generalize it into a 'GNU more' with long-opts, --version, etc. I'll see about contacting someone at GNU.org about it. Ummm, why? It seems to me that the only reason to have an actual 'more' binary, is so that you have something that is behaviorally identical to the original 'more' program -- so that progs that spawn 'more' get something that actually acts like 'more' (and not 'less'). If you break the behaviorally identical requirement, you might as well just 'cp less.exe more.exe' and be done. I can GPL formerly BSD'd code, right? Err, not really. The original code remains under the copyright ownership of whoever wrote it -- and only they can change the licensing terms. However, your changes, and support code (Makefiles, etc) can be released under the GPL. Since the util-linux source is BSD-no-advert, it is compatible with the GPL -- and if you mix GPL+BSD-no-advert, the result taken as a whole is therefore bound by the GPL. (e.g. BSD-no-advert code can be assimilated into a GPL project, but still remains BSD-no-advert) But IANAL. --Chuck
Re: pager in default install
Joshua Daniel Franklin wrote:
That's because I didn't use this list. I had another criteria which,
if you are looking in the email archives, you should be able to see
mentioned a few times. I used the 'base' category from debian. Hopefully
we haven't drifted from that too much.
I remember something about that but thought it was just a general
guideline. I installed Debian with the Potato netinst CD
http://www.debian.org/CD/netinst/
and guess what's in 'base'? util-linux including 'more'
http://packages.debian.org/stable/base/util-linux.html
So what does this mean for more's inclusion?
Not arguing for or against, here, but as a point of order:
util-linux IS what cgf is worried about cygutils BECOMING: a catch all
for lots and lots of stuff -- some important, some not. util-linux
contains (among other things):
/bin/arch
/bin/dmesg
/bin/kill
/bin/login
/bin/more
/etc/fdprm
/etc/pam.d/chfn
/etc/pam.d/chsh
/etc/pam.d/kbdrate
/etc/pam.d/login
/etc/security/console.apps/kbdrate
/sbin/agetty
/sbin/blockdev
/sbin/clock
/sbin/ctrlaltdel
/sbin/elvtune
/sbin/fdisk
/sbin/fsck.minix
/sbin/hwclock
/sbin/kbdrate
/sbin/mkfs
/sbin/mkfs.bfs
/sbin/mkfs.minix
/sbin/mkswap
/sbin/nologin
/sbin/pivot_root
/sbin/rescuept
/sbin/sfdisk
/usr/bin/cal
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/col
/usr/bin/colcrt
/usr/bin/colrm
/usr/bin/column
/usr/bin/cytune
/usr/bin/ddate
/usr/bin/fdformat
/usr/bin/getopt
/usr/bin/hexdump
/usr/bin/ipcrm
/usr/bin/ipcs
/usr/bin/logger
/usr/bin/look
/usr/bin/mcookie
/usr/bin/mkcramfs
/usr/bin/namei
/usr/bin/newgrp
/usr/bin/raw
/usr/bin/rename
/usr/bin/renice
/usr/bin/rev
/usr/bin/script
/usr/bin/setfdprm
/usr/bin/setsid
/usr/bin/setterm
/usr/bin/ul
/usr/bin/whereis
/usr/bin/write
/usr/games/banner
/usr/sbin/cfdisk
/usr/sbin/hwclock
/usr/sbin/ramsize
/usr/sbin/rdev
/usr/sbin/readprofile
/usr/sbin/rootflags
/usr/sbin/tunelp
/usr/sbin/vidmode
/usr/sbin/vigr
/usr/sbin/vipw
Now, surely 'kill' and 'login' are BASE programs, but 'newgrp'? Sure,
it's useful, but the system is completely functional without 'newgrp'.
And 'ddate' -- fun but hardly necessary. 'cal', 'col', 'banner'? Ditto.
But, since the machine is pretty much useless without 'login' (and
perhaps the pam modules) -- the whole thing gets classified as BASE.
Splitting things up into separate packages is good. That way, the
'login' program can be classified as BASE (as it is in cygwin, since we
have a 'login' package containing'login'!) but ddate and cal can go
live in the unimportant (but fun and useful) cygutils package.
(The argument could be made that everything in cygutils should be split
into individual packages, but SOME conglomeration is okay. We just need
to be reasonable about it)
Now, back to the topic: more. Just because util-linux is classified as
BASE by Debian, and we want to follow (within reason) Debian's category
scheme, it does not NECESSARILY follow that every program WITHIN
util-linux should ALSO be a 'base' package -- by splitting things up we
have more flexibility. ('more' might be 'base'able -- but not merely on
the basis of util-linux's position in the Debian category scheme).
--Chuck
Re: pager in default install
Lame followup to my own post: I think we should have A 'more' package for this reason: Q: Where's more? A: In the 'more' package. makes a lot more sense than Q: Where's more? A: Use less instead. It's better. BTW, you'll probably need to set PAGER=less. Oh, and NCFTP_PAGER=less. (Okay, that last one is an exagerration. Actually, the ncftp code has a special cygwin hack so that on cygwin, ncftp uses less by default. Other platforms use more by default. But you get the idea.) --Chuck Charles Wilson wrote: In my previous post, I didn't mean to argue against 'more' as a package, or against its inclusion in the 'base'. I was merely pointing out the fallacies in arguing that Debian(util-linux in 'Base') + util-linux(contains more) === cygwin(more in 'Base'). It doesn't. In fact, I think it would be a good idea to have a 'more' package for cygwin. I'm not sure it should be included in 'base' -- perhaps 'Text' or 'Utils' would be a better choice. If you are willing to port/package/provide/maintain 'more' then I think it should be added to the distribution.
Re: more package
Joshua Daniel Franklin wrote: requires: ash cygwin libintl1 ncurses pcre almost nothing actually depends on the ncurses package. the dependency is probably on the libncurses6 and/or terminfo packages. --Chuck
Re: release setup now?
Michael's script works for me. One caveat: I had to manually run 'clean_lst.pl ./a*.lst' 26 times (using different starting letters). However, that was because I got a BSOD when running it fullbore -- where it tried to fixup all files. Now, a perl script should never ever be able to cause a BSOD on W2K. Neither should a user-mode program (like setup.exe) However, on my machines, both do on rare occasions. The error is down deep in ntoskrnl and/or the ntfs file system driver -- I even did a full reinstall of the OS, yet I still get the BSOD sometimes. It's an MS bug, I am sure -- and I've noticed that it only happens when there are a lot of files being opened and closed rapidly. (For instance, when uninstalling lots of files in an old package, and installing lots of files in the new replacement package. Or when opening each .lst and rewriting them without \000 chars.) So, I don't blame Michael's script for my BSOD. I blame MS. But, once I limited the number of open/modified files per run (by running the script by hand on each letter of the alphabet) Michael's script DID successfully remove the \000 chars. --Chuck Robert Collins wrote: I'd already done a reinstall... can someone here validate Michael's script? (someone that tried the beta and has not reinstall those packages..) Rob
Now that the new setup is here...
there were two things I was going to do: 1) move gettext from the contrib directory to the latest directory -- and see if anybody barfs. 2) update bzip2 to the latest release -- which involves the grand library split thing (bzip2 - bzip2 + libbz2_0). However, the name libbz2_0 is incompatible with the old setup, and even 'cygcheck -c' gets confused prior to the cygwin-1.3.8 release. So, once I release libbz2_0, there's no going back to the old setup -- and everybody MUST update to the new setup or their installation will become very confused. Are we confident enough in the current setup.exe to do this? I ask because we've already yanked it down ONCE --Chuck
Re: setup all ok now....
Christopher Faylor wrote: On Wed, Mar 27, 2002 at 03:15:53PM +1100, Robert Collins wrote: I think we've done it. So Chuck, feel free to break everyone who's lagging behind :}.. Shouldn't we wait a day or two and let the new setup.exe work its way through the system? don't worry -- I saw the invisible sarcasm tags. I won't do anything rash. --Chuck
Re: How to create a ksh93 package...
Charles Wilson wrote: I suggest that the ksh-specific binaries should just go into /usr/bin/ksh/ or maybe /usr/libexec/ksh/ --Chuck
Re: Install-Info not found during installing CYGIN
Hack Kampbjørn wrote: Note this doesn't happen for wget. I've just checked. texinfo. Should be in base (IMHO). No! Anything that has info pages should depend on texinfo. That's what dependencies ARE FOR. Anything that installs .info files should have texinfo in its dependency list. If it doesn't, it's a bug, and the setup.hint should be fixed. (Yeah, it's possible some of my own packages violate this -- tell me and I'll fix 'em) --Chuck
Re: How to create a ksh93 package...
First, read my other message (sent immediately prior to this one) Christopher Faylor wrote: On Thu, Mar 28, 2002 at 11:21:22AM -0500, Fleischer, Karsten (K.) wrote: Would other executables that are not stub executables but alternative version to existing commands go there, too? ATT have own versions of dd, df, du, ed, expand, file, find, grep, od, pr, sed, sort, strings, etc. The other tools that have no Cygwin pendant, like cql, ditto, iffe, look, mamake, nmake, ratz, etc., they would go into /usr/bin? Nope -- if included at all, they should be segregated into /usr/libexec/ast/bin/* or wherever. We might eventually have our own 'look' package that wouldn't depend on cygksh*.dll -- and would therefore be preferable to non-ksh users (What? you mean I have to install the whole ast package just to get look?) I'm not interested in ATT's implementations of other utilities, actually. Why would we include those? If they are a requirement for ksh then I'm not sure I want ksh. I doubt they are required. (ksh the mega package sounds a lot like cygwin's old full.exe...). If ksh the mega package was split into about four components (or more), I think it would be manageable. I'd install the base ksh package and probably the -accel package, but not the other stuff... I'd suggest a simple ksh release without the plugins (or whatever they're called) and a separate package for the plugins. Yep. 'ksh' and 'ksh-accel' in my other message. If you have other executables that are not plugins then I think they will just be confusing and I really don't think I'm interested. If they are segregated into a separate directory that is not normally in the path, then only hardcore ksh'ers will set their path to get them, and those guys just want my ksh dammit. ksh-newbies like me -- I'll use my GNU tools thank you and keep /usr/libexec/ast/bin OUT of my path. Actually, if the plugins work differently from the stand-alone versions then I have reservations, too. As far as I understand, you have to explicitly enable each and every plugin. So only those that go thru the affirmative step of enabling them will ever run in to variant behavior -- if there is any. That's okay. It's all about freedom. I understand I just want my ksh -- think I just want my GNU tools on windows. == cygwin. It sure sounds like this should be one (or many) different packages, though, regardless. Yep. --Chuck
Re: more and base
Robert Collins wrote: Can we remove more from base? More is what? 3k? I'd love to have had it in the base install when I installed my cygwin - I support having a pager in the default install (which != base!!!) Base: cygwin is non-functional and completely broken(*) unless each and every package in Base is installed. 'more' is not a requirement for a functioning cygwin installation. Therefore it shouldn't go in Base. (Yes, there are a few other packages in Base that probably don't belong there, but that's an issue for another day). Now, a Base-only cygwin installation may be *useless* in the sense that sure, cygwin works -- but I can't do anything useful with it except mv files around, unless X Y and Z packages, which are not in Base, are installed. But useless is not the same as non-functional. (*) Yes, I know it's possible to configure certain specialized tasks with only (say) cygwin, sshd, and login (use c:\winnt\cmd.exe as the shell) -- but that's beyond the scope of the normal cygwin installation. I want the basic development environment too - since what use is the environment without gcc? Lots. Squid. Apache. SSH. CVS. None of these require gcc. Web development. perl programming. Python programming. Document creation (tex/xfig). --Chuck
Re: move texmf-* out of test?
Jan Nieuwenhuizen wrote: Hi, As tetex-beta-20001218-4 (now in curr) and texmf-*-2804-2 seem to work well together, can we remove the test marker from texmf? You are the maintainer; it is your decision. I thought there was a three weeks period for test; who's keeping track of that? I don't know of any hard rule about three weeks -- whatever you, as the maintainer, think is appropriate for your packages, is good. --Chuck
Re: Setup's download local cache storage directory!!!!
Earnie Boyd wrote: Also, the way that things are coded for choosing multiple mirror sites I could have the same file in more than one directory in the cache. Ouch, that bites. I don't think that will happen. Of all of the versions of project 'bob' on all of the download sites, only the newest one (as indicated by the various setup.ini's) will be downloaded to the local cache. So, if on Tuesday site X has bob-1.0-1 (and everybody else has bob-0.9), then only http%%%X%%% will contain a bob tarball. On Wednesday, site Y has bob-2.0 -- now, we download bob-2.0 tarball into http%%%Y%%%. Okay, so you now have two bob tarballs in the local cache -- but they are different versions. --Chuck
Re: TCP Wrappers
Corinna Vinschen wrote: Also, the name should be 'tcp_wrappers-7.6-REL...'; the package release version is missing. Agh! I'm sorry. I'm still not really back from vacation, apparently. Can I remove the package and keep the directory and setup.exe is still happy? Sure -- I've added and removed things from http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ all the time. the newly generated setup.ini will just not list tcp_wrappers. If a user has already installed tcp_wrappers, then their setup.exe will show the package, with 'Keep' action (or uninstall) -- but no reinstall or install. No probs. --Chuck
Re: TCP Wrappers
I've whipped up a repackaged version of your -src, that follows the approved conventions. Also, it uses a shell script to control building, and installs the man pages, header file, has a postinstall script to create /etc/hosts.allow/deny if they dont already exist, etc. I'll mail it to you privately, Prentis. The hooks are there to build/install the DLL version, but the allow_severity/deny_severity problem I referred to in my earlier message has to be fixed first, then you can uncomment the hooks in Makefile and in the shell script. --Chuck Prentis Brooks wrote: I am willing to look into this, it currently does not use libtool, so I have a lot of mods to make that happen, if I understood cgf right. I get cable modem today so I will be able to do more from home now ;) On Wed, 3 Apr 2002, Corinna Vinschen wrote: On Wed, Apr 03, 2002 at 09:06:55AM -0500, Prentis Brooks wrote: Hey Guys, what is the status of the TCP Wrapper upload? I got an email from Rob stating that he had problems getting to the files, I fixed the problem and responded, but no word since. I've uploaded it to the contrib area. I took the freedom to rename the package from tcp_wrappers_7.6... to tcp_wrappers-7.6..., just a dash instead of an underscore in front of the version number. Prepare to announce in a few hours. Btw., IMHO it would be really nice to get libwrap as a DLL in a near future. I'd like to link OpenSSH dynamically against tcp wrappers... Thanks, Corinna
Re: Now that the new setup is here...
Charles Wilson wrote: 1) move gettext from the contrib directory to the latest directory -- and see if anybody barfs. I did this. It's been many moons and many point releases (and a major release) since the last time we moved a package directory (ncurses, I think) from contrib to latest. Hopefully the changes in the internal logic -- and the greater reliance on setup.ini -- mean that this will cause little if any disruption. (Also, Robert asserts that it will cause no damage). So, a test (in preparation for cgf's possible reorg?) Besides, we have a several 'latest' packages (bison, grep, sharutils, texinfo, textutils, vim) that depend on libintl (gettext). The policy was that 'latest' stuff should depend only on other 'latest' stuff -- that was the rationale for moving ncurses, anyway. Okay, it's been a week -- and nobody seems to have noticed. That's promising. So, I'll go out on a limb here, and predict that cgf's massive reorg of the sourceware/cygwin dir structure won't upset setup (no pun intended). However, it may upset people who are anal about what setup does inside it's own localdir playground, and may lead to lots of duplication and unnecessary re-downloads -- which is bound to cause consternation. But those are social problems, not technical ones. 2) update bzip2 to the latest release -- which involves the grand library split thing (bzip2 - bzip2 + libbz2_0). However, the name libbz2_0 is incompatible with the old setup, and even 'cygcheck -c' gets confused prior to the cygwin-1.3.8 release. But I didn't do this. So, what's the opinion here? Should we cross the Rubicon? --Chuck
Re: SGML/XML packages available for testing
Gerrit P. Haase wrote: It is still dubious for me. Setup was able to fetch it from the server during 'Download only' with version number '1'. But when doing an install from local directory it wasn't offered anymore in the chooser. IIRC Setup is able to install packages even if there is no version in the name string (e.g. foo.tar.gz). Yes, but the problem here is that '-p4- is interpreted as another part of the name since it BEGINS with an alphabetic character. E.g. in tetex-beta-, the 'beta' is part of the name, not a version. So, setup is probably recording this as package: xml-base-p4 version: 1 release: none Perhaps renaming it to xml-base-4p-1 would help? Then, the parser would figure it out thus: package: xml-base version: 4p release: 1 Or am I just talking bull patties? --Chuck
Re: info: single install xfree86 + minimal cygwin?
Ian Burrell wrote: That is a list of subdirectories. But it won't work since the each package needs its own subdirectory. A better hiearchy would use the components from the package names. Hopefully, multiple levels of subdirectories will work. Yep. Subdirs work fine. For instance, the following are *currently* in use: cygwin/latest/ncurses/ cygwin/latest/ncurses/setup.hint cygwin/latest/ncurses/ncurses-5.2-?.tar.bz2 cygwin/latest/ncurses/ncurses-5.2-?-src.tar.bz2 cygwin/latest/ncurses/libncurses5/ cygwin/latest/ncurses/libncurses5/setup.hint cygwin/latest/ncurses/libncurses5/libncurses5-5.2-?.tar.bz2 cygwin/latest/ncurses/libncurses5/libncurses5-5.2-?.tar.bz2 cygwin/latest/ncurses/libncurses6/ cygwin/latest/ncurses/libncurses6/setup.hint cygwin/latest/ncurses/libncurses6/libncurses6-5.2-?.tar.bz2 cygwin/latest/ncurses/libncurses6/libncurses6-5.2-?.tar.bz2 Also, see gettext/libintl, readline/libreadline, etc. --Chuck
Re: info: single install xfree86 + minimal cygwin?
Robert Collins wrote: They were simple changes to the script I wrote to repackage the distributed archives. I'll try to write proper setup.hint files for all the packages. Cool. I'm unclear about how the -src packages (are/should be) handled, since there are a great many binary packages in XFree, but only a few original source packages. In the past, when multiple binary packages are generated from a single source package, we've done the following: ncurses-5.2-?-src.tar.bz2 contains the actual src dist for ncurses/libncurses, with cygwin patches, build scripts, etc However, building this -src generates two binary packages: ncurses-5.2-?.tar.bz2 libncurses6-5.2-?.tar.bz2 So, we create an empty libncurses6-5.2-?-src.tar.bz2 that contains only a single README that says go look over there, in ncurses-5.2-?-src.tar.bz2. Now, this works, and upset/setup are happy (every binary package has a src package) but it is hackish, ugly, and a pain to maintain. Is there a better solution? (Or can we discard the psuedo-src packages without repurcussion? Won't upset be upset by the bin without src problem?) --Chuck
Re: Now that the new setup is here...
Christopher Faylor wrote: On Wed, Apr 10, 2002 at 10:05:19AM +1000, Robert Collins wrote: But those are social problems, not technical ones. And ones I have little sympathy for. Setup is a technical tool, not a social one. It's not aimed at being the best downloader, only the best installer. Mirroring that handles directory relocation is a sitecopy style task... I'm not sure what reorg you were talking about but I've abandoned one of my plans to move everything into directories named after category names. That seemed like a lot of work for nothing. That was the one to which I was referring. The only thing I can think of to do is to get rid of latest/contrib and move to something else, like 'release', with all of the current directories located underneath. You mean like: cygwin/latest/zlib--- cygwin/release/zlib cygwin/contrib/libpng --- cygwin/release/libpng cygwin/xfree86/* --- cygwin/release/xfree86/ ? FWIW, I like this -- provided it won't cause problems... AFAIK, this won't cause any undue download activity will it? It will cause dumb mirroring tools (that cannot handle dir moves) to download all of the stuff from the new location. Wget, for instance, but probably also some of the official mirrors may hammer sourceware. Now, as far as setup doing unnecessary downloads merely because the dirs changed; no, I doubt it. But Robert can answer that question better than I. Regardless, I'm with Robert. setup was never designed to be a mirroring tool or a site deployment tool. If people are relying on a particular directory arrangement then, er, tough... Agreed. I have a pretty clever (IMHO; although, being based on wget it qualifies as dumb according to the definition above) wrapper around wget that I use to mirror the cygwin dist; I wonder if it would be useful to provide that somewhere (cgf's magic script area in the repository? Some other random useful stuff here repository?). Then, when people complain about setup, we say Here. Go use THIS tool, HERE, and don't try to fit the (setup) round peg into the (mirroring) square hole instead of Setup isn't a mirroring tool. Go away and use something else. Anything else. .OR.. does sourceware (or any of the official mirrors) provide anonymous rsync? That'd be way better... --Chuck
Re: Now that the new setup is here...
Robert Collins wrote: 2) update bzip2 to the latest release -- which involves the grand library split thing (bzip2 - bzip2 + libbz2_0). However, the name libbz2_0 is incompatible with the old setup, and even 'cygcheck -c' gets confused prior to the cygwin-1.3.8 release. But I didn't do this. So, what's the opinion here? Should we cross the Rubicon? Go. GO. GO! Okay -- I'll upload it once I get home. (Especially as Chris is advocating that the xfree folks use '_' in the names of their font packages, as a NONseparator --- it's that '_' which causes the incompatibility with the old setup.) --Chuck
Re: Now that the new setup is here...
Oooo, NOW I get it. I didn't understand that verpat: was a new field in setup.hint, PARSED by upset. It's perfectly clear in hindsight. Nevermind my earlier comments. Time for some sleep. --Chuck Christopher Faylor wrote: On Tue, Apr 09, 2002 at 10:24:18PM -0400, Charles Wilson wrote: Btw, I'm adding a new feature to upset: verpat: (.*-\d+dpi)(.*)(\.tar.bz2) ^^ ^^ ^ $1 $2 $3 $1 = prefix $2 = version $3 = suffix That won't help setup.ini-less installs much but, er... I don't grok regex's very well, but have we dropped support for tar.gz? .tar.gz is deprecated but that's kinda besides the point. If you wanted to use .tar.gz, you'd change the above to use .tar.gz. This is just a field for setup.hint so that we don't have to tell people to rename their scripts when there is a clear precedent for some version numbering that can't be automatically grokked. Like everything in setup.hint it should be used only when absolutely necessary. Also, how many special cases are we going to have? I understand wanting to keep xfree-fonts-75dpi-VER-REL instead of xfree-fonts_75dpi-VER-REL or xfree-fonts-dpi75-VER-REL but are we venturing down a path we don't really want to follow? I was just using this as an (incorrect, actually) example. If someone is comfortable with an underscore, that's fine. This would probably be more useful for something like contrib/tei-xml/tei-xml-p4-1-src.tar.bz2 . cgf
Re: [ANN] updated: apache-1.3.24-1
Corinna Vinschen wrote: On Wed, Apr 10, 2002 at 01:07:45PM +0200, Stipe Tolj wrote: Corinna, what about the announcement I posted to cygwin-announce ? It hasn't yet passed to the main lists, or have I missed it? Maybe you are peaking at me to take as long as I did for the package submission?! : Nope, I've no influence on the mailing list software. I've accepted the announcement and it's been send to the announce list. I don't know why it didn't make it to the cygwin list. Perhaps Chris has any insight. The cgywin-announce - cygwin gateway has been broken since Apr 7. According to Chris, cygwin-announce is getting trapped by spamassassin for various reasons. He's on the case, and hopefully the problem will be rectified soon. Until then, I'm going to send a duplicate copy of each announcement also to cygwin by hand. Excuse me, gotta do that for bzip2/libbz2_0 now... --Chuck
Re: Now that the new setup is here...
Robert Collins wrote: sitecopy is worth a look as a mirroring tool.. Sitecopy is intended for keeping a remote site in sync with the local master version (e.g. uploading your personal website to a server on which you have ftp access). It's isn't great for keeping a local mirror of a remote master. From sitecopy's website: But, sitecopy does not go to the FTP server and see what's there every time - this is the fundamental difference between sitecopy and mirror. This seems to be a problem, to me. Mebbe the 'mirror' perl script is the real way to go, here, rather than kludged-up scripts around wget...but then, 'mirror' only works with ftp site, and doesn't do http downloads (e.g. http://mirrors.rcn.net/) --Chuck
Re: [ANN] updated: apache-1.3.24-1
Stipe Tolj wrote: Ok, should I CC to cygwin by hand now?! No need to panic?! For the short term, yes. Once Chris fixes the gateway (or gets cygwin-announce out of spamassisin's black hole), then you can stop. For my part, I will wait a reasonable amount of time (15 mins?) after each of my posts appear on the cygwin-announce archive, and then if it hasn't been gatewayed, I'll resend to cygwin by hand. --Chuck
w32api update?
So I just updated my local mirror and discovered that somebody unpacked the entire w32api package onto sourceware: cygwin/latest/w32api/hold/w32api-1.3-2/* What's that all about? Shouldn't that stuff be kept out of the mirrored anonftp area? --Chuck
Re: w32api update?
Christopher Faylor wrote: On Wed, Apr 10, 2002 at 03:05:04PM -0400, Earnie Boyd wrote: Charles Wilson wrote: So I just updated my local mirror and discovered that somebody unpacked the entire w32api package onto sourceware: cygwin/latest/w32api/hold/w32api-1.3-2/* What's that all about? Shouldn't that stuff be kept out of the mirrored anonftp area? FWIW, I didn't create this. I'll check the area. Um, are you guys reading the cygwin mailing list? It should be obvious where this came from. Sorry -- I've gotten VERY trigger-happy with the mark-as-read/delete key on the main cygwin list. I just can't read every thread anymore... I saw the Directory structure : updates to mingw-runtime and w32api subject line, but didn't read the message -- and when my mirror script downloaded the unpacked version of w32api it didn't occur to me that the two things were related. Sorry for the noise. It was obviously a mistake on my part. I thought I'd deleted this directory. 'Kay. --Chuck
Re: cygwin port of Pine
Eduardo Chappa wrote: Hello, I am sending this message, because I have built Pine for cygwin, and I would like to know if the cygwin community is interested in distributing this package. I would maintain the package, that's not a problem at all. The Pine developers team also approves that I do this job (including redistribution of the binary), so the only missing part would be to know if you are interested in including this package. Below you can find a first version of the setup.ini file. If you are interested, the binary and source packages can be found at http://www.math.washington.edu/~chappa/cygwin/ I appreciate all feedback that you can provide. Thanks. category: Mail requires: crypt cygwin sdesc:A console E-Mail and Newsreader program, it includes Pico ldesc:Program for managing E-mail and News (USENET). It supports IMAP/(E)SMTP/POP3/NNTP/MIME. It includes the editor Pico curr: 4.44-1 First, the packages need to be renamed (note the '-' between 'pine' and '4.44'. Otherwise, you have version #1 of the 'pine4.44' package, not release #1 of version #4.44 of the 'pine' package. pine-4.44-1.tar.bz2 pine-4.44-1-src.tar.bz2 Second, you also need to add openssl to the requires: line, because the binary you include DOES need that DLL. Third, /usr/doc/Cygwin/pine4.44-1.README should be renamed (add a '-'), and /usr/doc/pine/ should probably be /usr/doc/pine-4.44/ ... Fourth, you might consider installing the man pages into /usr/man/man1, and other doco (doc/technotes/*, etc) into /usr/doc/pine-4.44/ Fifth, /usr/doc/pine4.44-1.patch doesn't belong in the binary package, it should be in the -src package. Recommend just copying it into your (already patched) -src like this: pine4.44-1/CYGWIN-PATCHES/pine4.44-1.patch and re-tarring the -src package. And Lastly, it's setup.hint, not setup.ini -- and you don't need to specify curr: 4.44-1. Other than that, sounds great! :-) --Chuck
Re: cygwin-doc
AFAIK, setup doesn't handle buildRequires. What I've been doing is to only list runtime dependencies for the binary package in the Requires: line, and then just mention the buildtime requirements in the readme. e.g. you don't list gcc/binutils in the Requires: line of every package. --Chuck Joshua Daniel Franklin wrote: Are you kidding? Cygwin-Man is the COOLEST! And would make a great mascot! Truth, Justice, and the American Way, my friend. Truth, Justice, and the American Way. Just think of it this way: instead of just some 'man' now we've got a 'doc'. Hmmm... I wonder if people are going to think this is a Cygwin version of DrWatson. OK, my last question was pretty obvious, but how about this one: The -src package here contains perl scripts. Is there any way to have (just) it 'depend' on perl? Or at least warn people beforehand that they'll need perl to remake the man pages? setup.hint: sdesc: Cygwin-specific man-pages for utilities and functions ldesc: The intro.1 and intro.3 man pages for Cygwin. Also includes autogenerated, man-formatted versions of the cygwin documentation available online at http://cygwin.com/cygwin-ug-net/using-utils.html and http://cygwin.com/cygwin-api/cygwin-api.html; category: Doc requires: cygwin man http://ns1.iocc.com/~joshua/cygwin/cygwin-doc-1.0-1.tar.bz2 http://ns1.iocc.com/~joshua/cygwin/cygwin-doc-1.0-1-src.tar.bz2 __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: libtool devel package still dll crippled.
Robert Collins wrote: Line 4476 of libtool.m4 setups allow_undefined to 'unsupported' for Cygwin. With --auto-import this is incorrect. It should set it to ...=' I *think* that's all I had to do to get the auto-import magic back on track :}. Chuck, I hate to be a bother, but is this enough for you? And do you have time to drop a patch back to the libtool list? (I don't have the CVS source checked out currently, so it is more efficient for you to do this... Well, I'm somewhat confused. I had already changed one allow_undefined for cygwin from '...=unsupported' to '...=' (line 2566). Didn't realize there was another one that applied. However, Ralf has the *opposite* problem: http://cygwin.com/ml/cygwin/2002-04/msg00362.html So I don't know WHAT to do. Ralf, does Robert's fix corrent your problem? Rob, does Ralf's fix correct your problem? --Chuck
Re: libtool devel package still dll crippled.
Robert Collins wrote: What Ralfs patch does is change allow_undefined_flag to no (as opposed to unsupported) and ?? what's the difference between ...=unsupported and ...=no and ...=? Shouldn't the SAME answer be given in all sections, with respect to whether allow_undefined_flag is a legal option? Granted, you can't build a DLL -- in any language -- if there are undefined symbols. But if I want to use libtool to build a static lib, I should be allowed to have undefined symbols. Fine -- by default cygwin-libtool asserts -no-undefined, so I need to override that. SO, allow_undefined_flag needs to be yes or supported or ...=, right? I don't understand how merely allowing a user to supply a flag hurts Ralf's KDE build -- unless he is (mistakenly) USING that flag (even though he shouldn't when building a DLL). And I REALLY don't want to disallow people from building static libs with undefined symbols using cygwin libtool. always_export_symbols to no (as opposed to yes). Now I'm not entirely sure what always_export_symbols does... Anyway, the reason there are multiple locations is that libtools guts are horrendous. There are folk putting time into factoring libtool to be a little bit more consistent and efficient though... The location I refer to us in AC_LIBTOOL_PROG_LD_SHLIBS, where as Ralf altered AC_LIBTOOL_LANG_CXX_CONFIG (which needed the alteration too - it effectively includes a copy of AC_LIBTOOL_PROG_LD_SHLIBS). Okay, my patch conflicts with his. Original CVS (20020316) (ignoring the always_export_symbols thing): _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported My patch: _LT_AC_TAGVAR(allow_undefined_flag, $1)= Ralf's patch _LT_AC_TAGVAR(allow_undefined_flag, $1)=no Again, the ...= came from you, Rob. So, what's the difference between ...= and ...=no or ...=unsupported (or ...=yes, for that matter). And which do we want/need? --Chuck
Re: libtool devel package still dll crippled.
Ralf Habacker wrote:
must be some way to prevent ld outputting the imported
symbols as
well as the exported symbols...
I'm using a special patched ld (based on the recent official
ld) which rejects exporting of all imported libs with a one
line patch
binutils/ld/pe-dll.c:234
/* Do not specify library suffix explicitly, to allow for
dllized versions. *
static autofilter_entry_type autofilter_liblist[] =
{
{ libgcc., 7 },
{ libstdc++., 10 },
{ libmingw32., 11 },
+// RH: workaround to allow using static libs in multiple
dlls
+ { .a, 2 },
{ NULL, 0 }
};
I really think this is a mistake. What if I want to build a shared
library using libtool, and it is composed of a number of object files
but also some convenience libs? And those convenience libs contains
symbols that I want to export?
Blindly refusing to export the symbols from anything that ends in .a is
a mistake, IMO. (I could be convinced that re-exporting symbols
obtained from a .dll.a is always bad, and should be screened out using
the brute-force, non-overrideable method in the patch above, but not .a)
--Chuck
Re: extra apache shared module DLLs
Stipe Tolj wrote: (i) package each module to an apache-mod_foobar-X-Y.tar.bz2 binary package and distribute through the standard Cygwin setup.exe (setting setup.hint to require the apache-1.3.x base package) This one. That's the way linux distros do it -- they have apache_mod_foobar...rpm, or even mod_foobar...rpm. So, I think we ought to have apache_mod_foobar...tar.bz2 or mod_foobar...tar.bz2. --Chuck
Re: 'release' directory now active
Christopher Faylor wrote: The affected subdirectories were readline/*, texmf/*, libpng/* . And probably ncurses/* bzip2/*. Anyway, I've checked the following: release/libpng/* release/readline/* release/ncurses/* release/bzip2/* and they all look fine. However, contrib/libpng , contrib/readline, latest/ncurses, and latest/bzip2 do not exist. Is that okay -- it appears that setup.ini only references the files within release/*, but still... Also, cygwin/setup.exe is still a symlink to cygwin/latest/setup.exe. Is that what you want? --Chuck
Re: enscript-1.6.3-2 bugfix release
Gerrit -- 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: if [ -f /etc/enscript.cfg ] ; then OUTFILE=/etc/enscript.cfg.new else OUTFILE=/etc/enscript.cfg fi cat EOF $OUTFILE ...text of your enscript file EOF --Chuck Gerrit P. Haase wrote: Hallo, I found some bugs in the first package, the postinstallscript was wrong and the /etc/enscript.cfg was missing. I fixed also some other problems with DESTDIR usage in the Makefile templates which were the cause of the .cfg bug: Corinna, woul;d you please fetch it from my server (only temporary up, now running Apache on Cygwin as service;): http://62.138.63.18/cywgin/enscript/ Gerrit
Re: xfree packages
I can do this -- but what was the outcome of the package name argument? Was it xfree-foo-4.2.0-1.tar.bz2 or xfree86-... or XFree86-...? I'll need to modify the znark script accordingly. --Chuck Christopher Faylor wrote: On Wed, Apr 10, 2002 at 01:22:52PM -0700, Ian Burrell wrote: Christopher Faylor wrote: Yes, please post the setup.hint files that you used. Check out http://www.znark.com/cygwin/. It doesn't include the archive files; my web account doesn't have the bandwidth or quota for them. To generate the packages, download the *.tgz files from cygwin/xfree/binaries/4.2.0 If someone wants to repackage these files into .bz2 format, I'll upload them to a temporary area on sourceware. cgf
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?
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?
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?
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
Re: strange source packaging?
Corinna Vinschen wrote: I'm talking about style 2. I'm using it for my packages. I don't see a need that the Cygwin package needs the patch from the original version. The pristine source is available elsewhere. We're responsible for the Cygwin version. In the long run the maintainer of a package should try to get his/her changes back into the main trunk anyway (I know, I never did that for inetutils). So the whole point is to get rid of the extra Cygwin patch and to offer the pristine sources anyway since they already contain the Cygwin patches. E.g the openssh sources are the original sources, just repacked to untar into the correct source dir according to our standards. I don't buy that everything should go into the main trunk. Do you really thing that the cygwin-specific readmes should be (or would be) incorporated into the upstream versions of all these project? or the postinstall.sh scripts? Even after all the substantive, code-based changes are accepted by the upstream folks, there are still a number of changes in the average cygwin package that just don't belong in the main trunk. Now, if you're arguing that those non-trunk-worthy changes should just be shipped -- without a reversal patch -- then fine, let's have that discussion. (For my part, it's academic; I prefer the rpm-like ship orig source tarball + patch + script (spec file...) style, anyway.) The argument for style 1 against style 2 is this: Does anybody, other than Chris, have ANY idea what the differences between gnu-gcc-2.95.3 and cygwin-gcc-2.95.3-5 are? How many files are changed, and how significantly? What options were used to build the cygwin binary package? Before Chris reluctantly picked up the duty, did anyone other than Mumit have a clue about the minutia of those differences (worse yet, Mumit's version was a fork of the cgywin version, which itself was a fork of the egcs version, which was a fork of the official gnu version...) Granted, gcc is pretty much the 'worst possible case' example, but the end result was that after Mumit dropped out of sight, it was over a year before we had another gcc update. (It was 18 months before some of the dll-building capabilities in binutils that Mumit had working in HIS version, were finally recreated/restored and pushed upstream into the main binutils trunk). Forcing maintainers to generate and include an actual diff in each -src tarball for each new release serves as a kind of reminder: here's how much stuff still needs to be pushed upstream. Heck, I evaluate my success with each release based on how much smaller that diff is...see ncftp... Sure, this kind of thing is the maintainer's purview; perhaps it's too authoritarian to micromanage and say you must do it this way -- OTOH, the size of these patches also serve to advertise to the community how well cygwin support is getting mainstreamed. BUT...having said all of that, I reiterate: I prefer the style 3 over EITHER style 1 or style 2 -- and the question here seems to be document styles 1,2,3, or document 1,(!2),3 or (!1),2,3 So I win, regardless. I really don't have a horse in the 1,2 vs. 1,(!2) vs. (!1),2 race. So, I've made my argument for 1,(!2) but won't defend it; I'll wait for a consensus to emerge and will document the result. --Chuck P.S. geez, I really didn't mean to restart that old November thread...
Re: strange source packaging?
Robert Collins wrote: And the GPL requires us to document the changes made - if we have the patch pre-applied, with no reverse patch, then this isn't the case. Asking folk to go elsewhere to get that 'pristine' source puts the onus on the upstream to make that available, which we can't do - for the same reason that folk that ship cygwin1.dll need to host their own copy of the source. At the risk of wading into yet another GPL argument -- I don't think the GPL requires documentation of the entire provenance of changes relative to some external source; it's just the polite thing to do. All the GPL requires is that you distribute THE source that YOU used to build THE binary YOU distribute. That's it. --Chuck
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: we have to make XFree86-base-src the package that contained the full source archive. Hmm. Yes. I think this would work. That might be the best solution. In fact, it may be a nice trend setter. I think setup.exe needs a little work before doing this, but it's a good direction. (i.e. setup.exe should have a view to only show src packages, and a view to only show binaries - to avoid confusing folk). (Think apt-get source vs apt-get install). How about my 'external-src: ' idea? setup hint for XFree86-[anything but base]-... external-src: XFree86-base setup hint for XFree86-base- no external-src tag and both upset and setup will understand this and do the right thing: upset needs to, for those pkgs with an external-src in their setup hint, find the -src tarball for the indicated package, whose VER-REL string matches the package-under-consideration, and put THAT into setup.hint, so (for the fonts package) you get install: release/xfree/xfree86-fonts/XFree86-fonts-4.2.0-2.tar.bz2 source: release/xfree/xfree86-base/XFree86-base-4.2.0-2-src.tar.bz2 [prev] install: release/xfree/xfree86-fonts/XFree86-fonts-4.2.0-1.tar.bz2 source: release/xfree/xfree86-base/XFree86-base-4.2.0-1-src.tar.bz2 Also, setup must do the following (even without new 'views' and whatnot) 1) all XFree86-...- indicate that src is available (that is, 'presence of a -src tarball' == 'no -src tarball but external-src: marker in setup.hint' 2) clicking on any one (or multiple) of the 'src' checkboxes in setup will trigger a download (and only one download) of the actual XFree86-base-4.2.0-1-src.tar.bz2 package - Later, we can get even fancier, and allow the specification of multiple -src packages...then the monolithic 'XFree86-base-4.2.0-1-src.tar.bz2' can be split into the stuff that cygwin-xfree doesn't change and the stuff that changes frequently (e.g. .../hw/xwin). e.g. setup hint for XFree86-[anything but base]-... external-src: XFree86-base setup hint for XFree86-base- no external-src tag extra-src: XFree86-base2 in release/xfree/xfree86-base/ XFree86-base-4.2.0-1.tar.bz2 XFree86-base-4.2.0-1-src.tar.bz2 XFree86-base2-4.2.0-1-src.tar.bz2 But that (or something like it) can be later - --Chuck P.S. Chris, where'd upset go? the current version used to be in htdocs, but it's gone now. AND, the old version which lived in cinstall/temp, is still there -- and you said you were going to remove it. Did you remove the wrong one?
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 20, 2002 12:59 PM Also, setup must do the following (even without new 'views' and whatnot) Setup should already do that, why not make a test setup.ini and see what happens :]. It's all data driven and there is no requirement for -src packages to follow the same name as the base. Whaddaya know. It works. point setup.exe here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ There are 3 packages, bob, bobx, and boby. only bob has a -src package, the other two have source: lines that explicitly specify bob's source package. It seems to work perfectly -- with only a single niggle: if you select the source for more than one of [bob|bobx|boby], then it is downloaded only once (good) but is unpacked three times. This isn't a terrible thing, but it is a waste of effort If you play around with this, you can clean up by uninstalling the binary packages, and deleting the file /usr/src/bob.file.src. (Or, you can delete /bob.file, /bobx.file, /boby.file, and /usr/src/bob.file.src, and remove the bob, bobx, and boby entries from /etc/setup/installed.db) So, except for the niggle above, if upset were modified to allow the external-src: keyword, then multiple-binary-packages from one -src package would work! (and the niggle isn't a show stopper). --Chuck
New versions of autoconf, automake
On 3/25, I uploaded new versions of autoconf-devel and automake-devel, but I didn't mark them current because Corinna was on vacation. Corinna, any objections to removing the 'test' designation from autoconf-devel-2.53-1 and automake-1.6-1 ? (Be sure to read the previously posted announcements first... autoconf-2.53-1 http://cygwin.com/ml/cygwin/2002-03/msg01385.html automake-1.6-1 http://cygwin.com/ml/cygwin/2002-03/msg01386.html --Chuck
Re: strange source packaging?
Charles Wilson wrote: 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. ;-) Okay, as promised: documentation. If you don't want to unpack the tarball and look at it, go here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/setup.html http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/generic-build-script http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/generic-readme Comments? I hope I covered all the bases, but I may have missed something. I presented two different options for -src packaging... --Chuck src-packages.tar.bz2 Description: Binary data
Re: strange source packaging?
Can we get a diff for the HTML page? Okay --- setup-old.html Sun Apr 21 03:03:18 2002 +++ setup.html Sun Apr 21 03:01:44 2002 @@ -21,9 +21,9 @@ border=0 usemap=#topbar alt=/a/center !-- == -- -!---- -!--Left Sidebar -- -!---- +!-- -- +!--Left Sidebar -- +!-- -- table align=left border=1 cellspacing=0 cellpadding=8 width=20% bgcolor=ee trtd bgcolor=ee valign=top @@ -71,11 +71,11 @@ pThis document is intended for people who post packages to sources.redhat.com, and thus need to make them available through the -standard Cygwin setup program. This documents the syntax of the +standard Cygwin setup program. This documents the syntax of the setup.ini file, the program that automatically generates it on a regular basis, the layout required for packages, and the related policies to ensure good behaviour from the setup.exe program./p pSetup depends -on certain conventions being followed. If they are not followed, bad +on certain conventions being followed. If they are not followed, bad things may happen to the users of setup.exe. Where a convention can be ignored, should circumstances warrent, this document will specify that./p pThe mailing list [EMAIL PROTECTED] is the correct @@ -94,11 +94,11 @@ /ul h2a id=naming name=namingPackage file naming/a/h2 -p Package naming scheme: use the vendor's version plus a suffix for +p Package naming scheme: use the vendor's version plus a release suffix for ports of existing packages (i.e. bash 2.04 becomes 2.04-1, 2.04-2, etc, until bash 2.05 is ported, which would be 2.05-1, etc). Some packages also use a YYMMDD format for their versions, e.g. binutils-20010901-1.tar.bz2. -The first release of a package should have a -1 suffix./p +The first release of a package should have a -1 release suffix./p pA complete package currently consists of three files:/p ul @@ -107,18 +107,18 @@ lia setup.hint file /ul -pBinary tar files are named package-version.tar.bz2. They generally +pBinary tar files are named package-version-release.tar.bz2. They generally contain the executable files that will be installed on a user's system plus any auxilliary files needed by the package. See the a href=#package_contentsmaking packages/a section below for more details on how to generate a binary tar file./p -pSource tar files are named package-version-src.tar.bz2. Source tar files -should contain the source files needed to rebuild the package. While +pSource tar files are named package-version-release-src.tar.bz2. Source tar files +should contain the source files needed to rebuild the package. While installing these files is optional under setup.exe, the inclusion of a source tar file is part of the totality that makes up a cygwin package -and so, these files are emnot/em optional. See the a -href=#package_contents making packages/a section below for more +and so, these files are emnot/em optional. See the a +href=#srcpackage_contents making packages/a section below for more details on the contents of a -src tar file../p pThe setup.hint file is discussed a href=#setup.hintbelow/a. @@ -126,22 +126,31 @@ h2a id=sources.redhat.com name=sources.redhat.comAutomatic setup.ini generation on sources.redhat.com/a/h2 pA script runs on sources.redhat.com which collects information from -(currently) the ttlatest/tt and ttcontrib/tt directories in the +(currently) the ttrelease/tt directory in the ftp download area. Information from subdirectories of these directories is parsed to automatically generate the default a href=#setup.ini setup.ini/a file which is used by the cygwin setup.exe program for installation control. If you are responsible for maintaining a cygwin package, it is important that you understand how this process works./p -pPackages are grouped by directory under ttlatest/tt or -ttcontrib/tt. The directory name is typically the same as the -package name. For example, the ttboffo/tt package will live in the -ttboffo/tt subdirectory. Exceptions to this rule are historical. -All new packages will follow the rule of package name == directory name. +pPackages are grouped by directory under ttrelease/tt. The directory +name is the same as the package name. For example, the ttboffo/tt package +will live in the ttboffo/tt subdirectory. Exceptions to this rule are +historical. All new packages will follow the rule of package name == +directory name. However, for closely related groups of packages, it is acceptable +to use a heirarchical tree under ttrelease//tt: +prett +
Re: [ANNOUNCEMENT] cygwin/xfree86 setup.exe packages available for comments and testing
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 21, 2002 8:33 AM if you select the source for more than one of [bob|bobx|boby], then it is downloaded only once (good) but is unpacked three times. This isn't a terrible thing, but it is a waste of effort This won't change anytime soon. Long term we'll have the concept of a source package - as opposed to a src attribute of an existing package. This will require setup.ini changes to represent properly, so I want all the kinks out first... Like I said, NOT a showstopper. you ONLY see this behavior if you click the src checkbox for multiple packages that all share the same source. It's only downloaded once. When setup is done, you have the source. Behind the scenes, that source package gets installed multiple times. Big deal. IMO, if upset gets the ability to do the right thing with an 'external-src:' directive in setup.hint, then everything necessary for multiple-bin/single-src packages would be in place. --Chuck --Chuck
