Re: Oops

Hi Nicklas, Thanks for your answer. Will definitely do during the upcoming weekend. Cheers, Vincent

Oops

Folks, I should definitely chime in, shouldn’t I. I’ve been through thick and thin lately, but I’m going to find time and update the ports I’m responsible for. Pinkie promise. Can just someone let me know what’s on my slate? Thanks a bunch Vincent

Re: Oops, apologies :/

Thanks Frank, For the time being I’m rebuilding my tree so as to be up to date. I’ll resume update ports as soon as I’m on top of things. Have a great weekend, Vincent

Oops, apologies :/

Folks, I’d like to apologise for being totally absent of late. I’ve had a pretty rough year 2022, but fortunately things are quieting a little now so I’ll be able to snatch some time back to look after my ports. Once again, I’m deeply sorry for the inconvenience I’ve caused. Happy new year to

Re: perl 5.34 branch

Hi Ryan, > Since perl has so many small modules that depend upon one another, it strikes > me as exceedingly difficult to manually come up with small batches of modules > that could be updated together. This is true, of course. However, in the case of ffmpeg, for example, I was able to

perl 5.34 branch

Folks, while trying to install ‘ffmpeg’ using perl5.34 as my base version, I stumbled on a slew of p5 ports which have not been updated to the 5.34 branch yet. I did that manually, and now I’m left in my private tree with more than a score of modified p5 ports. Shall I commit them? Thanks,

Re: Detecting Apple Silicon (vs. legacy Intel)

Hi Ryan, > If you were asking how to do this within a Portfile, yes, that's how you > would do it. However, note that we don't want any Portfile to use -march > flags, no matter what architecture, unless within a variant called "native", > since -march flags enable features specific to some

Re: Detecting Apple Silicon (vs. legacy Intel)

> On 31 Dec 2021, at 18:36, Chris Jones wrote: > >> I was wondering if there is a simple scheme to detect on which type of >> architecture MacPorts is running. My problem here is that clang on M1 does >> not honour the -march flag and exits with an error. > > if {${os.arch} eq "arm"} { > … >

Detecting Apple Silicon (vs. legacy Intel)

Folks, finally put my hands on my brand new MacBook Pro 14”! (Well, not really mine, rather my company’s, but let’s pretend…) I was wondering if there is a simple scheme to detect on which type of architecture MacPorts is running. My problem here is that clang on M1 does not honour the -march

Re: GitHub Sponsors

> On 13 Nov 2021, at 17:46, Mojca Miklavec wrote: > > I've been in favour of establishing a French non-profit org (1901). > We've had one for more than 10 years and there's nearly no overhead. > One needs a trustworthy representative person with an address in > France, at least a president and

Re: GitHub Sponsors

My lords, > On 10 Nov 2021, at 21:33, Perry E. Metzger wrote: […] You can also consider registering the MacPorts association outside the US, e.g. (I don’t toot my own horn, it’s just an example I’m familiar with) in France, associations are tax-exempt, and, barring the need of one local

perl 5.34 branch

My lords, is there any plan to add the 5.34 branch to all p5- ports? I’ve done it locally in order to install ffmpeg on my legacy MacBook, but I think it would be nice to generalise it. Have a great weekend, Vincent

Re: New project member: judaew

> Thank you, I am pleased to see these words. I'm pleased to be here. > It's my first message on the Mailing List. I hope I did everything right to > send the message. No worries. Welcome on board and lots of fun to come, I hope! Vincent

Re: upgrade to openssl 3.0.0

> On 5 Oct 2021, at 20:10, Daniel J. Luke wrote: > > I suspect if we wait, we'll just end up doing this same thing later - so > might as well get it over with now. The sooner we get to a state where > (mostly) things all work with the latest openssl, the better. Just my tuppence: While I

Re: Why does Texinfo explicitly depend on perl 5.30?

Hey Mojca, > My personal guess: no special reason other than trying to use a newer > version given that it was available. > It's a bit unfortunate if some ports use one version and others > another, but in particular 5.30 is already obsolete. Couldn’t the Portfile be modified in order to comply

Why does Texinfo explicitly depend on perl 5.30?

Well, all is said in the subject :) Cheers, Vincent

