similar to: LZMA2 (xz) support for Dovecot?

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

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

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

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 "./configure --with-x=no" ok. The make fails in src/extra/xz with what looks like a Makefile problem: liblzma.a: $(liblzma_a_OBJECTS) $rm -f $@ $(AR) -cr $@ $(liblzma_a_OBJECTS) $(RANLIB) $@ What I see in the make log is:

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

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

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

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

Hi, I am having trouble compiling R-2.10.0 on the Solaris x86_64 platform using the native solaris-studio cc/F99 compilers. I am pretty sure that I have all my environment set up for a 64-bit compile. However, when doing a make I get the following error: /opt/solstudio12.2/bin/cc -m64 -I./api -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -KPIC -xO3 -c

I was wondering if someone with more familiarity with MC on X86 could consider looking into adding support for the hyphenated versions of the VIA Padlock instructions? If anyone is up for it there are details within these two bug reports.. http://www.llvm.org/bugs/show_bug.cgi?id=8556 http://www.llvm.org/bugs/show_bug.cgi?id=10266 -- This message has been scanned for viruses and dangerous

Hello! I'm trying to install R-patched from source on a Windows 64 bit laptop. I have installed R-tools 2.16 and set up the jpeg, tiff, and libpng files Here is the output: c:\R64\R-patched\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 be done for

On Wed, Jan 16, 2013 at 12:04:52PM -0500, Stephen Checkoway wrote: > > On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > > > I was wondering if someone with more familiarity with MC > > on X86 could consider looking into adding support for > > the hyphenated versions of the VIA Padlock instructions? > > > Take a look at

Hi, I tried to compile R-2.10.0 src on 64 bit window. After install Rtools and wingw-w64 compiler and put it the first of my PATH variable, but i got the following error when i tried to compile. Anything I missed? thank you. x86_64-w64-mingw32-gcc -std=gnu99 -I../include -I. -I../extra -DHAVE_CONFIG_H -D R_DLL_BUILD -O3 -Wall -pedantic -DR_ARCH='"x64"' -c malloc.c -o

flight 9061 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9061/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9054 test-i386-i386-pv

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

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

*All boxes are EL6 x86_64, fully up to date* Updated to R 3.3.0-3 recently, however just yesterday I tried to update a couple packages for a user and noticed almost nothing would build. I was (am) getting the same build errors as another previously posted (https://stat.ethz.ch/pipermail/r-sig-fedora/2016-June/000452.html). I watched over the bodhi page for the issue and noticed 3.3.0-5 was

R fails to build with visibility on and gcc 4.9's link time optimzation, because of its practice of building part of it as archive first. Specifically it builds some bundled libraries as archive first, the symbols of which are then entirely invisible in gcc 4.9. The Matrix package also does this awful practice, with CHOLMOD.a COLAMD.a AMD.a SuiteSparse_config.a . One way of fixing R is: