Re: faust-devel
> On 29 Jun 2020, at 16:06, Ryan Schmidt wrote: > > > > On Jun 28, 2020, at 12:24, rmgls wrote: > >> here is what i get: >> >> fetching distfiles for faust-devel >> >> and nothing else! > > How long did you wait? Unlike most ports, this one fetches from a git > repository. There will be no progress bar or any other output while the > download happens. In the current version, it fetches 625MB of data. That may > take some time if your network is slow. My network is fairly fast so it only > took a minute. > a long time! the download did not start at all. > the version is apparently really old. >> >> faust version is 2.14.4 on their site >> (there is a binary package too). >> can we upgrade? > > Probably. I haven't touched these ports in awhile. There is another > maintainer but he hasn't been active lately either. Would you file a ticket > in our issue tracker requesting this update? Or if you're feeling adventurous > you can try to do the update yourself and submit a pull request to us. > i will try to see, if i am too stuck, i will put a ticket. Thanks Rayan. Raoul rm...@orange.fr
Re: rsync upgrade to 3.2.1_1 and libressl
On Jun 29, 2020, at 02:52, Ryan Schmidt wrote: > On Jun 29, 2020, at 00:58, Christopher Chavez wrote: >> >> I'm not sure it applies here, but the pattern being applied to other >> ports is to replace port:openssl with path:lib/libssl.dylib:openssl, so >> as to allow using LibreSSL but fallback to installing OpenSSL if neither >> is already present. > > Since the user even verified that it builds fine with libressl, yes, that's > what should be used here. > > Until we handle libressl and openssl separately as we should (see ticket), > Portfile authors should assume that libressl will work as a replacement for > openssl in their ports and use the above syntax. Only if it can be shown that > libressl is not compatible and if no patch to fix that can be found should it > be changed to port:openssl. In that case, add a comment with a link to the > upstream bug report or discussion. Fixed: https://github.com/macports/macports-ports/commit/bb1e0a790af0e7303ca36de8f1be2dc00f26b62b In the future, please file bug reports in the issue tracker.
Re: faust-devel
On Jun 28, 2020, at 12:24, rmgls wrote: > here is what i get: > > fetching distfiles for faust-devel > > and nothing else! How long did you wait? Unlike most ports, this one fetches from a git repository. There will be no progress bar or any other output while the download happens. In the current version, it fetches 625MB of data. That may take some time if your network is slow. My network is fairly fast so it only took a minute. > the version is apparently really old. > > faust version is 2.14.4 on their site > (there is a binary package too). > can we upgrade? Probably. I haven't touched these ports in awhile. There is another maintainer but he hasn't been active lately either. Would you file a ticket in our issue tracker requesting this update? Or if you're feeling adventurous you can try to do the update yourself and submit a pull request to us.
Re: Noah port (and alternatives?)
On Jun 28, 2020, at 16:08, Ces VLC wrote: > I'm looking for a Linux user mode emulation on Mac, and I just found Noah on > github, and then realized there's already a port for it. From what I've read, > it seems it's quite experimental (BTW: there were some merged PRs a few days > ago, that are not included in the 0.5.1 tag that the port is downloading > right now). That's undoubtedly true for most software projects: their developers make improvements to them, and after a time the developers decide that the work they've done is ready to be made available to users and they make a new release. When they do, we'll update the port. > Said this, do you know of any other attempt at Linux user-mode emulation on > Mac, or is Noah the only project you've seen about this? (note that qemu has > user mode emulation, but, AFAIK, it requires the host system and the guest > system to be the same, making it useful only for running binaries for other > architectures in the same OS). > > If you don't know of any other alternatives or attempts, maybe I should > consider improving Noah, but I'd prefer not to reinvent the wheel... I'm not aware of any alternatives but I haven't looked for any either. I added the noah port to MacPorts in the hopes that it would spur interest and maybe increased development activity. We found that the developer of noah had been hired by Microsoft to implement a similar feature in Windows, which might explain why the open source version that works on macOS has not gotten much attention. If the original developer no longer has interest or time to work on the software or is under an NDA from their employer that prevents them from doing so it may need to be forked and continued by a new interested developer.
Re: libffi
Curtis Matz wrote: > I’ve installed libffi but I’m trying to compile and it says it can’t find > ffi.h. How do I tell my compiler which happens to be gcc9 to look in > /opt/local for the header file? > >> port installed | grep libffi > libffi @3.2.1_0 (active) > > src/rtlib/thread_call.c:33:10: fatal error: ffi.h: No such file or directory >33 | #include > | ^~~ > compilation terminated. > make: *** [src/rtlib/obj/darwin-x86_64/thread_call.o] Error 1 This is the problem pkg-config was designed to solve. Compile with `pkg-config --cflags libffi` and link with `pkg-config --libs libffi`. It happens that libffi doesn't put its header directly in /opt/local/include, but pkg-config knows that so you don't have to. - Josh
Re: rsync upgrade to 3.2.1_1 and libressl
On Jun 29, 2020, at 00:58, Christopher Chavez wrote: > > I'm not sure it applies here, but the pattern being applied to other > ports is to replace port:openssl with path:lib/libssl.dylib:openssl, so > as to allow using LibreSSL but fallback to installing OpenSSL if neither > is already present. Since the user even verified that it builds fine with libressl, yes, that's what should be used here. Until we handle libressl and openssl separately as we should (see ticket), Portfile authors should assume that libressl will work as a replacement for openssl in their ports and use the above syntax. Only if it can be shown that libressl is not compatible and if no patch to fix that can be found should it be changed to port:openssl. In that case, add a comment with a link to the upstream bug report or discussion.