Shutting down the Atlas port

Guys, Atlas, the software meant to provide scientific computing tools with a high-performance assembly-based library has, IMHO, reached its end of life. My case is this: • Last developer (unstable) release is more than two years old; • Last stable release is twice older (2016); •

Re: Thoughts on switching our archive compression method

Ryan, > Maybe, but if we could use something built into macOS, like xz on 10.9 and > later, then we wouldn't need to bundle yet another third-party project (the > decompression program) into MacPorts base. Sure, but if the ultimate goal is to reduce disk size and bandwidth, then it can be

Re: Thoughts on switching our archive compression method

> (xz is 85% of bz2 size) > (xz is 70% of bz2 size) > (xz is 57% of bz2 size) > > So I think we could save ourselves and our mirror providers, CDN, and users > some disk space and bandwidth by switching to xz. bz2 was the best available > built-in compression on Mac OS X 10.6 when we started

Re: macOS 11 and Apple Silicon

> On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia > wrote: > > I just pushed some changes to base/master and dports/master to better support > macOS 11 and Apple Silicon, but there's quite a bit of work ahead of us. […] > Please reach out if you have any questions or concerns. We’re

Re: Proper value for os.arch on Apple Silicon

Ryan, > Now that Apple has announced that Macs will have ARM processors [1], what is > the proper value for ${os.arch} on such systems? It should be noted that, apparently (I didn’t follow the keynote), the Apple staff never referred to the new arch as “ARM”, but used “Apple silicon”. So why

OpenCL and sqlite3 incompatibilities

Folks, Just to inform you, after digging into this, that the legacy OpenCL framework some ports may use and Macport’s sqlite3 are incompatible. The OpenCL framework, as farfetched as it seems, pulls in the system provided /usr/lib/libsqlite3.dylib, which causes, if Macport’s sqlite3 is also

Re: trying to understand the --no-exec activate option (on by default?)

> That warning only prints during an install or upgrade (when the runtime dep > is not active). > > The default for this option should be OFF IMHO; there are also ports which do > important things in the post-activate; the lldb ports remind the user that an > executable needs to be

Re: Xcode configuration woes

Chris, > On 21 Nov 2018, at 10:12, Chris Jones wrote: > Do as you like, but I suspect /usr/include being missing is not a bug but > intentional. I didn’t mean that. I mean the fact that when /usr/include exists, it is filled with outdated include files. Vincent

Re: Xcode configuration woes

Oops, also: >> Ok, I set configure.sdkroot and it worked fine now. Should I commit it with: >> >> if {${os.platform} eq "darwin" && ${os.major} == 18} { >> configure.sdkroot … >> } >> >> ? > > > If this code only gets compiled on 10.14, then that would work. But do you > think (or have

Re: Xcode configuration woes

Ryan, Did you file a bug report with Apple w/r to that, or do you want me to go ahead? > I've updated the buildbot machine, and it also still doesn't have > /usr/include. But I also haven't installed the command line tools there. > Maybe if I did that, /usr/include would now show up. Vincent

Re: Xcode configuration woes

Ryan, > Unless you do have /usr/include on your system. Do you? For users who have > installed /usr/include using the hidden installer package, you might need to > have the port set configure.sdkroot to the path of the SDK, even when > MacPorts wouldn't otherwise have done so. Ok, I set

Re: Xcode configuration woes

Ryan, > I don't know why Apple is doing this to us. This contradicts what we > previously knew about how SDKs were meant to function. The SDKs are supposed > to be the same as the system headers of a particular version. We may want to > file a bug report with Apple about this. Maybe then they

Re: Xcode configuration woes

Chris, > On 9 Nov 2018, at 21:12, Chris Jones wrote: > >> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, >> the production release. >> Also that doesn’t explain why the headers in /System/Library/Frameworks are >> one version behind… > > I disagree. You are

Re: Xcode configuration woes

Chris, > > Isn't it obvious ? Beta releases are more likely to have problems… I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release. Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind… V.

Re: Xcode configuration woes

>> Weird, no? > > Not necessarily. You are running beta versions. Anything is possible. > > Do you really need do this ? Wouldn't switching to the production version not > make sense now ? How do you mean? V.

Re: Xcode configuration woes

Ryan, > Yup, NSAppearanceNameDarkAqua is new in macOS 10.14. […] > So you must be on macOS 10.13 with Xcode 10. Unfortunately not : > uname -a Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64 As you can see, I

Xcode configuration woe

Folks, I try to update QGis to 3.4.1, and stumble on that compilation error: — /opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:18: error: property 'effectiveAppearance' not found on object of type '__kindof NSApplication *'

Re: Merging pull requests before 72 hours

> That's one of things our existing 72-hour timeout period is for. It's not > specific to patchfiles; it's for any issue that the maintainer hasn't > responded to. Okay, thanks Ryan :)

