Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
Jeremy Drake via Cygwin writes: > Well, Microsoft's LINK.EXE and LLVM's LLD have already been using these > new defaults for some time. But I was surprised how quickly my patch was > accepted/merged. That was not under dispute in any of the discussions I've seen on this topic. > To clarify, default base addresses should not have changed for cygwin > targets, they were already above 4GB. For 64bit, yes -- so I wasn't overly worried about that. > I have a prelimiary patch that I plan to send upstream once I get some > testing done on it, which reverts the default dll characteristics for > cygwin targets. I don't know if what you've done to 'nix it' for Cygwin > was similar. I've just done what makes it close enough to 2.35.2 in my view: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/binutils.git;a=blob_plain;f=binutils-2.36.1-cygwin-peflags.patch I don't want to carry such a patch for any longer time of course. > I have not seen anything one way or the other on the NXCOMPAT flag. Does > that also needs to be reverted for Cygwin? I don't know. I think maybe not since it should announce itself pretty early in testing, but things are always a bit more complicated than they seem at first. > I have seen the issues you described on 32-bit, but my understanding of > how ASLR works suggested that it should be very rare on 64-bit. That's the crux of the matter. It fails when it produces a collision and the chances of it doing that are going down exponentially with the size of the address space. But the target is not to have it fail rarely, it must not fail at all. > ... but now that you mention the stack moving, yes, I could see that > being an issue. Note that I don't have an idea if the stack really got moved or something else mapped into the space formerly occupied by the stack. Either way would be surprising since the case where it happened isn't using any libraries besides cygwin1.dll. > Yes, the specific field where these flags are stored is called "DLL > Characteristics" so that is how it was referred to, but they do not > exclusively apply to DLLs. > > https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#dll-characteristics Again, the question really is "what does this flag actually do for executables"? ASLR is not very well documented beyond the fact that it exists and the odd blog post here and there as far as I can tell. Its been changed quite a bit over the time too, but which change went into which release of Windows (or patches) is not documented, again AFAIK. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
On Sun, 28 Feb 2021, ASSI wrote:
> > Is this still problematic for cygwin?
>
> Yes it is and I'm currently figuring out how to best get rid of it in
> order to be able to update binutils (why this was ever allowed in
> without an accompanying configure option is a mystery to me).
Well, Microsoft's LINK.EXE and LLVM's LLD have already been using these
new defaults for some time. But I was surprised how quickly my patch was
accepted/merged.
> I've
> already nixed it for Cygwin, but I'm not yet sure what to do for the
> cross compilation toolchain. While it should in principle work there,
> I'm pretty sure that there will be problems when it comes to the nitty
> gritty details. It's already transpired that some of the linker scripts
> can't deal with the larger base addresses this change does generate
> eventually.
To clarify, default base addresses should not have changed for cygwin
targets, they were already above 4GB.
I have a prelimiary patch that I plan to send upstream once I get some
testing done on it, which reverts the default dll characteristics for
cygwin targets. I don't know if what you've done to 'nix it' for Cygwin
was similar.
I have not seen anything one way or the other on the NXCOMPAT flag. Does
that also needs to be reverted for Cygwin?
> > The reason I'm asking is because we updated to 2.36 in MSYS2 and are
> > wondering if we need to patch this out (or change the defaults) It
> > seems to work as is right now, but maybe we are just lucky(?).
>
> You are just lucky and need to test more. :-)
I have seen the issues you described on 32-bit, but my understanding of
how ASLR works suggested that it should be very rare on 64-bit.
> Note that the change does not only affect DLL as the commit message
> would want you to believe and you will eventually end up with a
> situation where ASLR tries moves the stack of an executable, at which
> point you can no longer fork.
... but now that you mention the stack moving, yes, I could see that
being an issue.
Yes, the specific field where these flags are stored is called "DLL
Characteristics" so that is how it was referred to, but they do not
exclusively apply to DLLs.
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#dll-characteristicsFrom 39bde2f11a1eb97503bae9cf15f5fc05640e5251 Mon Sep 17 00:00:00 2001
From: Jeremy Drake
Date: Sun, 28 Feb 2021 15:49:08 -0800
Subject: [PATCH] ld: revert default dll characteristics for Cygwin.
Mail thread from
https://cygwin.com/pipermail/cygwin/2021-February/247922.html suggests
these flags will NOT work for Cygwin, which relies on stable address
layouts for their fork() emulation.
In the process, renamed move_default_addr_high shell variable to
cygwin_beahior, as the old name wasn't quite accurate anymore and I
wanted to use it choose which dll characteristics flags to use by
default.
Also copied that switch to pe.em, as it was only in pep.em before but
32-bit also needed to switch defaults for Cygwin.
---
ld/emultempl/pe.em | 13 -
ld/emultempl/pep.em | 40 +---
2 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/ld/emultempl/pe.em b/ld/emultempl/pe.em
index 748a6b49412..9f757cc31dc 100644
--- a/ld/emultempl/pe.em
+++ b/ld/emultempl/pe.em
@@ -5,6 +5,16 @@ if [ -z "$MACHINE" ]; then
else
OUTPUT_ARCH=${ARCH}:${MACHINE}
fi
+
+case ${target} in
+ *-*-cygwin*)
+cygwin_behavior=1
+;;
+ *)
+cygwin_behavior=0;
+;;
+esac
+
rm -f e${EMULATION_NAME}.c
(echo;echo;echo;echo;echo)>e${EMULATION_NAME}.c # there, now line numbers
match ;-)
fragment <--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
Christoph Reiter via Cygwin writes: > To clarify: I was referring to non-cygwin targets. I had assumed you > meant that by "cross compilation toolchain". Then maybe I don't understand what you meant when you said you've built MSys2 packages with ASLR on. The MingW-W64 toolchains indeed target Windows, but the code you compile it with may not exactly be meant to be used that way. I'd like to caution again that the appearance of anything working is unfortunately different from it actually working. I've been seriously trying to enable ASLR on Cygwin several years ago (some vestiges of which are still in the autorebase scripts). After the first rounds of ironing out the (now obvious) kinks, it was always in a state of "almost working" until the day it didn't or the next installation that just never got off the ground (keep in mind these were all installations on pretty much identical hardware from a single master image). > We've only needed this to to work around linker errors, so it's pretty > clear when it is needed as the build will fail. A linker error should just show up when this hits, so yes that's easier to figure out. I'm more concerned about those problems that won't show up until much later. > Anyway, maybe the linked patches can be helpful to you. Yes, thanks for the links. I'm not sure how relevant those are for Cygwin yet, but I'll have a look in more detail later. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
On Sun, Feb 28, 2021 at 3:22 PM ASSI wrote: > > Christoph Reiter via Cygwin writes: > > MSYS2 builds all packages with ASLR since 6 months, so things look > > good. > > That doesn't tell you all that much since you will have to wait for some > unfavorable address space layout constellation to appear for the problem > to announce itself and then you need someone to recognize the reason and > report it back to you. I tend to see this only on 32bit on my > development machine where I have a large amount of dependencies > installed. After a reboot the problem will move somewhere else, which > means that you will need to find another reproducer. To clarify: I was referring to non-cygwin targets. I had assumed you meant that by "cross compilation toolchain". > > We've added a patch that allows reverting the base address if needed: > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-binutils/2001-ld-option-to-move-default-bases-under-4GB.patch > > In other words, that should be the default then since you can't know if > it works otherwise. Also, I really don't think we should need to change > all toolchains to use these options just in order to produce working > executables. If "safer" means "it doesn't work", then there are clearly > easier ways to get there. We've only needed this to to work around linker errors, so it's pretty clear when it is needed as the build will fail. Anyway, maybe the linked patches can be helpful to you. regards -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
Christoph Reiter via Cygwin writes: > MSYS2 builds all packages with ASLR since 6 months, so things look > good. That doesn't tell you all that much since you will have to wait for some unfavorable address space layout constellation to appear for the problem to announce itself and then you need someone to recognize the reason and report it back to you. I tend to see this only on 32bit on my development machine where I have a large amount of dependencies installed. After a reboot the problem will move somewhere else, which means that you will need to find another reproducer. > We've added a patch that allows reverting the base address if needed: > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-binutils/2001-ld-option-to-move-default-bases-under-4GB.patch In other words, that should be the default then since you can't know if it works otherwise. Also, I really don't think we should need to change all toolchains to use these options just in order to produce working executables. If "safer" means "it doesn't work", then there are clearly easier ways to get there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
On Sun, Feb 28, 2021 at 1:16 PM ASSI wrote: > > Christoph Reiter via Cygwin writes: > > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled > > linker > > will give you: > > > >> peflags -v mydll.dll > > mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) > > pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) > > > > Is this still problematic for cygwin? > > Yes it is and I'm currently figuring out how to best get rid of it in > order to be able to update binutils (why this was ever allowed in > without an accompanying configure option is a mystery to me). OK, thanks (nxcompat as well btw?). I've reverted these changes in MSYS2 now: https://github.com/msys2/MSYS2-packages/commit/c5757a43b42fb20730792469facf9a65571a2e81 > I've > already nixed it for Cygwin, but I'm not yet sure what to do for the > cross compilation toolchain. While it should in principle work there, > I'm pretty sure that there will be problems when it comes to the nitty > gritty details. It's already transpired that some of the linker scripts > can't deal with the larger base addresses this change does generate > eventually. MSYS2 builds all packages with ASLR since 6 months, so things look good. We've added a patch that allows reverting the base address if needed: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-binutils/2001-ld-option-to-move-default-bases-under-4GB.patch > > The reason I'm asking is because we updated to 2.36 in MSYS2 and are > > wondering if we need to patch this out (or change the defaults) It > > seems to work as is right now, but maybe we are just lucky(?). > > You are just lucky and need to test more. :-) > > Note that the change does not only affect DLL as the commit message > would want you to believe and you will eventually end up with a > situation where ASLR tries moves the stack of an executable, at which > point you can no longer fork. OK, thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
Christoph Reiter via Cygwin writes: > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker > will give you: > >> peflags -v mydll.dll > mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) > pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) > > Is this still problematic for cygwin? Yes it is and I'm currently figuring out how to best get rid of it in order to be able to update binutils (why this was ever allowed in without an accompanying configure option is a mystery to me). I've already nixed it for Cygwin, but I'm not yet sure what to do for the cross compilation toolchain. While it should in principle work there, I'm pretty sure that there will be problems when it comes to the nitty gritty details. It's already transpired that some of the linker scripts can't deal with the larger base addresses this change does generate eventually. > The reason I'm asking is because we updated to 2.36 in MSYS2 and are > wondering if we need to patch this out (or change the defaults) It > seems to work as is right now, but maybe we are just lucky(?). You are just lucky and need to test more. :-) Note that the change does not only affect DLL as the commit message would want you to believe and you will eventually end up with a situation where ASLR tries moves the stack of an executable, at which point you can no longer fork. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cygwin + binutils 2.36 + ASLR/dynamicbase defaults
Hey, binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker will give you: > peflags -v mydll.dll mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) Is this still problematic for cygwin? The reason I'm asking is because we updated to 2.36 in MSYS2 and are wondering if we need to patch this out (or change the defaults) It seems to work as is right now, but maybe we are just lucky(?). Some context: https://github.com/msys2/MSYS2-packages/pull/2345 regards -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH 1/3 v3] Cygwin: accounts: Unify nsswitch.conf db_* defaults
On Apr 21 20:31, David Macek via Cygwin-patches wrote: > Signed-off-by: David Macek > --- > winsup/cygwin/uinfo.cc | 11 +-- > winsup/doc/ntsec.xml | 21 ++--- > 2 files changed, 11 insertions(+), 21 deletions(-) Thanks, all patches pushed. Corinna -- Corinna Vinschen Cygwin Maintainer
[PATCH 1/3 v3] Cygwin: accounts: Unify nsswitch.conf db_* defaults
Signed-off-by: David Macek
---
winsup/cygwin/uinfo.cc | 11 +--
winsup/doc/ntsec.xml | 21 ++---
2 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 57d90189d3..2d5fc488bb 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -626,15 +626,12 @@ cygheap_pwdgrp::init ()
grp_cache.cygserver.init_grp ();
grp_cache.file.init_grp ();
grp_cache.win.init_grp ();
- /* Default settings:
+ /* Default settings (excluding fallbacks):
passwd: files db
group: files db
db_prefix: auto DISABLED
db_separator: + DISABLED
- db_home: cygwin desc
- db_shell: cygwin desc
- db_gecos: cygwin desc
db_enum: cache builtin
*/
pwd_src = (NSS_SRC_FILES | NSS_SRC_DB);
@@ -831,12 +828,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
c += strspn (c, " \t");
++idx;
}
- /* If nothing has been set, revert to default. */
- if (scheme[0].method == NSS_SCHEME_FALLBACK)
- {
- scheme[0].method = NSS_SCHEME_CYGWIN;
- scheme[1].method = NSS_SCHEME_DESC;
- }
}
}
break;
diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml
index 5287845686..a4c253098d 100644
--- a/winsup/doc/ntsec.xml
+++ b/winsup/doc/ntsec.xml
@@ -1507,19 +1507,16 @@ of each schema when used with
db_home:
-As has been briefly mentioned before, the default setting for
-db_home: is
+db_home: defines no default schemata. If this setting is
not
+present in /etc/nsswitch.conf, the aforementioned fallback
+takes over, which is equivalent to a /etc/nsswitch.conf
+settting of
db_home: /home/%U
-
-So by default, Cygwin just sets the home dir to
-/home/$USERNAME.
-
-
@@ -1590,8 +1587,10 @@ when used with db_shell:
-As for db_home:, the default setting for
-db_shell: is pretty much a constant
+db_shell: defines no default schemata. If this setting is
+not present in /etc/nsswitch.conf, the aforementioned
+fallback takes over, which is equivalent to a
+/etc/nsswitch.conf settting of
@@ -1664,13 +1663,13 @@ The following list describes the meaning of each schema
when used with
Fallback
If none of the schemes given for db_gecos:
- define a non-empty pathname, nothing is added to
+ define a non-empty string, nothing is added to
pw_gecos.
-The default setting for db_gecos: is the empty string.
+db_gecos: defines no default schemata.
--
2.26.1.windows.1
Re: [PATCH 1/3 v2] Cygwin: accounts: Unify nsswitch.conf db_* defaults
On Apr 21 11:12, Corinna Vinschen wrote: > Hi David, > > source patch is ok, just the docs... Patch 2 and 3 are ok, they just don't apply cleanly as long as patch 1 isn't applied. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
Re: [PATCH 1/3 v2] Cygwin: accounts: Unify nsswitch.conf db_* defaults
Hi David, source patch is ok, just the docs... On Apr 20 19:20, David Macek via Cygwin-patches wrote: > diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml > index 5287845686..032bebe4dc 100644 > --- a/winsup/doc/ntsec.xml > +++ b/winsup/doc/ntsec.xml > @@ -874,9 +874,6 @@ set up to all default values: >db_prefix:auto >db_separator: + --> >db_enum: cache builtin > - db_home: /home/%U > - db_shell: /bin/bash > - db_gecos: empty > I'm not exactly happy with removing these lines. While your patch is *technically* correct in terms of schemata, these *are* the default values. The target audience are users. A simple overview like the above is helpful to just look up the defaults, while the technical description below is for the more in-depth view. So from my POV this hunk should be remove from your patch. > id="ntsec-mapping-nsswitch-syntax.title">The > /etc/nsswitch.conf syntax > @@ -1508,15 +1505,8 @@ of each schema when used with > db_home: > > > As has been briefly mentioned before, the default setting for > -db_home: is > - > - > - > - db_home: /home/%U > - > - > - > -So by default, Cygwin just sets the home dir to > +db_home: defines no schemata, which means only the > fallback > +option is used, so by default, Cygwin just sets the home dir to Just adding text on top and trying to keep the former wording intact doesn't do justice to the actual change here. I'd like to suggest a stronger rephrasing, along the lines of db_home: defines no default schemata. If this setting is not present in /etc/nsswitch.conf, the fallback is to set the home directory to /home/$USERNAME. This is equivalent to a /etc/nsswitch.conf settting of db_home: /home/%U Same or similar in the db_shell case. db_gecos is fine as is. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer
[PATCH 1/3 v2] Cygwin: accounts: Unify nsswitch.conf db_* defaults
Signed-off-by: David Macek
---
winsup/cygwin/uinfo.cc | 11 +--
winsup/doc/ntsec.xml | 27 +++
2 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 57d90189d3..2d5fc488bb 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -626,15 +626,12 @@ cygheap_pwdgrp::init ()
grp_cache.cygserver.init_grp ();
grp_cache.file.init_grp ();
grp_cache.win.init_grp ();
- /* Default settings:
+ /* Default settings (excluding fallbacks):
passwd: files db
group: files db
db_prefix: auto DISABLED
db_separator: + DISABLED
- db_home: cygwin desc
- db_shell: cygwin desc
- db_gecos: cygwin desc
db_enum: cache builtin
*/
pwd_src = (NSS_SRC_FILES | NSS_SRC_DB);
@@ -831,12 +828,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
c += strspn (c, " \t");
++idx;
}
- /* If nothing has been set, revert to default. */
- if (scheme[0].method == NSS_SCHEME_FALLBACK)
- {
- scheme[0].method = NSS_SCHEME_CYGWIN;
- scheme[1].method = NSS_SCHEME_DESC;
- }
}
}
break;
diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml
index 5287845686..032bebe4dc 100644
--- a/winsup/doc/ntsec.xml
+++ b/winsup/doc/ntsec.xml
@@ -874,9 +874,6 @@ set up to all default values:
db_prefix:auto
db_separator: + -->
db_enum: cache builtin
- db_home: /home/%U
- db_shell: /bin/bash
- db_gecos: empty
The
/etc/nsswitch.conf syntax
@@ -1508,15 +1505,8 @@ of each schema when used with db_home:
As has been briefly mentioned before, the default setting for
-db_home: is
-
-
-
- db_home: /home/%U
-
-
-
-So by default, Cygwin just sets the home dir to
+db_home: defines no schemata, which means only the fallback
+option is used, so by default, Cygwin just sets the home dir to
/home/$USERNAME.
@@ -1591,14 +1581,11 @@ when used with db_shell:
As for db_home:, the default setting for
-db_shell: is pretty much a constant
+db_shell: defines no schemata, which means only the fallback
+option is used, so by default, Cygwin just sets the home dir to
+/bin/bash.
-
- db_shell: /bin/bash
-
-
-
@@ -1664,13 +1651,13 @@ The following list describes the meaning of each schema
when used with
Fallback
If none of the schemes given for db_gecos:
- define a non-empty pathname, nothing is added to
+ define a non-empty string, nothing is added to
pw_gecos.
-The default setting for db_gecos: is the empty string.
+The default setting for db_gecos: defines no schemata.
--
2.26.1.windows.1
Re: [PATCH 1/2] cygheap_pwdgrp: Don't invent undocumented defaults in nsswitch.conf
On Apr 17 11:30, David Macek via Cygwin-patches wrote:
> ---
> winsup/cygwin/uinfo.cc | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> index 57d90189d3..227faa4248 100644
> --- a/winsup/cygwin/uinfo.cc
> +++ b/winsup/cygwin/uinfo.cc
> @@ -831,12 +831,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
> c += strspn (c, " \t");
> ++idx;
> }
> - /* If nothing has been set, revert to default. */
> - if (scheme[0].method == NSS_SCHEME_FALLBACK)
> - {
> - scheme[0].method = NSS_SCHEME_CYGWIN;
> - scheme[1].method = NSS_SCHEME_DESC;
> - }
> }
> }
>break;
> --
> 2.26.1.windows.1
The defaults are not undocumented, see at least the source, uinfo.cc
line 629ff. If I screwed that up somehow, the right patch is to make
sure the defaults are set right in cygheap_pwdgrp::init, rather than
removing the defaults altogether. If it's really important, we can also
add the exact default settings to the docs.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
[PATCH 1/2] cygheap_pwdgrp: Don't invent undocumented defaults in nsswitch.conf
---
winsup/cygwin/uinfo.cc | 6 --
1 file changed, 6 deletions(-)
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 57d90189d3..227faa4248 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -831,12 +831,6 @@ cygheap_pwdgrp::nss_init_line (const char *line)
c += strspn (c, " \t");
++idx;
}
- /* If nothing has been set, revert to default. */
- if (scheme[0].method == NSS_SCHEME_FALLBACK)
- {
- scheme[0].method = NSS_SCHEME_CYGWIN;
- scheme[1].method = NSS_SCHEME_DESC;
- }
}
}
break;
--
2.26.1.windows.1
Re: /etc/X11/app-defaults/XTerm refers to font "helvetica"
- Original Message - | From: "Rainer Blome" <rainer.bl...@gmx.de> | To: cygwin@cygwin.com | Sent: Thursday, June 30, 2016 1:22:37 PM | Subject: /etc/X11/app-defaults/XTerm refers to font "helvetica" | | Since many months (and probably several Cygwin and X11 releases), | starting `xterm` triggers the following annoying warning (xterm | starts fine otherwise): | | xterm & | Warning: Cannot convert string | "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type | FontStruct | | I have grepped for "helvetica" through my own config files | (`.Xdefaults` etc.) and not found such a font reference. | | The mailing list archives show that at least one other Cygwin user | has encountered the same issue, | and got no answer regarding this specific issue (just for another | font issue). | https://sourceware.org/ml/cygwin/2015-09/msg00184.html | https://sourceware.org/cgi-bin/search.cgi?wm=wrd=extended=all=D=%2Fml%2Fcygwin%2F%25=helvetica | At first glance, internet search provides only less relevant hits. | | It looks like the cause is in file `/etc/X11/app-defaults/XTerm`, in | the following line: | | *SimpleMenu*menuLabel.font: | -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* | | When I comment out that line (using "!"), xterm starts without any | warnings. | | I do not recall having added that line myself, so I assume that it is | part of its default content. | Are users expected to maintain that file? If there's a better choice for Cygwin, the packager probably should apply that as a patch. I see that it's been as-is in xterm sources since 1994... -- Thomas E. Dickey <dic...@invisible-island.net> http://invisible-island.net ftp://invisible-island.net -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
/etc/X11/app-defaults/XTerm refers to font "helvetica"
Since many months (and probably several Cygwin and X11 releases), starting `xterm` triggers the following annoying warning (xterm starts fine otherwise): xterm & Warning: Cannot convert string "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type FontStruct I have grepped for "helvetica" through my own config files (`.Xdefaults` etc.) and not found such a font reference. The mailing list archives show that at least one other Cygwin user has encountered the same issue, and got no answer regarding this specific issue (just for another font issue). https://sourceware.org/ml/cygwin/2015-09/msg00184.html https://sourceware.org/cgi-bin/search.cgi?wm=wrd=extended=all=D=%2Fml%2Fcygwin%2F%25=helvetica At first glance, internet search provides only less relevant hits. It looks like the cause is in file `/etc/X11/app-defaults/XTerm`, in the following line: *SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* When I comment out that line (using "!"), xterm starts without any warnings. I do not recall having added that line myself, so I assume that it is part of its default content. Are users expected to maintain that file? Regards, Rainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH client defaults
On Aug 16 17:24, Max Polk wrote: On a new 64-bit Cygwin install, no /etc/ssh* files or dirs exist, That's what /usr/bin/ssh-host-config is for. I copied over id_dsa and id_dsa.pub into my ~/.ssh, nothing else, and got the directory and file permissions right. Kept running into this failure connecting: debug1: Skipping ssh-dss key /MYPATH/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes If that's the new OpenSSH 7.0, then the deprecation information in the announcement probably explains the problem: https://cygwin.com/ml/cygwin-announce/2015-08/msg00021.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXW5Ccuz_vg.pgp Description: PGP signature
OpenSSH client defaults
On a new 64-bit Cygwin install, no /etc/ssh* files or dirs exist, I copied over id_dsa and id_dsa.pub into my ~/.ssh, nothing else, and got the directory and file permissions right. Kept running into this failure connecting: debug1: Skipping ssh-dss key /MYPATH/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes I noticed that PubkeyAcceptedKeyTypes is new. Apparently the client didn't let me login because id_dsa keys weren't acceptable to Cygwin ssh client. To fix it, I had to create a ~/.ssh/config file and I placed into it a setting to explicitly permit id_dsa style keys (by adding ssh-dss* at the end): Host * PubkeyAcceptedKeyTypes OTHERTHINGS,ssh-dss* Without this ~/.ssh/config permitting id_dsa style keys. In general, to find what kinds of things you can add to PubkeyAcceptedKeyTypes in your config file, run: ssh -Q key -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with Installation: No option to select DOS lines endings, defaults to UNIX.
Do you have any further help as to how I would achieve that? I am new to cygwin and *Nix, so any basic help is appreciated. How to I set it up that all text file will have DOS line endings? RE: Sat, 23 Jan 2010 03:09:10 -0800 On Jan 22 17:12, David Heyman wrote: I am having a problem with an installation of Cygwin. When I run setup.exe, I do not get an option for choosing line endings. So, I want to select DOS ine endings but that option is never available during setup, so it ends up being UNIX line endings. How do I force that option during installation? Please help. Not possible. The bin/textmode option in setup has been removed because setup doesn't create the fstab file. It's done using a script. If you want to use textmode mounts, add them to the fstab file after installation using an editor. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with Installation: No option to select DOS lines endings, defaults to UNIX.
On 1/25/2010 11:51 AM, David Heyman wrote: Do you have any further help as to how I would achieve that? I am new to cygwin and *Nix, so any basic help is appreciated. How to I set it up that all text file will have DOS line endings? http://cygwin.com/cygwin-ug-net/using.html#using-pathnames That will document the general information you need. You will also need to add to /etc/fstab the output of running mount -m where you replace the instances of binary in the fourth column of output with text. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with Installation: No option to select DOS lines endings, defaults to UNIX.
On Jan 22 17:12, David Heyman wrote: I am having a problem with an installation of Cygwin. When I run setup.exe, I do not get an option for choosing line endings. So, I want to select DOS ine endings but that option is never available during setup, so it ends up being UNIX line endings. How do I force that option during installation? Please help. Not possible. The bin/textmode option in setup has been removed because setup doesn't create the fstab file. It's done using a script. If you want to use textmode mounts, add them to the fstab file after installation using an editor. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem with Installation: No option to select DOS lines endings, defaults to UNIX.
I am having a problem with an installation of Cygwin. When I run setup.exe, I do not get an option for choosing line endings. So, I want to select DOS ine endings but that option is never available during setup, so it ends up being UNIX line endings. How do I force that option during installation? Please help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
rxvt-20050409-9 or (less likely) new X clobbered my app-defaults/Rxvt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I updated my cygwin installation, and lost my personal settings in app-defaults/Rxvt (now relocated). I presume this is a side effect of the 'addition' of some backgroundPixmap stuff to that file, per the description of rxvt-20050409-9 2008-11-15 in /usr/share/doc/Cygwin/rxvt-20050409.README If I'm right that this change overwrites, without backing up, the whole app-defaults/Rxvt file, that's. . .unhelpful. Looking at the preremove and postinstall scripts, it looks like this might have been inadvertent, in that the postinstall script installs the default in /etc/X11/app-defaults only if there is nothing there already (correct), _but_ the preremove script in fact removes /etc/X11/app-defaults/Rxvt (incorrect)! Many thanks to Chuck Wilson for maintaining this package, but in future, please try harder not to trash config files without saving a backup. . . ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFJdKa+kjnJixAXWBoRAjuxAJsF77j13N7pN3HZomPWz/l2pqwbJwCbBYvA 1NgRNQ7va8dU1CLtCcb+rSE= =Lt2w -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup-1.7 defaults to Just me
On Apr 15 21:55, Brian Dessent wrote: Corinna Vinschen wrote: I just found that, regardless of my privileges, setup-1.7 defaults to install for just me instead of all users while the standard setup defaults to all users. Why does that happen? This is very odd. Setup's is_admin() was returning 0 despite the user belonging to the administrators group, and debugging revealed that the cause was the following: // Get the group token information UCHAR token_info[1024]; PTOKEN_GROUPS groups = (PTOKEN_GROUPS) token_info; DWORD token_info_len = sizeof (token_info); status = GetTokenInformation (token, TokenGroups, token_info, token_info_len, token_info_len); CloseHandle (token); if (!status) return 0; For whatever reason, GetTokenInformation was failing and returning ERROR_NOACCESS when passed a 1024 byte buffer. I changed the code to first call it with NULL to get the desired size, and that seems to have satisfied it. I cannot explain why it would object to a 1024 byte buffer, maybe you have some idea. Not really, no. 1024 bytes should be big enough in most cases. Did you look for the desired size which now gets returned by the NULL call? I'll install an updated setup-1.7.exe in a moment. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
Corinna Vinschen wrote: Not really, no. 1024 bytes should be big enough in most cases. Did you look for the desired size which now gets returned by the NULL call? Yes, it was in the neighborhood of 230 bytes or so. It wasn't that the buffer was too small, and I would have expected ERROR_INSUFFICIENT_BUFFER anyway in that case. It was just something about the buffer that it didn't like. Brian
Re: setup-1.7 defaults to Just me
On Apr 16 02:12, Brian Dessent wrote: Corinna Vinschen wrote: Not really, no. 1024 bytes should be big enough in most cases. Did you look for the desired size which now gets returned by the NULL call? Yes, it was in the neighborhood of 230 bytes or so. It wasn't that the buffer was too small, and I would have expected ERROR_INSUFFICIENT_BUFFER anyway in that case. It was just something about the buffer that it didn't like. Alignment? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
On Apr 16 11:28, Corinna Vinschen wrote: On Apr 16 02:12, Brian Dessent wrote: Corinna Vinschen wrote: Not really, no. 1024 bytes should be big enough in most cases. Did you look for the desired size which now gets returned by the NULL call? Yes, it was in the neighborhood of 230 bytes or so. It wasn't that the buffer was too small, and I would have expected ERROR_INSUFFICIENT_BUFFER anyway in that case. It was just something about the buffer that it didn't like. Alignment? I mean, token_info was an UCHAR array, so it's not aligned while the token_group information might require a 4 or 8 byte alignment which you now get by chance. Probably you'd be better off not using `char buf[size]' but PTOKEN_GROUPS groups = (PTOKEN_GROUPS) alloca (size); instead because alloca always aligns sufficiently. What sounds strange here is that MSDN does not state anything about alignment requirements for the GetTokenInformation call. However, it also didn't say anything about alignment requirements of ZwQueryDirectoryFile but it failed on W2K for that reason nevertheless. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
On Apr 16 02:45, Brian Dessent wrote: Corinna Vinschen wrote: Alignment? Perhaps. Do you know if gcc aligns VLAs higher than their natural alignment? The nonworking code was just UCHAR foo[1024] whereas the working was char buf[size], which I cribbed from grp.cc:internal_getgroups(). Maybe such a dynamic stack allocation like `char buf[size]' uses an alloca-like function under the hood which also always aligns sufficently for all datatypes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
Corinna Vinschen wrote: Alignment? Perhaps. Do you know if gcc aligns VLAs higher than their natural alignment? The nonworking code was just UCHAR foo[1024] whereas the working was char buf[size], which I cribbed from grp.cc:internal_getgroups(). Brian
Re: setup-1.7 defaults to Just me
On Apr 16 02:49, Brian Dessent wrote: Don't you love discovering these little pearls of joy inside the Win32 API? They're like little rays of sunshine. No wait, the opposite. Big rays of moonshine? ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
Corinna Vinschen wrote:
I mean, token_info was an UCHAR array, so it's not aligned while
the token_group information might require a 4 or 8 byte alignment
which you now get by chance. Probably you'd be better off not
using `char buf[size]' but
PTOKEN_GROUPS groups = (PTOKEN_GROUPS) alloca (size);
Interesting:
#include stdio.h
#include malloc.h
int main (int argc, char **argv)
{
char vla[argc * 250];
char *alloca_array = (char *) alloca (argc * 250);
char normal_array[1024];
printf (alignof(vla) = %d\n, __alignof__ (vla));
printf (alignof(alloca_array) = %d\n, __alignof__ (alloca_array));
printf (alignof(normal_array) = %d\n, __alignof__ (normal_array));
return 0;
}
Returns:
alignof(vla) = 1
alignof(alloca_array) = 4
alignof(normal_array) = 1
So, perhaps this is working now by accident?
for the GetTokenInformation call. However, it also didn't say anything
about alignment requirements of ZwQueryDirectoryFile but it failed
on W2K for that reason nevertheless.
Don't you love discovering these little pearls of joy inside the Win32
API? They're like little rays of sunshine. No wait, the opposite.
Brian
Re: setup-1.7 defaults to Just me
On Apr 16 02:45, Brian Dessent wrote: Corinna Vinschen wrote: Alignment? Perhaps. Do you know if gcc aligns VLAs higher than their natural alignment? The nonworking code was just UCHAR foo[1024] whereas the working was char buf[size], which I cribbed from grp.cc:internal_getgroups(). Oh well, I suspected that I did that as well. As I said in the other reply, I never saw any alignment requirements for GetTokenInformation before. I just don't see any other potential reason for the ERROR_NOACCESS in this case. I'll fix that in grp.cc, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
On Wed, Apr 16, 2008 at 02:49:33AM -0700, Brian Dessent wrote: Don't you love discovering these little pearls of joy inside the Win32 API? They're like little rays of sunshine. No wait, the opposite. Windoze rulez! cgf
setup-1.7 defaults to Just me
Brian, I just found that, regardless of my privileges, setup-1.7 defaults to install for just me instead of all users while the standard setup defaults to all users. Why does that happen? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup-1.7 defaults to Just me
Corinna Vinschen wrote: I just found that, regardless of my privileges, setup-1.7 defaults to install for just me instead of all users while the standard setup defaults to all users. Why does that happen? This is very odd. Setup's is_admin() was returning 0 despite the user belonging to the administrators group, and debugging revealed that the cause was the following: // Get the group token information UCHAR token_info[1024]; PTOKEN_GROUPS groups = (PTOKEN_GROUPS) token_info; DWORD token_info_len = sizeof (token_info); status = GetTokenInformation (token, TokenGroups, token_info, token_info_len, token_info_len); CloseHandle (token); if (!status) return 0; For whatever reason, GetTokenInformation was failing and returning ERROR_NOACCESS when passed a 1024 byte buffer. I changed the code to first call it with NULL to get the desired size, and that seems to have satisfied it. I cannot explain why it would object to a 1024 byte buffer, maybe you have some idea. I'll install an updated setup-1.7.exe in a moment. Brian
[Packaging error: netpbm-doc-10.33-1] CRLF's in /etc/defaults/etc/manweb.conf
see subject -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
does rxvt really read /usr/X11R6/lib/X11/app-defaults/Rxvt as stated in cygwin documentation?
In the rxvt documentation shipped with cygwin (as presented by 'man rxvt') it claims I can set system-wide defaults in a file in a file named /usr/X11R6/lib/X11/app-defaults/Rxvt. I've been trying to do that but rxvt seems to completely ignore the contents of such a file. If, however, the same file contents are placed in ~/.Xdefaults it reads them fine. Is this documentation correct? I'm having no luck with getting rxvt to read /usr/X11R6/lib/X11/app-defaults. We do need some sort of system level default because we are configuring end user laptops with cygwin - we want a reasonable default set up but we also want to let the knowledgable user override it - the easiest way is to have two configuration files - one that gets updated by systems scripts and one the user maintains. We would like to reserve ~/.Xdefaults for the user's customizations. It doesn't appear to be a start up issue. No matter whether I launch rxvt from a shortcut (e.g. starting in XP land and moving into the world of cygwin) or if I start in a bash shell and enter rxvt at the prompt I have the same problem. (N.B. in both cases DISPLAY=:0) rxvt -h produces the following result: Rxvt v2.7.10 - released: 26 MARCH 2003 Options: XPM,transparent,utmp,menubar,multichar_languages,scrollbars=rxvt+NeXT+xterm,frills,linespace,.Xdefaults Usage: rxvt [-help] [--help] [-display string] [-tn string] [-geometry geometry] [-C] [-iconic] [-/+rv] [-/+ls] [-/+j] [-/+sb] [-/+sr] [-/+st] [-/+si] [-/+sk] [-/+sw] [-/+ip] [-/+ipf] [-/+ut] [-/+vb] [-/+mcc] [-/+tcw] [-bg color] [-fg color] [-ufbg color] [-pixmap file[;geom]] [-fb fontname] [-fn fontname] [-fm fontname] [-km mode] [-name string] [-title string] [-n string] [-cr color] [-pr color] [-bd color] [-sl number] [-w number] [-b number] [-lsp number] [-sbt number] [-mod modifier] [-xrm string] [-e command arg ...] beth -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
I had a similar problem a few months ago and also resolved it by installing first some basic packages and after the rest of the packages. Before that, I tried to remove the file were install hanged but after removing that, it hanged in other file (the next one, I think). I repeated this process a several times times and as I removed the files, the hang was always in the next file and the percentage of the installed files grew. At some point, I've excluded enough files to complete the installation After, I uninstalled everything (didn't trusted that kind of installation), selected some basic packages and installed them and after that I selected the rest of the packages and installed them also. Everything went OK. Maybe the setup cannot process such an amount of files like the one on a full installation at one time. --Lino Tinoco On Mon, Dec 20, 2004 at 10:40:03AM +0100, Alexander Gottwald wrote: On Sun, 19 Dec 2004, Greg Schussman wrote: I've just tried to do a full install of cygwin/X on Windows XP. The install hangs at 90%, saying: Installing xorgx-x11-etc-6.8.180.1 /etc/X11/app-defaults/Bitmap When I look at the file structure, etc/X11/app-defaults is a file, not a directory. Perhaps this is the problem (how can one write to app-defaults/Bitmap if app-defaults is not a directory)? This is really strange. Did you have anything from cygwin installed before? I could not find any cygwin package which does not create /etc/X11/app-defaults as file instead of a directory.
Re: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
On Thu, Jan 13, 2005 at 04:19:49PM -, Lino Miguel Martins Tinoco wrote: Maybe the setup cannot process such an amount of files like the one on a full installation at one time. setup.exe has been updated at http://cygwin.com/setup.exe so that it should no longer have this problem. cgf
Re: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
On Mon, Dec 20, 2004 at 10:40:03AM +0100, Alexander Gottwald wrote: On Sun, 19 Dec 2004, Greg Schussman wrote: I've just tried to do a full install of cygwin/X on Windows XP. The install hangs at 90%, saying: Installing xorgx-x11-etc-6.8.180.1 /etc/X11/app-defaults/Bitmap When I look at the file structure, etc/X11/app-defaults is a file, not a directory. Perhaps this is the problem (how can one write to app-defaults/Bitmap if app-defaults is not a directory)? This is really strange. Did you have anything from cygwin installed before? I could not find any cygwin package which does not create /etc/X11/app-defaults as file instead of a directory. Was there ever any resolution about this? It was a strange error and it would have been nice to track it down. cgf
Re: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
On Sun, 19 Dec 2004, Greg Schussman wrote: Hi. I've just tried to do a full install of cygwin/X on Windows XP. The install hangs at 90%, saying: Installing xorgx-x11-etc-6.8.180.1 /etc/X11/app-defaults/Bitmap When I look at the file structure, etc/X11/app-defaults is a file, not a directory. Perhaps this is the problem (how can one write to app-defaults/Bitmap if app-defaults is not a directory)? This is really strange. Did you have anything from cygwin installed before? I could not find any cygwin package which does not create /etc/X11/app-defaults as file instead of a directory. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
Is this not the same hang that has been address here and in the Cygwin List and the cygwin-apps list. If so please see other threads on this same subject in the mailing list archives and the cygwin list archives and if it is then the fix (for now) as posted many times is break the install into 2 steps: first install only the base packages and then install eveything else. bk
Re: Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
On Mon, Dec 20, 2004 at 04:02:33PM -0500, Brian Keener wrote: Is this not the same hang that has been address here and in the Cygwin List and the cygwin-apps list. If so please see other threads on this same subject in the mailing list archives and the cygwin list archives and if it is then the fix (for now) as posted many times is break the install into 2 steps: first install only the base packages and then install eveything else. If /etc/X11/app-defaults is really being created as a file instead of a directory, this is the first that I've heard of it. It would be very interesting to hear why that is. But, then, maybe if we implemented that idea of not allowing setup.exe to have any bugs, or to at least have it issue an error before it was about to hit a bug, we'd be further down the line to fixing this. Just a suggestion. cgf
Full install on XP hangs at /etc/X11/abb-defaults/Bitmap
Hi. I've just tried to do a full install of cygwin/X on Windows XP. The install hangs at 90%, saying: Installing xorgx-x11-etc-6.8.180.1 /etc/X11/app-defaults/Bitmap When I look at the file structure, etc/X11/app-defaults is a file, not a directory. Perhaps this is the problem (how can one write to app-defaults/Bitmap if app-defaults is not a directory)? But I think this raises several other things which might benefit from fixing as well. 1) Instead of hanging, whatever is trying to do this write should be able to detect that there is a problem and report a meaningful error message. 2) It would probably be a good idea to test doing a full install on at least the most popular operating systems, especially Windows XP. That way, this sort of problem doesn't scare away potential new members of the cygwin/X user base, and doesn't generate negative P.R for the project. Thanks! Greg
SSHD installation defaults / security
Hi! I've installed today the current release of cygwin (1.5.11-1) with OpenSSH package. There are 2 issues: 1. This package (or at least the ssh-host-config script) depends on cygserver, which doesn't gets installed automatically. Please can somebody change this dependency to select cygserver automatically if OpenSSH has been selected in the setup wizard? 2. After installation, the /etc/sshd_config file allows SSH protocol 1 by default. Since this protocol 1 has a coneceptual security hole, it should not be available after standard setup. If somebody requires it, he had to manually configure the sshd_config. That's why I suggest to change that file to: Port 22 Protocol 2 #,1 # -- activate protocol version 1 here, if you really require it #ListenAddress 0.0.0.0 #ListenAddress :: Please can the developers do these changes? Thanks! Jochen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSHD installation defaults / security
On Oct 11 13:29, Jochen Wezel wrote: Hi! I've installed today the current release of cygwin (1.5.11-1) with OpenSSH package. There are 2 issues: 1. This package (or at least the ssh-host-config script) depends on cygserver Neither the package nor ssh-host-config depend on cygserver. Dunno how you get the idea. Do you mean cygrunsrv? Yes, the ssh-host-config script depends on it *iff* you answer the question to install sshd as a service. I'm not sure if the package should require cygrunsrv, though. The /usr/share/doc/Cygwin/openssh.README file mentions that cygrunsrv is required to install sshd as service on NT systems. 2. After installation, the /etc/sshd_config file allows SSH protocol 1 by default. Since this protocol 1 has a coneceptual security hole, it should not be available after standard setup. If somebody requires it, he had to manually configure the sshd_config. That's why I suggest to change that file to: Port 22 Protocol 2 #,1# -- activate protocol version 1 here, if you really require it #ListenAddress 0.0.0.0 #ListenAddress :: Please can the developers do these changes? The above installation of /etc/sshd_config is, except for a small Cygwin specific tweak, the same sshd_config file as you get it when building and installing OpenSSH from scratch. There's no reason to change that unless the core developers of OpenSSH decide to install it differently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSHD installation defaults / security
On Mon, 11 Oct 2004, Corinna Vinschen wrote: On Oct 11 13:29, Jochen Wezel wrote: Hi! I've installed today the current release of cygwin (1.5.11-1) with OpenSSH package. There are 2 issues: 1. This package (or at least the ssh-host-config script) depends on cygserver Neither the package nor ssh-host-config depend on cygserver. Dunno how you get the idea. Do you mean cygrunsrv? Yes, the ssh-host-config script depends on it *iff* you answer the question to install sshd as a service. I'm not sure if the package should require cygrunsrv, though. The /usr/share/doc/Cygwin/openssh.README file mentions that cygrunsrv is required to install sshd as service on NT systems. Well, in the spirit of CGF's comment about tetex-x11 requiring X because of xdvi (see http://cygwin.com/ml/cygwin-apps/2004-10/msg00163.html), perhaps openssh *should* require cygrunsrv. 2. After installation, the /etc/sshd_config file allows SSH protocol 1 by default. Since this protocol 1 has a coneceptual security hole, it should not be available after standard setup. If somebody requires it, he had to manually configure the sshd_config. That's why I suggest to change that file to: Port 22 Protocol 2 #,1 # -- activate protocol version 1 here, if you really require it #ListenAddress 0.0.0.0 #ListenAddress :: Please can the developers do these changes? The above installation of /etc/sshd_config is, except for a small Cygwin specific tweak, the same sshd_config file as you get it when building and installing OpenSSH from scratch. There's no reason to change that unless the core developers of OpenSSH decide to install it differently. IOW, Jochen, take it up with the upstream openssh team... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. -- Dr. Jubal Harshaw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSHD installation defaults / security
On Mon, Oct 11, 2004 at 12:49:09PM -0400, Igor Pechtchanski wrote: On Mon, 11 Oct 2004, Corinna Vinschen wrote: On Oct 11 13:29, Jochen Wezel wrote: I've installed today the current release of cygwin (1.5.11-1) with OpenSSH package. There are 2 issues: 1. This package (or at least the ssh-host-config script) depends on cygserver Neither the package nor ssh-host-config depend on cygserver. Dunno how you get the idea. Do you mean cygrunsrv? Yes, the ssh-host-config script depends on it *iff* you answer the question to install sshd as a service. I'm not sure if the package should require cygrunsrv, though. The /usr/share/doc/Cygwin/openssh.README file mentions that cygrunsrv is required to install sshd as service on NT systems. Well, in the spirit of CGF's comment about tetex-x11 requiring X because of xdvi (see http://cygwin.com/ml/cygwin-apps/2004-10/msg00163.html), perhaps openssh *should* require cygrunsrv. Or, (Corinna will probably kill me for saying this but...) maybe it's time to split openssh into opensh-server and openssh-client? openssh-server could rely on cygrunsrv. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SSHD installation defaults / security
On Oct 11 12:53, Christopher Faylor wrote: On Mon, Oct 11, 2004 at 12:49:09PM -0400, Igor Pechtchanski wrote: On Mon, 11 Oct 2004, Corinna Vinschen wrote: I'm not sure if the package should require cygrunsrv, though. The /usr/share/doc/Cygwin/openssh.README file mentions that cygrunsrv is required to install sshd as service on NT systems. Well, in the spirit of CGF's comment about tetex-x11 requiring X because of xdvi (see http://cygwin.com/ml/cygwin-apps/2004-10/msg00163.html), perhaps openssh *should* require cygrunsrv. Or, (Corinna will probably kill me for saying this but...) maybe it's time to split openssh into opensh-server and openssh-client? OpenSSH's Makefile doesn't contain this split between client and server applications and files. I'd rather not add our own installation rules. openssh-server could rely on cygrunsrv. I've added cygrunsrv to the dependencies. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Pathnames for X server app-defaults etc.
On Thu, 2004-03-25 at 16:39, Harold L Hunt II wrote: Please look at my message about your installation being out of date. Harold I had previously tried a setup.exe 'reinstall' and also uninstalling xserv and installing it from the easynet.be mirror, neither worked. However, last night I tried deleting everything cygwin - not as easy as it sounds as there are some 'undeletable' link files - and reinstalling it all from uni-erlangen.de. This worked. So I must conclude that mirror.ac.uk at least, and possibly easynet.be, are poor mirror choices :-( It would be rather nice if setup had a way of verifying that the packages it loads are self-consistent. Regards, Ruth
RE: Pathnames for X server app-defaults etc.
Subject: RE: Pathnames for X server app-defaults etc. From: Ruth Ivimey-Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Dr.D.J.Picton' [EMAIL PROTECTED] Mime-Version: 1.0 Date: Thu, 25 Mar 2004 16:39:42 + Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) On Thu, 2004-03-25 at 15:36, Alexander Gottwald wrote: On Thu, 25 Mar 2004, Ruth Ivimey-Cook wrote: The xserver is called XWin.exe. Maybe X is a custom script that starts the xserver with xdmcp parameters. The first lines of the log should contain the commandline parameters. Unfortunately you stripped them It seems to me that we are chasing red herrings here. /usr/X11R6/X is just a symbolic link to /usr/X11R6/Xwin.exe - they are one and the same! I suspect that Ruth's problem is not quite the same as mine. My X server didn't crash; it just failed to find the application default files and fell back on a default for the keyboard map, so that when I typed '#' on my UK keyboard I got '\'. Anyway, the symbolic links fixed the problems. If the same symbolic links don't fix Ruth's problem, she probably needs to look elsewhere. Maybe the first thing to do is to reinstall the X11 packages.
Re: Pathnames for X server app-defaults etc.
Ruth Ivimey-Cook wrote: On Thu, 2004-03-25 at 16:39, Harold L Hunt II wrote: Please look at my message about your installation being out of date. Harold I had previously tried a setup.exe 'reinstall' and also uninstalling xserv and installing it from the easynet.be mirror, neither worked. However, last night I tried deleting everything cygwin - not as easy as it sounds as there are some 'undeletable' link files - and reinstalling it all from uni-erlangen.de. This worked. So I must conclude that mirror.ac.uk at least, and possibly easynet.be, are poor mirror choices :-( Both of those mirrors look to be up to date to me. It would be rather nice if setup had a way of verifying that the packages it loads are self-consistent. No, I think your 'undeletable' link files is a clue... there had to be something messed up with your installation. It probably won't happen again since you deleted and reinstalled. Harold
Re: Pathnames for X server app-defaults etc.
Hi, I've had similar problems. I noticed that the problems existed due to lack of permissions. When I set permissions (on the Windows side) as Full Control to Everyone, the deletion of old installation and the re-installation of new version worked. It seems that permissions of the C:\cygwin directory (the install directory) should be set as Full Control to Everyone. Otherwise it is easy to get problems on re-installation. Cheers, Tuli .. MTV3 Laajakaista - Hauskemman elämän puolesta. http://www.mtv3.fi/liittyma/hankinta/laajakaista/
Pathnames for X server app-defaults etc.
Earlier this week, I re-installed Cygwin from scratch. The current version of the X server is 4.3.0-60. I noticed various oddities - in particular, application default files were ignored and the keyboard map was incorrect (for example, '#' produced a '\'). Then I realized that the server now expects to find all the config files under /usr/X11R6/lib/X11. Installing a few symlinks fixed all the problems: cd /usr/X11R6/lib/X11; ln -s /etc/X11 . Now everything works properly. However, it seems to me that something is wrong with the package installation scripts which should either install all the files in /usr/X11R6/lib/X11, or create the relevant symlinks in this directory.
Re: Pathnames for X server app-defaults etc.
From: Dr.D.J.Picton dave at aps5 dot ph dot bham dot ac dot uk To: cygwin-xfree at cygwin dot com Date: Thu, 25 Mar 2004 12:22:01 + (GMT) Subject: Pathnames for X server app-defaults etc. Reply-to: cygwin-xfree at cygwin dot com Reply-to: Dr.D.J.Picton dave at aps5 dot ph dot bham dot ac dot uk I noticed various oddities - in particular, application default files were ignored and the keyboard map was incorrect (for example, '#' produced a '\'). Then I realized that the server now expects to find all the config files under /usr/X11R6/lib/X11. Installing a few symlinks fixed all the problems: cd /usr/X11R6/lib/X11; ln -s /etc/X11 . Sorry - spot the deliberate mistake! That should have been cd /usr/X11R6/lib/X11; ln -s /etc/X11/* .
RE: Pathnames for X server app-defaults etc.
Would the following issue: Earlier this week, I re-installed Cygwin from scratch. The current version of the X server is 4.3.0-60. Be why my X server doesn't start up any more? I get the following Xwin.log after running X :0 from the cygwin shell: (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winScreenInit - dwWidth: 1600 dwHeight: 1200 winSetEngine - Using Shadow DirectDraw NonLocking winAllocateFBShadowDDNL - Not changing video mode winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 6400 winAllocateFBShadowDDNL - Created shadow pitch: 6400 winAllocateFBShadowDDNL - Created shadow stride: 1600 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc105 Layout = gb Variant = (null) Options = (null) winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned XDM: too many retransmissions winProcEstablishConnection - Hello winProcEstablishConnection - Clipboard is not enabled, returning. winProcQueryTree - Clipboard is not enabled, returning. winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Restore returned: OsVendorReset - Hello winDeinitMultiWindowWM - Noting shutdown in progress
RE: Pathnames for X server app-defaults etc.
On Thu, 25 Mar 2004, Ruth Ivimey-Cook wrote: XDM: too many retransmissions There is a problem with the xdmcp server. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Pathnames for X server app-defaults etc.
Ago wrote: There is a problem with the xdmcp server. As I said, I ran the command as X :0, which IIRC should not require an xdmcp server. Even if it did, I have another machine which can log in to the same server fine. Regards, Ruth
RE: Pathnames for X server app-defaults etc.
On Thu, 25 Mar 2004, Ruth Ivimey-Cook wrote: Ago wrote: There is a problem with the xdmcp server. As I said, I ran the command as X :0, which IIRC should not require an xdmcp server. Even if it did, I have another machine which can log in to the same server fine. The xserver is called XWin.exe. Maybe X is a custom script that starts the xserver with xdmcp parameters. The first lines of the log should contain the commandline parameters. Unfortunately you stripped them bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Pathnames for X server app-defaults etc.
Ruth Ivimey-Cook wrote: Would the following issue: Earlier this week, I re-installed Cygwin from scratch. The current version of the X server is 4.3.0-60. Be why my X server doesn't start up any more? Does not appear to be. In addition to what Alexander said, if the XWin.log you sent was complete, then you are running an old version of the XFree86-xserv package since there is no version or command line information printed at the top of the file. Please run 'cygcheck -c XFree86-xserv' and report your results. If you think you have been updating regularly, then you may be pointing to a stale mirror and you need to reselect a different mirror from the mirror list. Note: If you selected a mirror that eventually became stale, it would be dropped from the downloaded mirror list, but it would still be your default mirror and would be added to the mirror list as a user entry. This isn't quite the way it should be (a mirror from the list being removed from the list should be distinct from a user entry) handled but that is the way it will continue to be until someone puts forth the effort on setup.exe. Harold
Re: Pathnames for X server app-defaults etc.
Dr.D.J.Picton wrote: Earlier this week, I re-installed Cygwin from scratch. The current version of the X server is 4.3.0-60. I noticed various oddities - in particular, application default files were ignored and the keyboard map was incorrect (for example, '#' produced a '\'). Then I realized that the server now expects to find all the config files under /usr/X11R6/lib/X11. Installing a few symlinks fixed all the problems: cd /usr/X11R6/lib/X11; ln -s /etc/X11 . Now everything works properly. However, it seems to me that something is wrong with the package installation scripts which should either install all the files in /usr/X11R6/lib/X11, or create the relevant symlinks in this directory. What are you talking about? The postinstall script for the lib package does exactly what you did... your installation must have barfed for some reason because those symlinks have been created by that script for months now, if not for longer than a year. Nothing has changed with that script that I know of, unless I royally broke something. Harold
RE: Pathnames for X server app-defaults etc.
On Thu, 2004-03-25 at 15:36, Alexander Gottwald wrote: On Thu, 25 Mar 2004, Ruth Ivimey-Cook wrote: The xserver is called XWin.exe. Maybe X is a custom script that starts the xserver with xdmcp parameters. The first lines of the log should contain the commandline parameters. Unfortunately you stripped them Whatever X is, it is part of the cygwin install, as I have not created any programs. % which X /usr/X11R6/bin/X % I didn't strip *anything* from the file I posted. Indeed, running XWin :0 has the same behaviour and the same log file. Ruth
Re: Pathnames for X server app-defaults etc.
Please look at my message about your installation being out of date. Harold Ruth Ivimey-Cook wrote: On Thu, 2004-03-25 at 15:36, Alexander Gottwald wrote: On Thu, 25 Mar 2004, Ruth Ivimey-Cook wrote: The xserver is called XWin.exe. Maybe X is a custom script that starts the xserver with xdmcp parameters. The first lines of the log should contain the commandline parameters. Unfortunately you stripped them Whatever X is, it is part of the cygwin install, as I have not created any programs. % which X /usr/X11R6/bin/X % I didn't strip *anything* from the file I posted. Indeed, running XWin :0 has the same behaviour and the same log file. Ruth
[FHS] what are the rules: /etc/defaults and system wide settings
Could someone explain what is the difference between: /etc/defaults/ /usr/share/package/ 1) Say, a file includes a 'packagerc' default settings that are used in case $HOME/.packagerc is not set, where this file should be done? 2) If package includes a SAMPLE, what administrator must specifically activate, where will this file be put? Is it: /usr/share/package/ Or /usr/share/doc/package/sample.packagerc 3) When package is updated and it includes a NEW version of the default configuration 'packagerc', how should this be handled? -- http://tiny-tools.sourceforge.net/ Swatch @time http://www.mir.com.my/iTime/itime.htm http://www.ryanthiessen.com/swatch/resources.htm Use Licenses! http://www.linuxjournal.com/article.php?sid=6225 Which Licence? http://www.linuxjournal.com/article.php?sid=4825 OSI Licences http://www.opensource.org/licenses/
[chris@areti.co.uk: Re: Keyboard auto-repeat defaults when using 'xwin -query host']
Did my reply below get lost in the Christmas rush somewhere? I still have this autorepeat proplem though using an explicit xset command in my startup is OK as a workaround. - Forwarded message from Chris Green [EMAIL PROTECTED] - Date: Sat, 27 Dec 2003 14:03:33 + From: Chris Green [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Keyboard auto-repeat defaults when using 'xwin -query host' References: [EMAIL PROTECTED] [EMAIL PROTECTED] On Fri, Dec 26, 2003 at 06:41:14PM -0500, Harold L Hunt II wrote: Chris, Chris Green wrote: The problem is that when I connect using cygwin/xfree the auto-repeat is set to silly values, if I do an 'xset -q' I get:- auto repeat: onkey click persent: 0LED mask: 00 auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. Thanks for the response and for treating me gently, I'm just feeling my way in cygwin/X although I have been using Unix/Linux for many years (since the early 1980s in fact). When running locally, I get: Keyboard Control: auto repeat: onkey click percent: 0LED mask: auto repeat delay: 500repeat rate: 31 auto repeating keys: 00ffdbbf fadfffdffdff bell percent: 50bell pitch: 400bell duration: 100 Just about exactly what I get except for the auto repeat delay values which I reported above. When logged into a remote machine via -query I get exactly the same values. I do not have an XF86Config file, and I am not passing any of the following command-line parameters to XWin.exe: == The X Keyboard Extension adds the following arguments: -kbdisable the X Keyboard Extension +kbenable the X Keyboard Extension [+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask] ] ] ] enable/disable accessx key sequences -ar1 set XKB autorepeat delay -ar2 set XKB autorepeat interval [...] -xf86config Specify a configuration file. == I'm running using a copy of startxwin.bat with the XWIn start line set to start XWin -query server. I have no XF86Config either. My /tmp/XWin.log file has the following: == (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) == Could you please confirm that you are not passing any additional args to XWin.exe, then send in your XWin.log files from both a local session and from a session when you use -query to connect to a remote machine? That should help us to investigate the problem. The remote XWin.log file is:- ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1600 h: 1200 winCreateBoundingWindowWindowed - Current w: 1600 h: 1200 winAdjustForAutoHide - Original WorkArea: 33 0 1200 1600 winAdjustForAutoHide - Adjusted WorkArea: 33 0 1200 1600 winCreateBoundingWindowWindowed - WindowClient w 1594 h 1137 r 1594 l 0 b 1137 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 3188 winAllocateFBShadowDDNL - Created shadow pitch: 3188 winAllocateFBShadowDDNL - Created shadow stride: 1594 winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowDDNL - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput
Re: Keyboard auto-repeat defaults when using 'xwin -query host'
Chris Green wrote: I still have this autorepeat proplem though using an explicit xset command in my startup is OK as a workaround. (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 You see, the server sets the autorepeat to useful values. I'm quite sure there is another program in the startup scripts which sets the autorepeat settings to the strange value. Maybe this is not xset but the the windowmanager (kde, gnome) itself. Please check the settings of the windowmanager if there is a strange autorepeat setting. bye ago NP: grauzone.03-12-28 -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Keyboard auto-repeat defaults when using 'xwin -query host'
On Fri, Dec 26, 2003 at 06:41:14PM -0500, Harold L Hunt II wrote: Chris, Chris Green wrote: The problem is that when I connect using cygwin/xfree the auto-repeat is set to silly values, if I do an 'xset -q' I get:- auto repeat: onkey click persent: 0LED mask: 00 auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. Thanks for the response and for treating me gently, I'm just feeling my way in cygwin/X although I have been using Unix/Linux for many years (since the early 1980s in fact). When running locally, I get: Keyboard Control: auto repeat: onkey click percent: 0LED mask: auto repeat delay: 500repeat rate: 31 auto repeating keys: 00ffdbbf fadfffdffdff bell percent: 50bell pitch: 400bell duration: 100 Just about exactly what I get except for the auto repeat delay values which I reported above. When logged into a remote machine via -query I get exactly the same values. I do not have an XF86Config file, and I am not passing any of the following command-line parameters to XWin.exe: == The X Keyboard Extension adds the following arguments: -kbdisable the X Keyboard Extension +kbenable the X Keyboard Extension [+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask] ] ] ] enable/disable accessx key sequences -ar1 set XKB autorepeat delay -ar2 set XKB autorepeat interval [...] -xf86config Specify a configuration file. == I'm running using a copy of startxwin.bat with the XWIn start line set to start XWin -query server. I have no XF86Config either. My /tmp/XWin.log file has the following: == (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) == Could you please confirm that you are not passing any additional args to XWin.exe, then send in your XWin.log files from both a local session and from a session when you use -query to connect to a remote machine? That should help us to investigate the problem. The remote XWin.log file is:- ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1600 h: 1200 winCreateBoundingWindowWindowed - Current w: 1600 h: 1200 winAdjustForAutoHide - Original WorkArea: 33 0 1200 1600 winAdjustForAutoHide - Adjusted WorkArea: 33 0 1200 1600 winCreateBoundingWindowWindowed - WindowClient w 1594 h 1137 r 1594 l 0 b 1137 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 3188 winAllocateFBShadowDDNL - Created shadow pitch: 3188 winAllocateFBShadowDDNL - Created shadow stride: 1594 winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowDDNL - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 (EE) No primary keyboard configured (==) Using compiletime defaults
Re: Keyboard auto-repeat defaults when using 'xwin -query host'
Chris Green wrote: I have a odd problem with the keyboard auto-repeat setup. I have two verions of cygwin/xfree installed on two different win2k computers and the problem is the same on both. One has the latest cygwin/xfree (just downloaded) and the other has a version from a few months ago. I have searched through the mailing list archive and see that a similar problem has been reported before but it isn't exactly the same and I don't see how to fix the problem anyway. I am connecting from both these win2k systems uisng 'xwin -query server' to a linux Slackware 9.1 system on my local (home) network. I have also got another X server available to me, X-Win32 but I'd prefer to use cygwin as it's free and otherwise I keep having to pay for upgrades to X-Win32. The problem is that when I connect using cygwin/xfree the auto-repeat is set to silly values, if I do an 'xset -q' I get:- auto repeat: onkey click persent: 0LED mask: 00 auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. XWin tries to set the repeat rate to something similar to the windows repeat rate. This is noted in the configfile. Maybe the session scripts of the linux host set the repeat rate to a bogus value. You can verify this by starting xwin without the query paramter and run DISPLAY=:0.0 xset -q from windows. This should print the default setting. bye ago NP: grauzone.03-12-14 -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Keyboard auto-repeat defaults when using 'xwin -query host'
On Sat, Dec 27, 2003 at 02:31:58PM +0100, Alexander Gottwald wrote: Chris Green wrote: auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. XWin tries to set the repeat rate to something similar to the windows repeat rate. This is noted in the configfile. Maybe the session scripts of the linux host set the repeat rate to a bogus value. But the problem only occurs when I connect to the remote system using cygwin's xwin, when I use my commercial X-Win32 X server I get the default keyboard set-up that I expect. You can verify this by starting xwin without the query paramter and run DISPLAY=:0.0 xset -q from windows. This should print the default setting. No. locally I appear to get the same problem too. -- Chris Green ([EMAIL PROTECTED])
Keyboard auto-repeat defaults when using 'xwin -query host'
I have a odd problem with the keyboard auto-repeat setup. I have two verions of cygwin/xfree installed on two different win2k computers and the problem is the same on both. One has the latest cygwin/xfree (just downloaded) and the other has a version from a few months ago. I have searched through the mailing list archive and see that a similar problem has been reported before but it isn't exactly the same and I don't see how to fix the problem anyway. I am connecting from both these win2k systems uisng 'xwin -query server' to a linux Slackware 9.1 system on my local (home) network. I have also got another X server available to me, X-Win32 but I'd prefer to use cygwin as it's free and otherwise I keep having to pay for upgrades to X-Win32. The problem is that when I connect using cygwin/xfree the auto-repeat is set to silly values, if I do an 'xset -q' I get:- auto repeat: onkey click persent: 0LED mask: 00 auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. On the other hand when I connect using X-Win32 I get:- auto repeat: onkey click persent: 0LED mask: 00 with no 'auto repeat delay' value at all, i.e. X-Win32 doesn't seem to have attempted to set the auto repeat delay or repeat rate at all and thus I'm left with the existing keyboard settings which are fine. It would appear that cygwin/xfree *is* setting the auto repeat delay and speed whereas X-Win32 isn't. If it is setting these where are the default values? If it isn't then what is going on? I know I can fix it by using 'xset' but this seems a bit of a bodge, I'd rather do it properly. -- Chris Green ([EMAIL PROTECTED])
Re: Keyboard auto-repeat defaults when using 'xwin -query host'
Chris, Chris Green wrote: The problem is that when I connect using cygwin/xfree the auto-repeat is set to silly values, if I do an 'xset -q' I get:- auto repeat: onkey click persent: 0LED mask: 00 auto repeat delay: 100repeat rate: 10 That auto repeat delay is much too short. When running locally, I get: Keyboard Control: auto repeat: onkey click percent: 0LED mask: auto repeat delay: 500repeat rate: 31 auto repeating keys: 00ffdbbf fadfffdffdff bell percent: 50bell pitch: 400bell duration: 100 When logged into a remote machine via -query I get exactly the same values. I do not have an XF86Config file, and I am not passing any of the following command-line parameters to XWin.exe: == The X Keyboard Extension adds the following arguments: -kbdisable the X Keyboard Extension +kbenable the X Keyboard Extension [+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask] ] ] ] enable/disable accessx key sequences -ar1 set XKB autorepeat delay -ar2 set XKB autorepeat interval [...] -xf86config Specify a configuration file. == My /tmp/XWin.log file has the following: == (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) == Could you please confirm that you are not passing any additional args to XWin.exe, then send in your XWin.log files from both a local session and from a session when you use -query to connect to a remote machine? That should help us to investigate the problem. Harold
Should --sysconfdir=/etc/defaults/etc/?
Current packaging instructions at http://cygwin.com/setup.html#package_contents indicate that --sysconfdir should be set to /etc. Should this perhaps be changed to /etc/defaults/etc, with the subsequent instruction that if your package actually has anything in sysconfdir, it should conditionally copy it to /etc if it doesn't already exist with a postinstall script[1]? [1] Setup wishlist item: Somehow tag files like this and integrate replace if not exist else ask user if he wants to replace functionality into setup, eliminating the need for disparate shell scripts and their possible disparate bugs. -- Gary R. Van Sickle
Re: Should --sysconfdir=/etc/defaults/etc/?
On Thu, Oct 30, 2003 at 08:43:31AM -0600, Gary R. Van Sickle wrote: Current packaging instructions at http://cygwin.com/setup.html#package_contents indicate that --sysconfdir should be set to /etc. Should this perhaps be changed to /etc/defaults/etc, with the subsequent instruction that if your package actually has anything in sysconfdir, it should conditionally copy it to /etc if it doesn't already exist with a postinstall script[1]? No. If you set --sysconfdir to something else than /etc, a big bunch of packages will search their config files in the wrong directory. Keep in mind, that the sysconfdir setting might get hardcoded into a tool on compile time. Better create a package script which moves the files from /etc to /etc/defaults/etc after calling `make install DESTDIR=...'. Or even do it by hand. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Should --sysconfdir=/etc/defaults/etc/?
[EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 08:43:31AM -0600, Gary R. Van Sickle wrote: Current packaging instructions at http://cygwin.com/setup.html#package_contents indicate that --sysconfdir should be set to /etc. Should this perhaps be changed to /etc/defaults/etc, with the subsequent instruction that if your package actually has anything in sysconfdir, it should conditionally copy it to /etc if it doesn't already exist with a postinstall script[1]? No. If you set --sysconfdir to something else than /etc, a big bunch of packages will search their config files in the wrong directory. Keep in mind, that the sysconfdir setting might get hardcoded into a tool on compile time. Better create a package script which moves the files from /etc to /etc/defaults/etc after calling `make install DESTDIR=...'. Or even do it by hand. RedHat does `make install DESTDIR=.. sysconfdir=..` for packages where they want the target sysconfdir be something other then the default set at compile time. Cheers, Nicholas
RE: Should --sysconfdir=/etc/defaults/etc/?
On Thu, Oct 30, 2003 at 08:43:31AM -0600, Gary R. Van Sickle wrote: Current packaging instructions at http://cygwin.com/setup.html#package_contents indicate that --sysconfdir should be set to /etc. Should this perhaps be changed to /etc/defaults/etc, with the subsequent instruction that if your package actually has anything in sysconfdir, it should conditionally copy it to /etc if it doesn't already exist with a postinstall script[1]? No. If you set --sysconfdir to something else than /etc, a big bunch of packages will search their config files in the wrong directory. Keep in mind, that the sysconfdir setting might get hardcoded into a tool on compile time. DOH! Right, sorry, I plead temporary insanity. ;-) -- Gary R. Van Sickle
Re: xterm.exe not reading XTerm file in app-defaults
On Sat, Mar 15, 2003 at 12:32:21AM -0500, Bryan Crader wrote: I think i have run in to a similiar problem with XTerm not reading the app-defaults file. I've deleted the cygwin directory and reinstalled it several times, and sometimes it works and sometimes it doesn't load up the XTerm defaults file. I then noticed that in the directory: /usr/X11R6/lib/X11/app-defaults/ there is a simlink 'app-defaults' that somtimes points to the /etc/X11/app-defaults/ directory, and sometimes it just points to /etc/X11/ if you remake the simlink to /etc/X11/app-defaults/ it seems to load the XTerm file then. Attempting to try how it works here, I found _two_ entries in /usr/X11R6/lib/X11/ both named app-defaults. One the link to /etc/X11/app-defaults/ and the second a real directory. The directory contained only one file Mwm and was shadowing (i.e. took precedence) over the sym-link. After removing that directory Xterm.exe definitely reads its app-defaults file (and current user, as well as installing user is non-admin). -- Daniel
xterm.exe not reading XTerm file in app-defaults
I think i have run in to a similiar problem with XTerm not reading the app-defaults file. I've deleted the cygwin directory and reinstalled it several times, and sometimes it works and sometimes it doesn't load up the XTerm defaults file. I then noticed that in the directory: /usr/X11R6/lib/X11/app-defaults/ there is a simlink 'app-defaults' that somtimes points to the /etc/X11/app-defaults/ directory, and sometimes it just points to /etc/X11/ if you remake the simlink to /etc/X11/app-defaults/ it seems to load the XTerm file then. Bryan
xterm.exe not reading XTerm file in app-defaults
I have run into a problem where xterm.exe ignores the XTerm file in \usr\X11R6\lib\X11\app-defaults. I have been able to reproduce this problem on the current binaries and the current CVS tree. It has showed up on both Windows NT and XP. The tricky part is that the problem is intermittent; on identical hardware, with identical ghost images, it will work on one machine and not the other. The Cygwin install is identical on each box. The current user is an admin user on both boxes. I am thinking that it could be an 8.3 naming problem with the app-defaults folder. Any ideas? Thanks, Bryan
Re: wrong app-defaults in fresh installation
It is the lesstif package which creates a folder /usr/X11R6/lib/X11/app-defaults when /usr/X11R6/lib/X11/app-defaults/Mwm is extracted. When there is already a link app-defaults - /etc/X11/app-defaults/ the everything is fine - otherwise later you will get the app-defaults link to /etc/X11/app-defaults/ inside the usr/X11R6/lib/X11/app-defaults folder. I had the same problem sometime ago and complained ;) to the list. Don't know whether the lesstif maintainer or somebody else could fix it. Frank-Michael Danilo Turina wrote: Hi, in in a fresh installation of Cygwin on my new XP PC, I noticed that xcalc (and other X apps) didn't work properly. I have had this problem some time ago: within the directory /usr/X11R6/lib/X11/app-defaults has been created a link to /etc/X11/app-defaults (where the app-defaults of many applications are). So while in /usr/X11R6/lib/X11/app-defaults there are on the app-defaults of Mwm all the other app-defaults are in /usr/X11R6/lib/X11/app-defaults/app-defaults and the various X apps (e.g. xcalc) can't find them. Last time I thought that this problem was my fault in that I installed X, lessTiff, WindowMaker as separate packages before they were included in setup and then, when they become available in setup, I replaced them with the setup versions. So I thought some re-packaging would have caused that problem and simply replaced /usr/X11R6/lib/X11/app-defaults with a link to /etc/X11/app-defaults. Now, with a fresh Cygwin installation, I have the some problem (that I will solve in the same way) so I think there is some problem with the installation of some X package. Ciao, Danilo Turina
wrong app-defaults in fresh installation
Hi, in in a fresh installation of Cygwin on my new XP PC, I noticed that xcalc (and other X apps) didn't work properly. I have had this problem some time ago: within the directory /usr/X11R6/lib/X11/app-defaults has been created a link to /etc/X11/app-defaults (where the app-defaults of many applications are). So while in /usr/X11R6/lib/X11/app-defaults there are on the app-defaults of Mwm all the other app-defaults are in /usr/X11R6/lib/X11/app-defaults/app-defaults and the various X apps (e.g. xcalc) can't find them. Last time I thought that this problem was my fault in that I installed X, lessTiff, WindowMaker as separate packages before they were included in setup and then, when they become available in setup, I replaced them with the setup versions. So I thought some re-packaging would have caused that problem and simply replaced /usr/X11R6/lib/X11/app-defaults with a link to /etc/X11/app-defaults. Now, with a fresh Cygwin installation, I have the some problem (that I will solve in the same way) so I think there is some problem with the installation of some X package. Ciao, Danilo Turina Here is the output of cygcheck -s: Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Feb 05 12:05:52 2003 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: . C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\Windows\system32 c:\Windows c:\Windows\System32\Wbem c:\Program Files\Rational\common c:\Program Files\Rational\Rose\TopLink\ C:\cygwin\usr\X11R6\bin SysDir: C:\Windows\System32 WinDir: C:\Windows HOME = `C:\cygwin\home\Administrator' MAKE_MODE = `unix' PWD = `/usr/X11R6/lib/X11/app-defaults' USER = `Administrator' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS 17351Mb 47% CP CS UN PA FC d: cd CDFS 634Mb 100%CS UN HotBurn_Sep17_02 C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive user binmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\sh.exe 58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll 6k 2002/06/24 C:\cygwin\bin\cygcharset-1.dll 847k 2003/01/09 C:\cygwin\bin\cygcrypto-0.9.7.dll 644k 2002/12/08 C:\cygwin\bin\cygcrypto.dll 45k 2001/04/25 C:\cygwin\bin\cygform5.dll 35k 2002/01/09 C:\cygwin\bin\cygform6.dll 19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll 20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll 28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll 21k 2001/06/20 C:\cygwin\bin\cygintl.dll 119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll 32k 2003/01/04 C:\cygwin\bin\cygltdl-3.dll 26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll 12k 2002/01/09 C:\cygwin\bin\cygpanel6.dll 40k 2001/11/21 C:\cygwin\bin\cygpcre.dll 39k 2001/11/21 C:\cygwin\bin\cygpcreposix.dll 175k 2002/07/22 C:\cygwin\bin\cygpng10.dll 22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll 108k 2001/06/28 C:\cygwin\bin\cygreadline4.dll 127k 2002/10/10 C:\cygwin\bin\cygreadline5.dll 177k 2003/01/09 C:\cygwin\bin\cygssl-0.9.7.dll 165k 2002/12/08 C:\cygwin\bin\cygssl.dll 253k 2002/02/10 C:\cygwin\bin\cygtiff3.dll 41k 2002/01/20 C:\cygwin\bin\cygXpm-noX4.dll 46k 2002/01/20 C:\cygwin\bin\cygXpm-X4.dll 50k 2002/03/12 C:\cygwin\bin\cygz.dll 885k 2003/01/24 C:\cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.3.19 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 71 Shared data: 3 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Thu Jan 23 21:31:48 EST 2003 CVS tag: cygwin-1-3-19-1 Shared id: cygwin1S3 41k 2002/05/14 C:\cygwin\usr\X11R6\bin
Re: FAO: cfg: defaults
On Sat, 4 Jan 2003, Randall R Schulz wrote: John, At 08:50 2003-01-04, John Morrison wrote: ... Please find for you perusal and review... (long links, will wrap!) Why don't you enclose all URLs in email within angle brackets instead of forcing people to reintegrate the wrapped links? Even a short URL can fall on a line wrap boundary if embedded in other text. Didn't know I could! :) Thanks for the tip, will do in future. J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
On Sat, Jan 04, 2003 at 07:32:50PM -0800, Randall R Schulz wrote: I hope this isn't too far off-topic or excessive in its protractedness. If you'd like, I'll tease the cat a little and get some scratches on my arms. Mrrow! I do appreciate the education. Thanks. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
On Sat, Jan 04, 2003 at 03:36:12PM -0500, Christopher Faylor wrote: You don't need my permission. Just post to cygwin-apps and see what others think. Or, since you're the package maintainer and, I'm sure that you've tested this, feel free to just refresh your packages. Actually, I do have one comment. If you are using incver_ifdep in setup.hint then you should name the package something like foo-01-1.tar.bz2. The 01 part gets updated every time there is a package which relies on it. To rephrase that: The 01 part gets incremented every time a package is updated or created which relies on the other criteria in the setup.hint. cgf
FAO: cfg: defaults
From: Christopher Faylor On Mon, Dec 02, 2002 at 12:56:03PM -, Morrison, John wrote: You'd probably want something like: snip/ setup.hint: sdesc: Conditionally move default files to proper location category: _PostInstallLast requires: ash findutils fileutils sed sh-utils autodep: etc/defaults/.* incver_ifdep: yes This would run automatically whenever packages are downloaded and installed in one shot. It wouldn't run if someone downloads everything and then installs piecemeal, though. I think there are lots of things that don't work when cygwin is not installed via setup. I can't think of any other way... The script to move the files would be the only thing in the package and it would be a post-install script. Done :) Please find for you perusal and review... (long links, will wrap!) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/upda te-defaults-1.0-.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/defa ults.html (this should be added to the 'how to create a package' instructions, or something like?) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/setu p.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/md5s um Also, re-done base-files using this mechanism... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-file s-1.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hin t http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum Christopher: is this OK? J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
On Sat, Jan 04, 2003 at 04:50:41PM -, John Morrison wrote: From: Christopher Faylor On Mon, Dec 02, 2002 at 12:56:03PM -, Morrison, John wrote: You'd probably want something like: snip/ setup.hint: sdesc: Conditionally move default files to proper location category: _PostInstallLast requires: ash findutils fileutils sed sh-utils autodep: etc/defaults/.* incver_ifdep: yes This would run automatically whenever packages are downloaded and installed in one shot. It wouldn't run if someone downloads everything and then installs piecemeal, though. I think there are lots of things that don't work when cygwin is not installed via setup. I can't think of any other way... The script to move the files would be the only thing in the package and it would be a post-install script. Done :) Please find for you perusal and review... (long links, will wrap!) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/upda te-defaults-1.0-.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/defa ults.html (this should be added to the 'how to create a package' instructions, or something like?) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/setu p.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/md5s um Also, re-done base-files using this mechanism... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-file s-1.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hin t http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum Christopher: is this OK? You don't need my permission. Just post to cygwin-apps and see what others think. Or, since you're the package maintainer and, I'm sure that you've tested this, feel free to just refresh your packages. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
[Redirecting to cygwin-apps] On Sat, Jan 04, 2003 at 03:17:40PM -0500, Christopher Faylor wrote: On Sat, Jan 04, 2003 at 04:50:41PM -, John Morrison wrote: From: Christopher Faylor On Mon, Dec 02, 2002 at 12:56:03PM -, Morrison, John wrote: You'd probably want something like: snip/ setup.hint: sdesc: Conditionally move default files to proper location category: _PostInstallLast requires: ash findutils fileutils sed sh-utils autodep: etc/defaults/.* incver_ifdep: yes This would run automatically whenever packages are downloaded and installed in one shot. It wouldn't run if someone downloads everything and then installs piecemeal, though. I think there are lots of things that don't work when cygwin is not installed via setup. I can't think of any other way... The script to move the files would be the only thing in the package and it would be a post-install script. Done :) Please find for you perusal and review... (long links, will wrap!) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/upda te-defaults-1.0-.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/defa ults.html (this should be added to the 'how to create a package' instructions, or something like?) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/setu p.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/md5s um Also, re-done base-files using this mechanism... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-file s-1.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hin t http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum Christopher: is this OK? You don't need my permission. Just post to cygwin-apps and see what others think. Or, since you're the package maintainer and, I'm sure that you've tested this, feel free to just refresh your packages. Actually, I do have one comment. If you are using incver_ifdep in setup.hint then you should name the package something like foo-01-1.tar.bz2. The 01 part gets updated every time there is a package which relies on it. If you use something like 1.2, I'm not sure exactly what will happen. It may just increment it to 1.3, 1.4, etc., but I don't know for sure. Also, how about posting the text bits to the mailing list rather than having us cut and paste a URL for perusal? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
John, At 08:50 2003-01-04, John Morrison wrote: ... Please find for you perusal and review... (long links, will wrap!) Why don't you enclose all URLs in email within angle brackets instead of forcing people to reintegrate the wrapped links? Even a short URL can fall on a line wrap boundary if embedded in other text. http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/update-defaults-1.0-.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/defaults.html (this should be added to the 'how to create a package' instructions, or something like?) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/setup.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/md5sum Also, re-done base-files using this mechanism... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-files-1.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum Randall Schulz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
On Sat, Jan 04, 2003 at 04:24:53PM -0800, Randall R Schulz wrote: At 08:50 2003-01-04, John Morrison wrote: Please find for you perusal and review... (long links, will wrap!) Why don't you enclose all URLs in email within angle brackets instead of forcing people to reintegrate the wrapped links? Even a short URL can fall on a line wrap boundary if embedded in other text. I've noticed that people do this and I'm always curious as to why. Is there a mail reader convention that causes angle bracket wrapped URLs to be properly understood? I know that my mail reader doesn't understand them but... cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
On Sun, 2003-01-05 at 12:33, Christopher Faylor wrote: On Sat, Jan 04, 2003 at 04:24:53PM -0800, Randall R Schulz wrote: At 08:50 2003-01-04, John Morrison wrote: Please find for you perusal and review... (long links, will wrap!) Why don't you enclose all URLs in email within angle brackets instead of forcing people to reintegrate the wrapped links? Even a short URL can fall on a line wrap boundary if embedded in other text. I've noticed that people do this and I'm always curious as to why. Is there a mail reader convention that causes angle bracket wrapped URLs to be properly understood? I know that my mail reader doesn't understand them but... Yes, there is. Uhmm, I *think* it was Eudora years and years ago that did it first. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: FAO: cfg: defaults
On Sat, Jan 04, 2003 at 05:58:10PM -0800, Randall R Schulz wrote: Chris, I think it's in one of the email RFCs. I remember tracking it down once during an (ill-considered) debate on one of the Bay Area Usenet groups. I should have made note of where I found it, but I didn't. I can find a variety of non-official mentions of this as a recommended convention using Google, but the relevant RFCs are numerous and voluminous. I'll try to find something definitive and authoritative and let you know. (It's one of those pet peeve / crusade things for me to get people to use these things, so the authority of the IETF is something good to have at hand.) Thanks. I'm glad I asked. I probably should have implemented something for my email reader a while ago. This might spur me on to do that. Hmm. I guess I'm getting off-topic now. *Slap* cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAO: cfg: defaults
Chris, I hope this isn't too far off-topic or excessive in its protractedness. If you'd like, I'll tease the cat a little and get some scratches on my arms. Anyway, I found this in RFC 1738, Uniform Resource Locators (URL) (http://www.ietf.org/rfc/rfc1738.txt, lines 1183 through 1225): -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- APPENDIX: Recommendations for URLs in Context URIs, including URLs, are intended to be transmitted through protocols which provide a context for their interpretation. In some cases, it will be necessary to distinguish URLs from other possible data structures in a syntactic structure. In this case, is recommended that URLs be preceeded with a prefix consisting of the characters URL:. For example, this prefix may be used to distinguish URLs from other kinds of URIs. In addition, there are many occasions when URLs are included in other kinds of text; examples include electronic mail, USENET news messages, or printed on paper. In such cases, it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URL. For this purpose, is recommended that angle brackets ( and ), along with the prefix URL:, be used to delimit the boundaries of the URL. This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified. In the case where a fragment/anchor identifier is associated with a URL (following a #), the identifier would be placed within the brackets as well. In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. No whitespace should be introduced after a hyphen (-) character. Because some typesetters and printers may (erroneously) introduce a hyphen at the end of line when breaking a line, the interpreter of a URL containing a line break immediately after a hyphen should ignore all unencoded whitespace around the line break, and should be aware that the hyphen may or may not actually be part of the URL. Examples: Yes, Jim, I found it under URL:ftp://info.cern.ch/pub/www/doc; type=d but you can probably pick it up from URL:ftp://ds.in ternic.net/rfc. Note the warning in URL:http://ds.internic. net/instructions/overview.html#WARNING. -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- I guess this passage, appearing as it does in an appendix with the title Recommendations ..., does not have the force of a standard per se, but it's good enough for me. I notice as I peruse the RFCs that this recommendation (including URL: part) is widely used in the plain-text RFCs. RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields is also somewhat relevant and indicates that for its purposes within headers, the angle brackets are in fact mandatory and specified within the RFC proper. Randall Schulz At 18:08 2003-01-04, Christopher Faylor wrote: On Sat, Jan 04, 2003 at 05:58:10PM -0800, Randall R Schulz wrote: Chris, I think it's in one of the email RFCs. I remember tracking it down once during an (ill-considered) debate on one of the Bay Area Usenet groups. I should have made note of where I found it, but I didn't. I can find a variety of non-official mentions of this as a recommended convention using Google, but the relevant RFCs are numerous and voluminous. I'll try to find something definitive and authoritative and let you know. (It's one of those pet peeve / crusade things for me to get people to use these things, so the authority of the IETF is something good to have at hand.) Thanks. I'm glad I asked. I probably should have implemented something for my email reader a while ago. This might spur me on to do that. Hmm. I guess I'm getting off-topic now. *Slap* cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: defaults
From: Christopher Faylor On Mon, Dec 02, 2002 at 12:56:03PM -, Morrison, John wrote: You'd probably want something like: snip/ setup.hint: sdesc: Conditionally move default files to proper location category: _PostInstallLast requires: ash findutils fileutils sed sh-utils autodep: etc/defaults/.* incver_ifdep: yes This would run automatically whenever packages are downloaded and installed in one shot. It wouldn't run if someone downloads everything and then installs piecemeal, though. I think there are lots of things that don't work when cygwin is not installed via setup. I can't think of any other way... The script to move the files would be the only thing in the package and it would be a post-install script. Done :) Please find for you perusal and review... (long links, will wrap!) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/upda te-defaults-1.0-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/defa ults.html (this should be added to the 'how to create a package' instructions, or something like?) http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/setu p.hint http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/update-defaults/md5s um Also, re-done base-files using this mechanism... http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/base-file s-1.2-1.tar.bz2 http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/setup.hin t http://homepage.ntlworld.com/j-n-s.morrison/john/cygwin/base-files/md5sum *Please* test this before including in the distro! J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: defaults
On Wed, Dec 04, 2002 at 09:52:53PM -, John Morrison wrote: From: Christopher Faylor The other would be to get people to use it ;) Well, that's my mental thoughts on paper(?!). Any comments? would it be worth doing? Here's how _update-info-dir does it: Thanks :) So - do you... 1) Think it's worth it 2) Think the _way_ I'm proposing is OK and, 3) think I should implement it? :) Yes to all. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
defaults
Hi all. This has been at the back of my mind for awhile now since having to do something for /etc/profile.default. What I'm thinking of is a directory structure containing default files and a script which, if the original of the default file doesn't exist, copies it. I'm specifically thinking of: /etc/apache.new/access.conf.default /etc/apache.new/httpd.conf.default /etc/apache.new/magic.default /etc/apache.new/mime.types.default /etc/apache.new/srm.conf.default /etc/bash.bashrc.default /etc/enscript.cfg.default /etc/exim.conf.default /etc/mime.conf.default /etc/profile.default /etc/skel/[initial user files here] /etc/squid.conf.default I think creating... /etc/defaults/etc/apache/access.conf /etc/defaults/etc/apache/httpd.conf /etc/defaults/etc/apache/magic /etc/defaults/etc/apache/mime.types /etc/defaults/etc/apache/srm.conf /etc/defaults/etc/bash.bashrc /etc/defaults/etc/enscript.cfg /etc/defaults/etc/exim.conf /etc/defaults/etc/mime.conf /etc/defaults/etc/profile /etc/defaults/etc/skel/[initial user files here] /etc/defaults/etc/squid.conf and the script... #!/bin/bash cd /etc/defaults for f in `find . -type f`; do fDest = `echo $f | sed 's/^\.//g'` echo $f $fDest if [ ! -f $fDest ]; then echo Using the default version of $fDest cp $f $fDest else echo $fDest is already in existance, not overwriting. fi done There are however, a few problems which need to be overcome. The first is that this script, although best as a postinstall, would have be executed _after every install_. The other would be to get people to use it ;) Well, that's my mental thoughts on paper(?!). Any comments? would it be worth doing? J. --LongSig It's so stupid of modern civilization to have given up believing in the Devil when he is the only explanation of it. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: defaults
On Mon, Dec 02, 2002 at 12:56:03PM -, Morrison, John wrote: The first is that this script, although best as a postinstall, would have be executed _after every install_. The other would be to get people to use it ;) Well, that's my mental thoughts on paper(?!). Any comments? would it be worth doing? Here's how _update-info-dir does it: sdesc: Generate info/dir file automatically category: _PostInstallLast requires: texinfo ash autodep: usr/info/.* incver_ifdep: yes You'd probably want something like: sdesc: Conditionally move default files to proper location category: _PostInstallLast requires: ash autodep: etc/defaults/.* incver_ifdep: yes This would run automatically whenever packages are downloaded and installed in one shot. It wouldn't run if someone downloads everything and then installs piecemeal, though. The script to move the files would be the only thing in the package and it would be a post-install script. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
setup HEAD (2.278) defaults to older packages
On the dialogs I choose: Download Source: Download from Internet OR Install from Internet Local package dir: C:\cygdist Internet Connection: Direct Connection Download Site: ftp://archive.progeny.com Now when the Chooser window comes up, I click on Base, and I see ash: 20020131-1 bash:2.05b-4 cygwin: 1.3.10-1 Despite the fact that the setup.ini says the current versions are: ash: 20020731-1 bash:2.05b-5 cygwin: 1.3.12-4 I can get at the latest version by clicking a few times, but shouldn't it default to the latest packages? I get the latest versions by default if I use version 2.249.2.5. Bug, or intentional? -Len
Re: setup HEAD (2.278) defaults to older packages
Len Giambrone wrote: On the dialogs I choose: Download Source: Download from Internet OR Install from Internet Local package dir: C:\cygdist Internet Connection: Direct Connection Download Site: ftp://archive.progeny.com Now when the Chooser window comes up, I click on Base, and I see ash: 20020131-1 bash:2.05b-4 cygwin: 1.3.10-1 Despite the fact that the setup.ini says the current versions are: ash: 20020731-1 bash:2.05b-5 cygwin: 1.3.12-4 I can get at the latest version by clicking a few times, but shouldn't it default to the latest packages? I get the latest versions by default if I use version 2.249.2.5. Bug, or intentional? Bug, definitely, but this is HEAD, after all, and see Robert's last post. Max.
lesstif confuses app-defaults
After upgrading XFree86 and installing lesstif (so far, I had used my own lesstif), I found that the directory tree was confused: instead of a symlink /usr/X11R6/lib/X11/app-defaults - /etc/X11/app-defaults, there was a directory /usr/X11R6/lib/X11/app-defaults containing a symlink app-defaults and a file Mwm (the latter should rather have been in /etc/X11/app-defaults). Thus no application (except mwm) could find its app-defaults file. This is obviously a bug in the lesstif tar file. (I just found this effect has been reported before in 2002-05/msf00296.html but is still not fixed.)
Re: lesstif confuses app-defaults
Dou you manage to use mwm normally ? Trying to use lesstiff with the file /usr/X11R6/lib/X11/mwm/system.mwmrc copied in $HOME/.mwmrc doesn't function. (even it's written in README in the same directory) It reports : Warning: Cannot convert string rom14 to type FontStruct (font problem, I think) and menus don't work, I cannot move/resize/close/... windows. --- Hans Werner Strube [EMAIL PROTECTED] a écrit : After upgrading XFree86 and installing lesstif (so far, I had used my own lesstif), I found that the directory tree was confused: instead of a symlink /usr/X11R6/lib/X11/app-defaults - /etc/X11/app-defaults, there was a directory /usr/X11R6/lib/X11/app-defaults containing a symlink app-defaults and a file Mwm (the latter should rather have been in /etc/X11/app-defaults). Thus no application (except mwm) could find its app-defaults file. This is obviously a bug in the lesstif tar file. (I just found this effect has been reported before in 2002-05/msf00296.html but is still not fixed.) ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
