[ANNOUNCEMENT] Updated: monotone-0.27-1

[Lapo Luchini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Version 0.27-1 of monotone has been uploaded.

monotone is a free distributed version control system. it provides a
simple, single-file transactional version store, with fully disconnected
operation and an efficient peer-to-peer synchronization protocol. it
understands history-sensitive merging, lightweight branches, integrated
code review and 3rd party testing. it uses cryptographic version naming
and client-side RSA certificates. it has good internationalization
support, has no external dependencies, runs on linux, solaris, OSX,
windows, and other unixes, and is licensed under the GNU GPL.

Major new features:
* Monotone can now push/pull/synchronize over arbitrary
  bidirectional streams, not just raw TCP.
* File-to-file synchronization is enabled out of the box,
  e.g.:
$ mtn -d db1.mtn sync file:/path/to/db2.mtn
* SSH synchronization is enabled out of the box, e.g.:
$ mtn -d local.mtn sync ssh://[EMAIL PROTECTED]/home/njs/remote.mtn
  Note that this requires mtn be installed on the remote
  computer, and locks the remote database while running; it
  is not ideal for groups accessing a shared database.
* New protocols can be defined with Lua hooks -- for
  example, someone could in principle make "$ mtn sync
  xmpp://[EMAIL PROTECTED]" do something interesting.
* See section "Other Transports" under "Advanced Uses" in the
  for more details.

You can fine more informations here:
http://venge.net/monotone/NEWS




If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from 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.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJEn3mrAAoJELBiMTth2oCDyroP/1D1cuYV1iEUE3kZNScHSNfw
28wi0sTVrWdu5rpszvWx2zSyOhzrqbvRuJATkTi7c1szvAAClpuKE22tM2jFQvs/
xP6727CE6Yhj6qAX2BSbe4XDBX1bTvOny/ye/BdJVfqx9groUQeIJGuNhRjzwSb4
W9DcrKWIJq5FD7KTnmAaqOlf68hOL4wWXkNghc3EO035v3gD4y+9dOOSvvKA2cIF
mUZs8j+1aQ2IX8qtwD4PVssjHHXSuMYNfJGyYkEKmR8vM7hSnCODAEWXrlRmEI3L
gsKRuPhC44WzJ8kvMogsMasewE29k4yoODoa+si4skvyAIJyboDw6EUzUi/I+V0r
zcbzPP7ieeyaiM7Aud+pwxFDSGHTRBwBu3Rrp6XIT7PcKQNiWubG2F4JsLwACmzu
Be+5UZGchEsLkb6316tF30pYu0fIxtrMLCqEmi1UZHkSIRHJ67Y+5qgXjJINq487
lpNZ66swKw0MBw/lt5kTuTROFu6uK0wN4lMIvQENs4zsen1R5CRsOWy2DOYDHTUm
kznvyrjBMg3sDeYy5pyzLnjTrwG4nxtkDGMBwbDK7tCrbYxz4KfoKVH/0nS5KNkH
WbadnQdTOO0BMfaElMdxK2MkUV+lLQzz9PJlf2jTVZUoOOoVBPcx3xsrG/8R21zp
gekwVLBsJRszC5lonM/O
=usoj
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

problem running a UDP client and server

[Varun Sharma]

Hi,
 I have been trying to run the abing code
(http://www-iepm.slac.stanford.edu/tools/abing/). It basically set up a
UDP client and server and then there are excahnge of UDP packets. I have
been running into troubles since when I have been trying to install it.
 Firstly the make file had the -lnsl option which it cannot find in
cygwin, so I removed it and compiled the code and everything worked fine
with the warning that it cannot find the -pthread option.
 Then to run the reflector in abing, one has to execute the following
commmand.
./abw_rfl -c &
./abing -c
./abw_rfl &

But in my case, I get an error when I run ./abing -c saying that revcfrom
failed with invalid argument. The code works fine with no error at all in
a normal linux distro. I am unable to find out the difference. Even UDP
clients and server codes which can be easily downloaded from the net work
fine.
 I would be really obliged if someone can tell me the problem or some
ekind of an experience he or she has on installing and using abing on
cygwin.

Thanks a lot in advance.
Varun Sharma


--
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: autossh broken with current openssh/cygwin

[Corinna Vinschen]

On Jun 23 20:19, Brian Dessent wrote:
> 
> I'm not sure if it is due to changes in openssh, or changes in Cygwin,
> but the current autossh package fails to work.  Instead of detecting
> that the connection is alive, it seems to continuously timeout and
> recycle the ssh process.  Here is a representative testcase:
> 
> $ AUTOSSH_FIRST_POLL=5 AUTOSSH_POLL=5 AUTOSSH_DEBUG=yes autossh -M 3
> -N dessent.net
> autossh: PID 3204: short poll time: adjusting net timeouts to 2500
> autossh: PID 3204: checking for grace period, tries = 0
> autossh: PID 3204: starting ssh (count 1)
> autossh: PID 3204: ssh child pid is 4160
> autossh: PID 4160: execing /usr/bin/ssh
> autossh: PID 3204: check on child 4160
> autossh: PID 3204: set alarm for 5 secs
> autossh: PID 3204: timeout on io poll, looping to accept again

Confirmed.  This has been introduced by trying to get the WinSock event
driven accept thread-safe.  This apparently doesn't work as expected.
To get that really right, a lot more has to be done.  Since that's
nothing I'd like to rip apart before 1.5.20, I reverted all event
handling for accept and connect and returned to using select again, as
it was implemented until 1.5.18.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: problem running a UDP client and server

[Corinna Vinschen]

On Jun 26 17:41, Varun Sharma wrote:
> 
> Hi,
>  I have been trying to run the abing code
> (http://www-iepm.slac.stanford.edu/tools/abing/). It basically set up a
> UDP client and server and then there are excahnge of UDP packets. I have
> been running into troubles since when I have been trying to install it.
>  Firstly the make file had the -lnsl option which it cannot find in
> cygwin, so I removed it and compiled the code and everything worked fine
> with the warning that it cannot find the -pthread option.
>  Then to run the reflector in abing, one has to execute the following
> commmand.
> ./abw_rfl -c &
> ./abing -c
> ./abw_rfl &
> 
> But in my case, I get an error when I run ./abing -c saying that revcfrom
> failed with invalid argument. The code works fine with no error at all in
> a normal linux distro. I am unable to find out the difference. Even UDP
> clients and server codes which can be easily downloaded from the net work
> fine.
>  I would be really obliged if someone can tell me the problem or some
> ekind of an experience he or she has on installing and using abing on
> cygwin.

This would require to get some more details from you besides "recvfrom
returns EINVAL".  http://cygwin.com/problems.html

Anyway, I have a wild guess.  Windows' recvfrom only understands MSG_OOB
and MSG_PEEK.  Any other flag value is unsupported and should result in
recvfrom returning EINVAL.  Maybe that's your problem.  Solution:  Don't
use flags except MSG_OOB and MSG_PEEK.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: strtod (and atof) on hex numbers

[Corinna Vinschen]

On Jun 22 14:04, Jeff Johnston wrote:
> I have integrated a newer version of strtod from David M. Gay's gdtoa 
> FreeBSD code.  This code has the C99 support in question including nan 
> and inf support.  I have tested on x86-linux and mn10300.
> 
> As usual, please run it through its paces on Cygwin and let me know if 
> there are any problems.
> 
> -- Jeff J.

Looks good to me.  Thanks for your quick solution.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: problem running a UDP client and server

[Varun Sharma]

Hi,
 Thanks a lot for your help, but my flag option is a default 0. This is
the same option that I am using with a normal UDP client and normal UDP
server which are working fine. Should I change this. I am attaching the
piece of code of the client:


in_addr_t gethostaddr(name)
 char *name;
{
   in_addr_t addr;
   register struct  hostent *hp;

   if ((addr = (in_addr_t)inet_addr (name)) != -1)
  return (addr);

   hp = (struct hostent*) gethostbyname(name);
   if (hp != 0)
  return (*(in_addr_t *)hp->h_addr);
   else
  return (0);
}
//

int Do_Client_Work(char * serverName, unsigned short int serverPort, int
rpt_cnt)
{
int i,pid,pc,sock,rcnt;
struct sockaddr_in dst; /* Echo server address */
struct sockaddr_in src; /* Source address of echo */
struct in_addr dst_addr;
unsigned short echoServPort; /* Echo server port */
int fromSize;   /* In-out of address size for recvfrom() */
char *servIP;/* IP address of server */
int incnt,outcnt,xcnt;   /* Length of received response */
struct hostent *hp;

//
   struct timeval *tp;

   struct ABWreport *ptrep;

   struct ABWrec *srec,*rrec;
   double sleeptime = DELAYTIME,ms1,djn,ms_iter;
   int  nc,nt,np,ppseq,rnum,endcnt=0,okfl=0;
   int  npkt = NPKT;
   int  pktsend;
   int  write_error = NO;
   int  dcnt = 0;
   double tpole[100];
   char *ptext, rdata[MAXMESG],sdata[MAXMESG];
//
   double sumt,sumf,sumr,avt_abw,avr_rtt,avf_abw,
si_t_abw, si_f_abw,si_rtt,di_t_abw, di_f_abw,di_rtt,
arr_t_abw[NMODMAX],arr_f_abw[NMODMAX],arr_rtt[NMODMAX];
//
   int timeout = 50;

tp = (struct timeval *)(malloc (sizeof (struct timeval)));
sleeptime=50;
srec = (struct ABWrec *) sdata;
rrec = (struct ABWrec *) rdata;
bzero((char *) srec, sizeof (struct ABWrec));
ptext=sdata+124;
strcpy(ptext,klic);
srec->rnum = htonl ((u_long) 2);

pktsend=1;
npackets=ntrains*npkt;
xcnt=1;

printf("The server name is %s and the port is %d\n",serverName, serverPort);
/* DNS resolution */
dst_addr.s_addr = gethostaddr(serverName);
printf("The address is %d\n",dst_addr.s_addr);
/*
char *dummy = (char *) malloc(9);
strcpy(dummy,"127.0.0.1");
hp = gethostbyname(dummy);
if (hp == 0) perror("Unknown host");
*/
if (dst_addr.s_addr ==0) {
fprintf (stderr,"Destination: %s: uknown host\n",serverName);
exit (1);
}

/* Create a datagram/UDP socket */
if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
DieWithError("socket() failed");

//fcntl(sock, F_SETFL, O_NONBLOCK);

//setsockopt(sock,SOL_SOCKET,SO_RCVTIMEO,(char *) 
&timeout,sizeof(timeout));
/* Construct the server address structure */
memset(&dst, 0, sizeof(dst));/* Zero out structure */
//dst.sin_addr.s_addr = inet_addr(servIP);  /* Server IP address */
//dst.sin_addr.s_addr = gethostaddr(servIP);  /* Server name */
dst.sin_family = AF_INET; /* Internet addr family */
dst.sin_addr = dst_addr;  /* Server addr */
//  bcopy((char *)hp->h_addr, (char *)&dst.sin_addr,hp->h_length);
dst.sin_port   = htons(serverPort); /* Server port */

if ((pid=fork()) == 0) {
/*  child = sender /
//printf("I am child and I will do all sendings: %d,%d to %s
\n",ntrains,npkt,serverName);

if (connect (sock, (struct sockaddr *) &dst, sizeof (dst)) < 0) {
  perror ("fabws: connect");
exit(-1);
}

printf("The values of socket is sock %d\n",sock);

signal(SIGALRM,time_out);


for (i=0;ippseq = htonl ((u_long) nt);
for (nc = 1; nc <= npkt; nc++) {
sprintf(ptext,"Tu je NC,NT=%d,%d a msg=%s",nc,nt,klic);   /*
Second arg: string to echo */
srec->num = htonl ((u_long) pktsend);
gettimeofday (tp, (struct timezone *) 0);
srec->snd.tv_sec = htonl ((u_long) tp->tv_sec);
srec->snd.tv_usec = htonl ((u_long) tp->tv_usec);

/* Send the string to the server */
outcnt = write (sock, sdata, pktsize);
if (outcnt < 0) {
}
pktsend++;
}
dcnt = 0;
tpole[nt]=msdelay(sleeptime);
   }
// new rpt_cycle need clean np
pktsend=1;
// set up delay in sec !
ms_iter=(iter_t - 1) *880.0+ 30;
ms1=msdelay(ms_iter);

} /*rpt_cnt_end*/
// start timeout now
raise(SIGALRM);
exit (-1);
} else {
/ parent = receiver ***/
//printf("I am parent and I will do receiving\n");
/* Recv a response */
fromSize = (unsigned int)sizeof(struct sockaddr_in);
rcnt=0;
  while (1) {
//printf("The source is fromsize234 is %u and pktsize i

Re: problem running a UDP client and server

[Varun Sharma]

 Hi,
 I would write some points here for that long code which make sense to me
and may be the problem.

1. I tried both MSG_PEEK and MSG_OOB and still I am getting an EINVAL.

2. The process does a fork and the child does the connect to the
destination, sendto and the parent does the recvfrom.

3. The 4th element of the struct sockaddr_in is not very clear in cygwin
and it is the case with all instances of sockaddr_in, but they do not seem
to create a problem as they are running fine in other programs using
datagram UDP sockets.

Also the uninitialized values of the elements of src sockaddr_in is
different in linux.

I think these might be the one that are creating problems.

Any advice would be helpful.

Thanks a lot,
Varun Sharma


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

query bzImage

[hulge hulge]

hi
i want to know
when we run command " make bzImage" ,
where do the cygwin store bzImage
actually i am trying to build linux kernel in cygwin,
i can run make menuconfig, after running command make dep
everything was fine but when i run "make bzImage" i get error of repeatative 
decleration

so plz help
regards
hulge



--
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: Issue with shmget

[Rahul Gulati]

Thanks I was able to get over the issue your guess was
right CYGWIN=server was not set.

Rahul

--- Igor Peshansky <[EMAIL PROTECTED]> wrote:

>  reformatted.
> 
> On Fri, 23 Jun 2006, Rahul Gulati wrote:
> 
> > --- Igor Peshansky <[EMAIL PROTECTED]> wrote:
> 
> . 
> Thanks.
> 
> > > On Fri, 23 Jun 2006, Rahul Gulati wrote:
> > >
> > > > Hi,
> > > >
> > > > I am new to cygwin and trying to port existng
> Linux
> > > > based implementation of shared memory on
> cygwin.
> > > >
> > > > I am having issues with shmget call. I tried
> to debug
> > > > and found out that everytime I try to call
> shmget
> > > > function I get an error and the main thread
> exits:
> > > > Program exited with code 06000
> > > >
> > > > cygserver is also running with default options
> which
> > > > includes :
> > > > XSI IPC Shared Memory support.
> > >
> > > Not nearly enough information, the problem
> reporting guidelines at
> > >  were not
> followed (e.g., no attached
> > > cygcheck output), and your code snippet isn't
> self-contained, doesn't
> > > compile (even discounting Yahoo's line wrapping
> -- next time, please
> > > attach the code), and doesn't reproduce the bug.
>  In the absense of
> > > the facts, I can only offer a WAG: does $CYGWIN
> contain "server" when
> > > you run your program?
> > >   Igor
> >
> > Will the system call work if i stop the daemon and
> > just have cygserver running with default
> options???
> 
> You have not provided enough information for anyone
> to help you.  Please
> read and follow the instructions at
> > Problem reports:  
> http://cygwin.com/problems.html
> 
> Moreover, if I understand your question correctly,
> it does not follow at
> all from the guess I offered and the question I
> asked above: when you run
> your code (the program that you provided a snippet
> of, not the cygserver
> daemon), does the environment variable CYGWIN
> contain the word "server" in
> it, as mentioned in
> /usr/share/doc/Cygwin/cygserver.README?  FYI,
> following the instructions above would have provided
> us with the output of
> a tool (cygcheck) that would have answered my
> question.
>   Igor
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED] |
> [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  Igor Peshansky, Ph.D.
> (name changed!)
>  |,4-  ) )-,_. ,\ (  `'-' old name: Igor
> Pechtchanski
> '---''(_/--'  `-'\_) fL   a.k.a
> JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> "Las! je suis sot... -Mais non, tu ne l'es pas,
> puisque tu t'en rends compte."
> "But no -- you are no fool; you call yourself a
> fool, there's proof enough in
> that!" -- Rostand, "Cyrano de Bergerac"
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.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: Fortran Compiler Error CMBFAST

[Williams, Gerald S \(Jerry\)]

Brad Krane wrote:
> I'm trying to compile the scientific package CMBFAST-4.5.1 in the
> cygwin environment using g77. I get the following error...
> 
> f77 -O2   -c -o jlgen.o jlgen.F
> jlgen.F: In program `jlgen':
> jlgen.F:14:
> include 'cmbfast.inc'
> ^
> Unable to open INCLUDE file `cmbfast.inc' at (^)

Tim Prince wrote:
> Normally, you would specify the path to search for include files with
> -I, if it is not in the current working directory.

I looked at the library, and the referenced include file
*is* in the same directory. The library even includes a
configure script, so this isn't simple pilot error--it
looks like there is a bug in the compiler.

For now, you can work around the problem by adding -I. to
the command lines, or more likely to the end of FFLAGS in
the Makefile (after running ./configure).

I don't use FORTRAN enough to say whether the behavior we
are seeing is correct, though from the evidence I've seen
I'd say it isn't.

gsw

--
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: email-2.5.0-1

[Ross Smith II]

Version 2.5.0-1 of email has been uploaded.

Email is a simple command-line program to send emails. It can be configured
to use either your sendmail installation or directly via SMTP.
It supports binary attachments, and a simple text based address book, with 
groups.
Also, if GnuPG is installed, it can digitally sign and encrypt outgoing emails.

Changelog:

- Separated e-mail name and address and only format them in the
  headers.  Only use address surrounded by <> as per RFC 822 for
  the MAIL FROM: and RCPT TO: SMTP commands.

- Added Dstring library which is a string library to growing
  strings.

- Using Dstring's for reading in config file and address book.
  This fixes the MINBUF limitations that were happening with
  very long Groups in the address book.

- Added ability to specify new headers on the command line.

- Handle \r in address book so that Cygwin users don't have to
  put a comment at the end of their lines.

- the --attach and --header option can be specified multiple
  times and also have multiple entries with comma delimeters.


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from 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.


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

Suggestion: split vim support files into separate package

[Marshall Abrams]

I want to suggest splitting vim support files (installed in
/usr/share/vim/vim) into a separate package from the
binaries.  There are two versions of vim binaries in Cygwin, the no-X
version (vim), and the version with X GUI compiled in (gvim), but their
(major) versions are not always in sync (as recent posts on this list
illustrated).  The problem is that if you install the newer version in
the most obvious way, the support files for the older version get
deleted, and all of a sudden the older version which you're still using
doesn't function properly.  (For example, at the moment, installing the
latest no-X vim in Cygwin, at version 7.0, deletes the support files for
the latest version of gvim in Cygwin, at version 6.4.)

