similar to: Error building CVS on Tru64 UNIX

Hi Paul, your suggestion about batch.c got by the compiler without a peep and it got much farther along again with complaint from cc until.... [root@hyperion: rsync-2.5.4]#CC=cc; export CC; ./configure configure: Configuring rsync 2.5.4 checking build system type... alphaev5-dec-osf5.1 checking host system type... alphaev5-dec-osf5.1 checking target system type... alphaev5-dec-osf5.1 checking for

Hi, I tried to compile rsync2.5.3 on Solaris5.7, and I still got the same errors as Solaris5.8, can you please help me to look at the problem? I got error messages: Configure was run successfully, then I ran make, I got: "batch.c", line 408: operands have incompatible types: pointer to unsigned long ":" pointer to unsigned int cc: acomp failed for batch.c ***

Greetings, here is the output of the 'configure' step and the compile step (using the Compaq cc compiler that comes with Tru64 V5.1A. The configure reported success and most of the compile steps cam through error/warning free except for the one that stumbled. Can someone help me out here? I am willing to provide a binary for Tru64 V5.1A if we can swat this bug. We depend greatly on Rsync

Platform: Compaq OpenVMS Alpha 7.3 Compiler: Compaq C T6.5 The following patch is an update to a previous patch that I submitted. The only change from the previous patch is that the const qualifier has been added to write_batch_*() routines to improve compiler efficiency. Because the gdiff -u was done against the distribution it includes the previous patch. The functions with no parameters

How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/

Here's the latest version of the batch mode cleanup patch. Index: batch.c =================================================================== RCS file: /cvsroot/rsync/batch.c,v retrieving revision 1.12 diff -u -r1.12 batch.c --- batch.c 24 Jan 2002 08:09:46 -0000 1.12 +++ batch.c 6 Feb 2002 19:47:57 -0000 @@ -8,55 +8,38 @@ #include "rsync.h" #include <time.h> -char

Andrew and I thought it might be an interesting experiment to move rsync to using BitKeeper rather than CVS for source code control. For a project with rsync's size and activity CVS is actually fine, but it would be a nice "toe in the water" with BitKeeper to get some practical experience before possibly using it on larger projects. BK is moderately well-proven on open source

What about this one? The diff looks like this: --- src/sys/net/zlib.c 2002/02/17 17:35:18 1.11 +++ src/sys/net/zlib.c 2002/03/20 04:05:26 1.12 @@ -10,7 +10,7 @@ * - added inflateIncomp and deflateOutputPending * - allow strm->next_out to be NULL, meaning discard the output * - * $FreeBSD: /c/ncvs/src/sys/net/zlib.c,v 1.11 2002/02/17 17:35:18 jedgar Exp $ + * $FreeBSD:

I wrote a patch to make the number of times and and the delay between retries that ssh attempts to talk to ssh-agent configurable. This patch is indispensible when running multiple ssh sessions in parallel from a script (e.g. to run commands on a large number of hosts); without the patch, many ssh sessions simply fail because they cannot contact the agent, rendering the mechanism unusable. If

Here's a list of cosmetic changes I'd be willing to make to the code in order to make it more consistent, which stylisticly it currently is not. - separate function definitions by 2 newlines - put spaces after commas in arg lists - put spaces around assignments - remove trailing spaces - change space indents to tabs - fix multiline comments - remove redundant /* dw */ comments (Deborah

1) Testing of uidswap.c on a Tru64 UNIX V4.0G PK4 (BL22) machine shows the following defines to be required for correct uid changing semantics: #define BROKEN_SETREGID 1 #define BROKEN_SETREUID 1 #define SETEUID_BREAKS_SETUID 1 Failure to fix these contributes to breaking privilege separation (in a safe way: connections will fail while UsePrivilegeSeparation=yes, thanks to

[My apologies if this question is deemed inappropriate for this list.] Using OpenSSH, is it possible for a program/script to copy files with known filenames from a remote server (running sshd), without allowing (interactive) ssh access to that server? I.e. ``ssh server ls'' or ``ssh server'' should not be possible (for security reasons), but ``scp server:file .'' should.

Tru64 UNIX has getaddrinfo but not by that name. Including <netdb.h> #defines getaddrinfo to ogetaddrinfo or ngetaddrinfo which exists in /usr/shlib/libc.so. So, AC_CHECK_FUNC(getaddrinfo) isn't enough to test for getaddrinfo. Best to AC_TRY_LINK so the #define takes effect. -- albert chin (china@thewrittenword.com) -- snip snip --- configure.in.orig Thu Jan 3 19:03:54 2002 +++

rsync+ is ready to go onto HEAD. Could Jos or somebody else who's used the feature before please prepare a few paragraphs for the manpage explaining how they work? Either send a patch to the .yo files or just plain text. Thanks, -- Martin

I see very odd results from rsync 2.4.7pre1, the latest cvs version (sept 12, i think was the last modified file). We have a number of network-attached storage devices. 10/100 ethernet, nfs2 mounted (under nfs3, they buffer deletes, and recursive deletions fail). Usually, these are kept syncronized across a wan by a nightly cronjob, We have a few we keep in reserve, which we syncronize

OpenSSH still has this feature, SSH-1.2.27 no longer has it. Admittedly it can be useful sometimes, even though I'd prefer this to be done using a trivial shell wrapper, which would be the UNIX way of doing things. Not being able to call OpenSSH's ssh by another name (say ``ssh1'') can get in the way when having to maintain two versions of ssh in parallel because the ``ssh ->

Tru64 UNIX 4.0D, with the DTK (Desktop Toolkit), includes int64_t in /usr/include.dtk/stdint.h. $ gmake ... (cd openbsd-compat && gmake) gmake[1]: Entering directory `/opt/build/openssh-3.2.3p1/openbsd-compat' cc -O2 -std -I/opt/TWWfsw/tcpwrap/include -I. -I.. -I. -I./.. -I/opt/TWWfsw/libopenssl09s/include -I/opt/TWWfsw/zlib11s/include -DHAVE_CONFIG_H -c bsd-arc4random.c cc: Error:

Hi all, I have rsync 2.5.1 (with a patch from albert chin - china@thewrittenword.com) installed OK on Tru64 5.1 UNIX. When I run rsync, it doesn't work with special files (FIFO, socket,...) Here is the error: mknod cluster/members/member1/dev/binlogdmb : Invalid argument mknod cluster/members/member1/dev/log : Invalid argument mknod cluster/members/member1/dev/printer : Invalid

Hi all, I have rsync 2.5.1 (with a patch from albert chin - china@thewrittenword.com) installed OK on Tru64 5.1 UNIX. When I run rsync, it doesn't work with special files (FIFO, socket,...) Here is the error: mknod cluster/members/member1/dev/binlogdmb : Invalid argument mknod cluster/members/member1/dev/log : Invalid argument mknod cluster/members/member1/dev/printer : Invalid

http://bugzilla.mindrot.org/show_bug.cgi?id=267 Summary: Build problems with 3.2.3p1 under Tru64 UNIX 4.0D Product: Portable OpenSSH Version: -current Platform: Alpha URL: ftp://ftp.thewrittenword.com/outgoing/pub/openssh- 3.2.3p1-3.patch OS/Version: OSF/1 Status: NEW Severity: normal