similar to: Problem building R-3.2.4

On 10 March 2016 at 08:51, Mick Jordan wrote: | I am trying to build R-3.2.4 on an Oracle Enterprise Linux system, where | I have previously built R-3.1.3 and predecessors without problems. I ran Well that is pretty much why R Core asks us to build early, and build often. | "./configure --with-x=no" ok. The make fails in src/extra/xz with what | looks like a Makefile problem: | |

I have lzma installed (in /usr/local) but R-3.3.0 configure doesn't like something about it: checking for lzma_version_number in -llzma... yes checking lzma.h usability... no checking lzma.h presence... no checking for lzma.h... no configure: error: "liblzma library and headers are required" bash-3.2$ ls /usr/local/lib/*lzma* ls /usr/local/lib/*lzma* /usr/local/lib/liblzma.5.dylib

On 2015-11-04 17:31, aixtools wrote: > On 2015-11-04 16:51, aixtools wrote: >> On 2015-10-15 15:02, Prof Brian Ripley wrote: >>> On 15/10/2015 13:32, Michael Felt wrote: >>>> Hi. >>>> >>>> Just wanted to let you know I am getting close to packaging R for >>>> AIX in >>>> 64.bit mode. >>> >>> Which

On 3/10/16 9:22 AM, Dirk Eddelbuettel wrote: > > > The same issue was already reported (and resolved) in the bug tracker earlier > today. All this is due to 'most systems' using their system lzma (so the > issue was not tickled in eg all the Debian and Ubuntu builds we do) but you > here do not -- and hence got bitten by a Makefile typo. > > Just fix it locally to

Dear R People: I'm trying to compile R-2.15.0 on a 64 bit Windows machine. However, I'm getting the following error: c:\R64\R-2.15.0\src\gnuwin32>set TMPDIR=c:\temp set TMPDIR=c:\temp c:\R64\R-2.15.0\src\gnuwin32>make all recommended make all recommended make[1]: `MkRules' is up to date. make[4]: Nothing to be done for `svnonly'. installing C headers make[2]: Nothing to

hello my server is centos 6 64 bit while installing dovecot i get this error Failed to run: ./test-compression what could be the reason. could someone guide me please Version dovecot-ce-2.3.0-1 0 / 7 tests failed ==21130== Conditional jump or move depends on uninitialised value(s) ==21130== at 0x349B00ACB2: ??? (in /usr/lib64/liblzma.so.0.0.0) ==21130== by 0x349B00AEA9: ??? (in

On 2015-10-15 15:02, Prof Brian Ripley wrote: > On 15/10/2015 13:32, Michael Felt wrote: >> Hi. >> >> Just wanted to let you know I am getting close to packaging R for AIX in >> 64.bit mode. > > Which version? (You mentioned 3.1.3 and 3.2.2 far below.) There is > little value in reporting on frozen branches, and most value in > reporting on R-devel where

Hi All, I am compiling R-devel on Linux (Ubuntu 16.04.2) and that works just fine, but I am missing some of the expected features, as shown here: https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Linux In particular, after configure (using all defaults), I see: R is now configured for x86_64-pc-linux-gnu [...] Interfaces supported: X11 External libraries:

Hello all, I'm trying to build R 32bit from source in a Windows 64 machine. I have followed the steps in "R Installation and Adiministration" ( http://cran.r-project.org/doc/manuals/R-admin.html#Getting-the-source-files) or at least I think I did everything described. I am not sure if I have installed the libjpeg, libtiff and libpng files though. I have upzipped them in the

v2: - Fixes a number of bugs in corner cases. - Uses a 1M block size to fetch from the underlying plugin. This improves performance considerably. I also tested this much more thoroughly and can't find any more bugs. Rich.

Matt asked if xz should really be a filter rather than a plugin. The answer is yes, of course it should be! That's been something in the todo file for a while. The commit converts the xz plugin code into a filter (leaving the plugin around, but deprecating it). plugin: nbdkit xz file.xz filter: nbdkit --filter=xz file file.xz plugin: # can't be done filter: nbdkit

Updated my R install on my GNU/Linux boxes (running CentOS 6.8) from 3.2.x -> 3.3.0, using latest from epel (i.e., not compiling from source), and while said upgrade seemed to go fine, am now (post-upgrade) having all sorts of problems with getting some (but not all) packages to compile (either during an initial install attempt, or upgrade to existing packages). For example, if I try to

On 2015-11-04 17:46, aixtools wrote: > On 2015-11-04 17:31, aixtools wrote: >> On 2015-11-04 16:51, aixtools wrote: >>> On 2015-10-15 15:02, Prof Brian Ripley wrote: >>>> On 15/10/2015 13:32, Michael Felt wrote: >>>>> Hi. >>>>> >>>>> Just wanted to let you know I am getting close to packaging R for >>>>> AIX

>>>>> peter dalgaard <pdalgd at gmail.com> >>>>> on Sat, 12 Mar 2016 19:11:40 +0100 writes: > OK, .Internal is not necessary to reproduce oddity in this area. I also see things like (notice 1980) >> strptime(paste0(sample(1900:1999,80,replace=TRUE),"/01/01"), "%Y/%m/%d", tz="CET") ............... >

Hello, the included XZ Utils source code contains an incorrect use of the restrict keyword. This leads to data corruption under certain circumstances. For a short discussion of the problem see http://sourceforge.net/projects/lzmautils/forums/forum/708858/topic/3306733 This was fixed in the XZ Utils git repository in commit commit 49cfc8d392cf535f8dd10233225b1fc726fec9ef Author: Lasse

This is definitely obscure but we had a unit test that called .Internal(strptime, "1942/01/01", %Y/%m/%d") with timezone (TZ) set to CET. In R-3.1.3 that returned "1942-01-01 CEST" which, paradoxically, is correct as they evidently did strange things in Germany during the war period. Java also returns the same. However, R-3.2.4 returns "1942-01-01 CET".

Hi! We appreciate the feedback we have received from everyone, and we have discussed it internally. The features we are removing are deprecated and should not have been used anymore. They all have alternatives that work equally well if not better. For the authentication drivers, you can use passwd, pam and Lua as replacements for most of them. Lua in particular allows good integration with just

Hello, Just wondering: Dovecot has gzip/bzip2 compression/decompression support. According to this: http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_lzma_vs_lzma2-xz_benchmark_reloaded gzip and bzip2 aren't really useful together. While gzip can offer speed and a reasonable amount of compression ratio, bzip2 is slow, especially on decompression, which Dovecot does

Hello, many linux SW is starting to implement new lzma compresson instrad of old zlib (gzip) od bzip2. lzma is default comrpession in very good compression SW 7-zip, which is faster and have higher compression ratio then bzip2 or rar. Currently its probalby the best compressor in therms of compression and decompression speed / compression ratio. In linux there is GNU lzma SW which implements

The 3.2.4 release had two annoyances which we would rather not have in an "ultra-stable" release, designed to hang around for the duration of the 3.3 series. One was a relatively minor Makefile issue affecting system using R's bundled lzma library. The other, rather more serious, affected printing and formatting of POSIXlt objects, which would unpredictably get the Daylight Savings