Of course there are various ways to work around this problem without too
much trouble, but why not just make the support files a separate package
with dependencies linking both versions of the binaries to it.  That
way, I assume, the older support files wouldn't go away if something
still depends on them.

Thanks.

Cygwin is great!


Marshall



--
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: dtoa.c fails to compile for sh-elf -m2e (Was: Re: strtod (and atof) on hex numbers)

[Jeff Johnston]

Joern Rennecke wrote:

You change to mprec.h broke dtoa.c compilation for sh2e:



Please try the attached patch and let me know if it sovles the problem.

-- Jeff J.
Index: libc/stdlib/mprec.h
===
RCS file: /cvs/src/src/newlib/libc/stdlib/mprec.h,v
retrieving revision 1.4
diff -u -p -r1.4 mprec.h
--- libc/stdlib/mprec.h	22 Jun 2006 17:59:52 -	1.4
+++ libc/stdlib/mprec.h	26 Jun 2006 15:39:17 -
@@ -141,6 +141,12 @@ typedef union { double d; __ULong L[2]; 
 #if 0
 #define IEEE_Arith  /* it is, but the code doesn't handle IEEE singles yet */
 #endif
+/* Following is needed due to IEEE_Arith not being set on above.  */
+#if defined(__v800)
+#define n_bigtens 2
+#else
+#define n_bigtens 5
+#endif
 #define Emin(-126)
 #define Exp_1   ((__uint32_t)0x3f80L)
 #define Exp_11  ((__uint32_t)0x3f80L)

--
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: Suggestion: split vim support files into separate package

[Igor Peshansky]

On Mon, 26 Jun 2006, Marshall Abrams wrote:

> I want to suggest splitting vim support files (installed in
> /usr/share/vim/vim) into a separate package from the
> binaries.  There are two versions of vim binaries in Cygwin, the no-X
> version (vim), and the version with X GUI compiled in (gvim), but their
> (major) versions are not always in sync (as recent posts on this list
> illustrated).  The problem is that if you install the newer version in
> the most obvious way, the support files for the older version get
> deleted, and all of a sudden the older version which you're still using
> doesn't function properly.  (For example, at the moment, installing the
> latest no-X vim in Cygwin, at version 7.0, deletes the support files for
> the latest version of gvim in Cygwin, at version 6.4.)
>
> Of course there are various ways to work around this problem without too
> much trouble, but why not just make the support files a separate package
> with dependencies linking both versions of the binaries to it.  That
> way, I assume, the older support files wouldn't go away if something
> still depends on them.

