similar to: Mac OS Mavericks über slow

Ralph B?hme writes: > > >Samba 4.2 will ship a new VFS module that addresses this: > > >vfs_fruit. It stacks with vfs_streams_xattr but takes care of the > > >resource fork stream itself (on Linux: by saving it to a ._ > > >AppleDouble file). > > > > I can confirm that with Samba 4.2.0rc2, with vfs_streams_xattr > > and vfs_fruit the time it

I'm trying to help someone to troubleshoot possible OSX Yosemite issues, but I've only got access to OSX (< 10.9) so I cannot check myself. When building/installing binary R packages, there are different binaries depending on OSX version. For instance, CRAN provides different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', e.g.

Dear List, I've realized that the "CRAN Checking Package" system returns some Warnings for my package TR8 under "r-release-osx-x86_64-mavericks"; all the warnings include the following message "Invalid MIT-MAGIC-COOKIE-1 key" which I find a little cryptic. After some web searches, I understood that "MIT-MAGIC-COOKIE" is related to the X server and

Dear mac folks, I have started porting a large legacy toolset maintained in windows and heavily mpi laden so it can be used across platforms in R... so I am building a package out of it. On this note, I am noticing that almost all of the mpi dependent packages do not compile on the CRAN repositories.... with the basic issue that it appears it can not find mpi installed: configure: error:

We run a dovecot mailserver. One of the clients I use is a Mac Laptop. Recently I upgraded from Mountain Lion (10.8) to Mavericks (10.9). Under 10.8 it worked fine. On 10.9 it syncs up when I invoke the client, but after a while stops getting updates. Most of my mail clients are on Linux (thunderbird) or Android (K9) and I admit that several run against my very large INBOX simultaneously. The

hello I maintain the gsl R package, and many users have recently reported that the package does not install from source under macosx 10.9 ("mavericks"). Users typically install the gnu GSL library and are able to compile and run a small "hello world" program which executes some of the Bessel functionality of the library; but under mavericks the configure script (which uses

Another posting in german, due to its subject, which has to do with the german translation of the Samba-3.0-documentation. --- Hallo, deutschsprachige Samba-user, die ?bersetzung der Samba-3-Dokumentation geht weiter. Die Info-Kampagne tr?gt Fr?chte, es gibt neue freiwillige Mitarbeiter! Unsere Projektseite liegt auf Berlios, eine kurze Projektbeschreibung findet man unter

I just checked your package on a mavericks VM and it seems fine, so I wouldn't worry about it. Probably some configuration issue on the CRAN server, perhaps xquartz is outdated. Unfortunately there is no easy way anymore to check on Mavericks. Travis used to support it, but they have deprecated mavericks (along with Apple and homebrew). Hopefully CRAN will update to the current MacOS for the

R.framework-Versions-Resources-library-grDevices-libs-cairo_20150120.tgz in http://sourceforge.net/projects/outmodedbonsai/files/R/ are dropped in replacement to the cairo.so's in the official R binaries (2.15.3, 3.0.3, 3.1.2). updated to cairo-1.12.18 and freetype-2.5.4. The official R binaries' were built with early freetype 2.4.x and cairo 1.11(?) and had a number of issues with some

[redirecting to nut-upsuser since we hardly use the packaging list anymore] On May 15, 2014, at 9:20 AM, Jose Vigil wrote: > Hi friends, > > I?m looking for an already compiled .pkg NUT Client to be installed in a Mavericks iMac. Can someone, please point me to place where I can find it? We don't have any official ones. If anyone else has compiled one, please feel free to share

Hi R-devel, I'm noticing the following behaviour: writeLines("#include <Rcpp.h>", file = "test.cpp") Rcpp::sourceCpp("~/test.cpp") ## succeeds at trivial compile Sys.setenv("USE_CXX1X" = "yes") Rcpp::sourceCpp("~/test.cpp") ## fails; CXX nor CXX1X properly set (?) IIUC, R is not propagating CXX nor CXX1X when

New to sshfs and new to this mailing list so please guide me if required. Is this a bug? When sshfs is given option -o rellinks, it responds with fuse: unknown option `rellinks' According to my understanding of the sshfs man page and --help output this option a) is valid and b) should be passed to the module, not to fuse. Versions: SSHFS version 2.4 FUSE library version: 2.8.5

On Sat, Nov 22, 2014 at 07:05:11PM +0300, Vladimir "Equidamoid" Shapranov wrote: > I've got the following error when tried to compile tinc-1.0.24: [...] > Undefined symbols for architecture x86_64: > "_res_9_init", referenced from: > _main_loop in net.o > ld: symbol(s) not found for architecture x86_64 > > The symbol is exported in

The windows replacement is R-library-grDevices-libs-winCairo_20150122.zip in http://sourceforge.net/projects/outmodedbonsai/files/R/ The cairo replacements are just two bundles, windows or OS X - containing replacements for R 2.15.3, 3.0.3 and 3.1.2. You just extract the relevant one for your R version. The windows builds of R packages snpStats x.x.x.8 and snpMatrix 1.19.0.20 were done with

Hi, I've got the following error when tried to compile tinc-1.0.24: gcc -g -O2 -pie -L/opt/local/lib -o tincd avl_tree.o conf.o connection.o dropin.o dummy_device.o edge.o event.o fake-getaddrinfo.o fake-getnameinfo.o getopt.o getopt1.o graph.o list.o logger.o meta.o multicast_device.o net.o net_packet.o net_setup.o net_socket.o netutl.o node.o pidfile.o process.o protocol.o

Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when

https://bugzilla.samba.org/show_bug.cgi?id=9783 Summary: please don't use client-server model for local copies Product: rsync Version: 3.0.9 Platform: All URL: http://lwn.net/Articles/400489/ OS/Version: Linux Status: NEW Severity: enhancement Priority: P5 Component: core

Hi, after trying sshfs to mount a remote file system on a server with the result that sshfs will sooner or later get stuck and require a reboot of the client, I'm fed up with it and am looking for alternatives. So next I would like to use NFS over a VPN connection instead. To minimize the instances of the NFS mount getting stuck, it might be helpful to use autofs. What happens when the

On Tuesday, May 19, 2020 1:36:03 AM CEST Warren Young wrote: > On May 18, 2020, at 5:13 AM, hw <hw at gc-24.de> wrote: > > Is there a better alternative for mounting remote file systems over > > unreliable connections? > > I don?t have a good answer for you, because if you?d asked me without all > this backstory whether NFS or SSHFS is more tolerant of bad

Hi there I am wanting to call sshfs (auth via DSA keys) via a rsync pre-xfer bash script, and cannot get something right. If I run it from the cmdline line: env - sshfs usern@server:/share /dir/path -o -o IdentityFile=/tmp/id_dsa it mounts it just fine. (note the "env -" - I specifically tested with no environment to try to make the two situations identical). If I put that sole line