[Meta-bug][WONTFIX] Please resolve OSX packaging situation

[LebedevRI]

It is my current understanding that currently, darktable releases for OSX are being built by @parafin. It is my current understanding that the version of XCode used to do so is stuck at 12.4 (LLVM10-based), and it can not be upgraded further due to the fact that newer OSX versions do not support the particular hardware used to do these builds.

Although i have not personally had the need to use those builds, i would like to thank @parafin for contributing these builds for all that time!

That being said, this situation is an evolutionary deadlock. It, both, forces a large (larger than strictly necessary) set of compilers to be supported, and provides no way forward.

Each year, a new major GCC version is release, and two major releases of LLVM happen. If someone is serious about CI, that means they all need to be tested in CI. In rawspeed, that currently already amounts to a pretty large matrix: https://github.com/darktable-org/rawspeed/actions/runs/4069778116 ... and i'm not even covering a half of the configurations i want to cover. At some point, there will be more CI jobs than allowed by github actions.

There is no way forward here, because, obviously, e.g. newer C++ standard versions are not implemented in older versions of compilers, and if we can't change the minimal required version, then we are stuck with what we've got.

cc @parafin @MStraeten @johnny-bit

[MStraeten]

be aware afaik with homebrew you can just build for your used macOS version. Macports allows to build for older macOS versions (back to 10.14 for current darktable codebase)

[leanderhutton]

@MStraeten thanks for the info, I've got a shiny new M2 here and my old 2015 Intel to learn on. I've been a MacPorts user since Christ was a cowboy so learning Homebrew for the newer builds too, as well as how to use GitHub. Been self hosting various versions git admin tools and using BitBucket at work all these years.

I got the Homebrew dev environment setup in a VM on my M2 machine and working through the instructions here: BUILD_hb.txt. I've run the scripts in order and I think the 1_install_hb_dependencies.sh omits pkg-config as the 2_build_hb_darktable_default.sh package complained about not finding it on a clean install of 13.2 Ventura. Did a brew install pkg-config and the build process proceeded afterwards.

[gronico]

Hi, I'm a CI/CD expert on mobile projects. I can easily help building the app - nightly / each commit on a branch... or on demand. I'm quite sure that I can find an old mac stuck on Catalina on a shelf and add it to my CI/CD server. If someone is ok to take care of the code, I can build any app.

[kmilos]

It is my understanding that only the last stable release series is supported.

While this is true, someone still has to the triage and figure out if the issues are still relevant, no?

[LebedevRI]

It is my understanding that only the last stable release series is supported.

While this is true, someone still has to the triage and figure out if the issues are still relevant, no?

That depends on what the original question meant by "floating around". I was responding about bugfix backports, not general triage.

[leanderhutton]

@LebedevRI that's what I was getting at, the open tickets for bugs in 3.8 and so on. I guess the steps should be see if they don't exist in the current version and if not recommend they upgrade, if they do exist in the current release see about getting them fixed? darktable doesn't have LTS releases as such and no one is going to back port changes to old version if I understand correctly.

@gronico I think the goal is to ultimately use GitHub actions for the Mac version CI. At least that's what was brought up on pixls.us. That's part of why the Mac build scripts are being moved from MacPorts to Homebrew from what I've read.

[johnny-bit]

the open tickets for bugs in 3.8 and so on. I guess the steps should be see if they don't exist in the current version and if not recommend they upgrade

Exactly! bunch of bugs can get and do get "invisibly" fixed.

darktable doesn't have LTS releases as such and no one is going to back port changes to old version if I understand correctly.

Yes.

I think the goal is to ultimately use GitHub actions for the Mac version CI.

Yes it is. Ideally we want all builds done via GH Actions and packages made by gh actions too. Especially nightlies, so errybody can test master and report bugs faster.

[MStraeten]

at least for macOS a release build was done once. So if bugs are found they might be fixed in a later release. Former releases supported macOS versions back to 10.7 (up to 3.8.1) and recent back to 10.14. so even 10 years old hardware is supported. So not really a demand to backport stuff for old darktable releases. That would require a lot of more effort to be spent to keep development environments that can build for even older releases… so not really relevant unless there’re several maintainers that have too much spare time;)