Sorry, but that's not how it works.  Cygwin package dependences are not
implicitly versioned, so if you release a newer version of the support
files package, it will overwrite the old one, just as it does in the
current setup.  Even now, gvim requires vim, and that doesn't help, as you
can see.

The vim and gvim packages are really intended to be released in lock-step.
The gvim maintainer was already asked to prepare a 7.0 version -- we'll
just have to wait until he does.

An alternative is to introduce explicitly versioned dependencies (i.e.,
where the version becomes part of the package name).  This is already done
for shared library packages -- whenever a new version gets released, a
compatibility package with the old version gets split off.  The problem is
that this is quite a bit of effort, ,
and the vim/gvim maintainers are (appropriately) not willing to invest
that much effort.  While it's necessary for shared libraries (since you
never know who will be needing the old DLL version), I don't think this
would be too useful for two sister packages like vim and gvim.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Suggestion: split vim support files into separate package

[Christopher Faylor]

On Mon, Jun 26, 2006 at 11:47:08AM -0400, Igor Peshansky wrote:
>An alternative is to introduce explicitly versioned dependencies (i.e.,
>where the version becomes part of the package name).  This is already done
>for shared library packages -- whenever a new version gets released, a
>compatibility package with the old version gets split off.  The problem is
>that this is quite a bit of effort, ,
>and the vim/gvim maintainers are (appropriately) not willing to invest
>that much effort.  While it's necessary for shared libraries (since you
>never know who will be needing the old DLL version), I don't think this
>would be too useful for two sister packages like vim and gvim.

