similar to: rsync 3.4.1 released

The build system rolled up R-3.4.1.tar.gz (codename "Single Candle") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.4.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard

Is there a way I can get access to a machine 3.4.0 is failing to build on? Maybe a VM under VirtualBox? Or some cloud service? I don't have an ia64 On Thu, 16 Jan 2025 at 01:20, <rsbecker at nexbridge.com> wrote: > On January 14, 2025 11:20 PM, Perry Hutchison wrote: > >"Randall S. Becker via rsync" <rsync at lists.samba.org> wrote: > > > >> FYI:

I have released rsync version 3.2.5pre1 for release testing. This includes a checksum fix that affects some architectures (such as ARM), improves the security of the received file list, enhances the manpage, etc. I'd really appreciate it if people would give this release some extensive testing and see if the improved security results in any false alerts. I did a bunch of testing and found a

I have released rsync version 3.2.5pre1 for release testing. This includes a checksum fix that affects some architectures (such as ARM), improves the security of the received file list, enhances the manpage, etc. I'd really appreciate it if people would give this release some extensive testing and see if the improved security results in any false alerts. I did a bunch of testing and found a

I have released rsync version 3.2.7pre1 for release testing. This has a few new features and continues in the fixing of bugs in the extra validation of args & filter rules. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.2.7 You can download the source tar file and its signature from here:

I have released rsync version 3.2.7pre1 for release testing. This has a few new features and continues in the fixing of bugs in the extra validation of args & filter rules. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.2.7 You can download the source tar file and its signature from here:

I have released rsync version 3.3.0. This is a bug fix release, with the increased version bump being a delayed reaction to some of the recent larger changes that have happened. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.3.0 You can download the source tar file and its signature from here:

I have released rsync version 3.3.0. This is a bug fix release, with the increased version bump being a delayed reaction to some of the recent larger changes that have happened. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.3.0 You can download the source tar file and its signature from here:

Hello, In the past, R was always OK. Today, I updated R from 3.4.0 to 3.4.1 from cran mirrors. Updating was OK, but when I started R 3.4.1, It told me it couldn't find libraries. I installed libraries in /home/<users>/R/x86_64-pc-linux-gnu-library/3.4/. Now, if I wanna install packages in 3.4.1, the suggested default path is 'NA' !?!? I reinstalled R 3.4.0. All is OK. Please

Also, the patch I previously sent works correctly on x86, but not ia64. This problem is isolated to popt/findme From: rsync.project <rsync.project at gmail.com> Sent: January 15, 2025 2:11 PM To: rsbecker at nexbridge.com Cc: Perry Hutchison <pluto at agora.rdrop.com>; rsync at lists.samba.org Subject: Re: new release 3.4.0 - critical security release Is there a way I can get

FYI: I think this is just missing #include ?rsync.h? in popt/findme.c From: rsbecker at nexbridge.com <rsbecker at nexbridge.com> Sent: January 14, 2025 10:35 PM To: rsbecker at nexbridge.com; 'rsync.project' <rsync.project at gmail.com> Cc: rsync at lists.samba.org Subject: RE: new release 3.4.0 - critical security release Another issue here in findme.c. strlcpy() is

I don't think that's a bug. source() uses eval(), and eval() creates a new function-like context frame. In a way expecting `break` to work inside source() is like expecting `break` to cross stack frames: my_break <- function() break repeat(my_break()) Lionel > On 23 ao?t 2017, at 09:17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >

oops, I should have tried it: expr <- quote(break) repeat(eval(expr)) So eval() has hybrid semantics where `break` has more reach than return(), weird. expr <- quote(return()) repeat(eval(expr)) # infloop Lionel > On 23 ao?t 2017, at 09:24, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > It is a bug in the byte-code compiler. I will fix >

Fixed in 73112. If you needed to run this code in unpatched versions of R, you can disable the problematic compiler optimization in the loop for instance by adding "eval(NULL)" to the body of the loop. However, please do not forget to remove this for future versions of R and specifically do not assume this would turn off a particular compiler optimization in future versions. Best

A new dependency was added since 3.3, alloca(), which is not portable. Is there a way around this? Thanks, Randall From: rsync <rsync-bounces at lists.samba.org> On Behalf Of rsync.project via rsync Sent: January 14, 2025 2:49 PM To: rsync-announce at lists.samba.org Cc: rsync at lists.samba.org Subject: new release 3.4.0 - critical security release We have just released version

the alloca comes from the new popt release. What system are you having an issue with? On Wed, 15 Jan 2025 at 07:16, <rsbecker at nexbridge.com> wrote: > A new dependency was added since 3.3, alloca(), which is not portable. Is > there a way around this? > > Thanks, > > Randall > > > > *From:* rsync <rsync-bounces at lists.samba.org> *On Behalf Of

The popt changes came from upstream popt. We have Solaris and FreeBSD CI tests, along with linux, but don't have a method for testing other platforms. If you submit a PR to fix this, please consider a way we can test the fix in CI. Cheers, Tridge On Wed, 15 Jan 2025 at 14:35, <rsbecker at nexbridge.com> wrote: > Another issue here in findme.c. strlcpy() is a BSD-only method and >

I'd also note that the patches for 3.4.0 were made available to 81 different vendors via VINCE since 18th December (under embargo to give time for vendors to prepare). It is unfortunate that it didn't cover the platform you are building for. What platform is it btw? On Wed, 15 Jan 2025 at 17:57, rsync.project <rsync.project at gmail.com> wrote: > The popt changes came from

This happens on NonStop x86 and ia64. I have been building/packaging Rsync for years ? almost a decade in fact. I think this happened once before this year, in fact. It is equivalent to the more portable malloc/free, which I would prefer to have in this series even if it has to be wrapped in a #if defined (__TANDEM) block. This call is considered not portable and allocates on the stack

Here is my fix for the situation: diff --git a/popt/findme.c b/popt/findme.c index ac4cbae..4fe8a18 100644 --- a/popt/findme.c +++ b/popt/findme.c @@ -25,12 +25,23 @@ const char * findProgramPath(const char * argv0) if (path == NULL) return NULL; bufsize = strlen(path) + 1; +#if defined __TANDEM + start = pathbuf = malloc(bufsize); +#else start = pathbuf =