Setup.hint for base-passwd is incorrect

[Doug Wyatt]

I've just investigated an anomaly with the base-passwd package, 
which turns out to be an incorrect setup.hint file in the repository.

repository base-passwd directories contain

base-passwd-2.0-1.tar.bz2   30-Nov-2003 07:16 1k
base-passwd-2.1-1.tar.bz2   21-Aug-2004 11:48 1k
md5.sum   21-Aug-2004 13:54 1k
setup.hint  16-Jul-2004 02:11   1k

but the setup.hint file contains

sdesc: "A script to set up initial passwords and groups"
requires: cygwin ash
category: base
test: 2.0-1
curr: 1.1-1

Is 2.0-1 curr and 2.1-1 test, or is 2.0-1 prev and 2.1-1 curr?

Regards,
Doug Wyatt

--
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: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Patrick Samson]

--- Patrick Samson wrote:
> 
> --- Igor Pechtchanski wrote:
> > On Mon, 27 Sep 2004, Patrick Samson wrote:
> > 
> > > I use a dll which have references to both
> > > cygwin and m$:
> > > $ cygcheck /usr/share/tcl8.4/dp4.0/win/dp40.dll
> > > D:/cygwin/usr/share/tcl8.4/dp4.0/win/dp40.dll
> > >   D:\cygwin\bin\tcl84.dll
> > > C:\WINNT\System32\ADVAPI32.DLL
> > >   C:\WINNT\System32\ntdll.dll
> > >   C:\WINNT\System32\KERNEL32.dll
> > >   C:\WINNT\System32\USER32.dll
> > > C:\WINNT\System32\GDI32.dll
> > >   C:\WINNT\System32\RPCRT4.dll
> > > D:\cygwin\bin\cygwin1.dll <-
> > >   C:\WINNT\System32\msvcrt.dll <
> > >   C:\WINNT\System32\WS2_32.DLL
> > > C:\WINNT\System32\WS2HELP.dll
> > >
> > > Should I suspect this to be a possible source of
> > trouble? Or does it
> > > mean nothing?
> > 
> > Depends.  Usually, this results in some sort of
> > trouble, mostly because of
> > the separate parallel stdio, malloc, etc
> > implementations.  You may be able
> > to get away with it for a while if none of the
> > msvcrt functions are
> > actually called, but it may come back and bite you
> > in the future.
> > Igor
> 
> Since my post I found a way to reproduce on
> development the problem I have on production.
> At some point cygserver hits 100%CPU and Postgres
> backends are no more able to serve requests.
> Now I must narrow the number of components involved,
> to prove that the culprit is really this DLL.
> As you suggest, it may be a mess with mem alloc.

I built the DLL another way, and now have:
$ cygcheck ./dp40.dll
.\dp40.dll
  D:\cygwin\bin\cygwin1.dll <
C:\WINNT\System32\ADVAPI32.DLL
  C:\WINNT\System32\ntdll.dll
  C:\WINNT\System32\KERNEL32.dll
  C:\WINNT\System32\USER32.dll
C:\WINNT\System32\GDI32.dll
  C:\WINNT\System32\RPCRT4.dll
  D:\cygwin\bin\tcl84.dll
  C:\WINNT\System32\WS2_32.DLL
C:\WINNT\System32\MSVCRT.dll <---
C:\WINNT\System32\WS2HELP.dll
Seems better, as msvcrt.dll is only there because
of ws2_32 (winsock2).