OTOH, if we had *rpm* for a package handler, this kind of thing would be
detected and there would be warnings and everything!

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: UTF-8 Cygwin

[Linda Walsh]

Christopher Faylor wrote:

On Tue, Jun 06, 2006 at 02:24:29PM -0700, Linda Walsh wrote:
  

SUZUKI Hisao wrote:


I made a patch to cygwin1.dll to support UTF-8.
It allows you to use all of characters and file (or path) names
allowed in Windows, while keeping binary-compatibility with the
current Cygwin.  It is fairly perfect except for lack of locale
support etc.  So it may remind you of the good old BeOS.  See:
http://www.okisoft.co.jp/esc/utf8-cygwin/
  

(and for bottom readers...)
When will we see this in the main-stream cygwin?
Soon? :-)


You can answer your own question.
Look here: http://cygwin.com/ml/cygwin-patches/ and see if you notice
any patch submissions.
  


   I am not certain, but I'm interpreting that as a "no".

   For people who "know" and are experts in a topic, the answers are 
self-evident.

For those who are not, we may not, not only not know where to look but may
not even know the right question.

   Also, I don't expect my interpretation of some information or 
reality to be
the same as someone else's interpretation.  Often I find my 
interpretation is

different from other's.

-l


--
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: UTF-8 Cygwin

[Igor Peshansky]

On Mon, 26 Jun 2006, Linda Walsh wrote:

> Christopher Faylor wrote:
> > On Tue, Jun 06, 2006 at 02:24:29PM -0700, Linda Walsh wrote:
> >
> > > SUZUKI Hisao wrote:
> > >
> > > > I made a patch to cygwin1.dll to support UTF-8.
> > > > It allows you to use all of characters and file (or path) names
> > > > allowed in Windows, while keeping binary-compatibility with the
> > > > current Cygwin.  It is fairly perfect except for lack of locale
> > > > support etc.  So it may remind you of the good old BeOS.  See:
> > > > http://www.okisoft.co.jp/esc/utf8-cygwin/
> > > >
> > > (and for bottom readers...)
> > > When will we see this in the main-stream cygwin?
> > > Soon? :-)
> > >
> > You can answer your own question.
> > Look here: http://cygwin.com/ml/cygwin-patches/ and see if you notice
> > any patch submissions.
> >
> 
>I am not certain, but I'm interpreting that as a "no".
>
>For people who "know" and are experts in a topic, the answers are
> self-evident. For those who are not, we may not, not only not know where
> to look but may not even know the right question.
>
>Also, I don't expect my interpretation of some information or reality
> to be the same as someone else's interpretation.  Often I find my
> interpretation is different from other's.

The answer is fairly simple, and has been reiterated on this list many
times.  .  Links to external projects
that are forks off the main Cygwin source aren't.  For something to get
into Cygwin, someone needs to submit a patch (or, preferably, a series of
patches) against the source in CVS.  The patches will be discussed, and,
hopefully, eventually accepted into the main source.  Once that happens,
the next release will contain the changes.  Until then, the answer, as you
correctly surmised, is "no".
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Latest Cygwin Release 5 month old...

[Linda Walsh]

Really?  a 6 y/o, 800MHz Celeron w/512M, & 4MB video taken out of main
memory?  You have alot more patience than me.

-l

Jim Drash wrote:

I run VMWare on on just such a configuration.

On 6/22/06, Linda Walsh <[EMAIL PROTECTED]> wrote:

Perhaps, but you are assuming one's primary Windows machine is capable
of being "virtually subdivided".  I run windows on a laptop  (external
keyb, mouse, screen).  While it was a good laptop new, it's a bit long
in tooth.




--
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: snapshots: first resort, or last resort?

[Linda Walsh]

mwoehlke wrote:

Science Guy wrote:
In http://cygwin.com/ml/cygwin/2006-06/msg00434.html, Brian said 
"using the
latest snapshot should always be the first thing you try when 
encountering a

problem before reporting it to the list."