So it makes sense to continue building the official packages targeting the oldest macOS version that can be supported with the darktable codebase. (10.14 for x86-64 and 11 for arm64) that minimises the demand for maintaining old darktable versions …

[MStraeten]

help needed for https://github.com/darktable-org/darktable/pull/13673#issuecomment-1436069810 (arm64 specific issue)

[kmilos]

I think the goal is to ultimately use GitHub actions for the Mac version CI. At least that's what was brought up on pixls.us. That's part of why the Mac build scripts are being moved from MacPorts to Homebrew from what I've read.

There is already macOS CI using Homebrew: https://github.com/darktable-org/darktable/blob/master/.github/workflows/ci.yml (that needs to be actively maintained, improved, etc.)

There is no macOS nightly package: https://github.com/darktable-org/darktable/blob/master/.github/workflows/nightly.yml

[LebedevRI]

@parafin is there any ongoing progress here? :)

[parafin]

Not a question for me. All my communications on this subject are in this thread, so you can see for yourself;)

[LebedevRI]

So trial by combat between the contenders then? :)

(@TurboGit ?)

The reason i'm asking is because i want to know whom to pester with the original questions i raised in the original comment here:

1. How high can we bump the XCode version? It would be awesome if we could bump it all the way to Xcode 14.0-14.2, which is LLVM14-based.
2. What will be the Xcode version story going forward? Ideally, we should just require the latest non-beta Xcode that is available in github actions, unless the required baseline LLVM version is lower at the moment.
3. What will be the story with macOS target version support? More importantly, can we actually test that in CI? cough https://github.com/darktable-org/darktable/issues/13509#issuecomment-1421205479
4. Directly tied to the previous question, when backdeploying, i suspect there will be issues with libc++ version. Are there some success stories abouth shipping newer libc++ version (statically linked?) Can we do something about that?

[TurboGit]

@LebedevRI : I have no definite name for MacOS maintainer.

But for those questions we can certainly ping @zisoft and @MStraeten.

BTW, may I ask officially if one of you @zisoft and @MStraeten want to be the official maintainer. I need to know as I'll send message from time to time to official maintainers when preparing the release.

[LebedevRI]

(There was also @leanderhutton)

[parafin]

Linking statically with libc++ will most likely result in a disaster, since we link against system frameworks, which are in turn linked to system libc++. I would advice against even trying that for dt.

[zisoft]

How high can we bump the XCode version? It would be awesome if we could bump it all the way to Xcode 14.0-14.2, which is LLVM14-based.

Xcode 14 requires at least macOS 12.5 (Monterey). Github CI hosted runners for macOS support macOS 11 (Big Sur) and macOS 12. So bumping Xcode to version 14 would set the darktable minimum OS requirements to be least macOS 12 or higher. This is by far much better than dropping darktable for macOS at all :-)

And yes, I would be in to be the next maintainer. Or even better: member of a small team of macOS maintainers. Come on Martin :-) The 10 years of experience and knowledge of @parafin cannot be substituted within weeks.

[LebedevRI]

So bumping Xcode to version 14 would set the darktable minimum OS requirements to be least macOS 12 or higher.

minimum OS requirements to build darktable, you mean?

[leanderhutton]

I'm more in a learning posture still. I will like to contribute as my skill set allows. I'm picking things up faster than I thought I would but I'd still be more comfortable being part of a larger team for this until I get fully up to speed.

@MStraeten , @kmilos and @johnny-bit have been answering a number of my questions in this thread about how the Mac side of the project is laid out.

My strong suit is definitely testing as it stands. I'm in a situation where I have access to a lot of hardware and have QC experience in hardware as well.

My thoughts on @LebedevRI 's questions if anyone is interested:

1. AFAIK Xcode 14 requires 12.5 or higher to run and supports macOS targeting High Sierra or later. HS came out in 2017 and I think cut off 2010-era and older Macs. That seems like a good target to me. I've got an old 2011 MacBook Pro that runs High Seirra I can test on. I'm not kidding on my hording problem testing capability.

2. Sounds good to me.

3. This is a sticky question. macOS is such a moving target but there are usually hard breaks every few versions. Maybe High Serra or Mojave or higher?