Re: Merging pull requests before 72 hours

> On 22 Oct 2018, at 06:32, Ryan Schmidt wrote: >> And yes, we have a huge number of people assigned as maintainers who >> no longer maintain the ports. We really need to clean up the list in >> order to reflect the reality. > > It is indeed a problem that we have many ports which claim to be

Launchctl script

Folks, I’m currently writing a Portfile for Strongswan, the IKEv2 VPN client/server. I’d like the demons ipsec and charon to be launched through launchctl. Is there a way to automatically write the required script, or must I do that by hand? Thanks a bunch, have fun everyone Vincent

Re: Adding a Code of Conduct to MacPorts

> On 28 Sep 2018, at 03:52, George Plymale II > wrote: > > Linux is arguably "capsizing" right now, to some extent. The drama > that's going on, between threats of lawsuits, possible forks, and > kicking out longtime leaders in the project... well, I'd say that > "capsizing" is perhaps an

Re: Adding a Code of Conduct to MacPorts

> In my experience, we in MacPorts-land don't have the obvious Linux issue. I > hope others don't experience the MacPorts project (developers, users, > commenters) as abusive in any medium (email lists, tickets / issues, PR's, in > person, whatever). - MLD In my experience :), when a project

Re: 2.5 and cxx_stdlib

Josh, > Not sure how you ran into that. Installing the new version of base must > be done as root as well, and it runs scripts that open the registry and > should trigger that upgrade. Transcript from my terminal: Air > sudo port selfupdate ---> Updating MacPorts base sources using rsync

Re: 2.5 and cxx_stdlib

> Just a reminder that MacPorts 2.5 will check whether ports are built > against the right C++ standard library as part of rev-upgrade. The Also, as part of this new check, a column is added to the registry, so please be sure to run a first ‘port outdated’ or whatever using sudo, otherwise you

Re: [MacPorts] #55764: geoexpress-sdk @9.0.0.3864: upgrade to 9.5.4.4709

Hi, > On 25 May 2018, at 16:47, Ryan Schmidt wrote: > On May 25, 2018, at 08:54, Rainer Müller wrote: >> >> We already have ports with other restrictive licenses in the tree, even >> closed-source software. Set the license option accordingly and make sure >> we are

Re: [macports-ports] branch master updated: gdal: more cleaning up

Ryan, > This should be: > > if {[string match *clang* ${configure.cxx}]} { > configure.ldflags-append -stdlib=${configure.cxx_stdlib} > } > > Only clang understands the -stdlib flag, but you always want to use it, > regardless of what the C++ stdlib is. I’ve changed that in the newest

Re: [macports-ports] branch master updated: qgis3: bump to 3.0.3

> Yeah, apparently there’s only one version of QT installable at a time. It was > part of an experiment, and I forgot to remove it. I’ll do it straight away. > Thanks. Done. Anyway, the purpose of this variant was to explore if the recurrent crashes were caused by using Qt 5.10 as opposed to

Re: [macports-ports] branch master updated: qgis3: bump to 3.0.3

On 22 May 2018, at 13:42, Ryan Schmidt wrote: > > > On May 22, 2018, at 04:40, Vincent wrote: >> +variant qt59 description "Build with qt59" { >> +depends_lib-delete port:qt5-qtwebkit \ >> +port:qt5-qtscript \ >> +

Re: [macports-ports] branch master updated: charls: initial commit

> Ah, it's because you specified the GitHub project name as "charLS" but the > project name is actually "charls". Fix this in the github.setup line, and > then you can remove the unnecessary name and worksrcdir lines. Right. Changed it and committed again. Thanks a bunch. Yeah, the message is

Re: fltk-devel has non-numeric revision

> Version can contain non-numeric characters, but revision must be an > integer. The qt59 portfile is extremely complicated, but qt59-qtwebkit > seems to have a revision of 1 for me, so check for local changes perhaps? Ok, gotcha. I had introduced an extra line in the qtwebkit subpart before the

Re: fltk-devel has non-numeric revision

In fact, the culprit is this: Air > port installed | grep qt59-qtwebkit qt59-qtwebkit @5.9.1_1 qt59-qtwebkit @5.9.1_overrides: (active) Any idea what can cause this? V.

fltk-devel has non-numeric revision

Hi there, the latest version of ftlk-devel is “1.4.x-r12914”. The “x” here causes the following error in “port outdated”: “process_cmd failed: can't use non-numeric string as operand of "-"”. Somehow base compares versions using a subtraction, and of course it can’t do that if there are

Re: Qt5 port group

Sorry to chime in back so late, I had several hiccups with my mail lately, and most (if not all) of your messages simply remained in transit until today. As far as I have experimented, a single version of Qt is allowed to be installed. Fair enough. I’ve rewritten the Qgis3 port introducing a

Qt5 port group

Hi there, I was in the process of modifying the Qt5 Port group to allow for choosing the Qt version one wants to link an application against using variants. However, before I go further, I’d like to know if concurrent installations of different Qt5 versions are supported in MacPorts. If not,

Re: Using qt59 instead of qt5 (latest release)

Hey Craig, > I am considering a similar move for mythtv.28. […] Thanks for that useful info. French has a saying which goes like this (more or less, it’s difficult to translate): “The best is oftentimes the good’s enemy”. In any case, yeah, I suppose this will mean at least writing variants.

Using qt59 instead of qt5 (latest release)

Hi there, I recently wanted to experiment with linking one of the ports I maintain (Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the glitches and crashes everyone experiences with that application. However, in order to do so, I’d have to rebuild several dependents

Heads-up: PROJ

Hey there, I’m going to commit a major overhaul to the “proj” port. Currently, “proj” is split between proj47 and proj, the latter corresponding to proj 5.0.0 recently released. The problem is this: • Proj 5.0.0 is buggy, unusable at least with QGis until a bugfix version is out; • Proj and

Re: 10.13 builder on our BuildBot is failing

Ryan, > as suggested in the thread. Thanks for pointing me toward it! Glad to know it worked. Have a great day!

Re: 10.13 builder on our BuildBot is failing

Ryan, so what was the problem? Vincent

Re: 10.13 builder on our BuildBot is failing

Ryan, > Granted we're running VMware ESXi on it and the VMs are seeing VMware's > emulated graphics card, but everything was working before it unaccountably > blew up. I’d say that before you stumble on a problem generally everything works fine. :P That being said, there was a hack listed

Re: 10.13 builder on our BuildBot is failing

Maybe that can help? https://www.tonymacx86.com/threads/macos-high-sierra-ioconsoleusers-gioscreenlockstate-3-hs-0-bs-0-now-0-sm-0x0.234731/

Re: 10.13 builder on our BuildBot is failing

> On 11 Jan 2018, at 16:36, Ryan Schmidt wrote: > > IOConsoleUsers: time(0) 0->0, lin 0, llk 1, > IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0 > Looks like a video issue? Vincent

Re: 10.13 builder on our BuildBot is failing

Ryan, > It does not seem to boot up correctly now. The black startup screen with > white Apple logo and progress bar filled all the way in never disappears. I'm > not certain if all the usual services have started up correctly. > > I can ssh in. I deactivated all the ports that had been left

Re: Python 2.7 – allow another db version beside 4.8

On 25 Dec 2017, at 20:30, Jan Stary wrote: > Generally, I tend to let the port/package use any version, > unless there is a specific reason for some specific version. > For example, if a port requires Python, then I consider > _any_ installed python to satsfy this requirement, >

Re: Python 2.7 – allow another db version beside 4.8

Folks, happy Xmas to all! > On 24 Dec 2017, at 11:23, Jan Stary wrote: > >> On Dec 24 05:19:35, j...@macports.org wrote: >>> On 2017-12-24 04:28 , Clemens Lang wrote: >>> Is there a reason to not just always use a newer version? >> And to turn the question around, what is gained

Python 2.7 – allow another db version beside 4.8

Hi there, I’ve a made a private change to my python27 Portfile to allow it to use DB60 instead of the default DB48, which was installed only for its needs. I think allowing people (through a variant) to build a Python 2.7 version which relies on another version of DB would be nice. Happy Xmas

QtKeyChain

Hey Mac-mavens, could someone add the aforementioned software to our plethoric but not enough collection of coddled ports? Or shall I proceed on my own? Thanks and enjoy the weekend! Vincent

Re: Cmake, Xcode 9, MacOS 10.13 and utimensat

Hi Ryan, > cmake likes to compile using the macOS SDK in Xcode, even when that's not > needed. What version of macOS SDK is in Xcode 9? I would not be surprised if > it contains a macOS 10.13 version of the SDK, and that utimensat is new in > macOS 10.13, and that there is a bug in the SDK

Cmake, Xcode 9, MacOS 10.13 and utimensat

Guys, I’ve been installing the new Xcode 9 (beta) and upgrading my ports. Cmake got bumped to 3.8.2 Then, a couple of ports onwards, I got this error: > dyld: Symbol not found: _utimensat > Referenced from: /opt/local/bin/cmake > Expected in: /usr/lib/libSystem.B.dylib Rolling back to the

Re: Why does libunistring depends on texlive?

Josh, thanks for the pointer. What I’ll do (since texlive seems to be required only to build the doc) is to add a doc variant that will pull the dependencies in but only when required. However, I’m not sure how to build the docs :) So I guess I’ll have to dredge a bit deeper. Thanks again,

Why does libunistring depends on texlive?

Folks, I was in the process of upgrading ffmpeg when I suddenly jumped out of my chair: the build was trying to pull in the bloated texlive source. I traced that spurious dependency to libunistring. Commenting out the dependency on texlive-basic does not produce any side effect (AFAIK): the

LLVM/CLANG enable specific targets with varants

Folks, I’ve always wondered what’s the point in letting LLVM/Clang ports build all possible CPU targets. Some of them are really obscure, and I don’t think the commoner needs them (e.g. Hexagon). So I think, given the extra time needed to compile all those superfluous targets, it’d be a nice

Packaging an app

Folks, I’m trying to create a redistributable binary of grass7. I just read the relevant webpage on the Macports website. Questions: • How to choose a suitable prefix? Any heuristics? Just a shot in the dark? • Must I recompile everything from source, or can I use binaries? Thanks! Vincent

Re: [macports-ports] branch master updated: grass: jump to 7.2RC2 (dubbed 7.1.99.2)

Ryan, sorry I didn’t see this before: >>grass: jump to 7.2RC2 (dubbed 7.1.99.2) > > Does upstream also refer to 7.2.0RC2 as 7.1.99.2, or is that something you > made up? If the latter, why? No, upstream’s name is RC2. But 7.1.99.2 would easily upgrade to 7.2.0 when it is released,

Re: Apache 24 woes

Hi Marius, thanks for answering. > He has expressed that he is no longer interested in putting in the effort to > make apache 2.4 the default (some work is needed, as apache2.4-devel has a > different directory structure than apache2 (2.2)). Okay. > Two questions: > > 1) why do you want to

Apache 24 woes

Folks, I’ve a problem on a website I look after and I’m trying to replicate the configuration locally on my Mac to ease debugging. So I’ve installed apache24 and stumbled on the following roadblocks or hitches: 1. Why is apache24 still called “apache24-devel”? 2. APR-UTIL should: a.

git question (ignoring a private patch)

Folks, I have a private version of the llvm-3.9/Portfile (I just narrowed down the targets to PowerPC and X86 rather than build everyone of them which squanders time). But now I can’t git pull —rebase, I get an error message. Of course I have no intention to commit that private patch. How can