However, the instructions for installing snapshots at
http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots say:  
"First,
are you sure you want to do this? Snapshots are risky. They have not 
been
tested. Use them ONLY if there is a feature or bugfix that you need 
to try,
and you are willing to deal with any problems, or at the request of a 
Cygwin

developer."

For a non-expert, such as me, this dichotomy of views is perplexing.  
This
is made all the more perplexing because there does not seem to be (I 
could
not find) a user-readable list of bugs that each snapshot fixes 
vis-a-vis
the latest release.  So how would a user know whether the "risky" 
step of

installing a snapshot will have any chance of fixing a particular bug?

-- Joe
--- 
   Excellent point Joe (aka Science Guy!). 

 If you have a problem, you should try a snapshot. However, you should 
keep in mind that doing so means trying a potentially unstable setup. 
Therefore, when trying a snapshot, you should do as little as possible 
while using that snapshot. If it doesn't fix your problem, it is 
safest to go back to a stable version. If it does, *then* you have to 
decide if you want to use a setup that might be unstable (more so than 
usual), or if you can wait for an official release.



   Which begs the question -- why aren't releases done more often?  Five
months between releases seems intensely long compared to, say, the linux
kernel, which averaged 1 month releases when 2.4 was active, to 2 month
releases, now, with 2.6 and the managed "bug fix" releases that happen in
between  regular releases.

   It doesn't do _users_ alot of good to check a snapshot.  It does,
indirectly, in that it may increase code quality, *but*, if they don't want
to run with an unstable snapshot, they won't see their bugfix for [several?]
months.

   Trying a snapshot fine for testing a particular bugfix, but snapshots