4. I differ to @parafin 's wisdom here.

[LebedevRI]

3. What will be the story with macOS target version support? More importantly, can we actually test that in CI? cough [Meta-bug][WONTFIX] Please resolve OSX packaging situation #13509 (comment)

3. This is a sticky question. macOS is such a moving target but there are usually hard breaks every few versions. Maybe High Serra or Mojave or higher?

To clarify, just because we require some shiny new Xcode version, we are still handicapped by the oldest macOS version we support, because not all the things that the particular compiler version brings are compile-time. E.g. some parts of the C++ standard library are not header-only, and might not have been available yet in the ${oldest supported macOS version}.

[leanderhutton]

@LebedevRI ahh I see, yes that makes sense.

So if we specify say just the last two or three major versions of macOS that would unhobble the rest of the project? Apple usually doesn't stop supporting hardware with new OSs too fast these days so maybe that would be preferable? It would suck to cut off folks with Macs that can't go past High Sierra or Mojave but those are getting pretty old now. My 2015 MacBook pro can go up to Monterey and that's probably honestly what I'd call barely serviceable for major editing tasks these days.

Honestly, that doesn't seem to unreasonable to me. Not sure how others feel about it. Apple seems to support a machine for 7-ish years with new OSs so that would give darktable users in theory around 9-10 years of being able to run the most current version if we do ${current macOS release}-2 as a minimum. Would that be enough to help the project take advantage of newer compile time features?

[LebedevRI]

Unlike the Xcode version, i don't really have a go-to number for the minimal macOS version that we should support. But given that the current minimal macOS version is 10.7 (sic!), i think if we are bumping the requirements, we might as well bump it too. The higher the better.

By how much -- i don't know, that's why i've posted this issue in the first place -- that's for an osx maintainer to answer :)

[parafin]

As a reference - support for my MacBook Air was dropped only with macOS 11 Big Sur. And I don’t consider this hardware worth supporting anymore, it’s too old and too weak. So IMHO bumping up to macOS 11 would be fine.

As for build vs run requirements - I would suggest not to use deployment target feature anymore. It’s pain in the ass even with macports, and homebrew AFAIK doesn’t support it at all. So pick macOS version to support and use the latest XCode it can run would be my suggestion.

[zisoft]

...and homebrew AFAIK doesn’t support it at all

yes, tons of linker warnings are thrown if the deployment target is set to an older OS version than the building OS.

So pick macOS version to support and use the latest XCode it can run would be my suggestion.

👍 And in addition to that: It all should run on Github CI which has the requirements I wrote above. Drawback: Github CI only targets i386 architecture.

[LebedevRI]

pick macOS version to support and use the latest XCode it can run

I don't like that solution.

[MStraeten]

BTW, may I ask officially if one of you @zisoft and @MStraeten want to be the official maintainer.

i feel quite honoured being asked, but I don’t have the development skills a maintainer needs. I‘m committed to test current master and prs, share development builds and help to identify and fix bugs…

[parafin]

Drawback: Github CI only targets i386 architecture.

x86_64 to be precise. There is arm64 support in GitHub’s roadmap, I think for this summer.

[parafin]

pick macOS version to support and use the latest XCode it can run

I don't like that solution.

Why? This is basically how it works for most Linux distributions.

[MStraeten]

the recent Xcode14.2 can be used to build with deployment target 10.14 - that’s the current minimum required for official packages. major dependency is the macos version used to build the packages. and that’s dependent on the age of the build machine. Xcode 14 needs macOS 12.5, Xcode 12.5.1 needs macOS 11.

[LebedevRI]

pick macOS version to support and use the latest XCode it can run

I don't like that solution.

Why? This is basically how it works for most Linux distributions.

Because it does not address the root issue i brought up, but merely sugarcoats them.

Deployment target feature is there for this precise reason - using newer compiler, while targeting older systems. Mac is oh so special, so while it is true that it's how things work in the *nix world, that does not mean that is how it must work there. Not using it creates more problems in this already problem-ful area.

Additionally, that would only allow us to bump the minimal LLVM version by a mere single release.

Additionally, even after that, we will again be stuck on that version forever, until we are fine bumping the minimal macOS version again. Which is when?

