similar to: rsync-2.6.9pre2: undeclared variable in source code

There is a small configure glitch for rsync-2.5.5rc1 on Apple Darwin (== MacOS X) [ uname -a Darwin darwin.math.utah.edu 5.2 Darwin Kernel Version 5.2: Fri Dec 7 21:39:35 PST 2001; root:xnu/xnu-201.14.obj~1/RELEASE_PPC Power Macintosh powerpc ] the config.h file gets the line #define INET6 1 The link then fails with /usr/bin/ld: Undefined symbols: _freehostent _getipnodebyaddr

The rsync-2.5.5rc1/README says >> ... >> If you have web access then please look at >> http://rsync.samba.org/rsync/ >> >> This will give you access to the bug tracking system used by the >> developers of rsync and will allow you to look at other bug reports or >> submit a new bug report. >> ... According to that Web site, the bug tracking system

Build attempts of the new ssh-openbsd-2003091700 distribution fail like this on OpenBSD 3.2: cc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o uidswap.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o

I found that my mail client reported invalid messages in the just-downloaded rsync.mbox. Further examination showed that they are due to instances of unprefixed words "From" at beginning of line in the message body. Once I fixed them, all messages are visible. It looks like the rsync.mbox file may have been prepared by simple concatenation of messages, without the filtering of

>> I have come across your reported log1p error (#2837) on a NetBSD (1.6W) >> system. I've just made further experiments on the deficient log1p() function on OpenBSD 3.2 and NetBSD 1.6 with this test program: % cat bug-log1p.c #include <stdio.h> #include <stdlib.h> #include <math.h> int main(int argc, char* argv[]) { int k; double x; for (k = 0; k

While builds and validations of R-1.6.2beta_2002-12-20 were successful on several systems, there were a few failures: ------------------------------------------------------------------------ Apple Darwin 6.2 (MacOS 10.2.2) with gcc-3.2.1: gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libgslcblas.0.0.0.dylib sasum.lo saxpy.lo ... isamax.lo izamax.lo xerbla.lo -lc -install_name

A build of the new openssh-3.7.1p1 distribution failed on SGI IRIX 6.5 because the inet_ntoa.h header file is not part of the openssh-3.7.1p1 distribution: cc -I/usr/local/include -I. -I.. -I. -I./.. -I/usr/local/include -I/usr/local/include -DHAVE_CONFIG_H -c inet_ntoa.c cc-1005 cc: ERROR File = inet_ntoa.c, Line = 46 The source file "inet_ntoa.h" is unavailable. #include

R-1.7.0 failed to build on OpenBSD 3.2: Machinetype: Intel Pentium III (600 MHz); OpenBSD 3.2 GENERIC#25 i386 Remote gcc version: gcc (GCC) 3.2.2 Remote g++ version: g++ (GCC) 3.2.2 Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib gcc -shared -Wl,-rpath,/usr/local/lib -o lapack.so Lapack.lo rgeev.lo rsyev.lo -L../../../bin -lRlapack

Brian Ripley writes today: >> There is already a usable log1p implementation in src/nmath/log1p, for >> platforms without it. All we need to do is to arrange to use it on those >> systems with broken versions. That's not easy without access to such a >> platform to test it, though. I need the same kind of test in my own software, so I made some experiments and

Ray Brownrigg <ray@mcs.vuw.ac.nz> writes today about the log1p() problems on NetBSD 1.6 and OpenBSD 3.2: >> Indeed, but since I have acess to a NetBSD developer, this is an >> opportunity to get it fixed for everyone. That's a start, but the reality is that it isn't enough. There will be many sites that don't upgrade O/S versions except at possibly very long

Ray Brownrigg <ray@mcs.vuw.ac.nz> writes today about the inaccurate log1p() on NetBSD 1.6 and OpenBSD 3.2: >> Well, the source which I have access to doesn't bear that out. Interesting. Our NetBSD installation is pretty recent: % uname -a NetBSD netbsd.vm.math.utah.edu 1.6 NetBSD 1.6 (GENERIC) #0: Sun Sep 8 19:43:40 UTC 2002

There are quite a few compilation warnings from rsync-2.5.5rc1 that could be eliminated by code cleanup. gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c main.c -o main.o main.c: In function `start_client': main.c:665: warning: unused variable `write_batch' main.c:664: warning: unused variable `whole_file' These warnings will go away when the two variables are properly bracketed

Builds of the R-2.0.0 release have been considerably more successful at my site than previous releases. I now have it installed on these platforms: Apple PowerPC G3 267MHz GNU/Linux 2.4.19-4a (Yellow Dog Linux release 2.3 (Dayton)) Compaq Alpha Sierra OSF/1 5.1 Compaq/DEC Alpha OSF/1 4.0F Intel Itanium-2 GNU/Linux Red Hat Linux Advanced Server release 2.1AS (Derry) Intel Pentium II FreeBSD

[This is not a bug report, just a suggestion.] With complex packages, it is often useful to maintain multiple versions installed, for bug checking, and performance comparisons, and for developers, for a development history (e.g., I have about 30 versions of ghostscript, whose development I contribute to, and I have on several occasions run tests files on with each them to find out when a change

On IBM RS/6000 AIX 4.2, I built R-1.2.1 with % env CC=xlc CXX=xlC F77=f77 FC=f77 ./configure R is now configured for powerpc-ibm-aix4.2.1.0 Source directory: . Installation directory: /usr/local C compiler: c89 -g C++ compiler: xlC -g FORTRAN compiler: f77 -g X11 support: yes Gnome support: no Tcl/Tk

I've now done two rebuilds of R-1.7.0 on NetBSD 1.6, one with the --without-zlib configure option, and one without. Both builds use the recently-installed gcc-3.2.3 compiler. As before, the one built normally gets a segment violation, whereas the one built with the --without-zlib option works. The odd thing is that neither uses shared libraries for zlib: % ldd /usr/local/lib/R/bin/R.bin

R-1.7.0 built on NetBSD 1.6, but the validation test suite failed: Machinetype: Intel Pentium III (600 MHz); NetBSD 1.6 (GENERIC) Remote gcc version: gcc (GCC) 3.2.2 Remote g++ version: g++ (GCC) 3.2.2 Configure environment: CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib make[5]: Entering directory `/local/build/R-1.7.0/src/library' >>> Building/Updating

On a typical embedded Linux device, with no MMU, there is no fork() or it returns ENOSYS. The nearest replacements are vfork() (which is only useful before exec*()), or to create threads with pthread_create(). rsync would be a very useful program on such devices, and I was a bit disappointed to build it, only to find the compile went fine but it failed at runtime due to ENOSYS. Is there any

I am looking at histogram breaks, and notice something odd: > foo <- hist(runif(10000),breaks=20) > length(foo$breaks) [1] 21 This makes sense to me. > foo <- hist(runif(10000),breaks=200) > length(foo$breaks) [1] 201 This also makes sense. BUT > foo <- hist(runif(10000),breaks=250) > length(foo$breaks) [1] 201 > foo <- hist(runif(100000),breaks=250) >

Hi, OpenSSH 6.5 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is