But the problem is still there, so this may not be
the primary cause.
With cygserver debug, I found the same case as:
http://sources.redhat.com/ml/cygwin/2004-07/msg01058.html
(cygserver - Postgres Multiple connection Load Testing
- Inifinte Loop). But this post has no reply :(
The log file is full (75M in a few seconds!) with:
cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
line 189: Unlockedmutex semid
cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
line 227: Try locking mutex semid
cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
line 227: Locked  mutex semid
cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1112: semop:  good morning (error=0)!

cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1121: semop:  good morning!

cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1049: semop:  semaptr=A056AA0, sem_base=A05684C,
semptr=A056870, sem[3]=0 : op=-1, flag=wait

cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1053: semop:  can't do it now

cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1086: semop:  rollback 0 through -1

cygserver:
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
line 1109: semop:  good night!

Got to upgrade to 1.5.11 and check if it's better.

Meanwhile, Corinna, any obvious suggestion,
looking at these above traces?





__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

--
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: Program exited with code 0303000

[Dan Osborne]

OK, my voyage of discovery continues. I've added exception specifications to
the appropriate functions (declarations and definitions - took a while to
work out I needed it on both) but no change in behaviour.

I've also remembered why I started to look at dumper.exe - If I don't run
the prog in gdb then instead of "Program exited with code 0303000" I get ...

Aborted (core dumped)

Presumably because of the uncaught exception, despite a catch (...) in my
main.

My main is mostly this ...

   try
   {
  char* s = strclone( cfg.getString( "FIRST_SCREEN" ) );
  RProg::Mode m = (RProg::Mode)cfg.getInt( "FIRST_MODE" );
  RProg::runScreen( s, m );
  delete[] s;
   }
   catch( RException& e )
   {
  RProg::displayMessage(e.what());
   }
   catch (...)
   {
  RProg::displayMessage("An unknown exception occurred");
   }

Most of the application is happening in the RProg class which is in a shared
object and loads other shared objects using the same runScreen function
above (it uses dlopen). These usually exit by throwing the same exception
(strange approach I know but the application is a translation of one written
in PowerHouse 4GL where the return verb is used to exit screens and I
couldn't think of a better way to implement this in C++).

The problem doesn't occur if the loaded shared objects don't do any database
activity and the C++ library that uses the odbc32.dll has all its code in
the otlv4.h header file with many inline functions. Might it help further
investigation if I split the header file into a .h and a .cc with no inline
functions?

Also, earlier there was some mention of linking statically against the
odbc32.dll - is that worth trying? As you can probably tell I'm up against
the limit of my knowledge in this area and am not sure how to do it.

Currently I do this to create the shared object ...

g++ -shared -Wl,--out-implib=libcxxdll.dll.a \
-o librbase.so rdata.o rchar.o rdate.o rdatetime.o rfloat.o rinteger.o
rfromany.
o rany.o roperator.o rnumber.o rexception.o rprog.o csql.o rfile.o rcrc32.o
robj
ect.o rlist.o rlogger.o rconfig.o roccurs.o dbinfo.o
local.o   -L. -L/usr2/ph/sr
c/lib/rdc/ -L/usr2/ph/src/../lib/  -lodbc32 -lboost_regex -lph2ax  -Wl,--exp
ort-
all-symbols

And this to link my program ...

g++ -Wall -g -O0 -I/usr2/ph/src/../include -I/usr2/ph/src/lib/rdc -I$ORACLE_
HOME
_CYG/oci/include -I. -o rscreen
rscreen.cc -L. -L/usr2/ph/src/lib/rdc/ -L/usr2/p
h/src/../lib/  -lodbc32 -lboost_regex -lph2ax   -L. -lcxxdll

I'm still puzzled by gdb losing track of which source line it is on, not so
much for its own sake but just because it is making it harder to get to the
bottom of what is going on.

Sorry to go on at length - its hard to find the right balance between
brevity and ommission.

Thanks in anticipation,

Dan



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Dan Osborne
> Sent: 28 September 2004 14:33
> To: '[EMAIL PROTECTED] Com'
> Subject: RE: Program exited with code 0303000
>
>
> >   Um.  Bizarre.  You did build with -g and -O0, didn't you?  Is
> > this an actual
> > function call here, or does add_var turn out to be some kind of
> > macro or something
> > that otherwise gets inlined?
>
> Well I was actually using -ggdb3 but I tried -g -O0 and it made no
> difference. I think the add_var line is spurious as there is no
> __cxa_rethrow in otlv4.h
>
> >
> >   Hmm.  Have you properly used 'throws XXX' declarations on all
> > the function
> > prototypes that need them?
> >
>
> Err, no there aren't any - I'll add them and see if it helps.
>
> > > So I'm wondering firstly why gdb seems to have a mismatch
> > > between address
> > > and source line number and why that throw didn't get caught
> > > in my catch in
> > > main.
> >
> >   You haven't shown me your main catch clause, but I'll assume
> > that it covers all
> > exception types (or at any rate, that it includes
> > RProgReturnException).  As I
> > suggest above, giving bad information to the compiler (through
> > missing or bogus
> > throws decls) can cause it to generate bad unwind info: and we
> > can pretty much
> > presume that the unwind info has to be bad in some way and that's
> > why it's missing
> > your outer catch when it unwinds.
>
> Yes, there's a catch (...) so I'll work on those throws clauses.
>
> Oh and the throw is in a shared library with the catch in my main if that
> has any bearing.
>
> Thanks,
>
> Dan
>
>
> --
> 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/
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 

Re: ssh-agent: Cygwin version problems

[Duncan Murdoch]

I've discovered that some of the information in my post below is
wrong:

On Sun, 26 Sep 2004 10:54:29 -0400, Duncan Murdoch
<[EMAIL PROTECTED]> wrote:

>I've been using OpenSSH with Cygwin for a while now, very
>successfully. Thanks to all who put this together.
>
>I'd like to set up my machine for remote logins now, which makes me
>much more security conscious:  using an old version of OpenSSH is not
>really an option.
>
>However, I can't find a way to get the latest OpenSSH to work without
>messing up ssh-agent in the sense that it becomes strongly attached to
>the bash window in which it was started.  With the versions I've got
>now, I can start ssh-agent, and an ssh tunnel, and then close the
>window, and those processes keep running.  This is very nice!
>
>As soon as I upgrade Cygwin, or the base files, this stops working.
>The bash window refuses to close; if I tell Windows to shut it down,
>it kills ssh-agent and ssh as well.

This is wrong.  ssh-agent is fine, it was ssh running some tunnels
that was creating the zombie windows.  I had a command line

ssh -N -f -L [tunnel 1] -L [tunnel 2] [EMAIL PROTECTED] >/dev/null
2>/dev/null 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: How can you change the DLL name in the .idata section header of a DLL?

[Reini Urban]

[ I switched from cygwin-apps, where it is not appropriate ]
Charles Wilson schrieb:
Reini Urban wrote:
Spoofing is a good point.
But I might prefer to be able to update dynamic dependencies without 
breakage. openssl usually gets updated with an security issue.
e.g curl or postgresql cannot deal with an openssl update which 
deletes cygssl-0.9.7.dll and replaces that with cygssl-0.9.8.dll.
If we had just a cygssl.dll we can simply upgrade that and nothing 
breaks.

That's the way most other DLLs on cygwin are named.  But cygssl is 
different -- as a security/encryption DLL, considerations other that 
"ease of slipstream replacement" are more important.  Usually there is a 
reason when a maintainer chooses to go against the common practice: 
openssl is one of those.

Anyway, see cygperl.dll:
DLL api's should stay binary compatible IMHO, unless it's really an 
issue (such as int32 => int64 on cygwin's switch from 1.3 => 1.5).
You normally can trust MS DLL backwards compatibility. Newer features 
are just added, or new versioned DLL's appear - newlib2.dll - but old 
DLL's must stay. ("contract")
With our libtool generated DLL names I'm not that happy.

Perl's build system is a nightmare.  We're lucky we have a shared 
version at all.  But if you want to assist Geritt in fixing some of the 
warts in the perl build system, I'm sure he'd welcome patches (and, as I 
indicate below, concentrating on the ACTUAL problems rather than trying 
to wholesale rework libtool/binutils/gcc/etc is probably a quicker path 
to solving your issues).

That name (cygssl-0.9.7.dll) is not libtool's fault.  Libtool uses two 
different mechanisms for setting the name of a DLL:
  -version-info c:r:a
and
  -release x.y.z
There are explicit rules governing how c, r, and a are to be updated, 
and how the dll name is derived from c,r,a in order to insure that (a) 
the library name changes rarely, and only when necessary to indicate 
binary incompatibility, and (b) all dlls with the same name are 
backwards compatible (e.g. old exe's linked against the old DLL will 
still work with the new DLL).  The libtool maintainers STRONGLY suggest 
using the -version-info paradigm.  On cygwin, this results in library 
names like libintl-3.dll (NOT libintl-0.12.1.dll)   Most cygwin packages 
which provide DLLs obey these rules and follow this "suggestion".

But the libtool folks do provide the -release mechanism, which is often 
used to name the DLL using the major.minor.micro revision numbering 
system.  There are sometimes good reasons to do this, but usually it's 
because the package maintainer doesn't understand library versioning, or 
libtool.  cygssl behave this way (even though it doesn't use libtool IIRC).

If libtool names were used "correctly" by the packages, then you would 
be "happy" -- and further, on cygwin we take GREAT PAINS to ensure that 
compatibility DLLs are kept around virtually forever whenever DLL names 
do change.  So what, exactly, is your beef?  Just perl and ssl -- and 
THAT justifies reworking libtool and binutils, and rewriting the 
underlying conventions of DLL names and cygwin's runtime loader?
Many thanks for this explanation. I was wrong.
Yes, indeed.
People forget about -no-undefined in their Makefile.am,
and then on any conflict libtool generates only the static version.
Which was e.g. the case with having -lgdi32 in the dependencies, for 
which no syms could be found.

It seems that the problem is NOT, then, libtool or the 
existence/non-existence of a .la file.  The problem is the "conflict" 
(e.g. build errors in the package in question).  Focus your efforts on 
fixing the problem, not band-aiding a "solution".
True. 99% of all conflicts are just incorrect object and library order. 
Seldom they miss a .o, lib or add a wrong dependency.

--
BTW, a binutils question:
"How can you change the DLL name in the .idata section header of a DLL?"
Don't do that.
Rationale:
DLL's cannot by symlinked on cygwin, unlike on other platforms.
DLL names are usually quite version specific, which makes perfect 
sense on those other platforms. DLL names are built in the executable 
PE header, so on any DLL rename or upgrade, breakage will occur. On MS 
Win32 old DLL's just stay, so no breakage will occur.
Not so with the cygwin setup.exe.

Faulty.  DLLs don't often change names, and when they do, the old 
versions stay around.  If not, then THAT is the problem.
Persuaded.
For instance, how many versions of libintl*.dll do you have on your 
system?  libncurses*.dll?  cygtiff*.dll?  cygjpeg*.dll?  cyggdbm*.dll? 
cygdb*.dll?

Are you noticing a pattern yet?
You caught me. Indeed.
It appears that your biggest beef is with the cygssl (and perl) DLL 
naming scheme: it uses -release versioning (even tho it actually doesn't 
use libtool to do it, IIRC).  (perl does something even wierder; I'm not 
going there).

This presents a difficulty for packages which depend on cygssl*dll. 
However, this IS one of those tim

Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Patrick Samson]

--- Patrick Samson wrote:
> 
> --- Patrick Samson wrote:
> > Since my post I found a way to reproduce on
> > development the problem I have on production.
> > At some point cygserver hits 100%CPU and Postgres
> > backends are no more able to serve requests.
> > Now I must narrow the number of components
> involved,
> > to prove that the culprit is really this DLL.
> > As you suggest, it may be a mess with mem alloc.
> 
> I built the DLL another way, and now have:
> $ cygcheck ./dp40.dll
> .\dp40.dll
>   D:\cygwin\bin\cygwin1.dll <
> C:\WINNT\System32\ADVAPI32.DLL
>   C:\WINNT\System32\ntdll.dll
>   C:\WINNT\System32\KERNEL32.dll
>   C:\WINNT\System32\USER32.dll
> C:\WINNT\System32\GDI32.dll
>   C:\WINNT\System32\RPCRT4.dll
>   D:\cygwin\bin\tcl84.dll
>   C:\WINNT\System32\WS2_32.DLL
> C:\WINNT\System32\MSVCRT.dll <---
> C:\WINNT\System32\WS2HELP.dll
> Seems better, as msvcrt.dll is only there because
> of ws2_32 (winsock2).
> 
> But the problem is still there, so this may not be
> the primary cause.
> With cygserver debug, I found the same case as:
>
http://sources.redhat.com/ml/cygwin/2004-07/msg01058.html
> (cygserver - Postgres Multiple connection Load
> Testing
> - Inifinte Loop). But this post has no reply :(
> The log file is full (75M in a few seconds!) with:
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
> line 189: Unlockedmutex semid
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
> line 227: Try locking mutex semid
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/bsd_mutex.cc,
> line 227: Locked  mutex semid
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1112: semop:  good morning (error=0)!
> 
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1121: semop:  good morning!
> 
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1049: semop:  semaptr=A056AA0,
> sem_base=A05684C,
> semptr=A056870, sem[3]=0 : op=-1, flag=wait
> 
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1053: semop:  can't do it now
> 
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1086: semop:  rollback 0 through -1
> 
> cygserver:
>
/netrel/src/cygwin-1.5.10-3/winsup/cygserver/sysv_sem.cc,
> line 1109: semop:  good night!
> 
> Got to upgrade to 1.5.11 and check if it's better.
> 
> Meanwhile, Corinna, any obvious suggestion,
> looking at these above traces?

Special note for Postgresql users:
So far I can only reproduce this problem if these
3 conditions are met:
- many connections (20, 25, 27) doing a simple SELECT
- a script running SELECT, CREATE/DROP TABLE/INDEX ...
- a pgAdmin III connected (but without activity)
(Postgresql version 7.3.6)

Quite the same with 1.5.11-3, only the loop is slower
so the CPU is not 100% and the log file doesn't
grow wildly.
Just an extract of the log here (full file 263K on
request):

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 189: Unlockedmutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 232: Try locking mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 232: Locked  mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1112: semop:  good morning (error=0)!

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1121: semop:  good morning!

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1049: semop:  semaptr=A056718, sem_base=A056440,
semptr=A0564F4, sem[15]=0 : op=-1, flag=wait

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1053: semop:  can't do it now

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1086: semop:  rollback 0 through -1

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1109: semop:  good night!

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 189: Unlockedmutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 232: Try locking mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/bsd_mutex.cc,
line 232: Locked  mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1112: semop:  good morning (error=4)!

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1218: Unlockedmutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 968: call to semop(65537, 0x22E444, 1)

cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 994: Try locking mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 994: Locked  mutex semid
cygserver:
/netrel/src/cygwin-1.5.11-1/winsup/cygserver/sysv_sem.cc,
line 1049: semop:  semaptr=A05

Re: cygserver won't start (FAQ alert)[SOLVED]

[Michael Hipp]

Larry Hall wrote:
True but you won't see a difference.  When you say "Task Scheduler", you
mean the Windows service/utility, right?  Just curious.  There's the same
issue with 'cron' and any service that runs under "SYSTEM".  It has no 
access to shares that require authentication to access.  So you either 
need to make your shares accessible to everyone or run the service under
your user name and only for your user.
Not sure I understood  all that. I have been attempting to run the 
scheduled task under the one-and-only username that ever accesses this 
box. (That's where the mapped network drives live.) So is it possible 
that re-installing as "Everyone" will fix it?

I've been thoroughly stumped thus far as to why a bash script that runs 
fine from the command prompt misbehaves from task scheduler even tho 
running as the same user.

Thanks,
Michael
--
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: cygserver won't start (FAQ alert)

[Igor Pechtchanski]

On Wed, 29 Sep 2004, Joshua Daniel Franklin wrote:

> On Wed, 29 Sep 2004 13:25:06 -0400 (EDT), Igor Pechtchanski wrote:
>
> > David, this is definitely an FAQ, but there is nothing in the FAQ about
> > services (other than the "how do I install snapshots" entry).  Should we
> > add something along the lines:
> >
> >   Why don't my services work?
> >
> >   Most Windows services run as the SYSTEM user.  If you installed Cygwin
> >   for "Just Me", the SYSTEM user won't see the mount table.  You need to
> >   re-mount all of your mounts as "system" for services to work.
> >
> > We could even include the recipe for remounting as system (e.g., from
> > ), or tell them to run
> > setup.exe again and select "All Users" on the "Install For" screen (and
> > use the "Keep" view, so that nothing gets upgraded accidentally).
> >
> > Incidentally, being able to use system mounts requires write access to the
> > HKLM registry tree.  However, installing services also seems to require
> > it, so if anyone has problems with services not working (but being
> > correctly installed into the registry) should also be able to use system
> > mounts.  Don't know if this is worth mentioning in the FAQ.
>
> Well, I updated that FAQ.

Thanks very much.

> I left out the registry-permission bits since it seemed superfluous.
> KISS!

Fair enough.

> 

Umm, a couple of minor nits.  First off, I think mentioning the option of
re-running setup.exe and selecting "Install For All Users" would be
helpful to those who don't like random scripts (besides, the script
mentioned will re-mount *all* user mounts, whereas only "/", "/usr/bin",
and "/usr/lib" are needed).  It could, of course, be fixed by something
like

eval "`mount -m | egrep '\"/(|usr/(bin|lib))\"' | sed -e 's/ -u / -s /g' -e 's/$/;/'`"

which you may or may not wish to use in the above entry.  Also, quoting
the contents of the above link:

   Workarounds include using public network share that does not require
   authentication (for non-critical files), or running the service as your
   own user with `cygrunsrv'.

I would say `cygrunsrv -u' here instead, just to point people in the right
direction.  Also,

   How should I set my PATH?

   How should I set my PATH?

   This is done for you in the file /etc/profile, which is sourced by...

i.e., the "How should I set my PATH?" question seems to have been
replicated.

HTH,
Igor
P.S. Joshua, are you the FAQ maintainer now?
-- 
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: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Patrick Samson]

> Special note for Postgresql users:
> So far I can only reproduce this problem if these
> 3 conditions are met:
> - many connections (20, 25, 27) doing a simple
> SELECT
> - a script running SELECT, CREATE/DROP TABLE/INDEX
> ...
> - a pgAdmin III connected (but without activity)
> (Postgresql version 7.3.6)

Doesn't fail by just changing pgAdmin III with
pgAdmin II.
What's the difference?
III tries first to talk in protocol V3 with the PG
backend. If the backend doesn't understand this
version, which the case for v7.3.6,
pgAdmin falls back to protocol V2 and things go on.
We can see it in the PG log with:
 FATAL:  unsupported frontend protocol

Does it mean that the backend did something wrong
with the IPCs when refusing V3 ...?




___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

--
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: Cygwin df -l option has wrong sense?

[Igor Pechtchanski]

On Thu, 30 Sep 2004, luke.kendall wrote:

> According to df --help, the -l option means to list only local drives.
> But in practice it seems to do the exact opposite:
>
> $ df -k /cygdrive/c/cygwin
> Filesystem   1k-blocks  Used Available Use% Mounted on
> C:\cygwin 39070048  32015012   7055036  82% /
>
> $ df -k -l /cygdrive/c/cygwin
> Filesystem   1k-blocks  Used Available Use% Mounted on
>
> $ df -k //handel/d
> Filesystem   1k-blocks  Used Available Use% Mounted on
> x: 4811432   2402244   2409188  50% /cygdrive/x
>
> $ df --help
> Usage: df [OPTION]... [FILE]...
> Show information about the filesystem on which each FILE resides,
> or all filesystems by default.
> [...]
>   -l, --local   limit listing to local filesystems
> [...]
> Report bugs to <[EMAIL PROTECTED]>.
>
> $ uname -a
> CYGWIN_NT-5.1 DOYLE 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown 
> Cygwin
>
> Have I misunderstood?
> luke

This is a problem with how fileutils tests for drives being local.  And,
it has been reported before (with a patch to fix it) -- see the thread
starting at .
Igor
P.S. The mount type fix is still on my TODO list :-(
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"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: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Patrick Samson]

Sigh,
Just after this post, I ran into the hang.
So pgAdmin II is no better, may be just a little
more difficult to fire the hang.

Still searching ...

--- Patrick Samson wrote:
> 
> > Special note for Postgresql users:
> > So far I can only reproduce this problem if these
> > 3 conditions are met:
> > - many connections (20, 25, 27) doing a simple
> > SELECT
> > - a script running SELECT, CREATE/DROP TABLE/INDEX
> > ...
> > - a pgAdmin III connected (but without activity)
> > (Postgresql version 7.3.6)
> 
> Doesn't fail by just changing pgAdmin III with
> pgAdmin II.
> What's the difference?
> III tries first to talk in protocol V3 with the PG
> backend. If the backend doesn't understand this
> version, which the case for v7.3.6,
> pgAdmin falls back to protocol V2 and things go on.
> We can see it in the PG log with:
>  FATAL:  unsupported frontend protocol
> 
> Does it mean that the backend did something wrong
> with the IPCs when refusing V3 ...?




__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

--
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: win95 pipe problems -- report + testcase + patch

[Donald Wallace Rouse II]

This patch is not in the current release (1.5.11-1).
I can't compile it myself, because ./config fails (because it uses pipes).
Can someone give me some kind of timeframe when the next version will be released 
(with this patch in it)?
Thanks.



--
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: win95 pipe problems -- report + testcase + patch

[Brian Dessent]

Donald Wallace Rouse II wrote:
> 
> This patch is not in the current release (1.5.11-1).
> I can't compile it myself, because ./config fails (because it uses pipes).
> Can someone give me some kind of timeframe when the next version will be released 
> (with this patch in it)?

http://cygwin.com/snapshots/

Brian

--
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/

seg-vios from gcc program at execv() on Windows XP

[Richard Troy]

Hello Cygwiners,

I'm a long-time user of Cygwin - love it, depend on it... and rarely have
a problem, but I really need some help with this one particular problem.
I've already tapped into my other technical resources on this and haven't
gotten anywhere at all. It isn't clear this is a Cygwin problem, but then,
it isn't clear that it isn't, either. ...I really need some insight
here...

A couple of weeks ago some skum-bag stole my laptop and my new one came
with Windows XP Professional. ...I now understand what XP stands for: XP
means eXtremely Painful. Anyway, I use the laptop for sales calls (I'm the
technical person) and it just _has_ to work. I've been having trouble
getting my company's software working on the system and my boss said,
"well, this is a good chance for you to make sure our stuff works on XP,
so, have fun!" - or words to that effect... But I am _not_ having fun.
-frown-

The problem is that we've got a GCC based program that ends up calling
Java via execv(). It _always_ seg-vios when the GCC program itself
is called from another program (non-interactive) and it sometimes seg-vios
when run from an interactive Cygwin Bash prompt. Significant testing has
shown that the interactive failure seems to be associated with environment
variables. For example, the code uses an environment variable to determine
if it should output "verbose" statements to std-out (via printf), and if
this is set, the execv() always fails. However, it also fails sometimes
depending on other variables that should have _nothing_ to do with the
program.

Here's an excerpt of the code in the vicinity of the exec:

  strcpy(program,JavaHomeenv);
  strcat(program,"/bin/java");
  // make sure that argv0 is fully qualified so that java doesn't
  // default to a local binary
  nargv[0]=program;
  //nargv[0]= "java";
  nargv[1]= "-classpath";
  nargv[2]= classpathenv;
  nargv[3]= std;
  nargv[4]= ck;
  nargv[5]= rus;
  nargv[6]= host;
  nargv[7]= stc;
  nargv[8]= stt;
  nargv[9]= dk;
  nargv[10]= cl;

  i = execv(program, nargv);

Note that the code is _rock_solid_ on Linux/Unix/Mac OSX, and on all
earlier versions of Windows we've ever tried it on. We've _never_ seen it
seg-vio before.

Also note that I recompiled the executable on the target system. I'm
wondering if there's something about the new installation of Cygwin on XP
that's changed something about how the binary runs...

In case it helps: cygcheck -s says we're running 1.5.10, and gcc is
3.3.1-3. It was a fresh, absolutely complete installation - even the stuff
I never need. (BTW ping and dig utilities would be nice!)

Help!

Thanks everyone,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
[EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/


--
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: cp to flash drive very slow

[David A. Rogers]

Thanks for responding, Gary.

> Regardless, <3.7Mb/second seems like something's wrong somewhere.  Are you
> running USB2.0 hub-to-device?

I dunno.  I'm not very knowledgable about hardware esp. USB.  How would I
tell?

dar

On Wed, 29 Sep 2004, Gary R. Van Sickle wrote:

> > I tried using cp to copy a zip file 106MB from my hard drive
> > to my flash drive (sandisk mini cruzer).  After 20 minutes it
> > still had not completed.
> >
> > xcopy copied the file in 22 seconds.
> >
> > Why would cp be so much slower?  Any ideas as to work-arounds?
> >
>
> Last I checked, cp was slower on network copies than xcopy was, but the
> difference was nowhere *near* that dramatic.  I can offer a few guesses
> here:
>
> 1.  Again last I looked, cp was using fopen()/fread() et al to do the copy.
> Good for portability, bad for efficiency.  Xcopy is probably using
> CopyFile{Ex} or some such lower-level funcion, which if MS is on the ball
> (yeah I know) involves a lot fewer layers of code, and if we're really good
> maybe is even copying raw sectors using scatter/gather (yeah I know I'm
> dreaming, but maybe).
>
> 2.  Caching.  Xcopy may be caching your writes to flash, cp may be forcing a
> flush somehow.  I've had similar copies take essentially no time, only to
> find out that the copy never actually got committed to disk until much much
> later.  XP SP1 doesn't default to that behavior IIRC, but check to make sure
> that you do NOT have that option turned on, or you WILL lose data.
>
> Regardless, <3.7Mb/second seems like something's wrong somewhere.  Are you
> running USB2.0 hub-to-device?
>
>


--
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: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Corinna Vinschen]

On Sep 30 00:12, Patrick Samson wrote:
> I built the DLL another way, and now have:
> $ cygcheck ./dp40.dll
> .\dp40.dll
>   D:\cygwin\bin\cygwin1.dll <
> C:\WINNT\System32\ADVAPI32.DLL
>   C:\WINNT\System32\ntdll.dll
>   C:\WINNT\System32\KERNEL32.dll
>   C:\WINNT\System32\USER32.dll
> C:\WINNT\System32\GDI32.dll
>   C:\WINNT\System32\RPCRT4.dll
>   D:\cygwin\bin\tcl84.dll
>   C:\WINNT\System32\WS2_32.DLL
> C:\WINNT\System32\MSVCRT.dll <---
> C:\WINNT\System32\WS2HELP.dll
> Seems better, as msvcrt.dll is only there because
> of ws2_32 (winsock2).

Which shouldn't be referenced at all.  dp40.dll apparently references
ws2_32.dll directly instead of using the Cygwin socket calls.


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: [ITP] libgpg-error-1.0-2

[Gerrit P. Haase]

Hi Lapo,

> Is a review really needed if the package is based on Gerrit's work?
> It's HIM that corrected my last packages actually ;-)

Nobody is perfect!


Nobody
-- 
=^..^=


--
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: Problems on Itanium: Found the Cause, What's Next?

[Corinna Vinschen]

On Sep 30 09:01, Alex Alexandrov wrote:
> Hi, Alex Alexandrov, you wrote
> 
> >I've posted the bug report to public.win32.programming.kernel and
> >private.windowsserver_64bit msft mailing lists - no answer so far...
> 
> OK, there is a reply from msft: "The problem is being checked out". Does it 
> mean that they were able to reproduce the bug?

That's a good question.  I'd translate this as "we have tested it
and verified that the problem exists", but I wouldn't bet on this.
After all I'm also not a native speaker.


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: seg-vios from gcc program at execv() on Windows XP

[Igor Pechtchanski]

On Thu, 30 Sep 2004, Richard Troy wrote:

> Hello Cygwiners,

I believe the technical term is "cygwinners" (unless you really mean
"cygwhiners"? ];->)

> I'm a long-time user of Cygwin - love it, depend on it... and rarely have
> a problem, but I really need some help with this one particular problem.
> I've already tapped into my other technical resources on this and haven't
> gotten anywhere at all. It isn't clear this is a Cygwin problem, but then,
> it isn't clear that it isn't, either. ...I really need some insight
> here...
>
> A couple of weeks ago some skum-bag stole my laptop and my new one came
> with Windows XP Professional. ...I now understand what XP stands for: XP
> means eXtremely Painful. Anyway, I use the laptop for sales calls (I'm the
> technical person) and it just _has_ to work. I've been having trouble
> getting my company's software working on the system and my boss said,
> "well, this is a good chance for you to make sure our stuff works on XP,
> so, have fun!" - or words to that effect... But I am _not_ having fun.
> -frown-
>
> The problem is that we've got a GCC based program that ends up calling
> Java via execv(). It _always_ seg-vios when the GCC program itself
> is called from another program (non-interactive) and it sometimes seg-vios
> when run from an interactive Cygwin Bash prompt. Significant testing has
> shown that the interactive failure seems to be associated with environment
> variables. For example, the code uses an environment variable to determine
> if it should output "verbose" statements to std-out (via printf), and if
> this is set, the execv() always fails. However, it also fails sometimes
> depending on other variables that should have _nothing_ to do with the
> program.
>
> Here's an excerpt of the code in the vicinity of the exec:
>
>   strcpy(program,JavaHomeenv);
>   strcat(program,"/bin/java");
>   // make sure that argv0 is fully qualified so that java doesn't
>   // default to a local binary
>   nargv[0]=program;
>   //nargv[0]= "java";
>   nargv[1]= "-classpath";
>   nargv[2]= classpathenv;
>   nargv[3]= std;
>   nargv[4]= ck;
>   nargv[5]= rus;
>   nargv[6]= host;
>   nargv[7]= stc;
>   nargv[8]= stt;
>   nargv[9]= dk;
>   nargv[10]= cl;
>
>   i = execv(program, nargv);

> Note that the code is _rock_solid_ on Linux/Unix/Mac OSX, and on all
> earlier versions of Windows we've ever tried it on. We've _never_ seen it
> seg-vio before.

Please provide a complete (hopefully simple) testcase, along with the
compilation flags, etc.  In particular, it'd be interesting to see how
nargv is allocated, etc.  I suspect you're not placing a NULL at the end
of the argument list, and Cygwin and Linux allocate nargv differently (so
that on Linux, nargv just happens to have zeroed memory after it).

FWIW, I have written a program that invokes java with various arguments
via execv (in almost exactly the same way as above), and it works just
fine on XP Pro.

> Also note that I recompiled the executable on the target system. I'm
> wondering if there's something about the new installation of Cygwin on XP
> that's changed something about how the binary runs...

More likely the memory alloc changes exposed a bug in your code.  If you
can come up with a program that tries invoking Java with constant
arguments and gets a SEGV, please post it.

> In case it helps: cygcheck -s says we're running 1.5.10, and gcc is
> 3.3.1-3. It was a fresh, absolutely complete installation - even the stuff
> I never need.

A better way to inform us about your system configuration would be to
*attach* (as an uncompressed text attachment) the output of "cygcheck
-svr", as requested in the Cygwin problem reporting guidelines at
.

> (BTW ping and dig utilities would be nice!)

FWIW, XP (and 2k) come with "`cygpath -S`/ping.exe" and
"`cygpath -S`/nslookup.exe".  There were also some threads on porting ping
to Cygwin -- search the list archives.
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: [PATCH] cygrunsrv --recovery

[Corinna Vinschen]

On Sep 29 18:31, Rainer Hochreiter wrote:
> the attached patch implements the options -r or --recovery to set service
> failure actions. allowed actions are 'none', 'boot' or 'restar'.
> not implemented are actions for running commands on failed actions, like
> supported by the windows SCM.
> 
> the patch also uses ChangeServiceConfig2() for setting the description of
> the installed service.

Thanks for the patch, but I can't apply it as it is, mainly  for two
reasons.

> not included is the ChangeLog of the patch!

- This is reason one.

- Please don't use ChangeServiceConfig2.  It will break running cygrunsrv
  on NT4.  That's the reason the description is written directly to the
  registry instead of using ChangeServiceConfig2.

Also, what's the reason you didn't implement running commands?  I'm asking
because there are still these `#if 0' parts left in your patch which point
to the fact that you began to implement it but just stopped at one point.


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/

cygwin locale broken? (was: Re: gnome 2.8.0 and external dependencies)

[Gerrit P. Haase]

Hi Yang,

I switched this thread over to the main list.

> Just try the small test program attached below

> $ gcc -o localetest localetest.c
> $ ./localetest fr_FR
> changed to: (null)
> current LC_ALl: C
> current LC_CTYPE: C

> $ gcc -o xlocaletest -DX_LOCALE -I/usr/X11R6/include localetest.c
> -L/usr/X11R6/lib -lX11
> $ ./xlocaletest fr_FR
> changed to: fr_FR
> current LC_ALl: fr_FR
> current LC_CTYPE: fr_FR

> (and IIRC, David Huang sent a message to this list discussing about
> this issue last year, but cgf said there's no one bother to improve
> the implementation of the locale support of cygwin1.dl itself)

If there is no one fixing it then it will stay as it is, why is cygwin
locale broken, what is broken, how to fix it?  I don't want to patch 50
packages because some locale implementation is broken, better fix it
once and forever?

And if it is working for X it should not be too hard to get it working
in Cygwin too.


> - 8< --
> localetest.c-
> #ifdef X_LOCALE
> #include 
> #else
> #include 
> #endif


> void check_locale()
> {
> char *curr;

> /* Get the name of the current locale.  */
> curr=setlocale(LC_ALL, NULL);
> printf("current LC_ALl: %s\n", curr);

> curr=setlocale(LC_CTYPE, NULL);
> printf("current LC_CTYPE: %s\n", curr);
> }

> int main(int argc, char *argv[])
> {
>   if (argc<=1) {
> check_locale();
>   } else {
> char *new;
> new = setlocale(LC_ALL, argv[1]);
> printf("changed to: %s\n", new);

> check_locale();
>   }
>return 0;
> }


Gerrit
-- 
=^..^=


--
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/

[OT] Re: seg-vios from gcc program at execv() on Windows XP

[Brian Dessent]

Igor Pechtchanski wrote:

> > (BTW ping and dig utilities would be nice!)
> 
> FWIW, XP (and 2k) come with "`cygpath -S`/ping.exe" and
> "`cygpath -S`/nslookup.exe".  There were also some threads on porting ping
> to Cygwin -- search the list archives.

I know this is heading off topic...

I like to install the win32 version of ISC BIND9, which gives a
unix-like dig / host / nslookup / named / rndc.  (It also allows you to
run your own caching resolver, which you can appreciate if you happen to
have a flakey ISP with poor nameservers.)

It would be nice to have a true Cygwin-ported set of netutils though, no
doubt about it.

Brian

--
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/

CVS cygserver compile errors w/gcc 3.4.3

[Brian Ford]

My own, compiled from CVS:
gcc (GCC) 3.4.3 20040928 (prerelease)

../../../../cygwin/winsup/cygserver/sysv_sem.cc:179: error: `__offsetof__'
was not declared in this scope
../../../../cygwin/winsup/cygserver/sysv_sem.cc: In function `void
seminit()':
../../../../cygwin/winsup/cygserver/sysv_sem.cc:217: error: `__offsetof__'
undeclared (first use this function)
../../../../cygwin/winsup/cygserver/sysv_sem.cc:217: error: (Each
undeclared identifier is reported only once for each function it appears
in.)

This is a mess of macros in code that I'm not familiar with, so I thought
I'd just report it rather than try to fix it.  It's not a showstopper
for me anyway.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

--
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: [PATCH] cygrunsrv --recovery

[Igor Pechtchanski]

On Thu, 30 Sep 2004, Corinna Vinschen wrote:

> On Sep 29 18:31, Rainer Hochreiter wrote:
> > the attached patch implements the options -r or --recovery to set service
> > failure actions. allowed actions are 'none', 'boot' or 'restar'.
> > not implemented are actions for running commands on failed actions, like
> > supported by the windows SCM.
> >
> > the patch also uses ChangeServiceConfig2() for setting the description of
> > the installed service.
>
> Thanks for the patch, but I can't apply it as it is, mainly  for two
> reasons.
>
> > not included is the ChangeLog of the patch!
>
> - This is reason one.
>
> - Please don't use ChangeServiceConfig2.  It will break running cygrunsrv
>   on NT4.  That's the reason the description is written directly to the
>   registry instead of using ChangeServiceConfig2.
>
> Also, what's the reason you didn't implement running commands?  I'm asking
> because there are still these `#if 0' parts left in your patch which point
> to the fact that you began to implement it but just stopped at one point.
>
> Corinna

And when you resubmit, please use "diff -u" instead of "diff -c" -- the
patch is much more readable that way.

One immediate change I noticed was that the description parameter migrated
from calls to install_registry_keys to calls to install_service, but you
haven't provided any changes to either of those functions.  Any reason for
this?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"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: [PATCH] cygrunsrv --recovery

[Corinna Vinschen]

On Sep 30 12:06, Igor Pechtchanski wrote:
> On Thu, 30 Sep 2004, Corinna Vinschen wrote:
> And when you resubmit, please use "diff -u" instead of "diff -c" -- the
> patch is much more readable that way.

ACK.

> One immediate change I noticed was that the description parameter migrated
> from calls to install_registry_keys to calls to install_service, but you
> haven't provided any changes to either of those functions.  Any reason for
> this?

That's the change from direct writing of registry keys to using
that ChangeServiceConfig2 function.


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: CVS cygserver compile errors w/gcc 3.4.3

[Corinna Vinschen]

On Sep 30 10:57, Brian Ford wrote:
> My own, compiled from CVS:
> gcc (GCC) 3.4.3 20040928 (prerelease)
> 
> ../../../../cygwin/winsup/cygserver/sysv_sem.cc:179: error: `__offsetof__'
> was not declared in this scope
> ../../../../cygwin/winsup/cygserver/sysv_sem.cc: In function `void
> seminit()':
> ../../../../cygwin/winsup/cygserver/sysv_sem.cc:217: error: `__offsetof__'
> undeclared (first use this function)
> ../../../../cygwin/winsup/cygserver/sysv_sem.cc:217: error: (Each
> undeclared identifier is reported only once for each function it appears
> in.)
> 
> This is a mess of macros in code that I'm not familiar with, so I thought
> I'd just report it rather than try to fix it.  It's not a showstopper
> for me anyway.

Thanks, I'm aware of this problem.  This is original code from FreeBSD,
but the FreeBSD code is plain C while I converted it partly to C++.
Unfortunately the offsetof macro in case of using C++ has drastically
changed with GCC 3.4 and it's said to be more correct this way...


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/

parse errors using setup

[Marco Bruschi]

Hallo,
The setup.exe stopped working properly from one day to the other 
(literally).
Now I get

parse error
(null) line 7449:syntax error, unexpected STRING
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
The setup version is the 2.425.
How to get rid of this ?
Thanks
--
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/

libtool convenience libs problem

[Reini Urban]

I don't where to direct libtool cygwin specific questions to, so I try 
it here.

I have an already libtoolized library, which should produce a DLL,
where several subdirs are just "convenience libs".
$ pinfo libtool
> Node: Static libraries
Such a convenience lib (a bastard between a real shared and static for 
intermediate usage, as I understand), depends on -lfl, which is only 
static. (some unimportant flex helpers)

Now when I try to link the main lib (libtool -mode=link) to create the 
DLL, the .la in the convenience libs contains -lfl, which is passed to 
the main lib linker verbatim, which creates a conflict in the link step, 
because -lfl cannot be linked dynamically, which causes the whole lib to 
be linked static only. Right? Sounds wrong to me.

I thought libtool is clever enough to resolve this dependency and just 
link those objects directly to the libfl.a objects, and just the rest 
dynamically via __imp stubs.

So it looks like that I have to persuade the convenience linker step 
somehow to link the static lib directly. dlopen or dlpreopen (as 
described in the warning) does not help, because there no cygfl.dll to 
load later.
Or should I declare -dlopen for my main lib?
Sounds wrong because the problem is that it doesn't link the libfl.a 
objects statically.
Or should I declare the convenience libs -static? Doesn't help neither.
I really don't want to extract the libfl.a objects and link it into the 
intermediate lib just to please libtool.

Example:
The two subdirs are just convenience libs (linked without -static and 
-rpath), where one depends on -lfl, the other on -lz (where a DLL exists).

/usr/src/libming/libming-0.3b2_20040929/.build/src
$ ../libtool --mode=link --tag=CC gcc  -O2 -o libming.la -version-info 
1:0:0 -no-undefined -rpath /usr/lib actioncompiler/libactioncompiler.la 
blocks/libswf.la *.lo
rm -fr  .libs/libming.a .libs/libming.la .libs/libming.lai

*** Warning: linker path does not have real file for library -lfl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libfl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libfl.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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: libtool convenience libs problem

[Reini Urban]

sorry for repating to myself.
But others had the same concerns this week 
http://lists.gnu.org/archive/html/libtool/2004-09/msg00124.html

And I'm also not convinvced that the given answer is practical.
"The static lib uses probably non-PIC code so it cannot be linked in.
Convenience libs should be avoided, rather link all objects directly.
and then do it via ld -r"
but libtool doesn't allow the setting of such an ld flag.
And I don't want to maintain the multiple dllwrap mess as before.
Esp. when it will not be accepted upstream.
So do I have to rebuild flex just to support a dynamic lib, which uses 
some parser generator support?

Reini Urban schrieb:
I don't where to direct libtool cygwin specific questions to, so I try 
it here.

I have an already libtoolized library, which should produce a DLL,
where several subdirs are just "convenience libs".
$ pinfo libtool
 > Node: Static libraries
Such a convenience lib (a bastard between a real shared and static for 
intermediate usage, as I understand), depends on -lfl, which is only 
static. (some unimportant flex helpers)

Now when I try to link the main lib (libtool -mode=link) to create the 
DLL, the .la in the convenience libs contains -lfl, which is passed to 
the main lib linker verbatim, which creates a conflict in the link step, 
because -lfl cannot be linked dynamically, which causes the whole lib to 
be linked static only. Right? Sounds wrong to me.

I thought libtool is clever enough to resolve this dependency and just 
link those objects directly to the libfl.a objects, and just the rest 
dynamically via __imp stubs.

So it looks like that I have to persuade the convenience linker step 
somehow to link the static lib directly. dlopen or dlpreopen (as 
described in the warning) does not help, because there no cygfl.dll to 
load later.
Or should I declare -dlopen for my main lib?
Sounds wrong because the problem is that it doesn't link the libfl.a 
objects statically.
Or should I declare the convenience libs -static? Doesn't help neither.
I really don't want to extract the libfl.a objects and link it into the 
intermediate lib just to please libtool.

Example:
The two subdirs are just convenience libs (linked without -static and 
-rpath), where one depends on -lfl, the other on -lz (where a DLL exists).

/usr/src/libming/libming-0.3b2_20040929/.build/src
$ ../libtool --mode=link --tag=CC gcc  -O2 -o libming.la -version-info 
1:0:0 -no-undefined -rpath /usr/lib actioncompiler/libactioncompiler.la 
blocks/libswf.la *.lo
rm -fr  .libs/libming.a .libs/libming.la .libs/libming.lai

*** Warning: linker path does not have real file for library -lfl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libfl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libfl.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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/

"find" - core dump on faulty arg

[Hannu E K Nevalainen]

Unintentionally I used %H in the 'find -printf' format string and ended up
with a core dump. I'm not entirely sure what %H is supposed to print; (as it
seems to me; nothing, when used this way)
man find/-printf format codes;
%H Command line argument under which file was found.
...so, this is a simple "heads up":

$ uname -svr


$ cygcheck -c findutils
Cygwin Package Information
Package  VersionStatus
findutils4.1.7-4OK

$ find -printf "%H\n"
Segmentation fault (core dumped)

$ cat find.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=004051F2
eax=0001 ebx=10010200 ecx= edx=00401044 esi=0022EF10
edi=100102A0
ebp=0022EE60 esp=0022EE04 program=C:\Program\Cygwin\bin\find.exe, pid 2388,
thread main
cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
Stack trace:
Frame Function  Args
0022EE60  004051F2  (00401044, 0022EF10, 10010258, 00406926)
0022EE90  0040491B  (00401044, 0022EF10, 10010210, 69776779)
0022EF50  0040193E  (00401044, 00401044, , 00401044)
0022F000  00401754  (00401044, 002D, 0041540C, 00401115)
0022F040  004014EB  (0003, 61781678, 100100A8, 0022F098)
0022F080  61005F34  (0022F098, 7FFDF000, , 32333838)
0022FF60  6100614B  (, , , )
End of stack trace


/Hannu E K Nevalainen, B.Sc. EE Microcomputer systems--72-->

** mailing list preference; please keep replies on list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
--END OF MESSAGE--


--
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: cp to flash drive very slow

[Hannu E K Nevalainen]

you wrote:

> Thanks for responding, Gary.
>
>> Regardless, <3.7Mb/second seems like something's wrong somewhere.
>> Are you running USB2.0 hub-to-device?
>
> I dunno.  I'm not very knowledgable about hardware esp. USB.  How
> would I tell?
>
> dar

Sorry for butting in...

 I'd say it should've read "USB 2.0" very clearly, somewhere on that
USB-thingie.

 Sometimes you can tell whether there is some caching going on by simply
moving everything away from the mounted drive (i.e. move Explorer's viewing
off the drive) and then submit an "Right click->Eject" on the drive letter.

If the Eject makes the USB-drive-led flicker, there was something cached.


/Hannu E K Nevalainen, B.Sc. EE Microcomputer systems--72-->

** mailing list preference; please keep replies on list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
--END OF MESSAGE--


--
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: Problems on Itanium: Found the Cause, What's Next?

[Alex Alexandrov]

Hi, Corinna Vinschen, you wrote
That's a good question.  I'd translate this as "we have tested it
and verified that the problem exists", but I wouldn't bet on this.
After all I'm also not a native speaker.
Yes, it seems you got them right. Today I've received the following message:
BEGIN OF MSG
Hello Alexei,
They reproduced the problem and a bug report was filed on the issue.
Thanks,
Darrell Gorter[MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights
< END OF MSG
So it is really very broken... :-( Today I've modified wincap.cc so that it 
uses GetNativeSystemInfo instead of IsWow64Process for determining 
environment details so that I can set has_working_copy_on_write to false 
only for Itanium-based machines (not for x86_64). Will you apply the patch 
if I provide it?

With best regards, Alex Alexandrov.  E-mail: [EMAIL PROTECTED] 
(remove numbers before e-mailing me) 

--
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: cp to flash drive very slow

[David A. Rogers]

Well, yes.  The flash drive is a Sandisk Cruzer Mini which is USB 2.0 with
fallback to 1.1.  The computer is a Dell Dimension 4600 which claims eight
USB 2.0 connectiors.  Running Windows XP.

I don't think caching is the difference.  I was able to unzip the .zip
file right after xcopy had copied it.

Is there anything faster than cp for copying out of the cygwin tools?  I'm
working out some scripts to share files between my work machine and my
home machine using the flash drive.  I could use xcopy but then I'd have
to go through the filename translation doohicky.

dar


On Thu, 30 Sep 2004, Hannu E K Nevalainen wrote:

> you wrote:
>
> > Thanks for responding, Gary.
> >
> >> Regardless, <3.7Mb/second seems like something's wrong somewhere.
> >> Are you running USB2.0 hub-to-device?
> >
> > I dunno.  I'm not very knowledgable about hardware esp. USB.  How
> > would I tell?
> >
> > dar
>
> Sorry for butting in...
>
>  I'd say it should've read "USB 2.0" very clearly, somewhere on that
> USB-thingie.
>
>  Sometimes you can tell whether there is some caching going on by simply
> moving everything away from the mounted drive (i.e. move Explorer's viewing
> off the drive) and then submit an "Right click->Eject" on the drive letter.
>
> If the Eject makes the USB-drive-led flicker, there was something cached.
>
>
> /Hannu E K Nevalainen, B.Sc. EE Microcomputer systems--72-->
>
> ** mailing list preference; please keep replies on list **
>
> -- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
> --END OF MESSAGE--
>
>
> --
> 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/
>
>
>


--
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/

[ANNOUNCEMENT] Updated: gv-3.5.8-2

[Dr. Volker Zell]

Hi

A new version of 'gv' has been uploaded to a server near you.


DESCRIPTION:

A PostScript and PDF viewer for X using 3d Athena Widgets

CYGWIN NEWS:


 o Changed gv so that is calls out to gs-x11 (which is a symbolic
   link to /usr/X11R6/bin/gs) to quiet the cygwin mailing lists about
   'unknown device x11' mails

 o Moved /usr/X11R6/doc to /usr/X11R6/share/doc


INSTALLATION:
=
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Save it and run setup, answer the questions and pick up
the above mentioned package from the 'X11' category.


DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need
to find a mirror which has this update, please choose the one nearest to
you: http://cygwin.com/mirrors.html


QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.


Enjoy
  Volker


--
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.hint for base-passwd is incorrect (setup.exe question)

[Christopher Faylor]

On Thu, Sep 30, 2004 at 02:04:56AM -0500, Doug Wyatt wrote:
>I've just investigated an anomaly with the base-passwd package, 
>which turns out to be an incorrect setup.hint file in the repository.
>
>repository base-passwd directories contain
>
>base-passwd-2.0-1.tar.bz2   30-Nov-2003 07:16 1k
>base-passwd-2.1-1.tar.bz2   21-Aug-2004 11:48 1k
>md5.sum   21-Aug-2004 13:54 1k
>setup.hint  16-Jul-2004 02:11   1k
>
>but the setup.hint file contains
>
>sdesc: "A script to set up initial passwords and groups"
>requires: cygwin ash
>category: base
>test: 2.0-1
>curr: 1.1-1
>
>Is 2.0-1 curr and 2.1-1 test, or is 2.0-1 prev and 2.1-1 curr?

I don't remember.  Do we still need base-passwd or is this now part
of setup.exe?

Max?  Rob?  I see myself responding to threads about this in the archives
but I'm not clear on what eventually happened.

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: Problems on Itanium: Found the Cause, What's Next?

[Christopher Faylor]

On Thu, Sep 30, 2004 at 10:11:45PM +0400, Alex Alexandrov wrote:
>Hi, Corinna Vinschen, you wrote
>
>>That's a good question.  I'd translate this as "we have tested it
>>and verified that the problem exists", but I wouldn't bet on this.
>>After all I'm also not a native speaker.
>
>Yes, it seems you got them right. Today I've received the following message:
>
>>BEGIN OF MSG
>Hello Alexei,
>They reproduced the problem and a bug report was filed on the issue.
>Thanks,
>Darrell Gorter[MSFT]
>This posting is provided "AS IS" with no warranties, and confers no rights
>< END OF MSG
>
>So it is really very broken... :-( Today I've modified wincap.cc so that it 
>uses GetNativeSystemInfo instead of IsWow64Process for determining 
>environment details so that I can set has_working_copy_on_write to false 
>only for Itanium-based machines (not for x86_64). Will you apply the patch 
>if I provide it?

No, not unless Microsoft indicates that they won't be fixing the problem.
This is a serious bug and it should be fixed properly not kludged around
in Cygwin.

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: cygwin locale broken? (was: Re: gnome 2.8.0 and external dependencies)

[Christopher Faylor]

On Thu, Sep 30, 2004 at 05:36:28PM +0200, Gerrit P. Haase wrote:
>Hi Yang,
>
>I switched this thread over to the main list.
>
>> Just try the small test program attached below
>
>> $ gcc -o localetest localetest.c
>> $ ./localetest fr_FR
>> changed to: (null)
>> current LC_ALl: C
>> current LC_CTYPE: C
>
>> $ gcc -o xlocaletest -DX_LOCALE -I/usr/X11R6/include localetest.c
>> -L/usr/X11R6/lib -lX11
>> $ ./xlocaletest fr_FR
>> changed to: fr_FR
>> current LC_ALl: fr_FR
>> current LC_CTYPE: fr_FR
>
>> (and IIRC, David Huang sent a message to this list discussing about
>> this issue last year, but cgf said there's no one bother to improve
>> the implementation of the locale support of cygwin1.dl itself)
>
>If there is no one fixing it then it will stay as it is, why is cygwin
>locale broken, what is broken, how to fix it?  I don't want to patch 50
>packages because some locale implementation is broken, better fix it
>once and forever?

If you are patching 50 packages, apparently you know something about what's
broken.

The locale implementation comes from newlib.  You can send bug reports and
patches to the newlib mailing list - newlib sourceware org.

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: parse errors using setup

[Christopher Faylor]

On Thu, Sep 30, 2004 at 06:24:46PM +0200, Marco Bruschi wrote:
>Hallo,
>The setup.exe stopped working properly from one day to the other 
>(literally).
>Now I get
>
>parse error
>(null) line 7449:syntax error, unexpected STRING
>(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
>(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
>(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
>(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
>(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
>
>The setup version is the 2.425.
>
>How to get rid of this ?

Don't keep us in suspense.  What's on line 7449?

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: parse errors using setup

[Marco Bruschi]

You mean in the setup.ini or the setup.bz2 ?
In the setup.ini:
7446: ###
7447: # KDE-3  internationalisation
7448: ###
7449: @ kde3-i18n-af
7450: category: KDE3-i18n
7451: requires: kdelibs-3
7452: version:  3.1.4
7453: install:  kde-i18n/kde3-i18n-af-3.1.4-0.tar.bz2 967158
7454: sdesc:"Afrikaans - KDE language support"
The other file I suppose is a binary.
Thanks for the moment
mb

Christopher Faylor wrote:
On Thu, Sep 30, 2004 at 06:24:46PM +0200, Marco Bruschi wrote:
Hallo,
The setup.exe stopped working properly from one day to the other 
(literally).
Now I get

parse error
(null) line 7449:syntax error, unexpected STRING
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
(null) line 7449:unrecognized line 7449 (do you have the latest setup ?)
The setup version is the 2.425.
How to get rid of this ?

Don't keep us in suspense.  What's on line 7449?
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/
--
Marco Bruschi
DESY Laboratory - Notkestrasse 85 - 22607 Hamburg (Germany)
Tel: +49 40 89981 982 Fax: +49 40 8994 1982 Handy: +49 172 1688839
e-mail: [EMAIL PROTECTED]
--
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: Crontab issue

[Larry Hall]

At 12:53 AM 9/30/2004, you wrote:
>On Thu, 09 Sep 2004 14:29:16 -0400, Larry Hall wrote:
>
>> Access to network shares seems to come up allot in the context of Cygwin
>> services.  Maybe it would be good to add something to the FAQ on this.
>> What do you think Joshua?
>
>See how this does:
>
>   Some Cygwin services normally run as the SYSTEM user, which has
>certain limitations. Under the Windows authentication scheme, the
>SYSTEM user cannot access network shares that require authentication.
>For more information, see
>`http://cygwin.com/cygwin-ug-net/ntsec.html'.
>
>   Workarounds include using public network share that does not require
>authentication (for non-critical files), or running the service as your
>own user with `cygrunsrv'.


Very nice.  Thank you.  I wonder if you would be able to add the following
on a future pass:

In the latter case, this is likely to keep the service from working for
any user other than your own.

Just a thought and really just for added clarification.  I'm already 
excited about being able to point to this new FAQ entry next time the 
question comes up! :-)


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
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: parse errors using setup

[Christopher Faylor]

On Thu, Sep 30, 2004 at 09:13:54PM +0200, Marco Bruschi wrote:
>You mean in the setup.ini or the setup.bz2 ?
>
>In the setup.ini:
>
>7446: ###
>7447: # KDE-3  internationalisation
>7448: ###
>7449: @ kde3-i18n-af
>7450: category: KDE3-i18n
>7451: requires: kdelibs-3
>7452: version:  3.1.4
>7453: install:  kde-i18n/kde3-i18n-af-3.1.4-0.tar.bz2 967158
>7454: sdesc:"Afrikaans - KDE language support"

So you're using a custom setup.ini.  I don't see a string there but possibly
this isn't the file that you're trying to use.  It may be the bzip2 file.

>The other file I suppose is a binary.

http://www.google.com/search?q=what+is+bz2+file

--
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: cygserver won't start (FAQ alert)

[Joshua Daniel Franklin]

On Thu, 30 Sep 2004 09:43:26 -0400 (EDT), Igor Pechtchanski wrote:
> > 
> 
> Umm, a couple of minor nits.  First off, I think mentioning the option of
> re-running setup.exe and selecting "Install For All Users" would be
> helpful to those who don't like random scripts 

> I would say `cygrunsrv -u' here instead, just to point people in the right 
> direction.  Also,

Right. 

> 
>How should I set my PATH?
> 
>How should I set my PATH?
 
Whoops. Fixed that.

> P.S. Joshua, are you the FAQ maintainer now?

Well, since davidsb is AWOL I've been de facto maintainer.

--
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: cp to flash drive very slow

[Hannu E K Nevalainen]

you ([EMAIL PROTECTED]) wrote on  :

> Well, yes.  The flash drive is a Sandisk Cruzer Mini which is USB 2.0
> with fallback to 1.1.  The computer is a Dell Dimension 4600 which
> claims eight USB 2.0 connectiors.  Running Windows XP.

Right, then we know. ;-)
 
> I don't think caching is the difference.  I was able to unzip the .zip
> file right after xcopy had copied it.

...which doesn't proove a thing about caching or not.
 
> Is there anything faster than cp for copying out of the cygwin tools?
> I'm working out some scripts to share files between my work machine
> and my home machine using the flash drive.  I could use xcopy but
> then I'd have to go through the filename translation doohicky.
> 
> dar

*** Untested  suggestion:

---
#!/bin/bash

src="/home/dar/personal-projects /projects/"
dst="/cygdrive/z" # for the USB drive

for d in $src; do
  find $d -type d | (
  while read dir; do
# cannot be used on SHARES
mkdir -p "$dst/$dir"
# assuming xcopy is in PATH
xcopy "$(cygpath -D "$dir")" "$(cygpath -D "$dst/$dir")"
  done
  )
done
---

Does it need to be more complex?

Otherwise the cygwin 'rsync' or 'unison' packages might be useful... 
Others might be able to help with them.

/Hannu E K Nevalainen, B.Sc. EE Microcomputer systems--72-->

** mailing list preference; please keep replies on list **

-- printf("LocalTime: UTC+%02d\n",(DST)? 2:1); --
--END OF MESSAGE--

--
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.hint for base-passwd is incorrect (setup.exe question)

[John Morrison]

> On Thu, Sep 30, 2004 at 02:04:56AM -0500, Doug Wyatt wrote:
>>I've just investigated an anomaly with the base-passwd package,
>>which turns out to be an incorrect setup.hint file in the repository.
>>
>>repository base-passwd directories contain
>>
>>base-passwd-2.0-1.tar.bz2   30-Nov-2003 07:16 1k
>>base-passwd-2.1-1.tar.bz2   21-Aug-2004 11:48 1k
>>md5.sum   21-Aug-2004 13:54 1k
>>setup.hint  16-Jul-2004 02:11   1k
>>
>>but the setup.hint file contains
>>
>>sdesc: "A script to set up initial passwords and groups"
>>requires: cygwin ash
>>category: base
>>test: 2.0-1
>>curr: 1.1-1
>>
>>Is 2.0-1 curr and 2.1-1 test, or is 2.0-1 prev and 2.1-1 curr?
>
> I don't remember.  Do we still need base-passwd or is this now part
> of setup.exe?
>
> Max?  Rob?  I see myself responding to threads about this in the archives
> but I'm not clear on what eventually happened.

Wrong way round Chris - base-passwd is the functionality extracted from
setup.  I'm not sure what happened to the numbering - there was an
experimental version which added a root user, I'm afraid I must have
gotten something mixed up.

I'll try and sort it out ASAP.

Sorry,

J.


--
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/

Home Typists Required.

[Arjun]

International Company needs reliable self-motivated people world-wide who
want to earn additional income from their home.  
 
Income is GUARANTEED! Positions are limited! Don't wait! Apply NOW!

[EMAIL PROTECTED]

--
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: Excessive CPU load (cygrunsrv.exe, tail.exe, etc)

[Steve B]

I do not believe that I am using Process Explorer.

Today, after contemplating my problem for a while, I
noticed some pertinent details that I would like to
share:

This CPU load overload can reliably be triggered by
Enemy Territory.  Guaranteed, every time I run Enemy
Territory, a cygwin process will begin to hog the CPU
starting with cygrunsrv.exe every time, and will
continue until either a) I keep killing (through the
Windows task manager) each cygwin process that
overloads until no more cygwin process exists so I can
return to my game, or b) I terminate Enemy Territory
through the Windows task manager and kill the cygwin
process that is overloading, then no other cygwin
processes will hog the cpu, but I cannot play Enemy
Territory.  I thought that since it could reliably be
triggered this way, perhaps that might assist with any
testing, if any.

Another thing I noticed, after reading Andrew DeFaria
post, was that csrss.exe would be using 25% of the CPU
while the cygwin processes would hog about %75 of the
CPU.  I'm not sure what csrss.exe is, except that I
cannot kill it (Access Denied, even as Administrator).
 I faintly recall seeing it somewhere in Services.

And one last thing:  I mentioned that when I kill
cygrunsrv.exe while it is "overloading", it will
immediately crash, but none of the other cygwin
processes display this behavior.  They all die
cleanly.
Well, it wasn't cygrunsrv.exe that was crashing
immediately after its kill.  Immediately after I kill
cygrunsrv.exe it was UmxCfg.exe that was crashing! 
This appears to be part of the Tiny Firewall (or tpf,
Tiny Personal Firewall for those of you that heard of
it back in the day) system.  I am going to investigate
this newly discovered fact and I'll be sure to let you
all know what I find out.



---
Steve B wrote:
> 
> When I am playing the freely available standalone
> version of Return to Castle Wolfenstein called Enemy
> Territory and I have various cygwin programs such as
> apache's httpd, tail.exe, cygrunsrv.exe, bash.exe,
or
> whatnot running, ET will lock up and when I bring up
> the task manager, seemingly random cygwin processes
> will be hogging the CPU until I kill it.  

If you happen to be using Process Explorer from
sysinternals.com then
that's the culprit.  If you have the "modules" display
enabled and
happen to click on or otherwise display info about a
cygwin process, the
result is a 100% hang until you kill the cygwin
process.

Brian





__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

--
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: parse errors using setup

[Marco Bruschi]

Any idea on how uniquely identify the setup.ini file effectively used by 
setup.exe?
Thanks

Christopher Faylor wrote:
On Thu, Sep 30, 2004 at 09:13:54PM +0200, Marco Bruschi wrote:
You mean in the setup.ini or the setup.bz2 ?
In the setup.ini:
7446: ###
7447: # KDE-3  internationalisation
7448: ###
7449: @ kde3-i18n-af
7450: category: KDE3-i18n
7451: requires: kdelibs-3
7452: version:  3.1.4
7453: install:  kde-i18n/kde3-i18n-af-3.1.4-0.tar.bz2 967158
7454: sdesc:"Afrikaans - KDE language support"

So you're using a custom setup.ini.  I don't see a string there but possibly
this isn't the file that you're trying to use.  It may be the bzip2 file.

The other file I suppose is a binary.

http://www.google.com/search?q=what+is+bz2+file
--
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/
--
Marco Bruschi
DESY Laboratory - Notkestrasse 85 - 22607 Hamburg (Germany)
Tel: +49 40 89981 982 Fax: +49 40 8994 1982 Handy: +49 172 1688839
e-mail: [EMAIL PROTECTED]
--
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: parse errors using setup

[Marco Bruschi]

Hi, maybe the problem is that in my downloading site
(kde-cygwin.sourceforge.net/install)
 they changed the
setup.ini today (30 september at 6:41).




On Thu, 30 Sep 2004, Christopher Faylor wrote:

> On Thu, Sep 30, 2004 at 09:13:54PM +0200, Marco Bruschi wrote:
> >You mean in the setup.ini or the setup.bz2 ?
> >
> >In the setup.ini:
> >
> >7446: ###
> >7447: # KDE-3  internationalisation
> >7448: ###
> >7449: @ kde3-i18n-af
> >7450: category: KDE3-i18n
> >7451: requires: kdelibs-3
> >7452: version:  3.1.4
> >7453: install:  kde-i18n/kde3-i18n-af-3.1.4-0.tar.bz2 967158
> >7454: sdesc:"Afrikaans - KDE language support"
>
> So you're using a custom setup.ini.  I don't see a string there but possibly
> this isn't the file that you're trying to use.  It may be the bzip2 file.
>
> >The other file I suppose is a binary.
>
> http://www.google.com/search?q=what+is+bz2+file
>
> --
> 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/
>
>

Dr. Marco Bruschi
DESY Laboratory - Notkestrasse 85 - 22607 Hamburg (Germany)
Tel: +49 40 89981 982 Fax: +49 40 8994 1982 Handy: +49 172 1688839


--
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: parse errors using setup

[Christopher Faylor]

On Thu, Sep 30, 2004 at 11:52:16PM +0200, Marco Bruschi wrote:
>Hi, maybe the problem is that in my downloading site
>(kde-cygwin.sourceforge.net/install) they changed the setup.ini today
>(30 september at 6:41).

Possibly.  Until you rule that out, it doesn't sound like this is a
setup.exe problem.  You should pursue this issue with the creators of
the setup.ini file.  They don't hang out here and we don't support that
file.

--
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: Excessive CPU load (cygrunsrv.exe, tail.exe, etc)

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Steve B
> Sent: 30 September 2004 22:00

> I do not believe that I am using Process Explorer.

> Well, it wasn't cygrunsrv.exe that was crashing
> immediately after its kill.  Immediately after I kill
> cygrunsrv.exe it was UmxCfg.exe that was crashing! 
> This appears to be part of the Tiny Firewall (or tpf,
> Tiny Personal Firewall for those of you that heard of
> it back in the day) system.  I am going to investigate
> this newly discovered fact and I'll be sure to let you
> all know what I find out.

  Betcha it also does something similar to procexp in that it places a hook or
otherwise injects into the code space of the cygwin app.


cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


--
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/

group name problem

[Jacob Kitzman]

Hi,

This cygwin stuff is pretty slick!  I'm hitting one snag, though, as I am trying
to setup sshd for remote access by limited users.

I've made a user "dnr" which is a member of the group "Limited SSHD users" (gid
1006).  After mkpasswd -l and mkgroup -l'ing, I've manually set the gid of user
dnr to 1006 in /etc/passwd.  Running as Administrator, id yields the expected
result:

[EMAIL PROTECTED] ~
$ id dnr
uid=1004(dnr) gid=1006(Limited SSHD users) groups=1006(Limited SSHD users)

However, when I ssh in to [EMAIL PROTECTED], cygwin doesn't seem to be able to find
a group with gid 1006.  (And I get the message upon login that your group is
currently "mkgroup")

[EMAIL PROTECTED] ~
$ id dnr
uid=1004(dnr) gid=1006(mkgroup) groups=1006(mkgroup)

Is there some local policy I need to set for the group "Limited SSHD users"? 
Any ideas for a workaround?

Thanks a bunch!

Jacob Kitzman


--
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: Excessive CPU load (cygrunsrv.exe, tail.exe, etc)

[Andrew DeFaria]

Steve B wrote:
I do not believe that I am using Process Explorer.
So then it's apparently not required that Process Explorer be running to 
trigger this process.

This CPU load overload can reliably be triggered by Enemy Territory. 
Guaranteed, every time I run Enemy Territory, a cygwin process will 
begin to hog the CPU starting with cygrunsrv.exe every time, and will 
continue until either a) I keep killing (through the Windows task 
manager) each cygwin process that overloads until no more cygwin 
process exists so I can return to my game, or b) I terminate Enemy 
Territory through the Windows task manager and kill the cygwin process 
that is overloading, then no other cygwin processes will hog the cpu, 
but I cannot play Enemy Territory. 
Well that's easy then. Stop playing games! :-)
Seriously though, maybe Enemy Territory is interrogating the process 
table in a similar manner as Process Explorer is.

I thought that since it could reliably be triggered this way, perhaps 
that might assist with any testing, if any.

Another thing I noticed, after reading Andrew DeFaria post, was that 
csrss.exe would be using 25% of the CPU while the cygwin processes 
would hog about %75 of the CPU. I'm not sure what csrss.exe is,
http://www.liutilities.com/products/wintaskspro/processlibrary/csrss/
   csrss.exe is the main executable for the Microsoft Client/Server
   Runtime Server Subsystem. This process manages most graphical
   commands in Windows. This program is important for the stable and
   secure running of your computer and should not be terminated.
except that I cannot kill it (Access Denied, even as Administrator).
That's what Process Explorer is for! It can kill things that the Task 
Manager won't let you. Unfortunately killing some things, like this, is 
very determental to your system (i.e. you reboot! IIRC).

--
Why isn't 11 pronounced "onety one"?
--
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: cp to flash drive very slow

[Gary R. Van Sickle]

> Well, yes.  The flash drive is a Sandisk Cruzer Mini which is 
> USB 2.0 with fallback to 1.1.  The computer is a Dell 
> Dimension 4600 which claims eight USB 2.0 connectiors.  
> Running Windows XP.
> 

Ok, like Hannu said, it's a USB 2.0 connection then, as long as you don't
have any USB 1.1 hubs in between the two.  I.e., if you're plugging the
drive directly into the computer, it's 2.0 all the way.

(EIGHT USB 2.0 connectors?  Wowzers!  This USB fad just might be catching
on! ;-))

> I don't think caching is the difference.  I was able to unzip 
> the .zip file right after xcopy had copied it.
> 

Well, that's exactly what caching is intended for.  The first xcopy copies
the file to a RAM buffer, and the RAM buffer gets sputtered out to the drive
in the background.  The unzip, in the reverse direction, would end up
reading from that same RAM buffer.

> Is there anything faster than cp for copying out of the 
> cygwin tools?  I'm working out some scripts to share files 
> between my work machine and my home machine using the flash 
> drive.  I could use xcopy but then I'd have to go through the 
> filename translation doohicky.

The latter is what I ended up having to do, but it wasn't for speed reasons
alone (cp was corrupting files over the network "back in the day").  I can't
think of any other alternatives offhand that would make any sense to do a
local copy like this.

What happens if you cp between two hard drives, or across the network?  Same
crazy slowness?

-- 
Gary R. Van Sickle


--
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: group name problem

[Pierre A. Humblet]

On Thu, Sep 30, 2004 at 10:16:46PM +, Jacob Kitzman wrote:
> Hi,
> 
> This cygwin stuff is pretty slick!  I'm hitting one snag, though, as I am trying
> to setup sshd for remote access by limited users.
> 
> I've made a user "dnr" which is a member of the group "Limited SSHD users" (gid
> 1006).  After mkpasswd -l and mkgroup -l'ing, I've manually set the gid of user
> dnr to 1006 in /etc/passwd.  Running as Administrator, id yields the expected
> result:
> 
> [EMAIL PROTECTED] ~
> $ id dnr
> uid=1004(dnr) gid=1006(Limited SSHD users) groups=1006(Limited SSHD users)
> 
> However, when I ssh in to [EMAIL PROTECTED], cygwin doesn't seem to be able to find
> a group with gid 1006.  (And I get the message upon login that your group is
> currently "mkgroup")
> 
> [EMAIL PROTECTED] ~
> $ id dnr
> uid=1004(dnr) gid=1006(mkgroup) groups=1006(mkgroup)
> 
> Is there some local policy I need to set for the group "Limited SSHD users"? 
> Any ideas for a workaround?

What are the permissions of /etc/group ?

Pierre

--
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: Cygwin df -l option has wrong sense?

[luke . kendall]

On 30 Sep, Igor Pechtchanski wrote:
>  This is a problem with how fileutils tests for drives being local.  And, 
>  it has been reported before (with a patch to fix it) -- see the thread 
>  starting at . 
>   Igor 

-# ifdef __CYGWIN__
-# define ME_REMOTE(fs_name, fs_type) (strchr (fs_name, ':') == 0)
-# else
 # define ME_REMOTE(fs_name, fs_type) (strchr (fs_name, ':') != 0)
-# endif

Under Unix, does the "host:/path" syntax apply to every network
filesystem type (Andrew, Coda, etc.), or just to NFS?

Certainly ":" is reserved in Windows for use only with drive letters.
Is fs_name (above) always what appears in the left column for df?

But what about mapped drives, then?  They often appear as U:/whatever.
E.g. below, only c: and d: are local drives.  Not to mention drive
letter mappings set up with the "subst" command.

$ df
Filesystem   1k-blocks  Used Available Use% Mounted on
C:\cygwin\usr\X11R6\lib\X11\fonts
  39070048  32015136   7054912  82% /usr/X11R6/lib/X11/fonts
C:\cygwin\bin 39070048  32015136   7054912  82% /usr/bin
C:\cygwin\lib 39070048  32015136   7054912  82% /usr/lib
C:\cygwin 39070048  32015136   7054912  82% /
d:\home   25165816   9080016  16085800  37% /home
c:39070048  32015136   7054912  82% /cygdrive/c
d:25165816   9080016  16085800  37% /cygdrive/d
l:27141816   2526576  24615240  10% /cygdrive/l
p:59046872  18911016  40135856  33% /cygdrive/p
u:17765376   5405696  12359680  31% /cygdrive/u
w:   191254528  86339584 104914944  46% /cygdrive/w
x: 4811432   2402196   2409236  50% /cygdrive/x
y:95379456  94943232436224 100% /cygdrive/y
z:13526696  11025336   2501360  82% /cygdrive/z

I would have thought it should really be looking at the filesystem type,
not the syntax of the mount point.  And I hereby confess that I don't
actually know the system call used to determine the filesystem type.

>  P.S. The mount type fix is still on my TODO list :-( 

Aren't TODO lists wonderful?  :-)

luke


--
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: cygwin locale broken? (was: Re: gnome 2.8.0 and external dependencies)

[Yang Guilong]

Hi, Gerrit

On Thu, 30 Sep 2004 17:36:28 +0200, Gerrit P. Haase
<[EMAIL PROTECTED]> wrote:
> Hi Yang,
> 
> I switched this thread over to the main list.
> 
> If there is no one fixing it then it will stay as it is, why is cygwin
> locale broken, what is broken, how to fix it?  I don't want to patch 50
Sorry, I don't know the detail info about this implementation either.

> packages because some locale implementation is broken, better fix it
> once and forever?
As for cygnome2,  just fixing gtk2 would resolve most problems,
as most packages uses gtk_set_locale().  Only a few packages
uses setlocale() directly.

> 
> And if it is working for X it should not be too hard to get it working
> in Cygwin too.
Yes, I think so. But we need somebody to do this.

best regards
Yang Guilong

--
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: seg-vios from gcc program at execv() on Windows XP

[Richard Troy]

On Thu, 30 Sep 2004, Igor Pechtchanski wrote:

>
> > Note that the code is _rock_solid_ on Linux/Unix/Mac OSX, and on all
> > earlier versions of Windows we've ever tried it on. We've _never_ seen it
> > seg-vio before.
>
> Please provide a complete (hopefully simple) testcase, along with the
> compilation flags, etc.  In particular, it'd be interesting to see how
> nargv is allocated, etc.  I suspect you're not placing a NULL at the end
> of the argument list, and Cygwin and Linux allocate nargv differently (so
> that on Linux, nargv just happens to have zeroed memory after it).

Almost; right issue, wrong problem. It turned out not that there wasn't a
terminating NULL but that there was an extra one, one past where it
should have been! This kind of problem is, apparently, _very_ easy to
overlook and I guess we just got away with it in the past. -shrug-

I want to thank you for taking the time to reply, Igor. I was awfully
stressed out about it. Even though it wasn't really a Cygwin problem, you
were supportive and I appreciagte it.

> > (BTW ping and dig utilities would be nice!)
>
> FWIW, XP (and 2k) come with "`cygpath -S`/ping.exe" and
> "`cygpath -S`/nslookup.exe".

??  ...Doesn't do _anything_ on my computer! -smile-

(Maybe I'd better to a hunt for them as they aren't in my path today.)

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
[EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/


--
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/

A good way to test if Cygwin isn't installed?

[luke . kendall]

I just wanted to run an idea past the list.

I want to write a shell script to test if Cygwin has been installed on
the machine running the shell script.

I do this by running a shell (from a network install of Cygwin if
necessary).

If Cygwin is installed on the local machine, then "cygpath -w /"
returns something like "c:\cygwin".  (Good for discovering what drive 
Cygwin was installed on, right?)  If Cygwin has not been installed, 
"cygpath -w /" returns a plain old backslash.

That's fine - maybe even great.  My question: is that a reliable way to
perform that test?  It seems good to me.

I'm working my way towards a shell script that installs or upgrades
Cygwin on a machine that may or may not have Cygwin installed, and do
all our local post-install stuff (which is a lot of stuff), and also
test that at least the major packages from the install work properly.

luke


--
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/

Request for a version/ revision/ release number for the whole Cygwin release/ distribution

[David Christensen]

[EMAIL PROTECTED]:

Per the Cygwin FAQ (http://cygwin.com/faq.html):

"If you are looking for the version number for the whole Cygwin
release, there is none. Each package in the Cygwin release has its own
version. The packages in Cygwin are continually improving, thanks to the
efforts of net volunteers who maintain the Cygwin binary ports. Each
package has its own version numbers and its own release process. "


I would like to request that this policy be reversed -- that there be a
version number for the entire Cygwin release.  Every O/S and application
I've used had a release number for the whole thing; Cygwin should as
well.


I would especially like to request that there be a "stable"
distribution.


Why?  Because:

1.  I use Cygwin for all sorts of stuff, including mission-critical
backup chores.  I was recently bitten by the cron-2.6.2 EOF issue, as
were others.  This represents real damages that people are suffering by
using Cygwin.  This is bad for the open-source movement.

2.  This is not the first time I've experienced this meta-problem.  It
indicates a lack of integration testing of Cygwin as a whole.  This is
also bad.

3.  I would like to be able to burn Cygwin X.Y.Z onto a CD or DVD for
myself and for others.  This is good.

4.  I develop software and would like to be able to tell people "it runs
on Cygwin X.Y.Z".  This is also good.


I hereby request that everybody who reads this message reply and express
their opinion so that the Cygwin release maintainers will know what the
community wants.


David


p.s.  I hereby volunteer my time to work on implementing my request.
However, be warned that I have very high standards and, especially as a
volunteer, I will not tolerate my time being wasted.


--
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/

Mirror site goodness

[luke . kendall]

I've made some improvements to my md5cygchk script, to solve the
problem of knowing when to trust our local mirrors.

Basically, we have a "stable" mirror - tried and tested, and known to
be complete and good.  And we have a "latest" mirror, which is updated
nightly via rsync from a single mirror site.

Nightly, after the rsync, we run "md5cygchk --report", and that writes a
report file at the top of the Cygwin mirror, and removes any old report
 files. So anyone can look at the mirror, and if they see the
"cygwin-archive-incomplete.txt", they know it'd be unwise to run setup
pointing there.  OTOH, if the file cygwin-archive-okay.txt, they know
the mirror is complete.

(cygwin-archive-incomplete.txt also lists the packages with problems, as
reported by md5.)

So now our local scripts (some of them dumb old .bat scripts), can tell
at a glance whether or not to trust the mirror.

It occurred to me that if the mirror sites chose to run the script,
with the --report option so that it wrote/deleted the appropriate
report file(s), then everyone around the world would be able to look at
a Cygwin mirror site and know whether or not it was complete.

I'm happy to pass on the updated script (even though I still haven't
gotten around to incorporating Fergus's 1st two good suggestions yet:

>  There are 3 parts to what the script does: 
>   
>  1. checks the timestamp on your local setup.ini with the one currently on 
>  the mirror; 
>  2. checks that the files you've got match the ones you should have (this 
>  just checks the names); 
>  3. checks the md5sum's. 

But, how much contact do you have with the people running the mirrors?
If you made it available to them, would they use it?

Anyway, I'm sharing the updated script (appended below), in case it's of
use to others.  Perhaps it should really be called cygmd5chk

BTW, the reason for creating two files is because I believe cmd.exe is
so dumb it has no way to distinguish between an empty file and one
that's not empty.

luke
- md5cygchk --
#!/bin/sh
#
# Check all the md5 signatures for a Cygwin mirror.
#
# Author: Luke Kendall
#
CYG_BAD=cygwin-archive-incomplete.txt
CYG_GOOD=cygwin-archive-okay.txt
ECHO=echo
MD5ARG=
MIRROR=/u/mirror/cygwin/release
MYNAME=`basename "$0"`
RECORD=false
TMP=/tmp/md5cyg$$
USAGE="Usage: $MYNAME [-q] [--record] cygwin-mirror-directory
Where:
-q  means quiet.
--recordmeans record a success or failure indicator in the
the directory above the mirror directory, by making
$CYG_GOOD & $CYG_BAD files
appear or disappear (so even DOS batch scripts can test
the archive's goodness).
You have to have write permission for this to work.
cygwin-mirror-directory
this should be the directory where you find setup.bz2,
setup.exe, and setup.ini.
Success/failure files are created in the directory
above this, if the --record option is used.

E.g.:

$MYNAME --record -q /u/mirror/cygwin/release

NOTE: running md5 over 2GB of files is best done on the host
machine, to avoid hammering our network.
(Use 'df -k \$MIRROR' to discover what machine
hosts \$MIRROR, that you should slogin to,
to run this $MYNAME.)"

trap 'rm -f $TMP; exit 1'

usage()
{
# sed, so that if they specified a mirror, it's used in the usage message.
echo "$USAGE" | sed "s|\$MIRROR|$MIRROR|" >&2
exit 1
}

while [ $# -ge 1 ]
do
case $1 in
-q)
MD5ARG="--status"
ECHO=":"
;;
--record)
RECORD=true
;;
-*)
usage
;;
*)
MIRROR="$1"
shift
break
;;
esac
shift
done
if [ $# != 0 ]
then
usage
fi
cd $MIRROR || exit 1
if [ ! -s ../setup.bz2 ]
then
echo "$MYNAME: Not a cygwin download (no file setup.bz2 in $MIRROR parent)" >&2
exit 1
fi
WHERE=`pwd`

find . -type d -print | \
while read dir
do
(
cd "$dir"
if [ -s md5.sum ]
then
$ECHO "$dir:"
if md5sum $MD5ARG --check md5.sum
then
:
else
{
echo
echo "In $WHERE/$dir:"
md5sum --check md5.sum 2>&1 | grep -v OK
} >> $TMP
fi
elif [ `ls -l | grep "^-" | wc -l` = 0 ]
then
:
else
echo "Worrying: $dir has no md5.sum file" >&2
echo "Worrying: $dir has no md5.sum file" >> $TMP
fi
cd $WHERE # Really, the shell popping via (...) does this.
)
done

if $RECORD
then
if [ ! -w $WHERE/.. ]
then
echo "$MYNAME: you don't have write permission on $WHERE/.." >&2
RECORD=false
else
# Remove them both, temporarily, in case th

Re: Cygserver 100% CPU (was: References to both cygwin1.dll and msvcrt.dl

[Patrick Samson]

--- Corinna Vinschen wrote:
> On Sep 30 00:12, Patrick Samson wrote:
> > I built the DLL another way, and now have:
> > $ cygcheck ./dp40.dll
> > .\dp40.dll
> >   D:\cygwin\bin\cygwin1.dll <
> > C:\WINNT\System32\ADVAPI32.DLL
> >   C:\WINNT\System32\ntdll.dll
> >   C:\WINNT\System32\KERNEL32.dll
> >   C:\WINNT\System32\USER32.dll
> > C:\WINNT\System32\GDI32.dll
> >   C:\WINNT\System32\RPCRT4.dll
> >   D:\cygwin\bin\tcl84.dll
> >   C:\WINNT\System32\WS2_32.DLL
> > C:\WINNT\System32\MSVCRT.dll <---
> > C:\WINNT\System32\WS2HELP.dll
> > Seems better, as msvcrt.dll is only there because
> > of ws2_32 (winsock2).
> 
> Which shouldn't be referenced at all.  dp40.dll
> apparently references
> ws2_32.dll directly instead of using the Cygwin
> socket calls.
> 
There is the link command generated by autotools:
gcc -mwin32 -g -O2  -o dp40.dll -shared
-Wl,--export-all-symbols -Wl,-s dpChan.o dpCmds.o
dpRPC.o dpPlugF.o dpFilte
rs.o dpIdentity.o dpPackOff.o dpInit.o dpSerial.o
dpSock.o dpWinInit.o dpWinSerial.o dpWinSock.o
dpWinTcp.o dpWinUD
P.o dpWinIPM.o -ltcl84 -lws2_32

If I omit -lws2_32, I receive "undefined reference"
for winsock functions (one of the source has
#include  for IP multicast).
What should I do?





__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

--
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: [ITP] libgpg-error-1.0-2

[Igor Pechtchanski]

On Thu, 30 Sep 2004, Gerrit P. Haase wrote:

> Hi Lapo,
>
> > Is a review really needed if the package is based on Gerrit's work?
> > It's HIM that corrected my last packages actually ;-)
>
> Nobody is perfect!
>
> Nobody

Hi, Nobody,

Did you switch to the main list as a sign of your [im]perfection? ;-)
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/