are no substitute for updating the released product on a regular basis.  If
the cost to do a release is low and number of changes / bugfixes are high,
it would be good to get the product to a "releasable" point every few weeks
to a month so users will see their efforts at find/isolating/reporting/
trying snapshots, rewarded.  Is there some obstacle to more regular
releases?

   If it were me, (and I know it's not, thank-you), I'd feel better about
getting updated releases into user's hands as soon as reasonable.  If I fix
something, or change something, I wouldn't want to wait 6 months to release
it, (ideally,) so if a change I make introduces an untested and unthought-of
incompatibility I'm more likely to remember the changes that went into the
code.  Five-Six months later, on active code and the changes might as well
have been made by someone else and I'm more likely to have to go in "cold"
to figure out which change broke things for some isolated user test case.
If there have been many changes, it's all the more difficult to find out
which change introduced the problem (IMNSHO).

   I would take advantage of the "Test" release present in setup to give
people time to check things, then rotate it into the "Current" slot, and the
older one to "Previous".  I know other people have different working styles,
but it helps to understand where they are coming from and their rationale
for doing it the way they do it. 


Linda




--
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: Latest Cygwin Release 5 month old...

[Warren Young]

Linda Walsh wrote:

Really?  a 6 y/o, 800MHz Celeron w/512M, & 4MB video taken out of main
memory?  You have alot more patience than me.


That's well over VMWare's recommended minimum configuration.  I'm pretty 
sure the first machine I used VMware on was in roughly that same class. 
 I was using Linux as a host for it, which helped, though.


The way I look at it, you can continue to write complaint messages to 
the Cygwin mailing list, or you can spend some time waiting for VMware 
to grind through some tests.  You're going to spend some time either 
way.  Which seems a more sensible use of your time?


--
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: snapshots: first resort, or last resort?

[Igor Peshansky]

On Mon, 26 Jun 2006, Linda Walsh wrote:

> mwoehlke wrote:
> > Science Guy wrote:
> > > In http://cygwin.com/ml/cygwin/2006-06/msg00434.html, Brian said
> > > "using the latest snapshot should always be the first thing you try
> > > when encountering a problem before reporting it to the list."
> > >
> > > However, the instructions for installing snapshots at
> > > http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots say:
> > > "First, are you sure you want to do this? Snapshots are risky. They
> > > have not been tested. Use them ONLY if there is a feature or bugfix
> > > that you need to try, and you are willing to deal with any problems,
> > > or at the request of a Cygwin developer."
> > >
> > > For a non-expert, such as me, this dichotomy of views is perplexing.
> > > This is made all the more perplexing because there does not seem to
> > > be (I could not find) a user-readable list of bugs that each
> > > snapshot fixes vis-a-vis the latest release.  So how would a user
> > > know whether the "risky" step of installing a snapshot will have any
> > > chance of fixing a particular bug?
> > >
> ---Excellent point Joe (aka Science Guy!).
> >  If you have a problem, you should try a snapshot. However, you should
> > keep in mind that doing so means trying a potentially unstable setup.
> > Therefore, when trying a snapshot, you should do as little as possible
> > while using that snapshot. If it doesn't fix your problem, it is
> > safest to go back to a stable version. If it does, *then* you have to
> > decide if you want to use a setup that might be unstable (more so than
> > usual), or if you can wait for an official release.
> 
>
>Which begs the question -- why aren't releases done more often?
> Five months between releases seems intensely long compared to, say, the
> linux kernel, which averaged 1 month releases when 2.4 was active, to 2
> month releases, now, with 2.6 and the managed "bug fix" releases that
> happen in between regular releases.
>
>It doesn't do _users_ alot of good to check a snapshot.  It does,
> indirectly, in that it may increase code quality, *but*, if they don't
> want to run with an unstable snapshot, they won't see their bugfix for
> [several?] months.
>
>Trying a snapshot fine for testing a particular bugfix, but snapshots
> are no substitute for updating the released product on a regular basis.
> If the cost to do a release is low and number of changes / bugfixes are
> high, it would be good to get the product to a "releasable" point every
> few weeks to a month so users will see their efforts at
> find/isolating/reporting/ trying snapshots, rewarded.  Is there some
> obstacle to more regular releases?
>
>If it were me, (and I know it's not, thank-you), I'd feel better
> about getting updated releases into user's hands as soon as reasonable.
> If I fix something, or change something, I wouldn't want to wait 6
> months to release it, (ideally,) so if a change I make introduces an
> untested and unthought-of incompatibility I'm more likely to remember
> the changes that went into the code.  Five-Six months later, on active
> code and the changes might as well have been made by someone else and
> I'm more likely to have to go in "cold" to figure out which change broke
> things for some isolated user test case. If there have been many
> changes, it's all the more difficult to find out which change introduced
> the problem (IMNSHO).
>
>I would take advantage of the "Test" release present in setup to give
> people time to check things, then rotate it into the "Current" slot, and
> the older one to "Previous".  I know other people have different working
> styles, but it helps to understand where they are coming from and their
> rationale for doing it the way they do it. Linda

What is the difference between installing a "test release" of Cygwin and
installing a "snapshot" of Cygwin (other than the mechanism by which you
do it)?  How would it help you if the current snapshot were made available
as a "release" today?  It would be as (un)stable as the snapshot it was
packaged from.  The Cygwin developers intentionally do not make snapshots
installable via setup, because of exactly that mindset: "releases are
stable, snapshots aren't".  If you got something via setup, you would feel
you have the right to complain about it if something breaks and demand
that it be fixed.  If you install a snapshot, well, you were warned.
You'd still complain (and we want you to), but you'll probably invest more
effort in tracking down the problem and producing a simple testcase.

FWIW, it's trivial for someone to provide a service that would mirror the
snapshot tarballs off the snapshots page and make them available to setup
as test releases.  It would even be possible, with a little effort, to be
selective and only mirror the snapshots that the developers deem stable
enough to be release candidates (though it would have to be done
manually).  However, anyone providing t

Re: g++ 4.1?

[Joe Schmoe]

Thanks to all that encouragement, I now have not one but two working
installations of gcc-4.1.1.  As Brian said, the cygwin compiler will
configure and make with no problems, except that -mno-cygwin doesn't
work. For a no-cygwin compiler, this is what I did -- I'm not saying
it's a good idea. First ftp your sources from GNU. (I only took
gcc-core and gcc-g++). Use setup to make sure you've got gcc-3.4.5 and
anything with mingw in the package name, and maybe gmp, flex and
bison. (I don't know exactly what is required. It turns out I already
had everything I needed.)

../<...>/configure --disable-nls --program-suffix=<...> \
 --host=i686-pc-cygwin --target=i686-pc-mingw32

make
## failure; can't find 
ln -s /usr/include/w32api /usr/i686-pc-ming32/sys-include # (stupid hack)

make
## failure; can't find i686-pc-mingw32-ar.exe
for x in as ld ar nm strip ranlib # (stupid hack)
do ln -s /usr/i686-pc-mingw32/bin/$x.exe /usr/bin/i686-pc-mingw32-$x.exe
done

make
make install

The resulting compiler does seem to make working native binaries, at
least for my program, which doesn't explicitly use DLLs or exceptions.
Final thought: this probably wasn't worth the trouble.

Regards, Buster.

--
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: dtoa.c fails to compile for sh-elf -m2e (Was: Re: strtod (and atof) on hex numbers)

[amylaar]

Quoting Jeff Johnston <[EMAIL PROTECTED]>:

> Joern Rennecke wrote:
> > You change to mprec.h broke dtoa.c compilation for sh2e:
> >
>
> Please try the attached patch and let me know if it sovles the problem.

Yes, it allows dtoa.c to compile.  However, the build now fails a bit
later on strtod:

/swbuild/nightly/2006-06-24/sh-elf-mprec/./gcc/xgcc
-B/swbuild/nightly/2006-06-24/sh-elf-mprec/./gcc/ -nostdinc
-B/swbuild/nightly/2006-06-24/sh-elf-mprec/sh-elf/newlib/ -isystem
/swbuild/nightly/2006-06-24/sh-elf-mprec/sh-elf/newlib/targ-include -isystem
/swbuild/nightly/2006-06-24/srcw/newlib/libc/include -B/usr/local/sh-elf/bin/
-B/usr/local/sh-elf/lib/ -isystem /usr/local/sh-elf/include -isystem
/usr/local/sh-elf/sys-include -L/swbuild/nightly/2006-06-24/sh-elf-mprec/./ld
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.14.0\" -DPACKAGE_STRING=\"newlib\ 1.14.0\"
-DPACKAGE_BUGREPORT=\"\"  -I. -I../../../../../../srcw/newlib/libc/stdlib -O2
-fno-builtin  -O2 -g -O2   -m2e -c -o lib_a-strtod.o `test -f 'strtod.c' ||
echo '../../../../../../srcw/newlib/libc/stdlib/'`strtod.c
../../../../../../srcw/newlib/libc/stdlib/strtod.c: In function ‘ULtod’:
../../../../../../srcw/newlib/libc/stdlib/strtod.c:154: error: ‘_1’ undeclared
(first use in this function)
../../../../../../srcw/newlib/libc/stdlib/strtod.c:154: error: (Each undeclared
identifier is reported only once
../../../../../../srcw/newlib/libc/stdlib/strtod.c:154: error: for each function
it appears in.)
../../../../../../srcw/newlib/libc/stdlib/strtod.c:155: error: ‘_0’ undeclared
(first use in this function)
../../../../../../srcw/newlib/libc/stdlib/strtod.c: In function ‘_strtod_r’:
../../../../../../srcw/newlib/libc/stdlib/strtod.c:439: error: ‘Flt_Rounds’
undeclared (first use in this function)

--
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: Latest Cygwin Release 5 month old...

[Christopher Faylor]

On Mon, Jun 26, 2006 at 02:31:38PM -0600, Warren Young wrote:
>Linda Walsh wrote:
>>Really?  a 6 y/o, 800MHz Celeron w/512M, & 4MB video taken out of main
>>memory?  You have alot more patience than me.
>
>That's well over VMWare's recommended minimum configuration.  I'm
>pretty sure the first machine I used VMware on was in roughly that same
>class.  I was using Linux as a host for it, which helped, though.
>
>The way I look at it, you can continue to write complaint messages to
>the Cygwin mailing list, or you can spend some time waiting for VMware
>to grind through some tests.  You're going to spend some time either
>way.  Which seems a more sensible use of your time?

Bingo.

This is generally obvious advice which goes beyond "vmware".  This
concept can also be applied to the people who send email trying to
figure out the fastest way to download cygwin because they have a slow
internet connection or people who ask where to find things in source
code and then wait two days for a reply...

In any event, maybe we can stop talking about this now?  Warren, I
appreciate your creative solution to this "problem" and hope you have
provided some fuel for thought for some people who may now be thinking
about testing snapshots.  However, I think it's pretty obvious that
we've gone beyond the point where further discussion is relevant to
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: snapshots: first resort, or last resort?

[Markus Schönhaber]

Igor Peshansky wrote:
> On Mon, 26 Jun 2006, Linda Walsh wrote:
> >If it were me, (and I know it's not, thank-you), I'd feel better
> > about getting updated releases into user's hands as soon as reasonable.
> > If I fix something, or change something, I wouldn't want to wait 6
> > months to release it, (ideally,) so if a change I make introduces an
> > untested and unthought-of incompatibility I'm more likely to remember
> > the changes that went into the code.  Five-Six months later, on active
> > code and the changes might as well have been made by someone else and
> > I'm more likely to have to go in "cold" to figure out which change broke
> > things for some isolated user test case. If there have been many
> > changes, it's all the more difficult to find out which change introduced
> > the problem (IMNSHO).
> >
> >I would take advantage of the "Test" release present in setup to give
> > people time to check things, then rotate it into the "Current" slot, and
> > the older one to "Previous".  I know other people have different working
> > styles, but it helps to understand where they are coming from and their
> > rationale for doing it the way they do it. Linda
>
> What is the difference between installing a "test release" of Cygwin and
> installing a "snapshot" of Cygwin (other than the mechanism by which you
> do it)?  How would it help you if the current snapshot were made available
> as a "release" today?  It would be as (un)stable as the snapshot it was
> packaged from.  The Cygwin developers intentionally do not make snapshots
> installable via setup, because of exactly that mindset: "releases are
> stable, snapshots aren't".  If you got something via setup, you would feel
> you have the right to complain about it if something breaks and demand
> that it be fixed.  If you install a snapshot, well, you were warned.
> You'd still complain (and we want you to), but you'll probably invest more
> effort in tracking down the problem and producing a simple testcase.

Nevertheless I'd like to propose that the cygwin snapshots shouldn't merely be 
called "snapshot" in the future but "stable snapshot". This might help to 
provide the cozy and warm feeling which seems to be so desperately needed.

Regards
  mks

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

rsync thinking a local transfer is "remote"

[Linda Walsh]

I've got a weird situation with rsync.   I'm trying to
transfer some files from a network share mounted as "B:\".

I'm copying the files to corresponding locations under C:\.

I've done many transfers from B->C, entire directories, but now
In a particular instance, rsync tries to transfer via the network.

I'm using the same syntax as before and have tried some variations
but am still seeing this odd behavior.

Commands I've tried include:
rsync -av /b/windows/Resources/* /c/WINDOWS/Resources/
rsync -v -a /b/Windows/Resources/Icons /Windows/Resources/
rsync -v -a /b/Windows/Resources/Icons/Home.ico /Windows/Resources/Icons/

(and with CWD=source dir)
rsync -va * /c/WINDOWS/Resources/
rsync -v -v -v -a Icons /c/WINDOWS/Resources/
rsync -v -v -v -a Icons /WINDOWS/Resources/

Each of the above attempted to open port 2201 for output (which
I denied).  And each failed with:
rsync: pipe: Connection refused (111)
rsync error: error in IPC code (code 14) at

/home/lapo/packaging/tmp/rsync-2.6.6/pipe.c(117)


I finally used:

cp -a Icons /Windows/Resources/

which works, but doesn't say much for "rsync" other than "it is
confused".

Are there any outstanding or known issues where "rsync" gets confused
and tries to do a networked copy when both the source and target are
locally mounted "disks"?

Thanks,
Linda




--
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: Fortran Compiler Error CMBFAST

[Billinghurst, David \(CALCRTS\)]

> From: Brad Krane
> 
> I'm trying to compile the scientific package CMBFAST-4.5.1 in the
> cygwin environment using g77. I get the following error and I have no
> idea how to fix this having never used Fortran before. This should
> work without any problem as many other people have compiled this and
> never run up on a similar problem. I think that it is a compiler
> specific issue or an environment one.
> 
> f77 -O2   -c -o jlgen.o jlgen.F
> jlgen.F: In program `jlgen':
> jlgen.F:14:
>  include 'cmbfast.inc'
>  ^
> Unable to open INCLUDE file `cmbfast.inc' at (^)
> jlgen.F:18:
>  integer l(lmax),i,j,lmo
>^
> Invalid declaration of or reference to symbol `lmax' at (^) [initially
> seen at (^)]
> jlgen.F:18:
>  integer l(lmax),i,j,lmo
>  1
> jlgen.F:21: (continued):
>  common /lvalues1/ l,l0,lmo
>2
> Invalid declaration of or reference to symbol `l' at (2) 
> [initially seen at (1)]

Brad,

This is not really a cygwin problem.  

The compiler can't find the file cmbfast.inc.  Perhaps:
 - copy the file into the same directory as jlgen.F, or
 - point to it with the -I compiler directive


NOTICE
This e-mail and any attachments are private and confidential and may contain 
privileged information. If you are not an authorised recipient, the copying or 
distribution of this e-mail and any attachments is prohibited and you must not 
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.

--
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: g++ 4.1?

[clayne]

It should also be noted that some of the latest snapshot, or code that
still exists in the latest snapshot, will fail under 4.1.1. Specifically:
declaration of objects within a label statement.

-cl

On Mon, Jun 26, 2006 at 09:52:41PM +0100, Joe Schmoe wrote:
> Thanks to all that encouragement, I now have not one but two working
> installations of gcc-4.1.1.  As Brian said, the cygwin compiler will
> configure and make with no problems, except that -mno-cygwin doesn't
> work. For a no-cygwin compiler, this is what I did -- I'm not saying

--
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: snapshots: first resort, or last resort?

[Christopher Faylor]

On Tue, Jun 27, 2006 at 01:19:35AM +0200, Markus Sch?nhaber wrote:
>Nevertheless I'd like to propose that the cygwin snapshots shouldn't merely be 
>called "snapshot" in the future but "stable snapshot". This might help to 
>provide the cozy and warm feeling which seems to be so desperately needed.

There is the small problem that snapshots are not guaranteed to be
stable, of course.

When we think a snapshot is stable and we're close to a release, Corinna
or I ask for testing of the snapshot so that we can get to a release.
Otherwise, there are no guarantees.

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: snapshots: first resort, or last resort?

[Igor Peshansky]

On Tue, 27 Jun 2006, Markus Schönhaber wrote:

> Igor Peshansky wrote:
> > On Mon, 26 Jun 2006, Linda Walsh wrote:
> > >If it were me, (and I know it's not, thank-you), I'd feel better
> > > about getting updated releases into user's hands as soon as reasonable.
> > > If I fix something, or change something, I wouldn't want to wait 6
> > > months to release it, (ideally,) so if a change I make introduces an
> > > untested and unthought-of incompatibility I'm more likely to remember
> > > the changes that went into the code.  Five-Six months later, on active
> > > code and the changes might as well have been made by someone else and
> > > I'm more likely to have to go in "cold" to figure out which change broke
> > > things for some isolated user test case. If there have been many
> > > changes, it's all the more difficult to find out which change introduced
> > > the problem (IMNSHO).
> > >
> > >I would take advantage of the "Test" release present in setup to give
> > > people time to check things, then rotate it into the "Current" slot, and
> > > the older one to "Previous".  I know other people have different working
> > > styles, but it helps to understand where they are coming from and their
> > > rationale for doing it the way they do it. Linda
> >
> > What is the difference between installing a "test release" of Cygwin and
> > installing a "snapshot" of Cygwin (other than the mechanism by which you
> > do it)?  How would it help you if the current snapshot were made available
> > as a "release" today?  It would be as (un)stable as the snapshot it was
> > packaged from.  The Cygwin developers intentionally do not make snapshots
> > installable via setup, because of exactly that mindset: "releases are
> > stable, snapshots aren't".  If you got something via setup, you would feel
> > you have the right to complain about it if something breaks and demand
> > that it be fixed.  If you install a snapshot, well, you were warned.
> > You'd still complain (and we want you to), but you'll probably invest more
> > effort in tracking down the problem and producing a simple testcase.
>
> Nevertheless I'd like to propose that the cygwin snapshots shouldn't
> merely be called "snapshot" in the future but "stable snapshot". This
> might help to provide the cozy and warm feeling which seems to be so
> desperately needed.

Ah, I can just imagine the subject of a message: "Please do not install
the 20060624 stable snapshot -- it is hopelessly broken". :-D

Though jokes aside, snapshots that multiple people used with no (or few)
problems could be marked "stable" so that people who are too cautious to
live on the bleeding edge of Cygwin can bring themselves to get the
benefit of the latest fixes in the snapshots.  Of course, that would
involve actually having the people that test the snapshots and report
successes somewhere (and hopefully on a separate mailing list), and then
someone to collate the results and notify the Cygwin developers to mark
the snapshot as "stable" (with pointers to success messages as proof of
stability).  But, as usual, .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
--
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: snapshots: first resort, or last resort?

[Linda Walsh]

Igor Peshansky wrote:

What is the difference between installing a "test release" of Cygwin and
installing a "snapshot" of Cygwin

---
I would hope it is the difference between daily work and something that
is of "Beta" quality -- i.e. something that "seems to work" and "should work
for most people" and isn't as likely as "daily" work to be as variable as
"daily" snapshots are.



The Cygwin developers intentionally do not make snapshots
installable via setup, because of exactly that mindset: "releases are
stable, snapshots aren't".

---
Bingo.  A Beta release should have some stability even though it
may not be that of a finished product.  Do you guys live in a black and white
world?  There are more than two points "stable" and "unstable" in the real
world.  Virtually no software released today is bugfree (and by that definition
has some "instability" in it), but there are different "levels" of quality
that I and most users I know can notice.  For example, very conservative users
stay away from "V.0" releases, as they are the first after major changes.  For
them, they want the stability that may come from an "V.0.17" or an "V.3".
Other users are fine with released, but perhaps cannot afford "Beta" level
quality.  Other users are can tolerate Beta, but don't want to get into
"alpha's" (which are often internal, anyway).  Of lower quality than "alpha's"
are "daily snapshots" (which hopefully, at least build and are installable, but
not guaranteed), and below that might be the current CVS image.

Different people are comfortable with different levels of "risk".



 If you got something via setup, you would feel
you have the right to complain about it if something breaks and demand
that it be fixed.  

---
Yeah, and?...So?



If you install a snapshot, well, you were warned.
You'd still complain (and we want you to), but you'll probably invest more
effort in tracking down the problem and producing a simple testcase.

---
If you are a developer on the project, yes, or if you have a full plate
with other projects -- many managers I've been under would not be pleased if you
spent time debugging Cygwin.  On the other hand, I wouldn't make daily snapshot
code available if it wasn't of some minimal level of quality.  For all anyone 
knows, a daily snapshot might reformat your disk.  And we'd be expected not to
be upset when this occurs on a production system (since most engineers know one 
don't try software that's less stable than their machine is "rated".




FWIW, it's trivial for someone to provide a service that would mirror the
snapshot tarballs off the snapshots page and make them available to setup
as test releases.

---
Automatic releases would defeat the point.

  It would even be possible, with a little effort, to be

selective and only mirror the snapshots that the developers deem stable
enough to be release candidates (though it would have to be done
manually). 

---
You mean, select what version is going out with what changes in
an "intelligent" manner?  Are you inferring this is too difficult or not
possible for the cygwin developers?



However, anyone providing that service should be prepared to
field complaints and generate proper bug reports.  If done properly, this
kind of service would be invaluable to the Cygwin project.  If done
poorly, it would be a great hindrance.


	Agreed.  The bugs could be filed (like the bugzilla available firefox and 
thunderbird) under their version -- whether its a daily snapshot, an alpha
a beta or a "released & tested version".  Perhaps cygwin could find a 
free-software bug-tracking site to integrate with?  Maybe the bugzilla website

could allow tracking of cygwin (might even give it more visibility, who knows?)?

I also agree that not having a public bug tracking mechanism would be
a hindrance to a large and complex project like Cygwin.

But barring any new developments, the Beta versions could be use
the same, bug tracking mechanism available today, right?  (ok, that's not
entirely fair), but the point would be when someone reports a bug in the "Beta"
or "Test" version, they *darn* well should say what version they are finding the
bug in, _and_, hopefully whether or not it is a new bug (is it in the released
version).

If the two versions were never more than a month or two apart, then that
mechanism should point to whether or not it is a regression, or a "new, 
unreported bug".


	It has the added benefit of users being able to search through existing bugs to 
see if one has already been filed -- versus the current expectation that

users will go and read the cygwin-mailing list archives to find their problem.
Searching the cygwin-mailing archives with Google generates alot of "noise" in
the search results that are unrelated to bugs that have been reported and are 
"in the system" to be addressed at some point.


I think the current method of scanning for bug reports

Re: snapshots: first resort, or last resort?

[mwoehlke]

Linda Walsh wrote a lot of stuff about how she wants more flavors and 
frequency of Cygwin releases...


...and as Igor said, . Care to volunteer?

--
Matthew
This line intentionally left blank.


--
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: rsync thinking a local transfer is "remote"

[clayne]

On Mon, Jun 26, 2006 at 04:35:30PM -0700, Linda Walsh wrote:
> I've got a weird situation with rsync.   I'm trying to
> transfer some files from a network share mounted as "B:\".

Anything strange about the filenames in those directories?
Colons or otherwise?

--
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: Where to get cygwin gcc 3.3.3 source

[Brian Dessent]

PLEASE do not reply to me personally.  Keep all replies to the list.

John Neil wrote:

> Hmmm... so there is no special "Cygwin" version of the gcc 3.3.3 source?
> I tried compiling the GNU gcc 3.3.3 source once and got different
> behavior with compiled apps than the installed Cygwin 3.3.3 binary.

Yes, of course there is, and that is exactly what I was trying to tell
you.  Look on any *Cygwin* mirror site and you'll find the gcc source
packages, which include all the Cygwin-local patches.  Note that the
filenames I quoted are "gcc-core-3.3.3-3-src.tar.bz2" and not
"gcc-core-3.3.3.tar.gz".  The former is the Cygwin source package name,
the latter is the upstream source tarball.

> My Cygwin mirror seems to have gcc 3.3.3 off by itself in a releases
> folder:
> ftp://mirrors.kernel.org/gnu/gcc/releases/gcc-3.3.3/
> Whereas all other releases are located at:
> ftp://mirrors.kernel.org/gnu/gcc/

You're looking at a GNU mirror site, not a Cygwin mirror site.  Those
are upstream, stock FSF releases of gcc.  mirrors.kernel.org mirrors
many projects and you're looking at the wrong one.  You want:  


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/