similar to: R 3.1.1 and 3.1.2 both fail their test suites

Hi, I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux distribution [1], but the build fails during the "make check" phase because of the following 2 issues: 1) The "tools" test in "tests/Examples" requires network access, which it doesn't have in our build environment. Therefore, it fails as follows according to

Duncan Murdoch writes: >> ./configure --without-recommended-packages && make && make check > > So you're getting paid to do what you do, but you want the volunteers > in R Core to do some work for you for free. You are jumping to conclusions. Nobody pays me a single cent to package R for Nix; I do that purely as a hobby. >> If no-one wants to make

I applied the patch Gene wrote here: https://github.com/triton/nixpkgs/commit/06e146b2ce5eaaa54ebea061dd5797f89ae2c37c The tree after that commit is entirely based on gcc5. In order to do a test with gcc4.9, I reverted: https://github.com/triton/nixpkgs/commit/8ccc1f121f379f4d66ce0a66f581c49d25fb4e15#diff-d7222640d82ff920625e9311d05a0137 and then built two images, one entirely based on gcc4.9

Hi Dirk, > I have been doing for R for about 20 years (if you count the time I > assisted Doug Bates when he was still the maintainer) (and longer for > Debian), and you seem to follow the same model we set up years ago of > splitting the content of r-recommended (itself a virtual package) off > r-base-core. > > You simply need to do this in stages. I have packaged

>>>>> Peter Simons <simons at nospf.cryp.to> >>>>> on Mon, 27 Feb 2017 10:30:39 +0100 writes: > Hi, I tried compiling the latest pre-release for R 3.3.3 > for the NixOS Linux distribution [1], but the build fails > during the "make check" phase because of the following 2 > issues: > 1) The "tools" test

Hi, Does anyone here have experience running Tinc on NixOS? I'm trying to run Tinc on a NixOS machine, using the similar configuration i had for Ubuntu. My home subnet is 192.168.1.0/24 and my work is 10.16.0.0/24. However, unlike ubuntu, when I start tincd on nixos, and try to 'ifconfig $INTERFACE 192.168.1.10 netmask 255.255.255.0' in my tinc-up, I loose network access on the box

Hi! I am running dovecot 2.1.16 on NixOS (http://nixos.org), and I have been fighting the dynamically loaded dovecot modules/plugins a bit. The problem is that in Nix/NixOS all packages are completely isolated from each other (each package has a separate /lib, /libexec, /bin etc, with only its own files in it). So dovecot has all its modules under

Hi, The recommended package matrix contains an empty file src/dummy.cpp which results in using g++ instead of gcc to link Matrix.so. What is the reason for that? Is there any difference between using g++ or gcc? (There are no other cpp files in the source) I asked the maintainers of the package (matrix-authors at r-project.org) 3 weeks ago but haven't received any answer. On my system (NixOS

Hi, I just tried to upgrade Nixpkgs to R 3.5.0, but unfortunately the new version fails its regression test suite. We configure the build using the flags "--without-recommended-packages", in case that's relevant. You can see a complete build log with all relevant information at [1]. Anyway, the test failures look like this: | make[3]: Entering directory

On 27/02/2017 09:30, Peter Simons wrote: > Hi, > > I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux > distribution [1], but the build fails during the "make check" phase > because of the following 2 issues: Hmm, R-devel (your subject line) is not a pre-release of R 3.3.3: it is 'R Under development' for what is planned as R 3.4.0.

I am trying to make Qemu agent work with libvirt thanks to https://github.com/NixOS/nixops/pull/922 with libvirt 4.1.0. I've been trying to make it work for quite some time but I still haven't the slightest idea of what is wrong, I keep seeing "Guest agent is not responding: QEMU guest agent is not connected" as the program I use (nixops) calls the libvirt python API. I

Hi all, I'm trying to understand why LLVM uses @rpath as the install name in its dynamic libraries on macOS. This complicates the process of linking against libLLVM from third-party tools and isn't nearly as common a practice on macOS as it is on Linux. I tried tracing through history on the LLVM repo and the main thing I could find was a commit from ages ago saying that the libraries are

Duncan Murdoch <murdoch.duncan at gmail.com> writes: > You can likely get rid of most of them by building with the recommended > packages. unfortunately, this is not an option for us. For various reasons, our build process requires that we build those packages separately. Ricardo appears to be in a similar situation and he has outlined some of those reasons already in his message.

https://bugzilla.netfilter.org/show_bug.cgi?id=1247 Bug ID: 1247 Summary: Module crash due to broken count Product: netfilter/iptables Version: unspecified Hardware: other OS: other Status: NEW Severity: blocker Priority: P5 Component: unknown Assignee: netfilter-buglog at

What is the purpose of supporting this "copy directories around" sort of build strategy anyway? At the end of the day, the way these packages get installed is via system package managers is independently, each project finding its dependencies with the standard prefix path. When I compile from source it's always like this: $ cd llvm-6.0.0rc2.src/ $ mkdir build $ cd build $ cmake ..

Anyone got a link to an older version of calibre, that I can install on CentOS 6? I see it wants python >= 2.7.6; we have a package we built at work, but that's 2.7.3.... mark

An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20230405/bc2e0ea7/attachment-0001.htm>

On 4/5/23 10:31, Aki Tuomi wrote: > Hi! > The crash occurs inside libldap. > Aki Thanks Aki, It was against openldap 2.6.3. Subsequently, I tried openldap 2.6.4 which is in nixpkgs unstable, but I wasn't able to test this because of an issue at the Portunus/openldap end of things. I think I'm out of time for experimenting with ldap for now, but I may come back around to this

On 23/04/2018 12:28 PM, Peter Simons wrote: > Hi Dirk, > > > I have been doing for R for about 20 years (if you count the time I > > assisted Doug Bates when he was still the maintainer) (and longer for > > Debian), and you seem to follow the same model we set up years ago of > > splitting the content of r-recommended (itself a virtual package) off >

On 23/04/2018 6:33 AM, Peter Simons wrote: > Hi, > > I just tried to upgrade Nixpkgs to R 3.5.0, but unfortunately the new > version fails its regression test suite. We configure the build using > the flags "--without-recommended-packages", in case that's relevant. You > can see a complete build log with all relevant information at [1]. > Anyway, the test