[leanderhutton]

i feel quite honoured being asked, but I don’t have the development skills a maintainer needs.

C'mon we can be incompetent and bodge the whole thing up as a group! I feel the same and am willing to learn as I've stated before, I mean how bad can we really screw this up? :) (that is not a challenge)

I second the team of people idea. Having one person do all the Mac stuff is a recipe for burn out.

Another thought: signing the package for the Mac so it doesn't warn. I've got a dev account (I need to renew it though), anyone else? How is that handled now? IIRC darktable doesn't give the unsigned warning. Although it's been a while since I've installed it fresh.

@LebedevRI reading the thread about the minimum OS spec really makes me feel stronger about the current release-2 plan. That's a riff on what we do at my day job, part of which is Mac Admin duty. Basically the thought process for us there is that some folks might not be able to upgrade to the newest right away due to some other software incompatibility so we generally do current non-beta-release-1 on our support. That would keep the Mac build moving along the LLVM version tree in a predictable manner in a instead of having to re-argue what the base OS support should be each version. It's keeps the road map more clear and keeps the legacy support costs to a minimum.

[parafin]

Right now I build on macOS 10.15 with XCode 12.4, which uses LLVM 10. If we bump to macOS 11.3 and XCode 13.2.1, it will be LLVM 12, so two releases bump. Latest non-beta XCode is LLVM 14. And I don’t suggest to get “stuck” on any version, but use oldest available in GitHub Actions, which they deprecate as new macOS versions are released.

But that’s just my suggestion. New maintainer has to decide.

[parafin]

So far I signed darktable releases with Developer account I use at work.

[zisoft]

And I don’t suggest to get “stuck” on any version, but use oldest available in GitHub Actions

That's exactly the way I have setup the nightly builds now.

[LebedevRI]

But that’s just my suggestion. New maintainer has to decide.

Same here, i'm just airing my grievances. I'm hopeful that the new maintainer will listen to them, and make the right choice.

I think having "current release-2" as the deployment target would be an awesome step forwards, but i'd really prefer to use the newest Xcode (+deployment target) for that build.

[parafin]

I think having "current release-2" as the deployment target would be an awesome step forwards, but i'd really prefer to use the newest Xcode (+deployment target) for that build.

Is there any point in having more stricter requirements for macOS than for Linux? I think it would be good to define more global strategy across platforms with supported compiler versions instead of applying pressure to just macOS direction.

[LebedevRI]

Is there any point in having more stricter requirements for macOS than for Linux?

I wouldn't say this is true. We are currently in the opposite situation, with macOS being treated as a special, that dictates the baseline. E.g. we should be fine requiring LLVM13 on the linux side, because it is available in the current debian stable. If anything, i'm trying to undo this special treatment.

[leanderhutton]

@parafin OK, sounds like we can just use anyone's key then for signing? I didn't know if there was a darktable specific key or something you used.

@LebedevRI so you're thinking target Big Sur for example and build with Xcode 14.x? So we wouldn't support building with Xcode 13 or older is the only difference there really?

Just a thanks for answering my questions and hearing my suggestions to everyone here. I'm mostly a Linux user these days but @TurboGit 's pixls.us post (and my job throwing Mac stuff at me again) got me to start dusting this skill set back off. Hopefully I'm limping my way into some kind of usefulness or at least less useless. :)

[LebedevRI]

@LebedevRI so you're thinking target Big Sur for example and build with Xcode 14.x? So we wouldn't support building with Xcode 13 or older

That is the basic idea, yes.

is the only difference there really?

A coin has two sides, just because we are handicapped by the oldest deployment target by the things that are not compile-time, not all things are non-compile-time.

[parafin]

Is there any point in having more stricter requirements for macOS than for Linux?

I wouldn't say this is true. We are currently in the opposite situation, with macOS being treated as a special, that dictates the baseline. E.g. we should be fine requiring LLVM13 on the linux side, because it is available in the current debian stable. If anything, i'm trying to undo this special treatment.

I’m all for not doing a special treatment for macOS, but it requires defining a normal treatment first. That’s what I’m asking - what is the plan for LLVM and GCC support on Linux and Windows? Then it will allow us to see how macOS fits in. My feeling Linux and Windows support plan will have to be discussed with other maintainers too.

