Re: Linker error after clean reinstallation of Cygwin
On Mon, 19 Dec 2005, Yitzchak Scott-Thoennes wrote: On Fri, Dec 16, 2005 at 07:03:12PM -0500, Igor Pechtchanski wrote: On Fri, 16 Dec 2005, Angelo Graziosi wrote: The cygipc package has not been reinstalled, it, now, belongs to obsolte section. Should I reinstall it or is sufficient to delete '-lcygipc' from the build command? Actually, cygipc *is* installed, but the new version is empty (as are all obsolete packages) Doesn't seem to be true in this case: setup.ini: setup-timestamp: 1134667219 ... @ cygipc sdesc: IPC support for cygwin ldesc: CygIPC provides a library, headers, and a daemon that can be used to provide IPC services for cygwin. It is, however, slated to become obsolete once the cygserver is complete (cygserver is a similar library and daemon that will be a built-in part of the main cygwin DLL). category: _obsolete requires: cygwin libpopt0 version: 2.03-2 install: release/_obsolete/cygipc/cygipc-2.03-2.tar.bz2 374271 38e9b514fd9c0946a8d019d8a4c9b031 source: release/_obsolete/cygipc/cygipc-2.03-2-src.tar.bz2 81505 71ff16929a3128a1c9a63c657deb380b [prev] version: 2.02-1 install: release/_obsolete/cygipc/cygipc-2.02-1.tar.bz2 358773 6340582cd657fb3beabef20ee47c5f78 source: release/_obsolete/cygipc/cygipc-2.02-1-src.tar.bz2 75792 d08c0fa695264c881fd6c7fe16a10226 $ cygcheck -c cygipc Cygwin Package Information Package VersionSta cygipc 2.03-2 OK $ cygcheck -l cygipc /etc/postinstall/cygipc.sh [snip more cygipc content] True -- I should've checked before assuming that this would be the case. Seems to be a cygipc packaging bug. Chuck, can we get an empty 2.03-3? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac
Re: Needing a debug version of setup.exe
On Fri, 9 Dec 2005, Doug Wyatt wrote: I'm trying to obtain a version of setup.exe that I can use with insight/gdb to investigate a problem with a Cygwin repository created within our Company's LAN. Since I recently updated our repository, setup.exe just crashes. This is with setup.ini created with the last original Upset from the infra directory, also with a more recently acquired upset (v1.0.5, slightly modified to fix some category related problems). I've tried to acquire Setup source from cvs, with variations on the following, over the last few weeks: $ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/src $ cvs login Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/src CVS password: [anoncvs] cvs [login aborted]: connect to sourceware.org(209.132.176.174):2401 failed: Connection timed out Could have been a temporary glitch, or something with your firewall -- I just executed this command with no problems (except that I changed /cvs/src to /cvs/cygwin-apps, of course, and used sources.redhat.com instead of cygwin.com, but neither of those should matter). $ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps \ checkout setup cvs [checkout aborted]: connect to sources.redhat.com(209.132.176.174):2401 failed: Connection timed out Has something changed with respect to cvs access to Setup.exe source code, or is this a manifestation of my cvs cluelessness? Not that I know of... Can you telnet sourceware.org 2401? I've also found that the -z flag didn't work for me on occasion -- did you try an uncompressed checkout? Can someone please tell me how to get the Setup source code for the current stable version? If all else fails, you can always try browsing CVS via the ViewCVS page... But that isn't very useful for getting a buildable source... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: PING setup-maintainer.
On Thu, 1 Dec 2005, Max Bowsher wrote: Buzz wrote: : * geturl.cc (init_dialog): Tell where file is downloaded from. [snip] Apart from the above patch, the two others I have waiting for my attention in my mailbox are: * Remember Chooser View * Warn about dropped mirrors If there are more, could you remind me? Thanks. How about http://cygwin.com/ml/cygwin-apps/2005-11/msg00141.html? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Request for a new setup snapshot
Brian, can we please get a 2.521 setup snapshot out? Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Request for a new setup snapshot
On Wed, 30 Nov 2005, Max Bowsher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Pechtchanski wrote: Brian, can we please get a 2.521 setup snapshot out? Thanks, Igor Done. http://cygwin.com/setup/ Perfect, thanks. Igor P.S. Should the snapshots older than 2.510 be moved to setup/old ? -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: RFC on packaging of additional Apache2 modules
On Thu, 24 Nov 2005, Max Bowsher wrote: I'm preparing a new Apache 2 release, and want to include a conf.d arrangement to allow additional module packagess to install configuration fragments in a useful way. So far, my tentative proposal is: Include /etc/apache2/conf.d/*.conf in httpd.conf. Have module packages install config fragments to /etc/apache2/conf-std.d/, and copy them insto conf.d if no equivalent exists. This is consistent with the way the package currently handles httpd.conf, etc. I'm posting here for input before I go ahead and do it. The above sounds fine, but why not use /etc/defaults/etc/apache2/conf.d/ instead of /etc/apache2/conf-std.d/? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Concern about new g-b-s logging change - loss of error detection
On Sun, 20 Nov 2005, Max Bowsher wrote:
Igor Pechtchanski wrote:
Let's try to come up with a solution (see below), but if we can't very
soon, I'll disable the logging.
Good.
or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
I think using a bashism is OK. Even people who don't actually use bash
interactively will have it installed - it's in 'Base', after all.
So, we make g-b-s a /usr/bin/bash script instead of /bin/sh script? Are
there any objections to this? Is this script ever used in any (e.g.,
cross-compilation) environments where /bin/sh is *not* bash?
Bash usually lives in /bin, not /usr/bin.
On Linux it does. If bash lives in /bin, it's standard on the system and
I'm not worried about those systems. I'm guessing I'm just overcautious.
I would think that any Linux system featureful enough to have a
compiler, would have a /bin/bash.
Why would ${PIPESTATUS[1]} not be OK?
Because that would only work for cases where the only pipe is added by
logging (i.e., fragile). If someone ever wanted to pipe something to
configure in that step, whoever made the change would need to know to
change ${PIPESTATUS[1]} to ${PIPESTATUS[2]}, which is too easy to miss
(i.e., fragile). I'm willing to be convinced that I'm being paranoid
here, though.
Hang on: It is the *first* item in the pipe (the real command) that we
care about, anyway, not any filters placed after it. So,
${PIPESTATUS[0]}, and we don't need to worry about people adding to the
end of the pipe.
Nope, that's why I said piping something *to* configure, not piping
configure output into something. The thing we're interested in may not
be the first item in the pipe (in fact, to preserve the behavior we had
before the logging change, we'd need to consider the return code of the
last pipe stage). Whether that's the correct behavior is a separate
question, which also needs to be addressed...
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Concern about new g-b-s logging change - loss of error detection
On Sat, 19 Nov 2005, Max Bowsher wrote:
This thread seems to have gone to sleep.
Sorry -- it was sitting in my Follow-Up folder, but I somehow didn't get
to reply to this.
Summary: The addition of the 'logging' g-b-s feature introduced a bug:
Errors during phases of package building do not halt the build, so that
an error during 'make' or 'make install' would not prevent the 'pkg'
operation running, and producing flawed package files.
If no one has time to fix the logging feature properly right now, could
we just revert the logging feature from g-b-s CVS HEAD until someone does?
Let's try to come up with a solution (see below), but if we can't very
soon, I'll disable the logging.
=== Full text of earlier part of thread follows: ===
Max Bowsher wrote:
Igor Pechtchanski wrote:
On Sat, 29 Oct 2005, Max Bowsher wrote:
Please forgive me if this has already been discussed - I've been
time-limited to scanning subject lines only recently.
Bourne shells consider only the exit status of the last command in a
pipeline when determining $? - this means that the addition of lots of
| tee somefile will cause errors occurring during the commands being
logged to be ignored.
This seems to me to be a more severe problem than not keeping the logs
in the first place - as a failing make could result in the packaging
of a partially built package.
Max,
Thanks for bringing this up. This hasn't been discussed, and I admit
I missed this aspect of the problem when reviewing the patch. I did
have a fleeting thought of changing the tees to redirections, but
didn't realize the importance of this. I just verified that even
with set -e in effect, bash will not terminate if an interior pipe
command fails.
I can think of two ways to tackle this: use redirection (with the
loss of immediate console output),
I don't like that idea. When building a large package, this would mean
many minutes without any feedback at all.
Agreed. I just wanted to bring this up for completeness.
or use $PIPESTATUS (which is a bashism, and is fragile, unless we use
${PIPESTATUS[$(([EMAIL PROTECTED]))]}).
I think using a bashism is OK. Even people who don't actually use bash
interactively will have it installed - it's in 'Base', after all.
So, we make g-b-s a /usr/bin/bash script instead of /bin/sh script? Are
there any objections to this? Is this script ever used in any (e.g.,
cross-compilation) environments where /bin/sh is *not* bash?
Why would ${PIPESTATUS[1]} not be OK?
Because that would only work for cases where the only pipe is added by
logging (i.e., fragile). If someone ever wanted to pipe something to
configure in that step, whoever made the change would need to know to
change ${PIPESTATUS[1]} to ${PIPESTATUS[2]}, which is too easy to miss
(i.e., fragile). I'm willing to be convinced that I'm being paranoid
here, though.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Please upload: naim-0.11.8
On Fri, 18 Nov 2005, Corinna Vinschen wrote: On Nov 18 11:13, Christopher Faylor wrote: On Fri, Nov 18, 2005 at 03:40:23PM +, Jon Allen wrote: On Fri, Nov 18, 2005 at 11:34:06AM +0100, Corinna Vinschen wrote: Packaging looks good. The above setup.hint is not quite correct, naim is linked against libncurses8, not libncurses7. I fixed that and uploaded the package to cygwin.com. You should also fix your local copy, perhaps. Thanks for catching that. The source package contains a copy of the incorrect setup.hint in naim-0.11.8-1.patch - should I correct this and roll a new source package? I don't think that's necessary as long as you've corrected your local version. Thanks for stepping up to do this. It is much appreciated. Igor, can we get a gold star for Jon? Everybody taking over an orphaned package should get one in future. Sure, done. Igor P.S. I didn't want to send a separate message, but since I'm replying to this thread anyway -- big thanks to Jon for not letting a very useful package fall through the cracks. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: generic-build-script extension to update version numbers in README
features of the g-b-s into a separate script (tentative name: maintainer-only-features.sh, suggestions welcome). In the meantime, another thing that would help is defining the core g-b-s features. Is anyone using the package signature feature? acceptpatch? logging? P.S. It'd be a different story if we were using an 'engine' with external overrides, like mingwports or cgf's netrel(?) -- then mods to the engine to provide new features would be distinct from the package-specific overrides. But gbs ain't like that. What's stopping us from trying to get there? Anything specific to the nature of the g-b-s? One way to address this may be defining more functions like unpack() to contain the pluggable/overridable behavior. There was also Jari Aalto's build script (I forget the name) which had some of the above properties, IIRC. BTW, thanks for your comments, Chuck. I'm afraid I lost sight of the fact that many maintainers have private mods to the g-b-s, and that feature updates may cause them trouble. We should definitely rectify this. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
[PATCH] setup: initially expand categories starting with .
This patch implements one of the setup augmentations useful for the
installation profiles idea (for lack of a better name :-) ).
Igor
==
ChangeLog:
2005-11-16 Igor Pechtchanski [EMAIL PROTECTED]
* PickView.cc (PickView::setViewMode): Auto-expand category if
its name starts with a dot.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: PickView.cc
===
RCS file: /cvs/cygwin-apps/setup/PickView.cc,v
retrieving revision 2.26
diff -u -p -r2.26 PickView.cc
--- PickView.cc 9 Sep 2005 19:08:01 - 2.26
+++ PickView.cc 16 Nov 2005 19:54:58 -
@@ -160,7 +160,8 @@ PickView::setViewMode (views mode)
for (packagedb::categoriesType::iterator n =
packagedb::categories.begin(); n != packagedb::categories.end();
++n)
-insert_category (*n, CATEGORY_COLLAPSED);
+insert_category (*n, *(*n).first.c_str() == '.'
+ ? CATEGORY_EXPANDED : CATEGORY_COLLAPSED);
}
else
{
Re: Prefab Program Selections (was: RE: Regrouping on installation profile idea)
On Tue, 15 Nov 2005, Tim O'Callaghan wrote: On Tue, Nov 15, 2005 at 01:51:24AM -0500, Christopher Faylor wrote: On Mon, Nov 14, 2005 at 10:43:11PM -0600, Gary R. Van Sickle wrote: Prefab Program Selections ? It still has that Unix ugly to it, but it actually says what it means and means what it says, so everybody wins. I like selections but I don't like prefab. And, right now, I think that Igor was telling me that you can't do something like: Prefab Program Selections C Development X Desktop ... Because setup.exe can't handle that. Actually setup.exe *can* handle that, but it'll be Prefab Program Selections 1.0-1 1.0-1[] [] 1k C Development (with many more spaces -- i.e., the words C Development will not be readily seen). We could, of course, reorder the columns in category view, but that won't help people using the current version of setup. So I agree with CGF -- the category name ought to immediately make it clear that there's interesting stuff beyond the right edge of the chooser... So, it would have to be: C Development Prefab Program Selection X Desktop Prefab Program Selection ... which is a little wordy. Nope. The point is that we want to convey the fact that this *category* contains groups of packages that allow performing certain tasks. The names of the packages themselves aren't as important. I do think we want to convey that these are optional easy-to-use selections which will pull in all of the programs required for a standard use case (as they like to say where I work). How about standard selection? C Development Standard Selection X Desktop Standard Selection ... Bleah. I don't know. Maybe it just can't be properly conveyed without all sorts of flashy gui balloons and help. How about 'Bundle' ? I like Bundle, but it still doesn't convey that one only needs to install one such bundle for each task that they want to do. How about Task-oriented Bundles[*] or something? The Task-oriented part clearly shows that these are bundled with a specific task in mind. Igor [*] Of course, it'd be .TASK-ORIENTED_BUNDLES... -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Prefab Program Selections (was: RE: Regrouping on installation profile idea)
On Tue, 15 Nov 2005, Christopher Faylor wrote: On Tue, Nov 15, 2005 at 10:44:04AM -0500, Igor Pechtchanski wrote: On Tue, 15 Nov 2005, Tim O'Callaghan wrote: On Tue, Nov 15, 2005 at 01:51:24AM -0500, Christopher Faylor wrote: On Mon, Nov 14, 2005 at 10:43:11PM -0600, Gary R. Van Sickle wrote: Prefab Program Selections ? It still has that Unix ugly to it, but it actually says what it means and means what it says, so everybody wins. I like selections but I don't like prefab. And, right now, I think that Igor was telling me that you can't do something like: Prefab Program Selections C Development X Desktop ... Because setup.exe can't handle that. Actually setup.exe *can* handle that, but it'll be Prefab Program Selections 1.0-1 1.0-1[] [] 1k C Development (with many more spaces -- i.e., the words C Development will not be readily seen). We could, of course, reorder the columns in category view, but that won't help people using the current version of setup. So I agree with CGF -- the category name ought to immediately make it clear that there's interesting stuff beyond the right edge of the chooser... Right. I was just representing what you mentioned in private email where you bemoaned the fact that the above isn't really feasible. I don't call the above handling that. 1.0-1? 1k? I think I misunderstood what you meant by that. :-) Indeed, setup cannot display tree package structures reasonably. But adding more words to the package name doesn't help. So, it would have to be: C Development Prefab Program Selection X Desktop Prefab Program Selection ... which is a little wordy. Nope. The point is that we want to convey the fact that this *category* contains groups of packages that allow performing certain tasks. The names of the packages themselves aren't as important. Nope meaning what? FOO Prefab Program Selection *is* wordy. Nope meaning it won't have to be. Or, rather, it won't help. I wasn't disputing the wordiness... I do think we want to convey that these are optional easy-to-use selections which will pull in all of the programs required for a standard use case (as they like to say where I work). That's why I suggested Usage profile. The profile part may be unintuitive, but the Usage certainly conveys the right flavor. How about standard selection? C Development Standard Selection X Desktop Standard Selection ... Bleah. I don't know. Maybe it just can't be properly conveyed without all sorts of flashy gui balloons and help. How about 'Bundle' ? I like Bundle, but it still doesn't convey that one only needs to install one such bundle for each task that they want to do. How about Task-oriented Bundles[*] or something? The Task-oriented part clearly shows that these are bundled with a specific task in mind. Igor So, does .Task-oriented Bundles make sense to people? Or .Usage-oriented Bundles? [*] Of course, it'd be .TASK-ORIENTED_BUNDLES... I really don't like the need for underscores or dashes and I *really* don't like the upper case stuff. When I see all upper case on a screen I think there's something not set up right somewhere. Well, it'll have to be attention-grabbing. Barring color, ALL-CAPS is the only way we can do this, right? The underscores you are probably right about -- I was just trying to avoid the need to quote the category name. BTW, the dash in this case is not a divider, but a legitimate hyphen -- it'd be there even in the normal case. Even though this has to be compatible with the current versions of setup, I'd still like to add some magic to setup to support something like this (e.g., auto-expand any category that starts with a ., or reorder columns in category view so that the package name comes first). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Prefab Program Selections (was: RE: Regrouping on installation profile idea)
On Tue, 15 Nov 2005, Christopher Faylor wrote: On Tue, Nov 15, 2005 at 12:20:26PM -0500, Igor Pechtchanski wrote: On Tue, 15 Nov 2005, Christopher Faylor wrote: So, does .Task-oriented Bundles make sense to people? Or .Usage-oriented Bundles? I think either makes sense, yes. Could you do an ASCII representation of what you'd expect the screen to look like? With the maximized chooser, of course: [+] All () Default [+] .Usage-oriented bundles () Default 1.0-1 () Keep n/a [ ] 1k GCC Development 1.0-1 () Keep n/a [ ] 1k LaTeX Development 1.0-1 () Keep n/a [ ] 1k SSH Server 1.0-1 () Keep n/a [ ] 1k Web Server 1.0-1 () Keep n/a [ ] 1k X Windows [+] Admin () Default [+] Archive () Default ... Looking at the above, .Intended Use makes even more sense, IMO. BTW, I see no reason to not use spaces in the names of these packages. Pasting the below from private mail, to make sure it doesn't get lost: Later, when setup is changed to put package name first in category view, something like this would make sense too: [+] All () Default [+] .I would like to... () Default Develop programs using GCC1.0-1 () Keep n/a [ ] 1k Run X windows 1.0-1 () Keep n/a [ ] 1k Run the SSHD server 1.0-1 () Keep n/a [ ] 1k Run the Apache web server 1.0-1 () Keep n/a [ ] 1k Write documents using LaTeX 1.0-1 () Keep n/a [ ] 1k [+] Admin () Default [+] Archive () Default ... [*] Of course, it'd be .TASK-ORIENTED_BUNDLES... I really don't like the need for underscores or dashes and I *really* don't like the upper case stuff. When I see all upper case on a screen I think there's something not set up right somewhere. Well, it'll have to be attention-grabbing. Barring color, ALL-CAPS is the only way we can do this, right? The underscores you are probably right about -- I was just trying to avoid the need to quote the category name. BTW, the dash in this case is not a divider, but a legitimate hyphen -- it'd be there even in the normal case. Aren't these already going to be sorted first, owing to the .? Could we use '***' instead of '.', maybe? That would be attention grabbing. Hmm... Not sure, but we can try it and see. It's not like the category name is set in stone -- it could always be changed later, until we find something that people like. Even though this has to be compatible with the current versions of setup, I'd still like to add some magic to setup to support something like this (e.g., auto-expand any category that starts with a ., or reorder columns in category view so that the package name comes first). Yes, I think the GUI needs to be updated at some point to handle these properly. BTW, I have the first patch ready -- will send it out separately. The second doesn't look too hard either; probably later this week... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
RE: Prefab Program Selections (was: RE: Regrouping on installation profile idea)
On Tue, 15 Nov 2005, Gary R. Van Sickle wrote: From: Igor Pechtchanski Sent: Tuesday, November 15, 2005 12:14 PM To: [EMAIL PROTECTED] I know it's a mailing list name, but AHEM... Subject: Re: Prefab Program Selections (was: RE: Regrouping on installation profile idea) On Tue, 15 Nov 2005, Christopher Faylor wrote: On Tue, Nov 15, 2005 at 12:20:26PM -0500, Igor Pechtchanski wrote: On Tue, 15 Nov 2005, Christopher Faylor wrote: So, does .Task-oriented Bundles make sense to people? Or .Usage-oriented Bundles? I think either makes sense, yes. Could you do an ASCII representation of what you'd expect the screen to look like? With the maximized chooser, of course: [+] All () Default [+] .Usage-oriented bundles () Default 1.0-1 () Keep n/a [ ] 1k GCC Development 1.0-1 () Keep n/a [ ] 1k LaTeX Development 1.0-1 () Keep n/a [ ] 1k SSH Server 1.0-1 () Keep n/a [ ] 1k Web Server 1.0-1 () Keep n/a [ ] 1k X Windows [+] Admin () Default [+] Archive () Default ... Looking at the above, .Intended Use makes even more sense, IMO. BTW, I see no reason to not use spaces in the names of these packages. Things like .Intended Use, Installation Type, etc make sense the very first time somebody installs. The next time that person touches setup on their machine, .Intended Use only causes confusion, as I described in my reply to Mr. Tacvek. I can guarantee you with proverbial metaphysical certitude that the messages on the lists asking I installed all of Cygwin, why can't I run program they didn't install?!?! will not only not go away, but will be joined by a chorus of people asking (and understandably so): - I accidentally installed Cygwin for the Intended Use of an SSH server, when I really wanted to do C programming! I'm using a 300-baud smoke-signal modem, and there's no way I'm going to redownload the Full Cygwin Installation (FCI(tm))! What do I do?!?! - Q: Do I need to install Cygwin on two separate machines to do C development and Perl development? - A: Well, the easiset way to do this is to install CygWINE, run two virtual Windows machines, and install a separate Cygwin on each one. - How can I manually edit the registry so I can use both the SSH Server Installation Type AND the X Windows Intended Use? I can't believe the idiots who wrote setup didn't allow for this! Metaphysical. Certitude. After a hearty LOL, I can't help but agree. .Intended Use does have an implication of being the only one. How about .Needed Functionality? Or even .Intended Use (more than one can be selected)? Pasting the below from private mail, to make sure it doesn't get lost: Later, when setup is changed to put package name first in category view, something like this would make sense too: [+] All () Default [+] .I would like to... () Default Develop programs using GCC1.0-1 () Keep n/a [ ] 1k Run X windows 1.0-1 () Keep n/a [ ] 1k Run the SSHD server 1.0-1 () Keep n/a [ ] 1k Run the Apache web server 1.0-1 () Keep n/a [ ] 1k Write documents using LaTeX 1.0-1 () Keep n/a [ ] 1k [+] Admin () Default [+] Archive () Default ... Now that I like. Yeah, me too. But, pasting the rest of that private mail: == The problem is that you wouldn't actually see the above, you'd see something like: [+] All () Default [+] .I would like to... () Default 1.0-1 () Keep n/a [ ] 1k Devel 1.0-1 () Keep n/a [ ] 1k Run X 1.0-1 () Keep n/a [ ] 1k Run t 1.0-1 () Keep n/a [ ] 1k Run t 1.0-1 () Keep n/a [ ] 1k Write [+] Admin () Default ... (at least until the chooser is maximized). Oh, well, so much for that idea. == That about says it all. We can't adopt something that requires special support from setup (yet, that is). Once a version of setup with the necessary changes becomes mainstream and the older versions are deprecated, we can revisit the category/bundle naming issue. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity
Re: [Patch] Setup: Store view setting
On Sun, 13 Nov 2005, Bas van Gompel wrote: Op Sun, 13 Nov 2005 02:15:51 -0500 (EST) schreef Igor Pechtchanski in Pine.GSO.4.63.0511130213590.24379atslinky.cs.nyu.edu: : On Sun, 13 Nov 2005, Bas van Gompel wrote: [Patch to let setup store the latest view of the chooser window] : Can we please get this re-sent with a non-inline patch and with a : different subject line? This thread is already horribly overloaded. [...] Sure. ChangeLog-entry: (Please fix the at.) 2005-11-13 Bas van Gompel patch-cygsup.buzzatbavag.tmfweb.nl * choose.h (class ViewSetting): Declare. * choose.cc (ViewSetting::load, ViewSetting::save): Implement. (ChooserPage::createListview): Use ViewSetting. (ChooserPage::OnNext): Store ViewSetting. This one looks pretty good. One thing for the TODO list (not critical for this patch): we have all these different setting files, each with one setting. It's time to consolidate them all into one setup.cfg (or whatever the name is) file. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: beta setup.exe (Attn: setup maintainer)
On Sun, 13 Nov 2005, Carl Karsten wrote: Re: RFC: [ITP] Installation Profiles packages Its done. What is the process for releasing beta versions of setup.exe? If someone will post a URL, I'll be happy to run it on a test box. When the patch is officially accepted into CVS, a new setup snapshot should (theoretically) be generated, at which point you'll find it at http://cygwin.com/setup-snapshots/. We've been lax in doing this for the last few significant functionality improvements (Brian, can we please get a setup snapshot?). Until then, feel free to do what I've been doing: compile setup yourself, and provide a snapshot on the web. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: RFC: [ITP] Installation Profiles packages
On Sun, 13 Nov 2005, Bas van Gompel wrote: Op Thu, 10 Nov 2005 01:51:45 +0100 (MET) schreef Bas van Gompel in n2m-g.dku81h.3vvae1b.at@buzzy-box.bavag: : Op Wed, 9 Nov 2005 17:21:28 +0100 schreef Corinna Vinschen : in 20051109162128.GA29765atcalimero.vinschen.de: : [...] :: Which reminds me... isn't there a way that setup could store the latest :: view of the chooser window the user has selected? For instance, in :: almost all cases I'd like to see the Partial view, not the Category :: view. Can storing the last view be added easily? : : It doesn't look hard... I've partly done it. If no-one starts jumping : up and down saying ``Let me!'', I'll finish it. Its done. ChangeLog-entry: (Please fix the at.) 2005-11-13 Bas van Gompel patch-cygsup.buzzatbavag.tmfweb.nl * choose.h (class ViewSetting): Declare. * choose.cc (ViewSetting::load, ViewSetting::save): Implement. (ChooserPage::createListview): Use ViewSetting. (ChooserPage::OnNext): Store ViewSetting. [snip] Can we please get this re-sent with a non-inline patch and with a different subject line? This thread is already horribly overloaded. Igor P.S. I'll try to sum up the real subject matter next week if I have the time... -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [Patch] Setup: Display mirrors sorted by location
On Thu, 10 Nov 2005, Rajesh Balakrishnan wrote: The following patch will display the location info beside the download site. e.g. North America, Virginia ftp://mirrors.rcn.net North America, Virginia http://mirrors.rcn.net North America, Wisconsin ftp://sourceware.mirrors.tds.net Please let me know your comments. Ok, here goes. First, thanks for doing this. However, if this is to be done at all, let's do it right. Notes on the changes * The earlier setup sorts sites based on url. This patch sorts on area, location too. That's good, but the sort order should be user-selectable, not unconditional as you have it. In fact, why are you still using the ListBox widget? Why not a ListView (with sortable columns)? MSDN has some sample code for this... * The non-official mirrors will not show the location information. They will be shown together at the bottom of the list. This could act as a cue, to the user, that it is a non-official mirror. This is good, but the fact that they'll always end up at the bottom isn't. * area, location are new members of the class. * The 'key' for site sorting is area + location + url Again, this is a bad default. We should keep the current sort order, but allow sorting by other fields. What I especially don't like is the Sorting order is comment in operator() -- if it belongs anywhere at all, it should precede the assignment to key in site_list_type::init(). Oh, and the location info should *follow* the URL, not precede it. * Two sites are same if the URLs are same (area doesn't matter). last-mirror doesn't store the area info. Huh? Will we ever have this situation? * The existing code tries to handle .com/.edu/.org (sort together) but I don't think that it is actually effective. In fact, that part of the code was buggy. There was at least one fix posted, but it didn't seem to have made it into CVS. Your code is cleaner. * I've added String.find(char, pos) method in String++. string.find(c, pos) handles negative pos better. substr() is better too. Why not also add String.split(char) that returns an array or a vector of Strings? That would make your parseSite() much simpler. I'm confused about string vs String. Can't we just use std::string? Maybe I should lookup the archives for the history of String++. * I haven't integrated Bas van Gompel's changes to site.cc And two more comments: 1) The above isn't a proper ChangeLog. 2) Next time, please attach the patch, rather than including it inline. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: RFC: [ITP] Installation Profiles packages
On Wed, 9 Nov 2005, Corinna Vinschen wrote: On Nov 8 18:13, Igor Pechtchanski wrote: On Tue, 8 Nov 2005, Christopher Faylor wrote: On Tue, Nov 08, 2005 at 01:52:20PM -0500, Igor Pechtchanski wrote: IMO, these packages should be in a special new category (I propose the name @Profiles to make setup put this at the top, but I don't know if setup will parse this correctly). I've attached a few sample profile packages for commonly requested configurations with the corresponding setup.hints. We could probably concentrate them all in one directory (thus the '@ ...' lines at the top of the hint files). All the .tar.bz2 files are the same empty tarball -- it's the setup.hints that are important. Comments and other suggestions welcome. Note that the attached packages are an initial cut at defining those profiles -- I'm bound to have missed something. Also, I'm not proposing to maintain *all* of the profiles, though I could maintain the ones I've attached, as there isn't too much work involved. Assuming that Corinna agrees, I'm willing to put these in a directory in release. I like the idea. I'd like to get some consensus on the name Profiles, though. Is that adequately intuitive? That's one of the things I wanted suggestions on. The main problem is to get the user to notice that this is something special. I had a long hard look into the chooser window and it's not only that this meta category should come first, it should also be an eye catcher by its own, IMHO. Therefore I'd like to propose an all uppercase name for this category. DEFAULT-PROFILES USER-PROFILES We'll need to put a space or an '@' at the beginning to ensure sort order, but otherwise I like the ALL-CAPS idea (in fact, the packages also ought to be ALL-CAPS, maybe with dashes in the category and the underscores in packages, or vice versa). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: RFC: [ITP] Installation Profiles packages
On Wed, 9 Nov 2005, Corinna Vinschen wrote: On Nov 9 09:35, Igor Pechtchanski wrote: On Wed, 9 Nov 2005, Corinna Vinschen wrote: The main problem is to get the user to notice that this is something special. I had a long hard look into the chooser window and it's not only that this meta category should come first, it should also be an eye catcher by its own, IMHO. Therefore I'd like to propose an all uppercase name for this category. DEFAULT-PROFILES USER-PROFILES We'll need to put a space or an '@' at the beginning to ensure sort order, What about a leading dot? Yep, looking at the lexer, a leading dot should work (without quoting). And I like it better than an '@' or a space... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
RE: RFC: [ITP] Installation Profiles packages
On Wed, 9 Nov 2005, Hannu E K Nevalainen wrote: on Wednesday, November 09, 2005 11:11 AM [EMAIL PROTECTED] wrote: Therefore I'd like to propose an all uppercase name for this category. DEFAULT-PROFILES Hmm... default has little to do with packages imho, or? USER-PROFILES USER indicates something personal... :-p John Morison wrote: (manual fix) +1 on the caps... How about FUNCTIONAL-[GROUPS|PROFILES] USEFUL-[GROUPS|PROFILES] PRESELECTED-[GROUPS|PROFILES|PACKAGES] More wording ideas: SELECTION, CHOICE, PRESET, ORIENTATION predefined package choice ? Cygwin_use-orientation-presets? Cygwin-use-presets ? ... with better wording. How about just .INSTALLATION-PROFILES? Why have more than one category here? AFTERTHOUGHT: The commandline automatic install possibilities need to be considered before adding GUI-stuff. Adding GUI-stuff is easy. Decoupling installation from GUI to allow command line automatic install is hard. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
RFC: [ITP] Installation Profiles packages
As the latest installment in the recent series of major D'oh!s, I realized that the installation profiles I previously proposed for setup could be initially implemented as special packages with the right dependences. This still doesn't absolve us from adding some more sophisticated support for these in setup (e.g., communicating the user prerefence about creating desktop icons to them), but it's a start, and it'll cut down on the I installed Cygwin, so how come gcc doesn't work (and the much more annoying just install everything, it's only 2 gigs answers to those). IMO, these packages should be in a special new category (I propose the name @Profiles to make setup put this at the top, but I don't know if setup will parse this correctly). I've attached a few sample profile packages for commonly requested configurations with the corresponding setup.hints. We could probably concentrate them all in one directory (thus the '@ ...' lines at the top of the hint files). All the .tar.bz2 files are the same empty tarball -- it's the setup.hints that are important. Comments and other suggestions welcome. Note that the attached packages are an initial cut at defining those profiles -- I'm bound to have missed something. Also, I'm not proposing to maintain *all* of the profiles, though I could maintain the ones I've attached, as there isn't too much work involved. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA XWindows.tar.bz2 Description: Binary data @ XWindows category: @Profiles requires: cygwin xorg-x11-base X-start-menu-icons sdesc:Includes packages needed to set up an X server ldesc:Profile for SSH server deployment. The packages included in this profile allow setting up and starting an X server on your machine. In the future this could include a postinstall script for creating a desktop icon, etc. WebServer.tar.bz2 Description: Binary data @ WebServer category: @Profiles requires: cygwin apache2 sdesc:Includes packages needed to set up a web server ldesc:Profile for SSH server deployment. The packages included in this profile allow setting up and starting a web server on your machine. SSHServer.tar.bz2 Description: Binary data @ SSHServer category: @Profiles requires: cygwin openssh sdesc:Includes packages needed to set up an SSH server ldesc:Profile for SSH server deployment. The packages included in this profile allow setting up and starting an SSH server on your machine. LatexDevelopment.tar.bz2 Description: Binary data @ LatexDevelopment category: @Profiles requires: cygwin tetex tetex-extra ghostscript ImageMagick sdesc:Includes packages needed to build documents with LaTeX ldesc:Profile for LaTeX document development. The packages included in this profile allow building documents using TeX/LaTeX, limited image conversion, as well as PostScript to PDF conversion. GCCDevelopment.tar.bz2 Description: Binary data @ GCCDevelopment category: @Profiles requires: cygwin bash gcc make autoconf automake gdb upx sdesc:Includes packages needed to build programs with GCC ldesc:Profile for GCC development. The packages included in this profile allow compiling programs using GCC, running 'make', debugging programs using 'gdb', and running autotools.
RE: [ITP] Installation Profiles packages
On Tue, 8 Nov 2005, Robb, Sam wrote: IMO, these packages should be in a special new category (I propose the name @Profiles to make setup put this at the top, but I don't know if setup will parse this correctly). I've attached a few sample profile packages for commonly requested configurations with the corresponding setup.hints. We could probably concentrate them all in one directory (thus the '@ ...' lines at the top of the hint files). All the .tar.bz2 files are the same empty tarball -- it's the setup.hints that are important. Wow. This sounds neat. Yeah, I was surprised myself at how well it works out... This would be particularly nice if setup.exe were modified so that on an initial installation, it showed a profile selection page first, instead of the package selection page. The profile selection page would let the user choose one or more profiles to install; the packages selected would be a union of the dependencies from the profiles. There could be a check box for advanced package selection that the user could select if they wanted to go to the regular package selection page. Re-running setup.exe (for updates, as opposed to an installation) would skip the profile selection page and go straight to the package selection page. This sounds like the kind of support we might eventually have, but for now, placing the @Profiles category first (which ought to happen automatically anyway), and maybe having setup auto-expand it, should be enough. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: RFC: [ITP] Installation Profiles packages
On Tue, 8 Nov 2005, Christopher Faylor wrote: On Tue, Nov 08, 2005 at 01:52:20PM -0500, Igor Pechtchanski wrote: As the latest installment in the recent series of major D'oh!s, I realized that the installation profiles I previously proposed for setup could be initially implemented as special packages with the right dependences. This still doesn't absolve us from adding some more sophisticated support for these in setup (e.g., communicating the user prerefence about creating desktop icons to them), but it's a start, and it'll cut down on the I installed Cygwin, so how come gcc doesn't work (and the much more annoying just install everything, it's only 2 gigs answers to those). IMO, these packages should be in a special new category (I propose the name @Profiles to make setup put this at the top, but I don't know if setup will parse this correctly). I've attached a few sample profile packages for commonly requested configurations with the corresponding setup.hints. We could probably concentrate them all in one directory (thus the '@ ...' lines at the top of the hint files). All the .tar.bz2 files are the same empty tarball -- it's the setup.hints that are important. Comments and other suggestions welcome. Note that the attached packages are an initial cut at defining those profiles -- I'm bound to have missed something. Also, I'm not proposing to maintain *all* of the profiles, though I could maintain the ones I've attached, as there isn't too much work involved. Assuming that Corinna agrees, I'm willing to put these in a directory in release. I'd like to get some consensus on the name Profiles, though. Is that adequately intuitive? That's one of the things I wanted suggestions on. BTW, I just noticed that the setup.hints as sent won't parse, since setup treats @ at the start of a word as a separate character. I'll need to quote the categories (in which case we might as well put a space there and call it @Installation Profiles, or even Installation Profiles, to ensure that they appear before the rest of the categories in the category view). Will upset parse quoted strings properly? Other comments? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: New application proposal - git-core SCM - Include Perl Module
On Wed, 2 Nov 2005, Tim O'Callaghan wrote: On Wed, Nov 02, 2005 at 02:31:47AM -0800, Yitzchak Scott-Thoennes wrote: On Wed, Nov 02, 2005 at 09:38:56AM +0100, Tim O'Callaghan wrote: On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote: $ cpan String::ShellQuote works out of the box. $ pmq String::ShellQuote 1.03/usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm cygwin doesn't package each and every perl package. Fair enough. I'll add this to the the git post-install script. Not sure that's a good idea, since cpan String::ShellQuote will fetch files from the internet (are there other post-installs that do this?). Also, if cpan has never been used before, it will go into a lengthy configuration dialog to set up CPAN::Config. It would be better to include with your package a git-core-config script and document that it needs to be run before using git-core. Ok, I'll look into local install and uninstall with the git setup scripts. Or you could package the necessary modules in a separate package that follow the installation structure of the Cygwin perl package (like perl-libwin32 did), and then make the git package depend on that. We've done this with some of our prerequisites for an internal project -- works quite well (incidentally, we needed String::Escape, among other things). Debian uses this model too, IIRC. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Concern about new g-b-s logging change - loss of error detection
On Sat, 29 Oct 2005, Max Bowsher wrote:
Please forgive me if this has already been discussed - I've been
time-limited to scanning subject lines only recently.
Bourne shells consider only the exit status of the last command in a
pipeline when determining $? - this means that the addition of lots of
| tee somefile will cause errors occurring during the commands being
logged to be ignored.
This seems to me to be a more severe problem than not keeping the logs
in the first place - as a failing make could result in the packaging
of a partially built package.
Max,
Thanks for bringing this up. This hasn't been discussed, and I admit I
missed this aspect of the problem when reviewing the patch. I did have a
fleeting thought of changing the tees to redirections, but didn't
realize the importance of this. I just verified that even with set -e
in effect, bash will not terminate if an interior pipe command fails.
I can think of two ways to tackle this: use redirection (with the loss of
immediate console output), or use $PIPESTATUS (which is a bashism, and is
fragile, unless we use ${PIPESTATUS[$(([EMAIL PROTECTED]))]}). Any
other suggestions?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ITP] run.exe was Re: Running ssh in background [solution/patch]
On Wed, 26 Oct 2005, Alexander Gottwald wrote: On Wed, 2005-10-26 at 15:43 +0200, Corinna Vinschen wrote: Maybe you could install a symlink in /usr/X11R6/bin, in the postinstall script, not in the package itself. The idea is that a postinstall script can create a symlink as windows shortcut by forcing CYGWIN=winsymlinks on ln(1). run.exe is often used from Windows shortcuts to start programs like XWin. Even the X-start-menu-icons uses it this way, A shortcut will not work. FWIW, setup supports hardlinks in binary tarballs, and does the right thing w.r.t. copying, etc, when needed. Since I'm replying here anyway, the patches I mentioned are attached (along with the new icon). The icon is useful for a VIm shortcut (essentially run rxvt -e vim) -- yes, I know I could use a separate icon file, but this is easier, and this vim icon is otherwise only available as part of the VIm source. Igor == 2005-10-26 Igor Pechtchanski [EMAIL PROTECTED] * Makefile.cygwin (run): Change to use $(CC). * run.c (main): Make retval unsigned. * run.rc (VIM): New icon. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA--- Makefile.cygwin-orig1998-12-19 22:45:19.0 -0500 +++ Makefile.cygwin 2004-07-20 18:51:35.0 -0400 @@ -2,8 +2,8 @@ .SUFFIXES: .c.o .rc.o # Makefile for gnu-win32 environments run : run.c run.h run_res.o - gcc -c -I. -O2 run.c -o run.o - gcc -mwindows -e _mainCRTStartup run.o run_res.o -o run.exe + $(CC) -c -I. -O2 run.c -o run.o + $(CC) -mwindows -e _mainCRTStartup run.o run_res.o -o run.exe run_res.o : run.rc windres -i run.rc -o run_res.o --- run.c-orig 2002-08-08 18:10:47.0 -0400 +++ run.c 2004-07-20 18:47:16.0 -0400 @@ -123,7 +123,7 @@ int start_child(char* cmdline, int wait_ SECURITY_ATTRIBUTES sec_attrs; SECURITY_DESCRIPTOR sec_desc; PROCESS_INFORMATION child; - int retval; + DWORD retval; memset (start, 0, sizeof (start)); start.cb = sizeof (start); --- run.rc-orig 1998-12-19 22:45:19.0 -0500 +++ run.rc 2004-07-20 19:08:36.0 -0400 @@ -3,6 +3,7 @@ rxvt ICON rxvt.ico XEmacs ICON xemacs.ico XEmacsFile ICON File.ico XEmacsLisp ICON Lisp.ico +VIM ICON vim.ico #include windows.h #include run.h vim.ico Description: Binary data
Re: Multiple pending setup patches
On Tue, 18 Oct 2005, Bas Buzz van Gompel wrote: Op Tue, 18 Oct 2005 01:35:12 -0400 (EDT) schreef Igor Pechtchanski: : On Tue, 18 Oct 2005, Buzz wrote: : Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski: [Mirror manually added or stale.] : : You are assuming that the format of the last-mirror file is fixed and : : won't change. We could keep the fact that the user typed in the mirror : : URL as opposed to clicking on one of the official ones... : : Igor : Would it not be possible to use the cached mirror-list to : differentiate the two cases? (Only warn if a mirror is used which is : in cache but not in new list. Keep the old mirror in the cache if : the user wants to be warned again.) : (I know, SHTDI.) : a) the cached mirror-list was only introduced recently, I suggest using it. Your point? That's one of the reasons it hasn't been done yet. : b) the cached mirror-list is overwritten every time a successful : connection is established with sourceware.org, That could change. (Or the stale mirrors might get appended.) SHTDI. PTC. : c) this kind of information belongs in last-mirror, IMO, and That is also an option. Adding a ``stale''-flag there, if the user wants to be warned again, should work. Still, one could use the cached mirror-list to determine when an official mirror went stale since last connection. SHTDI. PTC. : d) you said it: SHTDI. If there's interest, I'm willing to look into the source. (It may take me a while. The last time I looked at it is way back.) There's always interest for setup improvements. But, as I said before, I've given it some thought, and it's my opinion that this information belongs in last-mirror rather than mirror-list. You are, of course, welcome to take any approach you deem necessary. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Multiple pending setup patches
On Tue, 18 Oct 2005, Buzz wrote: Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski: : On Fri, 14 Oct 2005, Brian Dessent wrote: : : Brian Dessent wrote: : : Except, from the standpoint of setup there is no way to distinguish the : following two scenarios: : : That is, unless you meant mirror that was manually added *this : session*, whereas I was interpreting it to be user manually entered a : non-official mirror at some point in the past and continues to use it : each time they run setup. So we could in fact detect if the user typed : or pasted something into the edit box and not prompt; but if they then : ran setup again and didn't make any changes they would get the prompt : because at that point setup cannot differentiate anymore. : : Brian, : : You are assuming that the format of the last-mirror file is fixed and : won't change. We could keep the fact that the user typed in the mirror : URL as opposed to clicking on one of the official ones... : Igor Would it not be possible to use the cached mirror-list to differentiate the two cases? (Only warn if a mirror is used which is in cache but not in new list. Keep the old mirror in the cache if the user wants to be warned again.) (I know, SHTDI.) a) the cached mirror-list was only introduced recently, b) the cached mirror-list is overwritten every time a successful connection is established with sourceware.org, c) this kind of information belongs in last-mirror, IMO, and d) you said it: SHTDI. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Multiple pending setup patches
On Fri, 14 Oct 2005, Brian Dessent wrote: Brian Dessent wrote: Except, from the standpoint of setup there is no way to distinguish the following two scenarios: That is, unless you meant mirror that was manually added *this session*, whereas I was interpreting it to be user manually entered a non-official mirror at some point in the past and continues to use it each time they run setup. So we could in fact detect if the user typed or pasted something into the edit box and not prompt; but if they then ran setup again and didn't make any changes they would get the prompt because at that point setup cannot differentiate anymore. Brian, You are assuming that the format of the last-mirror file is fixed and won't change. We could keep the fact that the user typed in the mirror URL as opposed to clicking on one of the official ones... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install
On Sat, 15 Oct 2005, Eric Blake wrote:
According to Igor Pechtchanski on 10/14/2005 8:20 AM:
One thing I didn't notice earlier about either this patch or your original
one is that you removed the second cd $(topdir) from prep(). I know it
looks superfluous, but it's there for a reason (so that unpack() can
change directory with impunity -- yes, this happened to me before).
Applied, with that one change removed. Thanks for the patch. I'll
address the above *.LOG issue shortly.
Igor
This broke when following the directions at http://cygwin.com/setup.html
(that is, run mkdirs, spkg, then copy tarball to new location before
running pkg). Running spkg when the log files don't exist should still
work:
Ah, thanks, I wasn't aware that setup.html recommended running spkg right
after mkdirs.
However,
2005-10-15 Eric Blake [EMAIL PROTECTED]
* templates/generic-build-script (spkg): Don't fail if log files
do not exist.
This will still create an (empty) ${log_pkg_name} tarball, which will get
included in the source package (making it a bit misleading).
I've made the log tarball creation conditional on the existence of the log
files. Thanks for bringing this matter up.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Multiple pending setup patches
On Thu, 13 Oct 2005, Brian Dessent wrote: Igor Pechtchanski wrote: Technically, these packages *do* require bash, and coreutils, and possibly others, so automatic dependency detection is hard (we don't want to have setup parse shell scripts). Perhaps we should augment the depends function of the g-b-s to also look at the postinstall script and find packages for all commands invoked in it? Well hopefully, most (or all) of the coreutils commands will be plain binaries in /usr/bin, and not hard links or anything that requires fiddling from a postinstall. In other words, coreutils should be functional as soon as it's unpacked, so it doesn't really matter if package foo runs its postinstall before coreutils. In fact it doesn't even look like coreutils currently has a postinstall. Right. But it may later. Some other things used in postinstall may already have their own postinstall scripts. If we don't get the dependencies correct now, it might make it harder in the future. Even still, because of the fact that it's in many requires lists coreutils is going to always be near the top of the dependency sorted order list anyway. I have a feeling that bash and coreutils will tend to bubble up to the top of it regardless, even if there are some cases where the explicit dependency in some packages is not spelled out. That is certainly true. Perhaps we ought to have setup add both bash and coreutils to dependencies of packages with postinstalls... But then, what about sed, or tar? * io_stream.cc (io_stream::open): Better log message on error. (io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto. (io_stream::move,io_stream::exists): Ditto. Looks fine, go ahead. Better error messages are alwasy good. :-) Though I wonder if all those repeated throws should be a macro or inline instead... Makes sense. I've committed a variant that uses a macro. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Multiple pending setup patches
On Fri, 14 Oct 2005, Corinna Vinschen wrote: On Oct 14 03:30, Brian Dessent wrote: Corinna Vinschen wrote: Is there any way that my proposal of adding a check to see if the currently selected mirror is in the list of mirrors and issuing a pop-up warning if not, could be implemented? I suppose that this would have to be defeatable for people who want to use setup.exe for in-house mirrors but I'm not too worried about that. Ouch, I am. It should be possible to switch this off, or setup should differ between a mirror from the list, which just isn't available right now, and a mirror which has been added manually. What I had in mind was something like this: - Warning: The mirror you have selected is not on the list of official Cygwin mirrors. It may be out of date or missing some packages. If you experience installation problems consider trying an official mirror. [X] Don't show this again [ OK ] - That's it. FWIW, I was thinking more of a command-line option to turn it off, rather than a user-changeable setting... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s patch] Re: Trial plotutils packages again
On Thu, 13 Oct 2005, Eric Blake wrote: According to Igor Pechtchanski on 10/13/2005 5:36 PM: Exactly. So I'm asking again: *is* this the consensus? If so, I'll remove that section from the readme template. You've got my vote - I have to edit the readme file for every release to give details about the new release, but not worrying about the file list will make that a little less painful (even though g-b-s does provide the list option). Someone tried to fix this so that the README was automatically updated with the file list. Given that he hasn't completed the task, you're right. Agreed. Eric, if you plan to tweak the above patch, you should probably also mention http://cygwin.com/packages/ as the place to get package content listings. Done as requested, plus a sample generic-setup.hint: 2005-10-13 Eric Blake ebb9 at byu dot net * templates/generic-setup.hint: New file. * templates/generic-readme: Add License, Language. List date when releases are made. Remove explicit file listing in favor of instructions on how to reproduce it. * templates/generic-build-script: Fix typo when failing. Applied, with a slight rewording of the package listing section. Thanks! BTW, it might be worth mentioning in generic-setup.hint that even though setup doesn't currently understand the maintainer: field, it would be worthwhile to update it anyway (i.e., the setup.hint's sent to cygwin-apps would contain two comments -- the package and the maintainer). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
Igor Pechtchanski writes:
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
@@ -340,6 +349,7 @@
cp $0.sig ${srcinstdir}/ ; \
fi \
cd ${srcinstdir} \
+ tar cvjf ${log_pkg_name} *.LOG rm *.LOG \
tar cvjf ${src_pkg} * )
}
finish() {
One small issue here: would it make sense to list the files explicitly for
both tar and rm, instead of just using *.LOG? Suppose the variable
values get changed?
This would, of course, require some rethinking of the variable values
(i.e., the explicit path), or we could just change it to
+ tar cvjf ${log_pkg_name} ${configurelogfile%%${srcinstdir}/} \
+ ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
+ ${installlogfile%%${srcinstdir}/} \
+rm *.LOG ${configurelogfile%%${srcinstdir}/} \
+ ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
+ ${installlogfile%%${srcinstdir}/} \
(using bash-isms).
Comments?
No problem, but this time it's your turn :-) This takes way to long.
Please check in if nobody else objects.
One thing I didn't notice earlier about either this patch or your original
one is that you removed the second cd $(topdir) from prep(). I know it
looks superfluous, but it's there for a reason (so that unpack() can
change directory with impunity -- yes, this happened to me before).
Applied, with that one change removed. Thanks for the patch. I'll
address the above *.LOG issue shortly.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install
On Fri, 14 Oct 2005, Igor Pechtchanski wrote:
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
Igor Pechtchanski writes:
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
@@ -340,6 +349,7 @@
cp $0.sig ${srcinstdir}/ ; \
fi \
cd ${srcinstdir} \
+ tar cvjf ${log_pkg_name} *.LOG rm *.LOG \
tar cvjf ${src_pkg} * )
}
finish() {
One small issue here: would it make sense to list the files
explicitly for both tar and rm, instead of just using *.LOG?
Suppose the variable values get changed?
For the record, I've checked in a fix for this.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s patch] Re: Trial plotutils packages again
On Thu, 13 Oct 2005, Charles Wilson wrote: According to Charles Wilson on 10/12/2005 10:09 PM: Within the README file [t]here's no need to list... exactly which files are included within each of ... the tarballs; in fact it's actually discouraged (because it always ends up getting out of date). Actually, the generic-build-script template recommends this. Are you proposing changing the template? Huh? I thought for sure I saw something to the effect of my statement on the mailing list... Ah, here it is: http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00198.html But my memory was faulty; no conclusion was reached in that thread. Exactly. So I'm asking again: *is* this the consensus? If so, I'll remove that section from the readme template. * templates/generic-readme: Add License, Language. List date when releases are made. * templates/generic-build-script: Fix typo when failing. I don't see anything wrong with the patch, but I'm not the keeper of the g-b-s stuff anymore. I am, and I have that patch on my to apply list. Maybe the patch should be tweaked to recommend cygcheck -l $PKG instead of the current recommendation of an explicit list that is likely to get out of date. Yes, that's a pretty good idea. Agreed. Eric, if you plan to tweak the above patch, you should probably also mention http://cygwin.com/packages/ as the place to get package content listings. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s patch] Re: Trial plotutils packages again
On Thu, 13 Oct 2005, Charles Wilson wrote: Igor Pechtchanski wrote: On Thu, 13 Oct 2005, Charles Wilson wrote: According to Charles Wilson on 10/12/2005 10:09 PM: Within the README file [t]here's no need to list... exactly which files are included within each of ... the tarballs; in fact it's actually discouraged (because it always ends up getting out of date). Actually, the generic-build-script template recommends this. Are you proposing changing the template? Huh? I thought for sure I saw something to the effect of my statement on the mailing list... Ah, here it is: http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00198.html But my memory was faulty; no conclusion was reached in that thread. Exactly. So I'm asking again: *is* this the consensus? If so, I'll remove that section from the readme template. I consense: pkg listings should be removed from generic-README... :-) Okay, I take that as a yes... When Eric submits the tweaked patch, I'll apply it. Maybe the patch should be tweaked to recommend cygcheck -l $PKG instead of the current recommendation of an explicit list that is likely to get out of date. Yes, that's a pretty good idea. Agreed. Eric, if you plan to tweak the above patch, you should probably also mention http://cygwin.com/packages/ as the place to get package content listings. ...with OR without the addition of a recommendation to use cygcheck -l or /packages/. Just so I can stop hand editing those stupid lists. :-) You mean you don't use the list function of the g-b-s for this? It's a cinch to do in vim... :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Multiple pending setup patches
On Thu, 13 Oct 2005, Brian Dessent wrote:
Igor, I'm very thankful to have patches from you, and I appreciate that
you're contributing. I seriously need to work on being more timely
about this.
It's okay, I just wanted to make sure they didn't get lost in the noise...
I've applied the patches. Actually, one of them turned out to be stale,
as I've added a bit more functionality afterwards and forgot to resubmit
the patch, so I applied a new version, since the change was minor.
http://cygwin.com/ml/cygwin-apps/2005-09/msg00503.html
(GTG: http://cygwin.com/ml/cygwin-apps/2005-09/msg00514.html)
I suppose this is OK too. The only reservation I have is that it
imposes a new requirement on all package maintainers: that if your
package contains a postinstall script you must include bash in the
requires line. That is something that I think many packagers will get
wrong. It's non-obvious because both bash and ash are in category Base
and can be assumed to exist on any system. It might be better if setup
could figure this out on its own -- when unpacking the package if it
sees a .sh file in /etc/postinstall, it should add bash to the
dependencies if not there already. But that's probably a bit overkill.
I suppose it's possible to insert a package dependency on bash when any
postinstall script is detected in that package. This would cause bash to
come first when postinstall scripts are ordered. But that's not enough --
see below.
On the other hand, accidently omitting this dependency is probably no
worse than the current situation where the scripts are run in
alphabetical filename order.
Agreed.
So, go ahead.
Maybe we should update the setup.html page to explicitly state this.
And it would be nice if we could run a quick script against the package
repository to check if there are currently any packages with postinstall
scripts that don't have bash on their requires line.
Technically, these packages *do* require bash, and coreutils, and possibly
others, so automatic dependency detection is hard (we don't want to have
setup parse shell scripts). Perhaps we should augment the depends
function of the g-b-s to also look at the postinstall script and find
packages for all commands invoked in it?
http://cygwin.com/ml/cygwin-apps/2005-09/msg00508.html
OK.
I have another error message improvement patch in my local tree
(attached). Here's the ChangeLog entry, but I'm hoping I'll be the one
applying the patch if it's approved. Let me know what you think.
==
2005-10-14 Igor Pechtchanski [EMAIL PROTECTED]
* io_stream.cc (io_stream::open): Better log message on error.
(io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto.
(io_stream::move,io_stream::exists): Ditto.
==
[snip]
Go ahead and commit those. And again, thanks.
You're welcome.
I have been wanting to release a new setup with these and the other
minor fixes that have gone into it since the last release. However,
there are two things I'd like to resolve first:
1. This time we should do a release candidate, and advertise its
availability on the main list. With the last release there was a whole
flood of bug reports, which tells me that hardly anyone reads
cygwin-apps closely enough to tun test releases announced there.
FWIW, I've hosted an alpha version of setup-2.513 on my web site, and had
quite a few downloads (about 20, with no complaints so far).
2. I'd like to really fix this package validation error thing
[snip]
Yes, that looks like a tricky one... Good luck!
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: io_stream.cc
===
RCS file: /cvs/cygwin-apps/setup/io_stream.cc,v
retrieving revision 2.17
diff -u -p -r2.17 io_stream.cc
--- io_stream.cc5 May 2005 22:48:35 - 2.17
+++ io_stream.cc14 Oct 2005 04:55:53 -
@@ -99,7 +99,8 @@ io_stream::open (String const name, Str
{
IOStreamProvider const *p = findProvider (name);
if (!p)
-throw new invalid_argument (URL Scheme not registered!);
+throw new invalid_argument ((String(URL Scheme for ')+
+name+' not registered!).c_str());
io_stream *rv = p-open (name.c_str()[p-key.size()], mode);
if (!rv-error ())
return rv;
@@ -112,7 +113,8 @@ io_stream::mkpath_p (path_type_t isadir
Re: [g-b-s Patch] Write and save logfiles for configure/make/check/install
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
Igor Pechtchanski writes:
I feel I should clarify the statement that I'd rather not pollute the
source directory with more files. I don't care if there are extra
files in /usr/src/PKG-VER -- that's what it's there for. However, I'd
rather not have 4 extra files per package in */usr/src* -- it looks
cluttered as it is. That's why I like the step that puts them all in
the same tarball. The compression is incidental. The g-b-s can even
extract the logs in the prep() step, after applying the patch.
Well there would now be only one more extra file in /usr/src after
installing with setup.exe, ${FULLPKG}-BUILDLOGS.tar.bz2
Exactly, that's why I asked for the compressed tarball in the first place.
Maybe in the prep() stage we can then unpack the log files to
/usr/src/$PACKAGE/.logs and delete the ${FULLPKG}-BUILDLOGS.tar.bz2
Yes, .logs, or LOGS, or even just /usr/src/$PACKAGE[*] -- it's up to you.
As for deleting... What I normally do with source packages is run
./PKG-VER.sh prep, and then move PKG-VER.sh, PKG-VER.tar and
PKG-VER.patch to PKG-VER/CYGWIN-PATCHES. That helps me keep my /usr/src
reasonably clean. But that's just me, and others may not want stuff
deleted without their permission.
Igor
[*] If you choose the no subdirectory approach, beware that the g-b-s
as it stands will overwrite the logs. That's why I suggested that the
logs be created with lowercase names initially, but renamed to upper case
in .spkg before building the source package.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install
On Mon, 10 Oct 2005, Dr. Volker Zell wrote: Igor Pechtchanski writes: Yes, .logs, or LOGS, or even just /usr/src/$PACKAGE[*] -- it's up to you. As for deleting... What I normally do with source packages is run ./PKG-VER.sh prep, and then move PKG-VER.sh, PKG-VER.tar and PKG-VER.patch to PKG-VER/CYGWIN-PATCHES. That helps me keep my /usr/src reasonably clean. But that's just me, and others may not want stuff deleted without their permission. Igor [*] If you choose the no subdirectory approach, beware that the g-b-s as it stands will overwrite the logs. That's why I suggested that the logs be created with lowercase names initially, but renamed to upper case in .spkg before building the source package. Ok, I try again. Now after unpacking of the source archive you have the original logfiles compressed under /usr/src. This archive gets unpacked to /usr/src/$PACKAGE/.buildlogs during prep(). configure/make/check/install() still put their logfiles to /usr/src/$PACKAGE/.sinst so it's easy to diff them against their counterparts under /usr/src/$PACKAGE/.buildlogs. Sounds good, except can you please resubmit the diff with some context, preferably unified, just to make sure I can apply it cleanly? Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install
On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
@@ -340,6 +349,7 @@
cp $0.sig ${srcinstdir}/ ; \
fi \
cd ${srcinstdir} \
+ tar cvjf ${log_pkg_name} *.LOG rm *.LOG \
tar cvjf ${src_pkg} * )
}
finish() {
One small issue here: would it make sense to list the files explicitly for
both tar and rm, instead of just using *.LOG? Suppose the variable
values get changed?
This would, of course, require some rethinking of the variable values
(i.e., the explicit path), or we could just change it to
+ tar cvjf ${log_pkg_name} ${configurelogfile%%${srcinstdir}/} \
+ ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
+ ${installlogfile%%${srcinstdir}/} \
+rm *.LOG ${configurelogfile%%${srcinstdir}/} \
+ ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
+ ${installlogfile%%${srcinstdir}/} \
(using bash-isms).
Comments?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: 4th summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Mon, 10 Oct 2005, Harold L Hunt II wrote: The following is useful information from me... [snip] xwinclip I'm still listed as the maintainer of this and I declare it obsolete. I'm not going to maintain it anymore and it doesn't need to exist anymore, so please remove it from the distribution. Harold, I recall that there was an issue with XWin -clipboard -query, where in certain circumstances the clipboard thread didn't have permission to connect to the X server. This was one argument for having a separate xwinclip application. Your comment above implies that this issue is fixed in the newer X releases, right? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch] Write and save logfiles for configure/make/check/install
On Sun, 9 Oct 2005, Lapo Luchini wrote: Igor Pechtchanski wrote: I would compress the log files -- they're only there for reference Mhh, but aren't they compressed in the -src.bz2 archive itself, anyway? I don't quite see the reason to compress them again, but well, a nice idea in any case =) I feel I should clarify the statement that I'd rather not pollute the source directory with more files. I don't care if there are extra files in /usr/src/PKG-VER -- that's what it's there for. However, I'd rather not have 4 extra files per package in */usr/src* -- it looks cluttered as it is. That's why I like the step that puts them all in the same tarball. The compression is incidental. The g-b-s can even extract the logs in the prep() step, after applying the patch. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch] Write and save logfiles for configure/make/check/install
On Sun, 9 Oct 2005, Dr. Volker Zell wrote: Igor Pechtchanski writes: Also, please make sure your ChangeLog is formatted properly, and please attach the patch instead of including it inline. Ok, here it is. 2005-09-10 Dr. Volker Zell dr dot volker dot zell at oracle dot com * templates/generic-build-script (log_pkg_name): New. (configurelogfile): New. (makelogfile): New. (checklogfile): Name change. (installlogfile): New. FYI, this could be compressed: (configurelogfile,makelogfile,installlogfile): New. (conf): Add logging. (build): Add logging. (check): Add logging. (install): Add logging. And this: (conf,build,check,install): Add logging. (spkg): Compress logfiles. Looks good otherwise. Thanks for the patch and for putting up with me. :-) As I said in my reply to Lapo, I'd rather have as few files in /usr/src as possible -- once they are in the package-specific source directory, the maintainers can do whatever they want. So, would it make sense to add a step that would uncompress the log files into the source directory (say, in the prep() step)? You can put them in the package root, or create a logs subdirectory -- the structure is up to you. I'd also include a NOLOGS variable (or some other mechanism to turn off the logging for those maintainers who don't want it). I don't mean to be nitpicking here, but if we're doing this, let's do this right. I'd like to hear from people on what they feel is right in this case. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch] Write and save logfiles for configure/make/check/install
On Sun, 9 Oct 2005, Lapo Luchini wrote: Igor Pechtchanski wrote: You can put them in the package root, or create a logs subdirectory -- the structure is up to you. Or maybe .logs, for consistence with .build and friends. In this case the only strange directory without dot would be CYGWIN-PATCHES, whose position I don't particularly like, I must say, but oh well ;-) Whatever the location is, it better be different from where the new logs are created. I just realized that, unless the logs are created in a different location, or are renamed later, the g-b-s run by the user will overwrite the logs that were packaged by the maintainer. It might make sense to create the logs with lowercase names initially, and rename them to uppercase in the spkg() step. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: HEADSUP: pcre security announcement
On Sun, 9 Oct 2005, Yitzchak Scott-Thoennes wrote: On Wed, Sep 07, 2005 at 09:22:37AM -0400, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: On Sep 7 08:47, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: First of all, many many thank for taking over. This is definitely worth a gold star. GR! Huh, did I miss something? ;-) BTW, should Alan Hourihane get a few as well? Er... didn't he get them already? D'oh! Igor Speaking of D'oh's, you seem to have given me the gold stars that were due Yaakov S :) Why, so I did. :-) D'oh indeed. Fixed; sorry about that -- I'm sure you can rectify the situation shortly (by getting another gold star, I mean). :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [g-b-s Patch] Write and save logfiles for configure/make/check/install
On Fri, 7 Oct 2005, Dr. Volker Zell wrote: Hi Sometimes during package reviews it would be useful to have the logs of the original configure/make/check/install stage when the package was build, but also for comparison between different versions. The patch below for the g-b-s saves these logfiles in the src archive during the spkg stage As James said, an interesting idea. However... For example the texi2html-1.76-2-src.tar archive would include: texi2html-1.76.tar.gz texi2html-1.76-2.patch texi2html-1.76-2.sh texi2html-1.76-2-INSTALL.LOG texi2html-1.76-2-CHECK.LOG texi2html-1.76-2-MAKE.LOG texi2html-1.76-2-CONFIGURE.LOG Why the capitalized names? I would compress the log files -- they're only there for reference, and place them in a separate archive (again, as James suggested). I'm also a bit wary of polluting the source directory with yet more files... 2005-10-07 Dr. Volker Zell Dr dot Volker dot Zell at oracle dot com * generic-build-script: Save logfiles for configure/ make/check/install stage during spkg stage in the source package +++ generic-build-script 2005-10-07 18:14:14.67716 +0200 [snip] Also, please make sure your ChangeLog is formatted properly, and please attach the patch instead of including it inline. Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: updated: guile-1.6.7-2, guile-1.7.2-2
On Thu, 6 Oct 2005, Jan Nieuwenhuizen wrote: Eric Blake writes: [snip] I'm not sure whether .la files belong in usr/bin, or whether they should always be in usr/lib, but that may just be my misunderstanding of libtool. AFAIK, on Cygwin .la files that are used by dlopen need to be in usr/bin. IIUC, dlopen() uses LD_LIBRARY_PATH, which can contain /usr/lib. The only reason the DLLs are in /usr/bin is to make sure the Windows loader finds them. IOW, I don't think you need the .la files in /usr/bin. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
cygwin-doc build not self contained?
Hi, I just installed xmlto/docbook-xsl, and tried to build the Cygwin documentation. It seems that it's trying to connect to oasis-open.org, probably to get some DTD that's included from one of the cygwin-doc DTDs. Is this supposed to happen? Can there be a disconnected build of cygwin-doc (e.g., with cached external DTDs)? Igor P.S. Is this the right list to ask this question? It seems to be related to cygwin-doc packaging, but if it's a general DocBook issue, we'll move it to the main list. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: ATTN Harold Hunt - Re: https no longer supported with wget v1.10.1
On Tue, 4 Oct 2005, Harold L Hunt II wrote: Christopher Faylor wrote: On Tue, Oct 04, 2005 at 09:07:12AM -0700, Harold L Hunt II wrote: I just got this message today (after receiving almost every other message between now and then). Yesterday Hack's messages and my own messages were also delayed by several hours. I'm sure I'm not the only one... Sourceware email seems to be working fine after the move to a new system/IP address. Possibly this is the culprit: http://sourceware.org/ml/overseers/2005-q4/msg00011.html Hmm... interesting... However, it seems that the problem in my case might be more related to the Cygwin website being reachable only intermittently for me today and yesterday, with absolute failure for cygwin.com and only occasionally working for www.cygwin.com. Of course, accessing the site via www.cygwin.com doesn't work well because images and links refer to cygwin.com, so basically the site is unusable... I tried to look into the dns reconds with nslookup, but it's been too long for me to be helpful in this area. The workaround, of course, is to add cygwin.com's new address to /etc/hosts (provided you have control over that file on your machine). The IP is unlikely to change any time soon, right? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: 3rd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Mon, 3 Oct 2005, Corinna Vinschen wrote: Below are the results as of today 2005-10-03. [snip] LIST 3: PACKAGES WITHOUT REPLY FROM MAINTAINER SO FAR = [snip] naim FYI, Dan just released naim-0.11.8 (yes, from Fort Benning), so I'm assuming he's actively maintaining naim... As for the X packages, I'm not sure the people on cygwin-xfree who were asked to pick up the X maintainership are aware that they have to be subscribed to this list. Perhaps it would be worth reiterating it there. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ITP] qt3-3.3.4
On Thu, 29 Sep 2005, Peter Ekberg wrote:
On Wed, Sep 28, 2005 at 10:38:31PM -0400, Igor Pechtchanski wrote:
On Wed, 28 Sep 2005, Nicholas Wourms wrote:
unpack() {
winbase=`cygpath -m ${srcdir}`
Ahem,
winbase=`cygpath -m ${srcdir}`
Ahem,
quote from the autoconf manual:
--8--
[snip]
Contrary to a persistent urban legend, the Bourne shell does not
systematically split variables and back-quoted expressions, in
particular on the right-hand side of assignments and in the argument of
`case'.
--8--
Fair enough. The other quotes *are* needed, however.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
[PATCH] setup: mirror list caching
Hi,
The attached (QD) patch implements rudimentary mirror list caching. The
mirror list will be fully downloaded from sources.redhat.com every time if
possible, but if the site is down, a local copy (from last download) will
be used. There is no true caching (with timestamps, etc), but this
could be refined later.
I've tested this on two WinXP machines -- seems to work. We might want to
apply this soon and release a setup snapshot before this weekend, because
of http://cygwin.com/ml/cygwin/2005-09/msg00993.html.
As usual, the ChangeLog is below.
Igor
==
ChangeLog:
2005-09-29 Igor Pechtchanski [EMAIL PROTECTED]
* site.cc (get_site_list): Store mirror list locally.
Use local copy if unable to download.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA--- CVS/Base/site.cc2005-05-21 19:04:03.0 -0400
+++ site.cc 2005-09-29 11:58:05.307665600 -0400
@@ -201,9 +201,29 @@ get_site_list (HINSTANCE h, HWND owner)
char *bol, *eol, *nl, *theString;
{
String mirrors = get_url_to_string (mirror_url, owner);
-if (!mirrors.size())
- return 1;
-
+if (mirrors.size())
+ {
+ io_stream *f =
UserSettings::Instance().settingFileForSave(mirrors-lst);
+ if (f)
+ {
+ f-write(mirrors.c_str(), mirrors.size() + 1);
+ delete f;
+ }
+ }
+else
+ {
+ io_stream *f =
UserSettings::Instance().settingFileForLoad(mirrors-lst);
+ int len;
+ if (!f)
+ return 1;
+ while (len = f-read (mirror_url, 999))
+ {
+ mirror_url[len] = '\0';
+ mirrors += mirror_url;
+ }
+ delete f;
+ log (LOG_BABBLE) Using cached mirror list endLog;
+ }
theString = new_cstr_char_array (mirrors);
nl = theString;
}
[PATCH] setup: don't attempt to re-read a missing installed.db
The attached patch should fix gobs and gobs of io_stream_cygfile: fopen
failed 2 No such file or directory log messages for initial installs.
The ChangeLog is below.
Igor
==
ChangeLog:
2005-09-27 Igor Pechtchanski [EMAIL PROTECTED]
* package_db.cc (packagedb::packagedb): Remember missing package
database file.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: package_db.cc
===
RCS file: /cvs/cygwin-apps/setup/package_db.cc,v
retrieving revision 2.29
diff -u -p -r2.29 package_db.cc
--- package_db.cc 5 May 2005 22:48:35 - 2.29
+++ package_db.cc 30 Sep 2005 03:24:27 -
@@ -53,6 +53,7 @@ packagedb::packagedb ()
{
/* no parameters. Read in the local installation database. */
db = io_stream::open (cygfile:///etc/setup/installed.db, rt);
+ installeddbread = 1;
if (!db)
return;
/* flush_local_db_package_data */
@@ -123,7 +124,6 @@ packagedb::packagedb ()
// unknown dbversion
exit (1);
}
- installeddbread = 1;
}
}
Re: [ITP] ploticus and ploticus-doc
On Wed, 28 Sep 2005, Schulman.Andrew wrote: I would like to package and maintain ploticus for Cygwin. Ploticus is command-line software for creating plots and graphics, similar to gnuplot. [snip] - The HTML documentation for ploticus weighs about 4 times as much as the program package, and is available online. For that reason I've split the docs into a separate ploticus-doc package. [snip] setup.hint for ploticus-doc sdesc: Command-line plot and graph generator (HTML documentation) ldesc: Ploticus is command-line software for creating plots, charts, and graphics from data. This package contains the HTML documentation for ploticus. category: Graphics Doc requires: ploticus /setup.hint for ploticus-doc I don't have time for a review, but shouldn't ploticus-doc have an external-source directive in its setup.hint? Igor P.S. FYI, the setup.hint files got wrapped by your mailer (not a biggie, since you had links to real ones on the web as well). -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [PATCH] setup: Detect postinstall scripts correctly
On Wed, 28 Sep 2005, Eric Blake wrote: According to Igor Pechtchanski on 9/27/2005 10:19 AM: As I understand, there are now some postinstall scripts that rely on the current (buggy) behavior. However, this is the only way to enforce a deterministic order on the postinstall script execution in the presence of circular dependencies. Before we apply this patch, we ought to make sure that the current postinstall script structure doesn't break. It didn't seem to break for me -- I've tested it on a relatively large fresh install, but, as we all know, one sample does not a statistic make(tm). I'd be more comfortable with, say, Eric signing off on this with respect to the ash/bash postinstall scripts. Both ash and bash install their postinstalls named with a leading 00, putting them first alphanumerically in the 'other' group. But if dependency order is enforced, then any other package with a /bin/sh postinstall should make sure that they depend on bash, to guarantee that bash's postinstall will be run first (needed so that a /bin/sh exists to run the package's script). Any package with a postinstall shell script ought to depend on bash anyway, since it can't be completely installed without it (speaking of which, we don't detect postinstall dependencies in the g-b-s). I'm only worried about circular dependencies -- what does bash depend on? Actually, AFAICS, bash doesn't need the postinstall script to work correctly -- the sole purpose of the script is to make sure /bin/sh exists... Perhaps the bash/ash combo wasn't the right example for the kinds of problems I expected... The only problem that I can think of is if the user had a failed install, so that /bin/sh doesn't exist and 00bash.sh has not been renamed 00bash.sh.done; then on their next use of setup.exe they select a package with a postinstall. If I understood your explanation, that package postinstall will attempt to run before 00bash.sh, and fail because /bin/sh still doesn't exist. Correct. But considering the user already had a failed installation, we can just remind them to reinstall bash at the same time (and these days, there haven't been as many complaints of missing /bin/sh). Exactly. I'm less worried about those cases. Or maybe we can improve the dependency logic - sort all newly installed packages by dependency, but also check all dependencies on previously installed packages to see if the previous postinstall scripts haven't run, and if so, insert them in the proper dependency order rather than collecting them into the 'other' group. Ugh. I'd rather have a general fix for the previous setup run didn't complete situation. That way, all uncompleted postinstall scripts will run *first*, before any packages are installed. Those are easy enough to detect, BTW -- any script that's not .done at the time setup runs... Opinions? That would leave the 'other' group containing only those postinstall scripts not needed as dependencies of the sorted group. Technically, there shouldn't be *any* scripts in the other group ATM -- the only ones that wouldn't be in the package listings are those that are generated by other postinstall scripts (and we could have a separate mechanism for detecting those) or scripts that will perform administrative functions on next install (the latter category will break my above assumption, BTW). I'm game for making the fix. Good. Now it's up to Brian to give me the go-ahead to apply the patch (or apply it himself). We may want to post an alpha version of setup.exe to play with for a few days before announcing it to the list, however. Here you go: http://cs.nyu.edu/~pechtcha/cygwin/setup-2.513-alpha.exe. It contains all three of the recent patches I submitted. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ITP] qt3-3.3.4
that the buildscript is an ebuild (sorta). I think it is cool that you've hacked portage to support Cygwin. However, in converting it from an ebuild to a standalone script, I think that you've reinvented the wheel. A modest suggestion, just use the Generic Build Script provided by Cygwin and keep the ebuild stuff seperate. Once you've fixed the GBS template to handle multiple packages (see gettext for how), Okay, are there any plans to submit patches so that hacking the g-b-s in this way is easier? I should think it would take no longer to make new packages than it had with the ebuild-base template. Although it isn't required now, I think the hope is that someday we can standardize the buildscripts so that we have some uniformity. Using the g-b-s for new packages is certainly encouraged nowadays... And, as always, PTC. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Tue, 27 Sep 2005, Corinna Vinschen wrote: On Sep 26 17:08, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corinna Vinschen wrote: libpcreOBSOLETE (Yaakov S) Did we find any packages still dependent on this? Since it's still affected by the security vulnerability, I think it should be removed. I've replaced the existing 4.1-1 package with empty 4.1-2 packages, so that should do it. If that wasn't as good a move as we thought, I have a backup of the old packages. I've taken over maintainership for the empty packages ;-) While we're at it, I noticed the regex package isn't in the obsolete category, even though it says it's superseded by Cygwin itself. It's been in that mode for ages. Does *anything* out there depend on it anymore? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: g-b-s patch - dependency calculation
On Tue, 20 Sep 2005, Eric Blake wrote:
Dependency calculation should not do transitive closure, but should only
list direct library dependencies. For example, something that depends on
only libxml2 should not also depend on libiconv2. Otherwise, if libxml2
is recompiled to depend on a (theoretical) new libiconv3, the package that
depended on libxml2 pulls in the now unneeded libiconv2 in addition to
setup.exe correctly recognizing that libiconv3 is needed.
http://cygwin.com/setup.html agrees with this, stating Conversely, do not
include package dependencies of dependent packages in your dependency
list. So, this patch fixes g-b-s to only grab direct dependencies,
rather than everything:
2005-09-20 Eric Blake [EMAIL PROTECTED]
* templates/generic-build-script (depend): Don't do transitive
closure, only direct dependencies.
Eric,
You also included a few whitespace changes in your patch -- while I don't
mind cleanups, it would've been nice to explicitly mention them. Also,
your RE to detect dependencies ('/^ [[:alpha:]]/') seems wrong -- IMO,
it'll miss DLLs that start with digits or underscores. I've changed it
accordingly (to '/^ [A-Za-z0-9_]/') and checked in the patch with that
change.
Thanks for the patch.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: g-b-s patch - dependency calculation
On Tue, 27 Sep 2005, Eric Blake wrote:
You also included a few whitespace changes in your patch -- while I don't
mind cleanups, it would've been nice to explicitly mention them. Also,
your RE to detect dependencies ('/^ [[:alpha:]]/') seems wrong -- IMO,
it'll miss DLLs that start with digits or underscores. I've changed it
accordingly (to '/^ [A-Za-z0-9_]/') and checked in the patch with that
change.
Neither version is correct. Cygcheck output is the absolute windows
pathname, indented by spaces according to the depth of the
dependency. My regex was looking for exactly two spaces, followed
by a drive letter (the exact two spaces was the important part, as
that is what determines the direct dependencies).
Ok, that makes sense. I didn't remember that those were full pathnames.
I do seem to recall seeing .\smth.dll in there at times.
Your regex also looks for 1:\ and _:\, but since drive 1 and drive _
don't exist, it was a pointless change!
Right, since those are drives.
What we did wrong, however, was forgetting about UNC pathnames on the
PATH. So the corrected regex should be either:
'/^ [A-Za-z\\]/'
or:
'/^ [\\[:alpha:]]/'
or:
'/^ [^ ]/'
I like the last one. I'll make the change.
By the way, now that I have an upload account, am I allowed to
make CVS checkins for g-b-s?
I think you need to be explicitly given checkin privileges to the
cygwin-apps tree (CGF gives those out, IIRC). However, even if you get
them, I'd prefer if you ran every patch by me (on this list) before
checking it in, anyway.
I don't have employer copyright
disclaimer, so I know that I can't touch the winsup tree, but I
was under the impression that the cygwin-apps tree (including
g-b-s) have looser checkin rules.
Right, you don't need a copyright assignment for the cygwin-apps tree.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
[PATCH] setup: Detect postinstall scripts correctly
-= WARNING =- -= WARNING =- -= WARNING =- -= WARNING =- -= WARNING =-
Do NOT apply this patch until all the consequences have been considered
and discussed.
-= WARNING =- -= WARNING =- -= WARNING =- -= WARNING =- -= WARNING =-
This is a trivial patch that fixes a bug in postinstall script detection.
You may have noticed that when all postinstall scripts are run, No
package is displayed in the progress window. Here's some history:
When I first implemented the logging of postinstall script output, I
figured we'd run the known postinstall scripts (those coming from the
packages we just installed) first, in dependency order, and then run all
other postinstall scripts (e.g., custom ones, or those created by
postinstall scripts themselves) in alphanumeric order. There is code in
setup to display the name of the package for which we are currently
running postinstall scripts, with No package displayed for those other
scripts.
Unfortunately, there was a small bug in string comparison (which the
attached patch fixes) that failed to detect *any* postinstall scripts in
packages, causing everything in /etc/postinstall to be treated as other.
As I understand, there are now some postinstall scripts that rely on the
current (buggy) behavior. However, this is the only way to enforce a
deterministic order on the postinstall script execution in the presence of
circular dependencies. Before we apply this patch, we ought to make sure
that the current postinstall script structure doesn't break. It didn't
seem to break for me -- I've tested it on a relatively large fresh
install, but, as we all know, one sample does not a statistic make(tm).
I'd be more comfortable with, say, Eric signing off on this with respect
to the ash/bash postinstall scripts.
Discussion welcome. As usual, the ChangeLog is below.
Igor
==
2005-09-27 Igor Pechtchanski [EMAIL PROTECTED]
* script.cc (isAScript): Fix string comparison.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: script.cc
===
RCS file: /cvs/cygwin-apps/setup/script.cc,v
retrieving revision 2.20
diff -u -p -r2.20 script.cc
--- script.cc 1 Sep 2005 16:39:27 - 2.20
+++ script.cc 27 Sep 2005 16:01:44 -
@@ -269,8 +269,8 @@ bool
Script::isAScript (String const file)
{
/* file may be /etc/postinstall or etc/postinstall */
-if (file.casecompare (ETCPostinstall, sizeof(ETCPostinstall))
- file.casecompare (ETCPostinstall+1, sizeof(ETCPostinstall)-1))
+if (file.casecompare (ETCPostinstall, sizeof(ETCPostinstall)-1)
+ file.casecompare (ETCPostinstall+1, sizeof(ETCPostinstall)-2))
return false;
if (file.c_str()[file.size() - 1] == '/')
return false;
[PATCH] setup: better log message on failed fopen
The attached patch makes the error message from the io_stream_cygfile
constructor a bit more sensible. This could've helped diagnose the
problem reported in http://cygwin.com/ml/cygwin/2005-09/msg00901.html.
Igor
==
2005-09-27 Igor Pechtchanski [EMAIL PROTECTED]
* io_stream_cygfile.cc (io_stream_cygfile::io_stream_cygfile):
Better log message on error.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: io_stream_cygfile.cc
===
RCS file: /cvs/cygwin-apps/setup/io_stream_cygfile.cc,v
retrieving revision 2.21
diff -u -p -r2.21 io_stream_cygfile.cc
--- io_stream_cygfile.cc5 May 2005 22:48:35 - 2.21
+++ io_stream_cygfile.cc28 Sep 2005 01:24:58 -
@@ -144,7 +144,7 @@ io_stream_cygfile::io_stream_cygfile (St
if (!fp)
{
lasterr = errno;
-log(LOG_TIMESTAMP) io_stream_cygfile: fopen failed errno
+log(LOG_TIMESTAMP) io_stream_cygfile: fopen( name ) failed
errno
strerror(errno) endLog;
}
}
Re: libming and ploticus (Attn: SWI-Prolog maintainer)
On Mon, 26 Sep 2005, Andrew Schulman wrote: OK, I won't worry about SWF for now. I would be happy if you would like to propose it, but not so happy if you leave out the prefabs, docs, samples and testsuite. prefabs and docs, definitely. Samples and testsuite, sure, why not. First off, thank you for packaging ploticus. IMO, the testsuite can definitely be omitted. The samples could be useful (in /usr/share/ploticus*). I forgot if Bitstream Vera is in any other package yet. package-grep doesn't find it. Should be so. Sorry, I don't find these or any other fonts in the ploticus source. Where do they come from? Does ploticus depend on them? Just for SWF, or for other formats too? Should they go into a font package instead? I would suggest just creating separate fonts package(s?), if you can figure out where the fonts come from... Maybe like this? /usr/bin/ploticus.exe postinstall.sh: test -f /usr/bin/pl || ln -s /usr/bin/ploticus /usr/bin/pl Or how about this: rm -f /usr/bin/pl ln -s /usr/bin/ploticus /usr/bin/pl :) Just kidding... but how annoying that Prolog has already claimed /usr/bin/pl... what the heck is Prolog anyway? Is anyone using it? Yes, it's a filename clash -- we had those before. The solution would be for *both* packages to provide a uniquely-named executable and a postinstall script that would create a symlink. Then the nature of /usr/bin/pl would depend on the order of package installation (actually, the order of postinstall script execution). Seriously though, under your proposal, if a user installed ploticus and then later installed SWI-Prolog, would it cause a problem that /usr/bin/pl already existed? Well, it wouldn't in a sense that you'd have both /usr/bin/pl and /usr/bin/pl.exe (the latter will shadow the former). But you'd definitely need to coordinate with the maintainer of SWI-Prolog (Corinna?) to add those postinstall scripts together. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: 2nd summary (was Re: [HEADSUP] ALL Maintainers, please reply.)
On Mon, 26 Sep 2005, Max Bowsher wrote:
Christopher Faylor wrote:
On Mon, Sep 26, 2005 at 01:06:58PM +0200, Corinna Vinschen wrote:
clear
This comes from ncurses doesn't it? Is it being purposely dropped from the
ncurses distribution? Chuck?
The clear program that ships with ncurses is packaged as clearn.exe, to avoid
conflicting with the clear package.
The clear.exe from the clear package is tiny:
[[[
main()
{
write (1, \033[1;1H\033[2J, 10);
return 0;
}
]]]
Since ncurses is in category Base, perhaps we should drop the clear package
from the distribution, and allow ncurses clear to take the place of this
package?
It looks like the standalone clear might have been a temporary workaround,
before ncurses was ported.
If by dropping you mean obsolete -- I agree. Release a new, empty
clear, in the Obsolete category, and at the same time rename clearn
from ncurses to clear... Chuck, what do you think?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: libming and ploticus (Attn: SWI-Prolog maintainer)
On Mon, 26 Sep 2005, Corinna Vinschen wrote: On Sep 26 11:22, Igor Pechtchanski wrote: On Mon, 26 Sep 2005, Reini Urban wrote: I forgot to mention that SWI-Prolog already has pl.exe in a seperate location, and /usr/bin/pl is just a symlink to that. On SWI-Prolog installation the symlink is overwritten by setup.exe to use the prolog binary, and on ploticus installation the same, just by the postinstall script. There's no action required at the SWI-Prolog side. I'm not sure I parsed the last paragraph correctly, but if I did, then the action of creating the symlink for SWI-Prolog is unconditional. It needs to be made conditional, just like the one for ploticus, otherwise installing SWI-Prolog will *always* overwrite the symlink. Sorry, but the prolog interpreter is historically always named pl. And a name clash like this, which provides *entirely* different tools using the same name shouldn't be solved on a first come, first serve base. This isn't the same situation as with ksh and pdksh or ash and bash. So, no, I won't change the SWI-Prolog package to create /usr/bin/pl only if it doesn't exist. What's the problem having ploticus being named ploticus? Only the fact that it was also historically always named pl... :-) In any case, having a postinstall script in the ploticus package that conditionally creates the symlink /usr/bin/ploticus - /usr/bin/pl should be enough. That way, users who don't have SWI-Prolog installed will get the name they're used to, and those who *do* have SWI-Prolog installed probably won't expect ploticus to be /usr/bin/pl anyway. Installing SWI-Prolog after ploticus will shadow the symlink, so no problems here. Comments? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: FW: setup: how to handle circular dependencies?
On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Dave Korn Sent: 16 September 2005 14:23 Oops, sent this to the wrong list. [EMAIL PROTECTED] outlook-auto-address completion! Ditto, though in my case it's reading the message on cygwin@ before the one on [EMAIL PROTECTED] On Fri, 16 Sep 2005, Igor Pechtchanski wrote: On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Gerrit P. Haase Sent: 16 September 2005 14:14 Hi Setup maintainers, I need some circular dependencies, i.e. gcc-core requires gcc-core-mingw because -mno-cygwin will not work without the mingw version of the gcc runtime. However, the gcc-core-mingw package only includes the runtime which needs gcc-core to be useful. Maybe I should include the mingw gcc runtimes in the main gcc packages? I can't see the use in having them separate if gcc-core-mingw is really no use whatsoever on its own. Perhaps someone else can think of a reason? The only use I can see is later on, if setup allows optional dependencies, someone may be able to save disk space by omitting gcc-core-mingw (and other gcc-mingw packages) if they never plan to use -mno-cygwin. At the moment, having a circular dependency is the same as having the two in the same package -- both will be installed (unless the user goes to great pains to unselect one). What I would suggest, however, is placing a stub in the main gcc package that would produce a meaningful error on -mno-cygwin if *-mingw packages aren't present, thus making gcc-core independent of gcc-core-mingw. If gcc-core-mingw is that exact stub, then by all means fold it into gcc-core. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Upset (was Re: [ITP] libmad/libmad0/libmad-devel: A high-quality MPEG audio decoder)
On Wed, 7 Sep 2005, James R. Phillips wrote: --- Charles Wilson wrote: Side note: I often use an old copy of upset to generate setup.ini's for my locally built packages which I store in a cygwin/release tree on my private server, and add that URI to my setup.exe's URI list. I once advocated (RFD: A modest proposal #2: unsupported http://www.cygwin.com/ml/cygwin-apps/2003-04/msg00306.html) having an 'unsupported' tree on the official mirrors similar to the existing 'release' tree but that was shot down for good reason. IIRC at some point in the discussion it was pointed out that the existing functionality in setup was sufficient to solve the problem I described, and much more flexible, and did not require official sanction from the cygwin mirror system. How nice for you, and other long-time cygwin developers/packagers that have been grandfathered into this arrangement, because you downloaded upset when it was available, which it is not now, thus reducing the testability and quality of packages built by those not having this resource. It must be wonderful to have powerful tools like this - kind of like having unix available in windows. I've asked this before, and didn't quite understand the rationale for pulling upset from CVS (I *could* understand not accepting patches for it, and vetoing attempts to add it to the distribution). Upset is a tool that lets others generate external mirrors with their own packages; keeping it on sourceware essentially guarantees that those mirrors will have the format compatible with setup.exe. Perhaps we could bring it back as a tool to aid packagers, with the comment at the top that it's not to be changed or released by anyone except CGF? FWIW, googling for cygwin setup upset brings up two versions: Yaakov's (at cygwin-ports.sourceforge.net), and Reini's (at xarch.tu-graz.ac.at). HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Neon packaging of multiple versions
On Thu, 8 Sep 2005, Max Bowsher wrote: Neon is a library that is still in development, with an API which is still evolving. Thus, it is necessary to package multiple versions to support programs which will not always build against the latest API. For the most part this is not a problem. The current libpng packages use the alternatives system to manage exactly this kind of issue. However, the complication on which I am asking for advice is this: neon includes manpages. The alternatives system doesn't seem like a good way to handle this, because there are many manpages, and the exact list of names isn't guaranteed to be constant across multiple versions of neon. Ugh. Couldn't this be installed into /usr/share/neon-*/man, and handled by judicious manipulation of the MANPATH? Unless anyone has a better idea, I think I will have to handle this by inserting the version into the manpage file names - for example, the manpage ne_malloc would be installed as ne24_malloc by the 0.24.x package, and as ne25_malloc by the 0.25.x package. It might be a bit more intuitive to use ne_malloc-0.24 and ne_malloc-0.25. Alternatively, you could stick the version into the section number (i.e., ne_malloc from section 3-0.24 or 3-0.25). That way, users can select the right manpages by using the -S flag. Just some ideas... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Anyone looking at the 'setup.exe' 2.510.2.1 crashing problem?
On Thu, 8 Sep 2005, Christopher Faylor wrote: The problem with setup.exe crashing is pretty easy to duplicate. - Wipe out your download area - run setup.exe o Choose Download without installing o download some files o exit - rerun setup.exe o Choose Install from local directory o Crashes after Parsing ini file http://cygwin.com/ml/cygwin-apps/2005-09/msg00099.html. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Anyone looking at the 'setup.exe' 2.510.2.1 crashing problem?
On Thu, 8 Sep 2005, Christopher Faylor wrote: On Thu, Sep 08, 2005 at 10:53:55AM -0400, Igor Pechtchanski wrote: On Thu, 8 Sep 2005, Christopher Faylor wrote: The problem with setup.exe crashing is pretty easy to duplicate. - Wipe out your download area - run setup.exe o Choose Download without installing o download some files o exit - rerun setup.exe o Choose Install from local directory o Crashes after Parsing ini file http://cygwin.com/ml/cygwin-apps/2005-09/msg00099.html. Yes, I saw that. This doesn't seem to be a problem with the package database. You can add a umount --remove-all-mounts to the above, choose a different root during installation and still get the same result. Looks like Dave mis-spoke -- he said package database, but he seems to have been talking about the local package cache. At the risk of restating the obvious, this is probably a bug in the package verification code, since a fresh download should not have inconsistent files. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Anyone looking at the 'setup.exe' 2.510.2.1 crashing problem?
On Thu, 8 Sep 2005, Christopher Faylor wrote: On Thu, Sep 08, 2005 at 11:26:40AM -0400, Igor Pechtchanski wrote: On Thu, 8 Sep 2005, Christopher Faylor wrote: On Thu, Sep 08, 2005 at 10:53:55AM -0400, Igor Pechtchanski wrote: On Thu, 8 Sep 2005, Christopher Faylor wrote: The problem with setup.exe crashing is pretty easy to duplicate. - Wipe out your download area - run setup.exe o Choose Download without installing o download some files o exit - rerun setup.exe o Choose Install from local directory o Crashes after Parsing ini file http://cygwin.com/ml/cygwin-apps/2005-09/msg00099.html. Yes, I saw that. This doesn't seem to be a problem with the package database. You can add a umount --remove-all-mounts to the above, choose a different root during installation and still get the same result. Looks like Dave mis-spoke -- he said package database, but he seems to have been talking about the local package cache. And that theory would have been disproven by the wipe out your download area step. Not really. You do have a download some files step. Perhaps Dave should've said a *perceived* discrepancy, however, i.e., a genuine bug in setup. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ANNOUNCEMENT] Cygwin setup.exe bugfix release 2.510.2.2
On Thu, 8 Sep 2005, Brian Dessent wrote: I have updated the Cygwin setup utility to version 2.510.2.2. This release is meant to work around the unhandled exception problems that were widely reported with yesterday's release. What about the two patches for the problems Eric reported? If you encounter problems using setup.exe, please report your experience to the cygwin-apps mailing list, cygwin-apps at cygwin.com. You might want to mention next time that cygwin-apps is a subscriber-only list. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ANNOUNCEMENT] Cygwin setup.exe bugfix release 2.510.2.2
On Thu, 8 Sep 2005, Brian Dessent wrote: Igor Pechtchanski wrote: What about the two patches for the problems Eric reported? Oh, and about the disable version warning switch patch: It seems a bit much to add a switch for what is mostly a developer-only feature, when you can just hand edit setup_version.c if need be. Though I could see it coming in handy. Well, I initially figured it'd be a developer-only feature, but then realized that it would also be useful for people who have a working setup.exe and don't want the latest (like in the recent problem with crashes). Besides, suppose setup lives on a network drive, and updates from a local mirror -- there may be version check problems there too. However, I think the larger question is do we *really* need a release branch? I only did it this time because it seems to be established procedure, but I see no real reason to continue it. Absolutely. I guess it made sense in prior times when there were destabilising changes being made on HEAD, but is this something that's still relevent? Well, destabilizing changes *are* made to HEAD occasionally, but testing is the way to deal with those... I'd suggest tagging each release, but only converting the tag to a branch for back-ported fixes from the trunk. That way, regular releases will have the trunk versions, and only the patched one get the 4-digit branch versions. I don't think we need a specialized release branch. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: What's going on with 2.510.2.2?
On Thu, 8 Sep 2005, Max Bowsher wrote: Why does the 'bugfix' 2.510.2.2 release have no code changes in the CVS repository at all, versus the 2.510.2.1 release? What's going on? Does 2.510.2.2 contain uncommitted changes? If so, please commit them! http://cygwin.com/ml/cygwin-apps/2005-09/msg00117.html Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Tooltip delays (was: [ANNOUNCEMENT] Cygwin setup.exe bugfix release 2.510.2.2)
On Thu, 8 Sep 2005, Brian Dessent wrote: Igor Pechtchanski wrote: What about the two patches for the problems Eric reported? They looked good. The one about the background color could be simplified a bit by a single call to SetBkMode in PickView::paint, but otherwise your patch was more or less what I had tried in my working dir after seeing the report. You also need the change to BitBlt, otherwise the bitmaps get white backgrounds too. The tooltip delay has been on my todo list forever, so I'm glad to see a patch fot it too. However I'm not sure if calculating a delay based on the size of the tooltip is a great idea. Why not? The delay will never be shorter than the default, FWIW. I had planned to just set the delay to infinity (or whatever the max time is), and eliminate the question of how long to pause, and just have it disappear when the user moves off of the control. Huh, for some reason I was under the mistaken impression that the tooltip stayed shown for the duration of the delay even if the mouse left the control... I just verified that it works as you described -- so a long default delay is fine too. You can simply insert SendMessage(TooltipHandle, TTM_SETDELAYTIME, TTDT_AUTOPOP, 32767); into ActivateTooltips() and scrap my patch (though I kinda like the fact that tooltips disappear faster, just in case I want to keep my mouse on a button for a while). Does anyone else have an opinion on the tooltip delay? Is an infinite delay a UI no-no? I don't think we can make the delay infinite, anyway, but with almost 33 seconds, let's just make sure we don't have 2-page tooltips. :-) I didn't include them in this .2 update because I wanted to just get something out ASAP since the crashing seemed to be an acute problem. That's ok. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: HEADSUP: pcre security announcement
On Wed, 7 Sep 2005, Corinna Vinschen wrote: First a question to the maintainers in general: There's a dependency in pcre's setup.hint which pulls in the old libpcre which I created ages ago and which lacks versioning support. I just checked and we don't have any package left which requires the old libpcre. Shouldn't we finally pull this crap from the distro? I'd definitely remove it from pcre's setup.hint, but leave it in the obsolete category, as there may be self-compiled binaries depending on it. On Sep 6 16:51, Yaakov S wrote: Corinna Vinschen wrote: Two weeks and no response. Unfortunately we have this security issue and also a couple of packages relying on libpcre. So we would need either a quick response from Ronald or somebody willing to take over the package fairly quickly. Anybody, please? Here you go. Since a lot of key programs (i.e. grep) depend on this, please test and make sure that this doesn't break anything. First of all, many many thank for taking over. This is definitely worth a gold star. GR! Huh, did I miss something? ;-) BTW, should Alan Hourihane get a few as well? Did you run the testsuite? Did you already install it on your machine instead of the current pcre? Otherwise, seriously, how do we test this package expect for installing it?!? I did some simple grep -P tests which still work, AFAICS, and ... ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-6.3-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-6.3-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/pcre/setup.hint ftp://sunsite.dk/projects/cygwinports/release/pcre/libpcre0/libpcre0-6.3-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/pcre/libpcre0/setup.hint ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-devel/pcre-devel-6.3-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-doc/pcre-doc-6.3-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/pcre/pcre-doc/setup.hint ... the packaging looks good, so, if you don't mind, I don't mind to upload it immediately and throw the Cygwin community into cold water. Hehe, how exquisitely mean... :-) I just would like to remove the libpcre dependency, even if we don't remove the libpcre package. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Temporary change to pine's setup.hint
Ping. On Wed, 31 Aug 2005, Igor Pechtchanski wrote: Hi, According to http://cygwin.com/ml/cygwin/2005-08/msg01402.html, pine currently needs the tcsh package to function properly. Please update the setup.hint on sourceware. The new setup.hint is inline below: - setup.hint - sdesc: A text based E-Mail and Newsreader. It includes Pico ldesc: Program for managing E-mail and News (USENET). It supports IMAP/(E)SMTP/POP3/LDAP/NNTP/MIME. It includes the editor Pico category: Mail requires: crypt openssl cygwin tcsh - setup.hint - Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Drop textmode from setup?
On Wed, 7 Sep 2005, Corinna Vinschen wrote: I mean it! Mean, eh? :-) I don't want to drop textmode support from Cygwin(*), You mean, not just yet? but why do we still give the user the choice in the first place? If the user can't choose textmode in the base installation, we will have a lot more sane binmode installations in future and people will use textmode only if they (think they) know what they are doing. My first response was Well, if you're prepared to deal with people saying I created a file in Cygwin, and opened it in Notepad, and now it looks like one big line, go for it... Then I realized it's not true for all programs (e.g., vi doesn't do that), but let's review some of the possible complaints, so that we're prepared to handle them. At least, it's about time to publish the latest setup version with the improved interface which very explicit recommends UNIX mode. Yes, definitely. It's been time for a while. There were some outstanding issues -- IIRC, at least one has been fixed. Brian, what do you say? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Drop textmode from setup?
On Wed, 7 Sep 2005, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: I mean it! Mean, eh? :-) I don't want to drop textmode support from Cygwin(*), You mean, not just yet? but why do we still give the user the choice in the first place? If the user can't choose textmode in the base installation, we will have a lot more sane binmode installations in future and people will use textmode only if they (think they) know what they are doing. I also meant to add that if we had an Advanced Settings pane in setup, the mount mode setting would go in there. My first response was Well, if you're prepared to deal with people saying I created a file in Cygwin, and opened it in Notepad, and now it looks like one big line, go for it... Then I realized it's not true for all programs (e.g., vi doesn't do that), but let's review some of the possible complaints, so that we're prepared to handle them. At least, it's about time to publish the latest setup version with the improved interface which very explicit recommends UNIX mode. Yes, definitely. It's been time for a while. There were some outstanding issues -- IIRC, at least one has been fixed. Brian, what do you say? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Temporary change to pine's setup.hint
On Wed, 7 Sep 2005, Corinna Vinschen wrote: On Sep 7 09:01, Igor Pechtchanski wrote: Ping. On Wed, 31 Aug 2005, Igor Pechtchanski wrote: Hi, According to http://cygwin.com/ml/cygwin/2005-08/msg01402.html, pine currently needs the tcsh package to function properly. Please update the setup.hint on sourceware. The new setup.hint is inline below: Pong. Already done two days ago. Thanks! Shame on me for waiting for the confirmation message on cygwin-apps instead of checking sourceware myself. :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: HEADSUP: pcre security announcement
On Wed, 7 Sep 2005, Corinna Vinschen wrote: On Sep 7 08:47, Igor Pechtchanski wrote: On Wed, 7 Sep 2005, Corinna Vinschen wrote: First of all, many many thank for taking over. This is definitely worth a gold star. GR! Huh, did I miss something? ;-) BTW, should Alan Hourihane get a few as well? Er... didn't he get them already? D'oh! Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
[PATCH] setup: fix text background in chooser
On Wed, 7 Sep 2005, Eric Blake wrote:
I have updated the Cygwin setup utility to version 2.510.2.1.
[snip]
Minor bugs I have noticed:
On the file chooser page, all text has a white background rather
than using the default background selected by the current Windows
settings, as shown in the attachment. This was on Win2k, where the
default background color is chosen by Display properties, Appearance
tab, Item dropdown, Window.
[snip]
I was able to reproduce this on WinXP. The attached patch fixes the issue
for me. I haven't yet tested on Win2k (will tomorrow). ChangeLog below.
Igor
==
ChangeLog:
2005-09-07 Igor Pechtchanski [EMAIL PROTECTED]
* PickCategoryLine.cc (PickCategoryLine::paint): Set background mode.
Use bitwise AND to blit bitmaps.
* PickPackageLine.cc (PickPackageLine::paint): Ditto.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: PickCategoryLine.cc
===
RCS file: /cvs/cygwin-apps/setup/PickCategoryLine.cc,v
retrieving revision 2.8
diff -u -p -r2.8 PickCategoryLine.cc
--- PickCategoryLine.cc 21 May 2005 23:04:02 - 2.8
+++ PickCategoryLine.cc 8 Sep 2005 03:09:57 -
@@ -31,6 +31,7 @@ PickCategoryLine::empty (void)
void
PickCategoryLine::paint (HDC hdc, HRGN hUpdRgn, int x, int y, int row, int
show_cat)
{
+ int bkMode = SetBkMode(hdc, TRANSPARENT);
int r = y + row * theView.row_height;
if (show_label)
{
@@ -40,7 +41,7 @@ PickCategoryLine::paint (HDC hdc, HRGN h
// draw the '+' or '-' box
SelectObject (theView.bitmap_dc,
(collapsed ? theView.bm_treeplus :
theView.bm_treeminus));
- BitBlt (hdc, x2, by, 11, 11, theView.bitmap_dc, 0, 0, SRCCOPY);
+ BitBlt (hdc, x2, by, 11, 11, theView.bitmap_dc, 0, 0, SRCAND);
// draw the category name
TextOut (hdc, x2 + 11 + ICON_MARGIN, r, cat.first.c_str(),
cat.first.size());
@@ -54,7 +55,7 @@ PickCategoryLine::paint (HDC hdc, HRGN h
// draw the 'spin' glyph
SelectObject (theView.bitmap_dc, theView.bm_spin);
spin_x = x2 + 11 + ICON_MARGIN + labellength + ICON_MARGIN;
- BitBlt (hdc, spin_x, by, 11, 11, theView.bitmap_dc, 0, 0, SRCCOPY);
+ BitBlt (hdc, spin_x, by, 11, 11, theView.bitmap_dc, 0, 0, SRCAND);
// draw the caption ('Default', 'Install', etc)
TextOut (hdc, spin_x + SPIN_WIDTH + ICON_MARGIN, r,
@@ -104,6 +105,7 @@ PickCategoryLine::paint (HDC hdc, HRGN h
SelectClipRgn (hdc, hUpdRgn);
}
}
+ SetBkMode(hdc, bkMode);
}
int
Index: PickPackageLine.cc
===
RCS file: /cvs/cygwin-apps/setup/PickPackageLine.cc,v
retrieving revision 2.18
diff -u -p -r2.18 PickPackageLine.cc
--- PickPackageLine.cc 1 Sep 2005 15:49:58 - 2.18
+++ PickPackageLine.cc 8 Sep 2005 03:09:57 -
@@ -22,12 +22,13 @@ void
PickPackageLine::DrawIcon (HDC hdc, int x, int y, HANDLE hIcon)
{
SelectObject (theView.bitmap_dc, hIcon);
- BitBlt (hdc, x, y, 11, 11, theView.bitmap_dc, 0, 0, SRCCOPY);
+ BitBlt (hdc, x, y, 11, 11, theView.bitmap_dc, 0, 0, SRCAND);
}
void
PickPackageLine::paint (HDC hdc, HRGN unused, int x, int y, int col_num, int
show_cat)
{
+ int bkMode = SetBkMode(hdc, TRANSPARENT);
int rb = y + theView.tm.tmHeight;
int by = rb - 11; // top of box images
String s;
@@ -124,6 +125,8 @@ PickPackageLine::paint (HDC hdc, HRGN un
s += String(: ) + pkg.SDesc ();
TextOut (hdc, x + HMARGIN / 2, y, s.c_str(), s.size());
}
+
+ SetBkMode(hdc, bkMode);
}
int
[PATCH] setup: increase tooltip delay for larger tooltips
On Wed, 7 Sep 2005, Eric Blake wrote:
I have updated the Cygwin setup utility to version 2.510.2.1.
[snip]
Minor bugs I have noticed:
[snip]
The tooltip for the View button disappears before I have had a
chance to finish reading it, since it contains so much text.
The attached patch increases tooltip limits for tooltips larger than 80
characters, proportionally to the extra size. The delay calculation is
rather arbitrary -- I got about 20 seconds on the tooltip Eric complained
about.
Note: I think the maximum tooltip delay is 32768ms -- anything larger than
that was ignored (this is undocumented, but may be implied by
LPARAM==short). That's the reason for the 0.5 factor in the delay
calculation. To make the code more robust, we should probably test for
overflow and max out at some value.
As usual, the ChangeLog is below.
Igor
==
ChangeLog:
2005-09-07 Igor Pechtchanski [EMAIL PROTECTED]
* window.h (Window::TooltipDisplayHandler): New member function.
* window.cc (Window::TooltipDisplayHandler): Set delay proportional
to tooltip length.
* proppage.cc (PropertyPage::DialogProc): Call TooltipDisplayHandler
for TTN_SHOW notifications.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: proppage.cc
===
RCS file: /cvs/cygwin-apps/setup/proppage.cc,v
retrieving revision 2.17
diff -u -p -r2.17 proppage.cc
--- proppage.cc 21 May 2005 23:04:03 - 2.17
+++ proppage.cc 8 Sep 2005 03:10:17 -
@@ -256,6 +256,10 @@ PropertyPage::DialogProc (UINT message,
{
return TooltipNotificationHandler (lParam);
}
+ case TTN_SHOW:
+{
+ return TooltipDisplayHandler (wParam, lParam);
+}
default:
{
// Unrecognized notification
Index: window.cc
===
RCS file: /cvs/cygwin-apps/setup/window.cc,v
retrieving revision 2.13
diff -u -p -r2.13 window.cc
--- window.cc 7 May 2005 04:27:08 - 2.13
+++ window.cc 8 Sep 2005 03:10:17 -
@@ -483,3 +483,33 @@ Window::TooltipNotificationHandler (LPAR
return FALSE;
}
+BOOL
+Window::TooltipDisplayHandler (WPARAM wParam, LPARAM lParam)
+// this is the handler for TTN_SHOW notifications
+{
+ NMHDR *hdr = (NMHDR *)lParam;
+ int ctrlID = GetDlgCtrlID ((HWND)hdr-idFrom);
+ std::mapint, int::iterator findID = TooltipStrings.find (ctrlID);
+ int len, delay;
+
+ if (ctrlID != 0 findID != TooltipStrings.end ()) {
+
+// reset timeout for tooltips
+SendMessage(TooltipHandle, TTM_SETDELAYTIME, TTDT_AUTOPOP, -1);
+
+// Fetch the string resource
+TCHAR buf[2048];
+LoadString (GetInstance (), findID-second, (LPTSTR)buf,
+(sizeof (buf) / sizeof (TCHAR)));
+
+// increase timeout proportionally for longer tooltips
+if ((len = strlen(buf)) 80) {
+ delay = SendMessage(TooltipHandle, TTM_GETDELAYTIME, TTDT_AUTOPOP, 0);
+ delay = (int) (delay * (len + 80) * 0.5 / 80);
+ SendMessage(TooltipHandle, TTM_SETDELAYTIME, TTDT_AUTOPOP, delay);
+}
+ }
+
+ return FALSE;
+}
+
Index: window.h
===
RCS file: /cvs/cygwin-apps/setup/window.h,v
retrieving revision 2.11
diff -u -p -r2.11 window.h
--- window.h7 May 2005 04:27:08 - 2.11
+++ window.h8 Sep 2005 03:10:17 -
@@ -148,6 +148,7 @@ public:
void AddTooltip (int id, const char *text);
void AddTooltip (int id, int string_resource);
BOOL TooltipNotificationHandler (LPARAM lParam);
+ BOOL TooltipDisplayHandler (WPARAM wParam, LPARAM lParam);
};
#endif /* SETUP_WINDOW_H */
Re: Recent setup patches
On Wed, 7 Sep 2005, Igor Pechtchanski wrote: 2005-09-07 Igor Pechtchanski [EMAIL PROTECTED] * PickCategoryLine.cc (PickCategoryLine::paint): Set background mode. Use bitwise AND to blit bitmaps. * PickPackageLine.cc (PickPackageLine::paint): Ditto. 2005-09-07 Igor Pechtchanski [EMAIL PROTECTED] * window.h (Window::TooltipDisplayHandler): New member function. * window.cc (Window::TooltipDisplayHandler): Set delay proportional to tooltip length. * proppage.cc (PropertyPage::DialogProc): Call TooltipDisplayHandler for TTN_SHOW notifications. 2005-09-07 Igor Pechtchanski [EMAIL PROTECTED] * state.cc (no_warn_if_older): New global variable. * state.h (no_warn_if_older): Declare it. * main.cc (NoWarnIfOlderOption): New boolean option. * ini.cc (do_ini_thread): Don't warn about newer setup if no_warn_if_older is true. * IniDBBuilderPackage.cc (IniDBBuilderPackage::buildVersion): Ditto. FWIW, I have commit rights to cygwin-apps (including setup), so I can apply these myself. Brian, let me know if you want me to do that. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [PATCH] Update of size column patch for setup (Was Re: Is setup-2.506 ready to release?)
On Thu, 1 Sep 2005, Brian Dessent wrote: Igor Pechtchanski wrote: Ok, attached is a quick update to that patch -- please let me know if it needs more work. ChangeLog is at the end of this message. Thanks for the patch, I've applied it with a minor change to the logic that computes the size. In your version, if you clicked on Src for a package that was currently installed, the size column would display only the size of the source package and not the size of the combined bin+src. That makes sense from the standpoint of what has to be downloaded but it doesn't make sense from the standpoint of how much disk space will be occupied (which is how I interpret the meaning of the column.) Actually, I think it makes more sense to treat it as the amount of *extra* disk space that will be occupied after the downloads (since it doesn't account for the expanded size of the tarball anyway). I'll see if I can change the logic accordingly at some point soon. In some cases choosing to install the source package would cause the size column to decrease which is counterintuitive to the action of selecting an additional thing to be downloaded and installed. The modified version displays the sizeof(bin) or sizeof(bin+src) if src is also selected, but never just sizeof(src). As I said above, if the binary is installed, it shouldn't actually figure in the size calculations, IMO. And sorry for the delay in getting to this. No problem. On an unrelated note, do we want to resurrect Max's colorization patch (one that color-codes the packages according to their installed status, from wa-ay back when [Jan 2003])? Igor [Jan 2003] http://cygwin.com/ml/cygwin-apps/2003-01/msg00361.html -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ITP] texi2html: A highly customizable texinfo to HTML and other formats translator
On Mon, 5 Sep 2005, Christopher Faylor wrote: On Mon, Sep 05, 2005 at 06:10:04PM +0200, Dr. Volker Zell wrote: Here is the setup.hint file: sdesc: A highly customizable texinfo to HTML and other formats translator ldesc: The basic purpose of texi2html is to convert Texinfo documents into HTML, and other formats. Configuration files written in perl provide fine degree of control over the final output, allowing most every aspect of the final output not specified in the Texinfo input file to be specified. category: Text requires: cygwin perl cut here #!/bin/bash mkdir texi2html cd texi2html wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/texi2html/setup.hint wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/texi2html/texi2html-1.76-1-src.tar.bz2 wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/texi2html/texi2html-1.76-1.tar.bz2 cut here Uploaded. Thank you! Ditto, ditto, ditto. I don't have the power to give out gold stars (only to add them to the web page), but this case, I'd say, deserves one. CGF? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [PATCH] Update of size column patch for setup (Was Re: Is setup-2.506 ready to release?)
On Mon, 5 Sep 2005, Brian Dessent wrote: Igor Pechtchanski wrote: Actually, I think it makes more sense to treat it as the amount of *extra* disk space that will be occupied after the downloads (since it doesn't account for the expanded size of the tarball anyway). I'll see if I can change the logic accordingly at some point soon. The problem there is that by that interpretation, the size column should be zero for every row except those packages which have been selected to download/install/upgrade. That would be quite confusing, since you can no longer use the column to judge size before picking a package. Ah, I see. Yes, that would be a problem. How about naming it estimated download size (or 'Size to Download', just to get a reasonable cut-off), and setting it to '0k' for packages that are already installed? Otherwise you get the baffling situation of clicking Src and seeing the number decrease, despite the fact that you have just added more bytes to download and more hard drive space to be occupied. Using '0k' for installed packages would take care of this problem, won't it? I think the notion of amount that will be downloaded would be better expressed as a running total that is displayed on a different part of the dialog, rather than in the size column. We could do both. In fact, the number of bytes to download is a better progress indicator than the number of packages... No problem. On an unrelated note, do we want to resurrect Max's colorization patch (one that color-codes the packages according to their installed status, from wa-ay back when [Jan 2003])? I never saw that one. I'll look at it, but I'm a little hesitent that it might add more confusion to an already confusing interface. Plus when colors are involved, everyone has a different idea of what looks good, not to mention that end users will have varied visual themes / color schemes selected in display options. Read the whole thread from that message onward (and Google for Max Bowsher colour patch -- yes, the British spelling)... This was discussed, but never got anywhere. To be honest the next feature that I think needs to go in is some means of controlling the window size, such as saving/restoring the last window size/position. I say that because with the addition of this size column, the default starting size of the package picker page is now such that the description field is nearly entirely off the screen, and the user almost certainly will have to resize the dialog. Saving/restoring the window coordinates saves us from having to make any decisions about how large or small it should be - the user just resizes it once to whatever is desired and then it persists. Definitely. I was thinking of adding another preference file, such as /etc/setup/last-options or something that would store this information as well as anything similar. E.g. we could have the create desktop icon choice persist as well. That would be a good idea (in fact, why not consolidate all of the preferences files into one?). Also, it may be time to move them from files into the registry -- this has also been discussed previously. Some more random ideas -- a right-click context menu in the chooser. One possible context menu item is Lock (which locks a given version and doesn't attempt to update it). The list of locked packages could also be kept in the registry, or, better yet, we could mark them off in installed.db. I know, PTC -- I'm working on it. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Temporary change to pine's setup.hint
Hi, According to http://cygwin.com/ml/cygwin/2005-08/msg01402.html, pine currently needs the tcsh package to function properly. Please update the setup.hint on sourceware. The new setup.hint is inline below: - setup.hint - sdesc: A text based E-Mail and Newsreader. It includes Pico ldesc: Program for managing E-mail and News (USENET). It supports IMAP/(E)SMTP/POP3/LDAP/NNTP/MIME. It includes the editor Pico category: Mail requires: crypt openssl cygwin tcsh - setup.hint - Thanks, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: [ITP] singular-*-3.0.0-1, updated directory layout
On Fri, 26 Aug 2005, Oliver Wienand wrote: Binaries goes to /usr/share/lib/Singular Sorry, but this is a problem. /usr/share is for machine-independent stuff; binaries should go to /usr/lib. I suggest changing this to /usr/lib/Singular. Otherwise the structure looks ok to me. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Please test and upload: ORBit/libIDL, libIDL2, ORBit2
On Thu, 25 Aug 2005, Dr. Volker Zell wrote:
BTW, every GNOME package from you I try to build with .sh all
gives me as the last output line
rm: cannot remove directory `/usr/src/XXX/.sinst': Device or resource
busy
where XXX is the package name. Afterwards I'll be left with an empty
/usr/src/XXX/.inst directory which I have to remove manually. Not a
showstopper but just curious if somebody gets the same.
You could try running bash -x XXX.sh... I suspect this could be
caused by some leftover process still having ${srcinstdir} as its working
directory when the g-b-s tries to rm -rf ${srcdir}, but I don't know
which process it could be. You could try inserting a call to handle
from SysInternals, to see if that lets you catch the perpetrator.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Error in g-b-s (line 408: almostall: command not found)
On Tue, 23 Aug 2005, Marcel Telka wrote: On Mon, Aug 15, 2005 at 10:10:05AM -0400, Igor Pechtchanski wrote: On Sat, 13 Aug 2005, Eric Blake wrote: This patch fixes that (and a few other things)... 2005-08-13 Eric Blake [EMAIL PROTECTED] * templates/generic-build-script (build): Variables must be set after make to override Makefile's setting. (test_rule): Default to check, since FSF coding standards and automake prefer that. (install_docs): Add USAGE. (list): Sort the list. (LC_ALL): Set, to ensure sane behavior with sort and others. (src_orig_pkg_name): Improve error message. (all): Fix broken usage of almostall. Thanks, I'll review and apply this later today. Looks like this subsumes your 8/1 patch (http://cygwin.com/ml/cygwin-apps/2005-08/msg2.html). ping Pong. Thanks for the reminder. Applied. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Is setup-2.506 ready to release?
I've been pointing people to setup-2.506-alpha.exe for a while now, with no problem reports. It's been repeatedly dubbed a release candidate by various developers. Any reason why it hasn't been released yet? The reason I'm asking is that there are a few pending patches to setup, which, I assume, aren't going in until after the next release. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: Is setup-2.506 ready to release?
On Fri, 19 Aug 2005, Brian Dessent wrote: Igor Pechtchanski wrote: I've been pointing people to setup-2.506-alpha.exe for a while now, with no problem reports. It's been repeatedly dubbed a release candidate by various developers. Any reason why it hasn't been released yet? The reason I'm asking is that there are a few pending patches to setup, which, I assume, aren't going in until after the next release. Yes, there are still a couple of minor little things that I had hoped to give attention to, but unfortunately just never got around to it. Would you mind summarizing these if you have them handy? I could probably find them in the archives, but searching for setup issues is notoriously hard to get right... :-) What we have now is probably better than the current released setup anyway, so going ahead with a release probably wouldn't be a bad idea. WRT to your patch that adds the size column, I would like to apply it but I was hoping for a version that used MB instead of bytes, so that the column is a little easier to read. If you already posted that one then please forgive me as I must have missed it. No, it's my fault -- I've been meaning to get back to it and fix it, but got sidetracked (though I was planning to use the ...k formatting). I'll see what I can do in the next week or so. FWIW, I'm not going to be particularly disappointed if it doesn't appear in the next release... Also, that change that makes it try bash instead of sh for scripts should go in if we're about to release. Would it be possible to post a list of outstanding issues with setup (I mean all issues, not just those that should be fixed before the release)? Or are they in bugzilla already? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
[PATCH] Update of size column patch for setup (Was Re: Is setup-2.506 ready to release?)
On Fri, 19 Aug 2005, Igor Pechtchanski wrote:
On Fri, 19 Aug 2005, Brian Dessent wrote:
WRT to your patch that adds the size column, I would like to apply it
but I was hoping for a version that used MB instead of bytes, so that
the column is a little easier to read. If you already posted that one
then please forgive me as I must have missed it.
No, it's my fault -- I've been meaning to get back to it and fix it, but
got sidetracked (though I was planning to use the ...k formatting).
I'll see what I can do in the next week or so. FWIW, I'm not going to be
particularly disappointed if it doesn't appear in the next release...
Ok, attached is a quick update to that patch -- please let me know if it
needs more work. ChangeLog is at the end of this message.
Also, that change that makes it try bash instead of sh for scripts
should go in if we're about to release.
FWIW, I also have another patch, one that propagates the exit code of
postinstall scripts to setup. It doesn't yet do anything about the exit
code, though. I'll send that one out in a separate message.
Igor
==
ChangeLog:
2005-08-19 Igor Pechtchanski [EMAIL PROTECTED]
* PickView.h (PickView::size_col): New instance variable.
* PickView.cc (pkg_headers, cat_headers): Add size column.
(PickView::set_headers): Initialize size_col.
(PickView::init_headers): Include width of size column.
* PickPackageLine.cc (PickPackageLine::paint): Handle size_col.
* String++.cc (format_1000s): New function.
* String++.h (format_1000s): Declare new function.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: PickPackageLine.cc
===
RCS file: /cvs/cygwin-apps/setup/PickPackageLine.cc,v
retrieving revision 2.16
diff -u -p -r2.16 PickPackageLine.cc
--- PickPackageLine.cc 21 May 2005 23:04:02 - 2.16
+++ PickPackageLine.cc 19 Aug 2005 17:52:10 -
@@ -88,6 +88,28 @@ PickPackageLine::paint (HDC hdc, HRGN un
TextOut (hdc, x + HMARGIN / 2, y, s.c_str(), s.size());
}
}
+ else if (col_num == theView.size_col)
+{
+ int sz = 0;
+ // Use chosen version or the default
+ packageversion picked = pkg.desired;
+ if (!picked) picked = pkg.trustp(theView.deftrust);
+ // If source is picked, add up the size
+ if (picked.sourcePackage().picked())
+sz += picked.sourcePackage().source()-size;
+ // If binary or nothing is picked, add up the binary size
+ if (picked.picked() || sz == 0)
+ sz += picked.source()-size;
+ // If no binary, add up the source size
+ if (sz == 0)
+sz += picked.sourcePackage().source()-size;
+ // If size still 0, size must be unknown
+ s = (sz == 0) ? ? : format_1000s((sz+1023)/1024) + k;
+ SIZE tw;
+ GetTextExtentPoint32 (hdc, s.c_str(), s.size(), tw);
+ int cw = theView.headers[col_num].width - HMARGIN - tw.cx;
+ TextOut (hdc, x + cw + HMARGIN / 2, y, s.c_str(), s.size());
+}
else if (col_num == theView.pkg_col)
{
s = pkg.name;
Index: PickView.cc
===
RCS file: /cvs/cygwin-apps/setup/PickView.cc,v
retrieving revision 2.24
diff -u -p -r2.24 PickView.cc
--- PickView.cc 21 May 2005 23:04:02 - 2.24
+++ PickView.cc 19 Aug 2005 17:52:11 -
@@ -34,6 +34,7 @@ static PickView::Header pkg_headers[] =
{Bin?, 0, 0, false},
{Src?, 0, 0, false},
{Categories, 0, 0, true},
+ {Size, 0, 0, true},
{Package, 0, 0, true},
{0, 0, 0, false}
};
@@ -44,6 +45,7 @@ static PickView::Header cat_headers[] =
{New, 0, 0, true},
{Bin?, 0, 0, false},
{Src?, 0, 0, false},
+ {Size, 0, 0, true},
{Package, 0, 0, true},
{0, 0, 0, false}
};
@@ -98,7 +100,8 @@ PickView::set_headers ()
bintick_col = new_col + 1;
srctick_col = bintick_col + 1;
cat_col = srctick_col + 1;
- pkg_col = cat_col + 1;
+ size_col = cat_col + 1;
+ pkg_col = size_col + 1;
last_col = pkg_col;
}
else if (view_mode == views::Category)
@@ -109,7 +112,8 @@ PickView::set_headers ()
bintick_col = new_col + 1;
srctick_col = bintick_col + 1;
cat_col = 0;
- pkg_col = srctick_col + 1;
+ size_col = srctick_col + 1;
+ pkg_col = size_col + 1;
last_col = pkg_col;
}
else
@@ -443,9 +447,15 @@ PickView::init_headers (HDC dc
[PATCH] Propagate exit codes of scripts to setup
As promised, here's a patch that makes Script::run() (and
try_run_script()) return the exit code of the script. This just sets up
the infrastructure -- the exit code is currently ignored (well, logged),
but that could be changed later in both Installer::preremoveOne(),
packagemeta::uninstall(), and do_postinstall_thread().
As usual, the ChangeLog is below.
Igor
==
ChangeLog:
2005-08-19 Igor Pechtchanski [EMAIL PROTECTED]
* script.cc (run): Change to return the exit code or negative error.
(Script::run): Ditto.
(try_run_script): Receive both filename and extension and run only
one script. Also return the exit code.
* script.h (try_run_script): Change signature.
(Script::run): Ditto.
* postinstall.cc (RunScript::operator()): Change to return the exit
code or negative error.
* install.cc (Installer::preremoveOne): Pass extension to
try_run_script().
* package_meta.cc (packagemeta::uninstall): Ditto.
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: install.cc
===
RCS file: /cvs/cygwin-apps/setup/install.cc,v
retrieving revision 2.76
diff -u -p -r2.76 install.cc
--- install.cc 14 May 2005 15:30:06 - 2.76
+++ install.cc 19 Aug 2005 18:14:43 -
@@ -143,7 +143,8 @@ Installer::preremoveOne (packagemeta p
Progress.SetText1 (Running preremove script...);
Progress.SetText2 (pkg.name.c_str());
log (LOG_PLAIN) Running preremove script forpkg.name endLog;
- try_run_script (/etc/preremove/, pkg.name);
+ try_run_script (/etc/preremove/, pkg.name, .sh);
+ try_run_script (/etc/preremove/, pkg.name, .bat);
}
void
Index: package_meta.cc
===
RCS file: /cvs/cygwin-apps/setup/package_meta.cc,v
retrieving revision 2.48
diff -u -p -r2.48 package_meta.cc
--- package_meta.cc 14 May 2005 15:30:06 - 2.48
+++ package_meta.cc 19 Aug 2005 18:14:43 -
@@ -201,7 +201,8 @@ packagemeta::uninstall ()
if (RemoveDirectory (d.c_str()))
log (LOG_BABBLE) rmdir d endLog;
}
- try_run_script (/etc/postremove/, name);
+ try_run_script (/etc/postremove/, name, .sh);
+ try_run_script (/etc/postremove/, name, .bat);
}
installed = packageversion();
}
Index: postinstall.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v
retrieving revision 2.19
diff -u -p -r2.19 postinstall.cc
--- postinstall.cc 5 May 2005 22:48:36 - 2.19
+++ postinstall.cc 19 Aug 2005 18:14:43 -
@@ -59,7 +59,7 @@ private:
vectorScript *_scripts;
};
-class RunScript : public unary_functionScript const , void
+class RunScript : public unary_functionScript const , int
{
public:
RunScript(String const name, int num) : _num(num), _cnt(0)
@@ -71,12 +71,14 @@ public:
{
Progress.SetText3 ();
}
- void operator() (Script const aScript)
+ int operator() (Script const aScript)
{
+ int retval;
Progress.SetText3 (aScript.fullName().c_str());
- aScript.run();
+ retval = aScript.run();
++_cnt;
Progress.SetBar1 (_cnt, _num);
+ return retval;
}
private:
int _num;
Index: script.cc
===
RCS file: /cvs/cygwin-apps/setup/script.cc,v
retrieving revision 2.19
diff -u -p -r2.19 script.cc
--- script.cc 5 May 2005 22:48:36 - 2.19
+++ script.cc 19 Aug 2005 18:14:44 -
@@ -158,14 +158,16 @@ OutputLog::out_to(std::ostream out)
SetFilePointer(_handle, 0, NULL, FILE_END);
}
-static void
+static int
run (const char *sh, const char *args, const char *file, OutputLog file_out)
{
char cmdline[MAX_PATH];
STARTUPINFO si;
PROCESS_INFORMATION pi;
DWORD flags = CREATE_NEW_CONSOLE;
+ DWORD exitCode = 0;
BOOL inheritHandles = FALSE;
+ BOOL exitCodeValid = FALSE;
sprintf (cmdline, %s %s %s, sh, args, file);
memset (pi, 0, sizeof (pi));
@@ -190,10 +192,15 @@ run (const char *sh, const char *args, c
flags, 0, get_root_dir ().c_str(),
si, pi);
- if (createSucceeded)
+ if (createSucceeded) {
WaitForSingleObject (pi.hProcess, INFINITE);
+exitCodeValid = GetExitCodeProcess(pi.hProcess, exitCode);
+ }
CloseHandle(pi.hProcess
Re: upload: diffstat-1.40-1, tar-1.15.1-1
On Wed, 17 Aug 2005, Eric Blake wrote: [snip] Then you went through the sources, and for all files that manipulate human-readable files (such as file name lists, as opposed to actual tars), you added FOPEN_TEXT_READ, defined as rt, to fopen calls, and O_TEXT to open calls. All file manipulations that were on binary files you left alone. This means that in some cases, your patch to 1.13.25 actually created text files (\r\n endings) on a binary mount point. I'm not sure this is correct. fopen(..., rt) should create LF endings on binary mounts and CRLF on text mounts... IIUC, the open mode is a hint to the underlying filesystem whether line ending translation should be done -- the actual translation is done based on the mount type. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: upload: diffstat-1.40-1, tar-1.15.1-1
On Wed, 17 Aug 2005, Christopher Faylor wrote: On Wed, Aug 17, 2005 at 12:22:50PM -0400, Igor Pechtchanski wrote: On Wed, 17 Aug 2005, Eric Blake wrote: [snip] Then you went through the sources, and for all files that manipulate human-readable files (such as file name lists, as opposed to actual tars), you added FOPEN_TEXT_READ, defined as rt, to fopen calls, and O_TEXT to open calls. All file manipulations that were on binary files you left alone. This means that in some cases, your patch to 1.13.25 actually created text files (\r\n endings) on a binary mount point. I'm not sure this is correct. fopen(..., rt) should create LF endings on binary mounts and CRLF on text mounts... IIUC, the open mode is a hint to the underlying filesystem whether line ending translation should be done -- the actual translation is done based on the mount type. Opening with rt bypasses the underlying mount type. Umm, ok. I guess I was confused (and what I mentioned above seems to me a more logical behavior, though I'm not proposing a change). And, it only opens the file for read. Of course, I should have omitted the r (or changed it to a w). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
Re: upload: diffstat-1.40-1, tar-1.15.1-1
On Wed, 17 Aug 2005, Eric Blake wrote: I'm not sure this is correct. fopen(..., rt) should create LF endings on binary mounts and CRLF on text mounts... IIUC, the open mode is a hint to the underlying filesystem whether line ending translation should be done -- the actual translation is done based on the mount type. Opening with rt bypasses the underlying mount type. And, it only opens the file for read. But opening with rt is non-POSIX, while opening with r or rb is POSIX, so the upstream maintainers are more reluctant to accept a patch that uses rt. I have never seen any standards documentation that describes what rt should do, so I assumed that it forced opening a file in text mode (ie. all \r\n in the file are collapsed to \n to the application reading the file, regardless of the mount point of the file). It sounds like you are telling me my assumption was wrong, and that rt on a binary mount point preserves \r? That's what I was saying, but I was confused. Chris said that text mode always forces CRLF-LF conversion on reads and LF-CRLF conversion on writes. The fact that there are no standards for O_TEXT or rt/wt didn't help my confusion any. It seems that wt is rather useless, then. If one wanted to always produce a file with CRLF line endings, she'd open it with O_BINARY and use \r\n sequences for line endings. In any case, rt/wt should be equivalent to O_TEXT... Maybe we need an update to http://cygwin.com/cygwin-ug-net/using-textbinary.html Yes, it does say there is no direct way to specify text mode in an fopen() call, doesn't it? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
