Re: [setup PATCH] Add some log msgs to installOneSource
On Wed, 2003-07-16 at 20:11, Max Bowsher wrote:
This isn't an error. It's simply the automagic compressed archive
detection.
The message could be clearer, but it is valuable info to know whether the
docompress or the dearchive failed. How about:
if (tmp) {
/* Existing code */
} else {
if (!tmp2) { log (Decompression failed. Maybe source not compressed?; }
else { log (De-archiving failed.);
}
Is that ok?
+}
+}
+ else
+{
+ log(LOG_PLAIN, String(Failed to open: ) + source.Cached() );
}
this is redundant: the if (thefile) check covers this case, as thefile
is null on error.
Yes, but the additional message shows you *how* it failed.
Actually it doesn't *add* any value in the code path.. EIther both log
messages trigger, or neither does. You can consolidate the logging to
one place easily.
i.e.
if (thefile) {
...
}
--
if (!thefile) {
if (tmp2)
log (unable to get an archive from compressed file);
else if (tmp)
log (corrupt compression format or corrupt archive format in
uncompressed file);
else
log (could not open source file);
} else {
...
}
Rob
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
signature.asc
Description: This is a digitally signed message part
setup suggestion: obsolete
Sorry if I'm missing something already implemented but this idea just occured to me and I thought I should write it down before I forget it again. Currently, if a new package foobar is build which overrides package foo, some extra work is needed, e.g. creating an empty foo package with a new version number or similar stuff. The idea is this: Create a new setup.hint entry called `obsoletes:', which allows to override old packages liek this: @ foobar sdesc: Brand new package category: Utils requires: cygwin obsoletes: foo As a result, when somebody chooses to install the new package foobar, the package foo would automatically get deinstalled. A good example is IMHO the not yet existing coreutils package. Coreutils is the union of the GNU fileutils, sh-utils, and textutils packages. It contains all tools of the former three packages so creating a coreutils package would be very easy if setup allows this: @ coreutils sdesc: GNU core utilities category: Base requires: cygwin libintl2 ... obsoletes: fileutils sh-utils textutils Do we have something like that already? Or would that be hard to implement? Any other comment besides go away? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: setup suggestion: obsolete
On Wed, 2003-07-16 at 22:28, Corinna Vinschen wrote: Do we have something like that already? Or would that be hard to implement? Any other comment besides go away? Replaces: We already parse this, but the logic isn't implemented. It's on my eventual TODO. Difficulty? Haven't gotten close enough to estimate that. Probably not hard. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
Re: setup suggestion: obsolete
On Wed, Jul 16, 2003 at 10:35:41PM +1000, Robert Collins wrote: Replaces: Ah, cool. We already parse this, but the logic isn't implemented. It's on my eventual TODO. Difficulty? Haven't gotten close enough to estimate that. Probably not hard. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
TEST: tcsh-6.12.00-6
Hi, I've uploaded the 64 bit version of tcsh, 6.12.00-6, marked as test. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
TEST: tin-1.6.0-1
Hi, I've uploaded the 64 bit version of tin, 1.6.0-1, marked as test. This is an entirely new version of tin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
TEST: vim-6.2-2
Hi, I've uploaded the 64 bit version of vim, 6.2-2, marked as test. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: 1.5.0 Test packages status
Elfyn, On Tue, Jul 15, 2003 at 06:50:21PM +0100, Elfyn McBratney wrote: Current available 'test' packages (version) cygipc2.00-2 cygutils 1.2.0-1 expat 1.95.6-2 gettext 0.12.1-1 libiconv 1.9.1-1 libpng101.0.15-2 libpng12 libpng 1.2.5-2 libtool-devel 1.5-2 openssl 0.9.7b-2 openssh3.6.1p1-3 rsync2.5.6-2 xerces-c 2.3.0-3 any chance to get this together with the list of *not* available packages in the first place? I know that looks like redundant information but I have that feeling it's easier to recognize this as a oh, isn't that *my* package in that list which needs some care?, if you know what I mean... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
[setup PATCH] Add log msgs to Installer::installOneSource (Take 2)
Index: ChangeLog
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/ChangeLog,v
retrieving revision 2.367
diff -u -p -r2.367 ChangeLog
--- ChangeLog 11 Jul 2003 22:48:13 - 2.367
+++ ChangeLog 16 Jul 2003 13:13:00 -
@@ -1,3 +1,8 @@
+2003-07-16 Max Bowsher [EMAIL PROTECTED]
+
+ * install.cc (Installer::installOneSource): Add some log messages, as
+ a stopgap until we add some proper error handling here.
+
2003-07-10 Jeremy White [EMAIL PROTECTED]
* mount.cc, root.cc, site.cc: Make StringOptions required,
Index: install.cc
===
RCS file: /home/max/cvsmirror/cygwin-apps-cvs/setup/install.cc,v
retrieving revision 2.61
diff -u -p -r2.61 install.cc
--- install.cc 25 Mar 2003 20:57:13 - 2.61
+++ install.cc 16 Jul 2003 13:14:37 -
@@ -340,6 +340,16 @@ Installer::installOneSource (packagemeta
total_bytes_sofar += package_bytes;
}
+ else
+{
+ if (!tmp) log(LOG_PLAIN, String(Failed to open file: )
+ + source.Cached() );
+ else if (!tmp2) log(LOG_PLAIN,
+ String(Failed to initialize decompressor or archive extractor:
)
+ + source.Cached() );
+ else log(LOG_PLAIN, String(Failed to initialize archive extractor:
)
+ + source.Cached() );
+}
progress (0);
Re: 1.5.0 Test packages status
On Wed, 16 Jul 2003, Corinna Vinschen wrote: Elfyn, On Tue, Jul 15, 2003 at 06:50:21PM +0100, Elfyn McBratney wrote: Current available 'test' packages (version) cygipc2.00-2 cygutils 1.2.0-1 expat 1.95.6-2 gettext 0.12.1-1 libiconv 1.9.1-1 libpng101.0.15-2 libpng12 libpng 1.2.5-2 libtool-devel 1.5-2 openssl 0.9.7b-2 openssh3.6.1p1-3 rsync2.5.6-2 xerces-c 2.3.0-3 any chance to get this together with the list of *not* available packages in the first place? I know that looks like redundant information but I have that feeling it's easier to recognize this as a oh, isn't that *my* package in that list which needs some care?, if you know what I mean... Yep, OK. Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: 1.5.0 Test packages status
On Wed, Jul 16, 2003 at 02:23:47PM +0100, Elfyn McBratney wrote: On Wed, 16 Jul 2003, Corinna Vinschen wrote: any chance to get this together with the list of *not* available packages in the first place? I know that looks like redundant information but I have that feeling it's easier to recognize this as a oh, isn't that *my* package in that list which needs some care?, if you know what I mean... Yep, OK. Swell, thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: naim review (was Re: Pending package status (14 Jul 2003))
On 2003-07-16T09:31+0100, Max Bowsher wrote:
) OK, I've found the problem. Setup's integrated tar code is rather
) oversensitive to magic numbers. Specifically, your naim tarball does not
) contain ustar\040\040\0 at offset 257. Repacking with GNU tar is the short
) term fix. Long term, maybe setup could become more tolerant in its tar
) code - PTC. What kind of tar did you pack these packages with?
It was actually packaged on a Cygwin system, using its GNU tar 1.13.25.
tbz2: CYGWIN-PATCHES/dist
mkdir ${top_builddir}/tmp
make install-strip DESTDIR=`cd ${top_builddir}/tmp; pwd`
(cd ${top_builddir}/tmp; $(AMTAR) cof - --owner 0 --group 0 usr | bzip2 -9
-c ../${pkgtbz2})
rm -rf ${top_builddir}/tmp
The -o option I pulled from elsewhere in automake's generated files: all
automake-generated tar files (including the source tarballs generated by
make dist) will be in that format as well:
-o, --old-archive, --portability write a V7 format archive
I believe it's done for compatibility with older versions of tar, and I
believe that is the format Solaris' tar uses as well. It's ironic that using
-o breaks setup.exe's tar routines :)
For the next release, should I remove the -o? Also, is there a way to run
setup.exe against a local file (not in any setup.ini) to check whether setup
can install the package? I'm thinking that could be the last step in the
packaging procedure, before uploading to a webserver/submitting to
cygwin-apps.
Thanks, all,
--
Daniel Reed [EMAIL PROTECTED] http://shell.n.ml.org/n/
It is so easy to miss pretty trivial solutions to problems deemed complicated. The
goal of a scientist is to find an interesting problem, and live off it for a while.
The goal of an engineer is to evade interesting problems :) -- Vadim Antonov [EMAIL
PROTECTED] on NANOG
http://site.n.ml.org/download/20030715233159/naim/naim-0.11.5.9.cyg11.tar.gz
Re: naim review (was Re: Pending package status (14 Jul 2003))
On Wed, 16 Jul 2003, Max Bowsher wrote: OK, I've found the problem. Setup's integrated tar code is rather oversensitive to magic numbers. Specifically, your naim tarball does not contain ustar\040\040\0 at offset 257. Repacking with GNU tar is the short term fix. Long term, maybe setup could become more tolerant in its tar code - PTC. What kind of tar did you pack these packages with? Thanks for looking into it, Max. I have re-created the archives using GNU tar, so we'll see how it goes. Daniel, mirrors .rcn.net will update at about ~15:30, at which time we should know if it worked. If so... Please send an announcement in a couple of hours :-) Thanks, Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: SetupXP
Hi Gary, More stuff to decrease the size of your diff: I think you are only supposed to update Copyright comments when you actually change something in a file? Unless I am wrong, please drop your copyright-comment-only change to splash.h from your local mods. Please rm ChangeLog.window.txt, since the changes detailed there are already merged. Please do a cvs update. The following files are unmodified in your local copy, but have changes in the repository: ChangeLog, Makefile.am, GUIDELINES, .cvsignore, README, RECTWrapper.h (In the case of GUIDELINES and .cvsignore, the change is the fact they have been created.) The following files have local modifications and changes in the repository. CVS can successfully merge them without conflicts (I have tested): proppage.h, propsheet.h Please rm COPYING INSTALL. They are junk from an ancient automake run. Please add the following to your generated files filter when making your tarball: inilex.cc iniparse.cc iniparse.h res.aps setup_version.c Setup.aep Setup.aew Setup.dev Setup.dev.bak Setup.layout Thanks, Max.
Re: TEST(1.5.0): uw-imap 2002d-2 and c-client 2002d-2
On Tue, 15 Jul 2003, Abe Backus wrote: This is identical to the uw-imap 2002d-1 just announced, except that it's built against the test openssl-devel and cygwin 1.5.0. Uploaded. Please send an announcement in a couple of hours. Thanks, Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: naim review (was Re: Pending package status (14 Jul 2003))
Daniel Reed wrote:
On 2003-07-16T09:31+0100, Max Bowsher wrote:
) OK, I've found the problem. Setup's integrated tar code is rather
) oversensitive to magic numbers. Specifically, your naim tarball does not
) contain ustar\040\040\0 at offset 257. Repacking with GNU tar is the
short
) term fix. Long term, maybe setup could become more tolerant in its tar
) code - PTC. What kind of tar did you pack these packages with?
It was actually packaged on a Cygwin system, using its GNU tar 1.13.25.
tbz2: CYGWIN-PATCHES/dist
mkdir ${top_builddir}/tmp
make install-strip DESTDIR=`cd ${top_builddir}/tmp; pwd`
(cd ${top_builddir}/tmp; $(AMTAR) cof - --owner 0 --group 0 usr |
bzip2 -9
-c ../${pkgtbz2}) rm -rf ${top_builddir}/tmp
The -o option I pulled from elsewhere in automake's generated files: all
automake-generated tar files (including the source tarballs generated by
make dist) will be in that format as well:
-o, --old-archive, --portability write a V7 format archive
I believe it's done for compatibility with older versions of tar, and I
believe that is the format Solaris' tar uses as well. It's ironic that
using
-o breaks setup.exe's tar routines :)
For the next release, should I remove the -o?
Yes, please.
Also, is there a way to run
setup.exe against a local file (not in any setup.ini) to check whether
setup
can install the package? I'm thinking that could be the last step in the
packaging procedure, before uploading to a webserver/submitting to
cygwin-apps.
Sort of. If you really want a full test environment, you can set up upset on
your local machine, and run it to make a setup.ini for your test packages. I
maintain a small tree alongside my mirror of release/, containing self-built
replacements for a few cygwin packages, packages I am reviewing, and
packages so old they have fallen out of setup.ini, that I might want to
reinstall.
Max.
Re: SetupXP
On Thu, 2003-07-17 at 00:46, Max Bowsher wrote: Hi Gary, Please add the following to your generated files filter when making your tarball: inilex.cc iniparse.cc iniparse.h res.aps setup_version.c Setup.aep Setup.aew Setup.dev Setup.dev.bak Setup.layout Don't tarball by hand. Use make release. Rob -- GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt. signature.asc Description: This is a digitally signed message part
/etc/mlock.exe (was Re: TEST(1.5.0): uw-imap...)
On Wed, 16 Jul 2003, Elfyn McBratney wrote: On Tue, 15 Jul 2003, Abe Backus wrote: This is identical to the uw-imap 2002d-1 just announced, except that it's built against the test openssl-devel and cygwin 1.5.0. Abe, I noticed this a while ago and it didn't register. Sorry to do this right after a release, but does mlock.exe really need to be in /etc ? Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
1.5.0 Test packages status (issue 2)
Current available 'test' packages (version) ash 20020731-2 bash2.05b-11 cygipc2.00-2 cygutils 1.2.0-1 cpio 2.5-2 expat 1.95.6-2 file 4.03-1 fileutils 4.2-2 gawk 3.1.3-2 gettext 0.12.1-1 libiconv 1.9.1-1 libpng101.0.15-2 libpng12 libpng 1.2.5-2 libtool-devel 1.5-2 ncurses5.3-2 openssl 0.9.7b-2 openssh3.6.1p1-3 readline 4.3-3 rsync2.5.6-2 sed 4.0.7-2 tcsh 6.12.00-6 tin 1.6.0-1 uw-imap 2002d-2 vim6.2-2 xerces-c 2.3.0-3 zlib 1.1.4-2 Awaiting 'test' packages ELFIO a2ps agetty apache astyle autoconf automake bc binutils bison byacc bzip2 ccache ccdoc chkconfig cmake compface cron crypt ctags curl cvs db dejagnu diff diffutils doxygen dpkg ed emacs enscript exim expect fetchmail figlet findutils flex fortune gcc gcc2 gdb gdbm ghostscript gnugo gnupg gperf grace grep groff gsl guile gzip indent inetutils ioperm irc jbigkit jgraph jpeg keychain less libungif libxml2 libxslt lilypond links login lynx m4 make man mc more mt mutt naim nano nasm ncftp netcat opengl par patch patchutils pcre pdksh perl pine pinfo pkgconfig popt postgresql procmail procps proftpd python rcs rebase robots rpm ruby rxvt sed sh-utils sharutils splint squid ssmtp stunnel sunrpc swig sysvinit tar tcltk tcp_wrappers tetex texinfo texmf textutils tidy tiff ttcp ucl units unzip upx wget xinetd xpm-nox zip zsh
Re: 1.5.0 Test packages status (issue 2)
On Wed, 16 Jul 2003, Jan Nieuwenhuizen wrote: Elfyn McBratney [EMAIL PROTECTED] writes: Missed termcap Ok [... going over my dependencies again] and what about XFree86-bin? The Cygwin/XFree people manage their own releases and will (most likely) be performing tests after this period. and libintl is part of the (already ported to 1.5) gettext Ok, of course. Also, some of the Awaiting... lot might not need to be re-linked, but as I don't use them, I'm not too sure and,I didn't plan on nm'ing the day away. ;-) :-) I was just thinking: how am I going to figure out what libraries are already available for 1.5, and there was your message. Most useful. Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: naim review (was Re: Pending package status (14 Jul 2003))
On 2003-07-16T09:31+0100, Max Bowsher wrote: ) Daniel Reed wrote: ) Any headway on this? I see naim's version listed as 0.11.5.9-cyg1-1 now, ) still get the same behaviour. Off the top of my head, I'm wondering if the ) symlinks in the tarball could be confusing something. If I try ftp://mirrors.rcn.net/ now, when it gets to the Downloading... stage it immediately displays a dialog box stating Download Incomplete. Try again? If I try a mirror like ftp://archive.progeny.com/, I still have the Nothing needed to be installed message. -- Daniel Reed [EMAIL PROTECTED] http://shell.n.ml.org/n/ I don't believe in making something user friendly just for the sake of being user friendly, though; if you're decreasing the users' available power, you're not really being all that friendly to them. http://site.n.ml.org/download/20030715233159/naim/naim-0.11.5.9.cyg11.tar.gz
Re: naim review (was Re: Pending package status (14 Jul 2003))
On Wed, 16 Jul 2003, Daniel Reed wrote: On 2003-07-16T09:31+0100, Max Bowsher wrote: ) Daniel Reed wrote: ) Any headway on this? I see naim's version listed as 0.11.5.9-cyg1-1 now, ) still get the same behaviour. Off the top of my head, I'm wondering if the ) symlinks in the tarball could be confusing something. If I try ftp://mirrors.rcn.net/ now, when it gets to the Downloading... stage it immediately displays a dialog box stating Download Incomplete. Try again? If I try a mirror like ftp://archive.progeny.com/, I still have the Nothing needed to be installed message. OK, can you re-create the tarballs without the options you stated and send me an URL? Elfyn -- Elfyn McBratney, EMCB | http://www.nongnu.org/wwwauth/ http://www.emcb.co.uk | http://www.emcb.co.uk/webauth/ [EMAIL PROTECTED] | wwwauth-users AT nongnu DOT org
Re: naim review (was Re: Pending package status (14 Jul 2003))
I noticed that the release directory from mirrors.rcn.net is empty just now. Earnie. Daniel Reed wrote: On 2003-07-16T09:31+0100, Max Bowsher wrote: ) Daniel Reed wrote: ) Any headway on this? I see naim's version listed as 0.11.5.9-cyg1-1 now, ) still get the same behaviour. Off the top of my head, I'm wondering if the ) symlinks in the tarball could be confusing something. If I try ftp://mirrors.rcn.net/ now, when it gets to the Downloading... stage it immediately displays a dialog box stating Download Incomplete. Try again? If I try a mirror like ftp://archive.progeny.com/, I still have the Nothing needed to be installed message.
RE: /etc/mlock.exe
Good question. I don't know a heck of a lot about the file and whether it's used at all. There's some info about it in the UW-imap faq http://www.washington.edu/imap/IMAP-FAQs/index.html#7.10. The file location is based on the information about a default location provided there. I don't mind either removing the file from the distribution or changing the LOCKPGM path described in this FAQ entry... Any suggestions either way? Thanks! -Abe -Original Message- Abe, I noticed this a while ago and it didn't register. Sorry to do this right after a release, but does mlock.exe really need to be in /etc ?
RE: SetupXP
On Thu, 2003-07-17 at 00:46, Max Bowsher wrote: Hi Gary, Please add the following to your generated files filter when making your tarball: inilex.cc iniparse.cc iniparse.h res.aps setup_version.c Setup.aep Setup.aew Setup.dev Setup.dev.bak Setup.layout Don't tarball by hand. Use make release. D'OH! Well that would have saved me a lot of time -- Gary R. Van Sickle Brewer. Patriot.
Re: [Ready for test/1.5.0] libiconv gettext (many)
Corinna Vinschen wrote: On Tue, Jul 15, 2003 at 08:42:04PM -0400, Charles Wilson wrote: Real fix: figure out why sharutils thinks it needs access to that variable, and use the public API to do the same thing. If possible. shar just uses the value to print it to stdout if the option --print-text-domain-dir is given. AFAICS, printing this value is even wrong. The correct value is the one returned by a former call to bindtextdomain(), right? So I'd guess the correct solution would be to store the return value of bindtextdomain() and to use this to print: localedir = bindtextdomain (PACKAGE, LOCALEDIR); ... puts (localedir); Am I right here? I had not much to do with libintl so far so please excuse my questions. No, I think that actually SETS the localedir to the appropriate subdirectory under the specified LOCALEDIR. You want to know where it would look by *default*, so instead of (for instance) /usr/share/locale [the value of _nl_default_dirname, you get LOCALEDIR/domain/PACKAGE.po Believe it or not, here's how gettext.exe determines the default value of the localdir (under which there are languauge-secific subdirectories, etc etc). This code snippet is from the section that generates the --help output: ... Standard search directory: %s\n), getenv (IN_HELP2MAN) == NULL ? LOCALEDIR : @localedir@); See that? It actually relies on autoconf to HARDCODE the correct value! (But it doesn't illegally access dcigettext's _nl_default_dirname variable) -- or it uses LOCALDIR, which is a define passed in via the makefile (gcc -DLOCALEDIR=\$(localedir)\ ...) And, of course, in dcigettext, _nl_default_dirname[] itself is initialized with const char _nl_default_dirname[] = LOCALEDIR; So it appears there really is no way to get this value, except by accessing _nl_default_dirname. But you don't know if it is there or not -- it might be _nl_... if the gettext in question is part of the libc; or if you're using an external library (like libintl or cygintl) then it might be libintl_nl_... The only way to automatically figure this out is to, within configure, piggyback on the internal variables set by the stuff from gettext.m4: --- in configure.ac --- if test $gt_cv_func_gnugettext_lib == yes; then NL_DEFAULT_DIRNAME_VAR=_nl_default_dirname else NL_DEFAULT_DIRNAME_VAR=libintl_nl_default_dirname fi AC_SUBST([NL_DEFAULT_DIRNAME_VAR]) --- in Makefile.am/.in --- nl_default_dirname_var = @NL_DEFAULT_DIRNAME_VAR@ DEFS = -D_nl_default_dirname=$(nl_default_dirname_var) @DEFS@ -- BTW, the following is the configure.ac incantation that I use in order to force NOT build and NOT link against the local intl/ directory: AM_GNU_GETTEXT(external,[],[]) BUILD_INCLUDED_LIBINTL=no USE_INCLUDED_LIBINTL=no AC_SUBST(BUILD_INCLUDED_LIBINTL) AC_SUBST(USE_INCLUDED_LIBINTL) --Chuck -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
RE: SetupXP
Hi Gary, More stuff to decrease the size of your diff: I think you are only supposed to update Copyright comments when you actually change something in a file? Unless I am wrong, please drop your copyright-comment-only change to splash.h from your local mods. No, I know, I noticed that too. I had changed it, but then reverted the changes because the new OnAcceptActivation() replaced them. I'll leave it for now, since something might creep in there between now and intent-to-submit-for-review, and if there's anything I'll forget to do it's update the copyright. Please do a cvs update. The following files are unmodified in your local copy, but have changes in the repository: ChangeLog, Makefile.am, GUIDELINES, .cvsignore, README, RECTWrapper.h (In the case of GUIDELINES and .cvsignore, the change is the fact they have been created.) Noticed that as well last night. The following files have local modifications and changes in the repository. CVS can successfully merge them without conflicts (I have tested): proppage.h, propsheet.h Please rm ChangeLog.window.txt, since the changes detailed there are already merged. Please rm COPYING INSTALL. They are junk from an ancient automake run. Please add the following to your generated files filter when making your tarball: inilex.cc iniparse.cc iniparse.h res.aps setup_version.c Setup.aep Setup.aew Setup.dev Setup.dev.bak Setup.layout I'll try Rob's 'make release' suggestion here I think. Shoulda thought of it sooner in fact, but whaddaya do. That should ignore any of my accumulated cruft. Thanks, Thanks for the pre-reviews and tips Max. -- Gary R. Van Sickle Brewer. Patriot.
RE: SetupXP
[snip] Seems I spoke too soon. The diff is still messy in parts. Oh I know. I'm not submitting anything for inclusion yet, just trying to get some general feedback. First, please drop -r HEAD from your diff command. All that accomplishes is to make the generated patch *revert all changes to HEAD that you haven't merged into your local copy*. Ouch, ok, important safety tip. I thought I had gotten all the changes to HEAD, but as you discovered I hadn't. Second, could you include CVS dirs in your tarball. It wouldn't add much to the size, and it would allow me a better chance at getting a clean diff out of your changes. Third, you are accumulating quite a large quantity of changes. Mmmm, yes and no. A few parts of my last Big Chooser patch have already made it to mainline, and the OnAcceptActivation() change has reduced the size of the remainder a bit. The only additions since then (I think, without checking) are the new XP theme/visual style thing and a reversion of the wizard page titles to Cygwin Setup (which I need to bring up for discussion separately). The XP manifest change seems to be conveniently modular. Want to submit that to cygwin-apps@, as a first step to decreasing the size of your monolithic patch? If I can get it to work, sure ;-). Currently it doesn't work like I thought it did. I think it might be a problem with windres, I have to look into it. I'd like to see bigchooser get to the mainline. I've been patching it into my personal-use setup since you first posted a patch. Me too. I appreciate your pre-reviewing; it will be instrumental in getting this to happen. -- Gary R. Van Sickle Brewer. Patriot.