[LebedevRI]

windows is essentially rolling release, so usually the newest upstream version of the compiler is always avaliable. For linux, the idea is to be able to build the dt release (but not necessarily the master) on the current debian stable and the latest ubuntu LTS.

[kmilos]

windows is essentially rolling release

Yep, we can't really set any policy there and have to follow upstream (Msys2, which kinda tracks Arch Linux). The only thing we can choose is the GHA runner OS, but it doesn't seem to have a big impact on darktable up to now, as Windows backwards compatibility has been solid so far.

[parafin]

windows is essentially rolling release, so usually the newest upstream version of the compiler is always avaliable. For linux, the idea is to be able to build the dt release (but not necessarily the master) on the current debian stable and the latest ubuntu LTS.

And what does it mean exactly in terms of LLVM and GCC versions?

Because for example there is #13727, so on Linux CI currently LLVM12 is the latest working version, not LLVM13 as you are suggesting to require, if I understand correctly.

[LebedevRI]

Because for example there is https://github.com/darktable-org/darktable/issues/13727, so on Linux CI currently LLVM12

darktable's CI is not maintained by me, and therefore i fully expect it to be broken and unreliable. I have proper coverage on rawspeed's side: https://github.com/darktable-org/rawspeed/actions/runs/4258358404 https://github.com/darktable-org/rawspeed/blob/19047138fdd7a77cb942d433b1fd99cd7dd7c344/cmake/compiler-versions.cmake

[parafin]

That’s great, but we’re discussing darktable situation here, do we not? And I’m raising my concerns that proposed LLVM version bump is problematic for Linux too, and therefore it’s not just macOS that blocks it. macOS support can follow the requirements if necessary, I don’t see real problems here. But compiler support matrix probably deserves a separate ticket to discuss for all platforms (there’s actually more than three).

[LebedevRI]

I haven't finished replying.

And what does it mean exactly in terms of LLVM and GCC versions?

Right this instant?

• GCC10 (as per current debian stable, https://tracker.debian.org/pkg/gcc-10, ubuntu 22.04LTS has GCC12 https://packages.ubuntu.com/jammy/gcc-12)
• LLVM13 (https://tracker.debian.org/pkg/llvm-toolchain-13, https://packages.ubuntu.com/jammy/clang-13 / https://packages.ubuntu.com/jammy/clang-14) ... yet it's at LLVM10 due to the xcode/osx.

With upcoming debian release, the plan is to bump those requirements to

• GCC 11 or 12 (available in debian testing, https://tracker.debian.org/pkg/gcc-11 / https://tracker.debian.org/pkg/gcc-12, https://packages.ubuntu.com/jammy/gcc-11 / https://packages.ubuntu.com/jammy/gcc-12)
• LLVM 14 or 15 (available in debian testing, https://tracker.debian.org/pkg/llvm-toolchain-14 / https://tracker.debian.org/pkg/llvm-toolchain-15, https://packages.ubuntu.com/jammy/clang-14 / https://packages.ubuntu.com/jammy-updates/clang-15) ... yet it will again be constrained by the xcode/osx.

@parafin IOW, it is not yet obvious to me why the LLVM version is problematic on linux side.

[TiredOfGuessing]

As a Mac darktable user for about a year, I have been concerned about long term Mac viability. I can't contribute much yet, but will learn how to build. Regarding older macOS version support I made a table which shows HW and supported OS version going back to 2012 HW (from Feb 2023 Apple web pages). I realize that I am at a point in life (retired) where I can afford relative recent HW but given GPU code and algos could not see myself having the patience to use dt on 2012 HW. Anyway some real data to help with support decisions. MacHW-macOS-Feb2023.pdf

[TurboGit]

With upcoming debian release, the plan is to bump those requirements to ...

• LLVM14

Note that we have suspicion of code generation issue with LLVM 14 or some constructs ambiguous used in dt and not well generated. See #13727. So at the moment we have reverted to LLVM 12 for the CI. Hopefully this will be sorted out soon but at the moment we are in the fog!

[LebedevRI]

It's almost assuredly just a normal UB in the source code.

[LebedevRI]

Why is the build using ccache by default?