search

darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.67k stars 1.13k forks source link

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

Closed LebedevRI closed 1 year ago

LebedevRI commented 1 year ago

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

TurboGit commented 1 year ago

Why is the build using ccache by default?

To speed up compilation but don't ask me more about cmake :)

TurboGit commented 1 year ago

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

Yes, that's what I have called "ambiguous" as not well defined.

LebedevRI commented 1 year ago

Why is the build using ccache by default?

To speed up compilation but don't ask me more about cmake :)

Why is that not an opt-in and why is there no toggle for it? :)

LebedevRI commented 1 year ago

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!

Better now? :)

TurboGit commented 1 year ago

Yes, much better :)

parafin commented 1 year ago

Could someone from the new team test PR #13754 whether it solves #2810? First obviously you will need to reproduce the #2810, it may have been solved in recent macOS releases.

parafin commented 1 year ago

Regarding LLVM versions - so if we ignore the question of other platforms (like *BSD or Solaris) for now, we just need to select minimal LLVM version for the near future. For macOS it would mean one of the following:

LLVM 12 - XCode 13.2.1, macOS 11.3 LLVM 13 - XCode 13.4.1, macOS 12.0 LLVM 14 - XCode 14.2, macOS 12.5 LLVM 15 - XCode 14.3, macOS 13.0 (XCode is still in beta)

As I said, I don't personally see any problem with any of these options, my main point was that compiler support policy has to be formulated somewhere explicitly (and then followed), which can't (shouldn't) be platform-specific.

LebedevRI commented 1 year ago

Unless said policy literally states "compiler version support is not set in stone", i'm not sure how well it would work in practice. These bumps happen relatively infrequently, much like the distro releases in question.

The real problem is, what is the chicken and what is the egg here? Are we catering to the (1) developers, (2) distro maintainers, (3) users? If it was to the (1), then we should just support a single compiler, and only the latest version of it. Literally, only a single compiler. If it was to (2)/(3), then we'd still have to support gcc 4.6. The sad reality is somewhere in the middle.

We can't really set in stone the LLVM version policy, because we still don't know what will work in reality. Are the OSX maintainers okay with the idea i've raised in

@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.

... iow, requiring the newest (non-beta?) Xcode version? Or are we going with some other guideline? Said Xcode story will be dictating the baseline LLVM version to support.

But if you insist, i guess it would be something along the lines of:

We strive to keep the software releases (but not necessarily development versions!)
buildable with the versions of the dependencies provided out-of-the-box
in the following distributions:
* debian stable
* latest(!) ubuntu LTS
* latest(!) macOS

Compiler-wise, that means that we support three compiler families:
* GCC, with the required version being the newest one that is available
  in *both* the debian stable *and* the latest ubuntu LTS
* Xcode, only the latest non-beta release is supported
* LLVM, with the required version being the oldest one between
   * the Xcode's underlying LLVM version
   * and the newest one that is available in *both* the debian stable *and* the latest ubuntu LTS

Does this sound remotely sensible?

parafin commented 1 year ago

To me - yes, that's what I wanted to hear. But my target here was to get as much relevant information as possible and to delegate the decision to the people who is actually going to maintain the code;)

LebedevRI commented 1 year ago

poke

leanderhutton commented 1 year ago

@LebedevRI I've been overwhelmed at work the last week or so trying to meet some deadlines so not much time to post here.

I'm not sure how this is supposed to work officially. I guess it's up to @TurboGit ? I've re-upped my personal Apple Dev account. I'm not sure I'm the correct person for the job but @zisoft, @MStraeten and myself seem to be the ones showing up. @rgo I think said something about helping up there? Hopefully this pokes him too. IMO I think it'd be better to have imperfect Mac support than none at all. Considering the huge amount of photographers who use Mac that would be cutting off the project's nose to spite its face. Plus I'd like to be able to run it on my Mac every once in a while. :)

I know @MStraeten has said he does not want to be the maintainer and I'm unsure of @zisoft 's feelings on it but I'd like to drag them in if I could. I think if there was a group of us handling the Mac side that would help the project more if they are up for it.

As for my qualifications: I've been using darktable since ~1.6 on Mac and Linux, mostly Linux since 2.x though. I do a variety of admin, some basic dev and support work at my job so I'm moderately familiar with how this stuff works. For Mac specifically I'm one of three people working on our Jamf management tasks and scripting out stuff for our builds at a university with ~20K students plus faculty and staff. I also handle a number of Linux machines and applications along with cloud and infrastructure stuff. I've got access to enough hardware to test and compare bugs across OS and configurations too.

I don't mind helping, building and signing release packages (if needed) at all. Just keep in mind I'm still learning and I'll probably be an idiot here or there as we we get going. I'm pretty easy to get along with I think but I'm not terribly confident. I do have experience working in a large scale environment, managing expectations and sub-dividing tasks down.

The fact that it'll likely take 2-3 people to replace @parafin should be testament to his dedication to the project over the last decade.

LebedevRI commented 1 year ago

Thanks!

I'm not sure how this is supposed to work officially. I guess it's up to @TurboGit ?

In the end someone would need to take a step forward and claim the role, otherwise we can't make forward progress on the mentioned version issue.

LebedevRI commented 1 year ago

poke

zisoft commented 1 year ago

Regarding the maintainer role I have already commited to that several times.

Compiler versions:

We want to run Xcode 14, that requires at least macos 12.5 (Monterey)

Now we have two package managers for macOS: Homebrew and MacPorts.

Now for the CI: GitHub hosted action runners for macOS target macos-11 (Big Sur) or macos-12/macos-latest (Monterey). If we want to build only on Xcode 14 we need to run macos-12/macos-latest.

For Homebrew that would mean to drop support for macos-11 and older. Homebrew is installed by default on GitHub runners.

MacPorts can simply be installed on GitHub runners. I have tried to setup a GitHub action with MacPorts and to rebuild all dependencies from source. This fails due to the maximum allowed execution time for jobs, which is 6 hours.

TLDR;

I would definitely prefer to build everything within GitHub hosted actions. CI, nightly builds and the release builds twice a year.

leanderhutton commented 1 year ago

@zisoft that has been my understanding as well, the main issue with Homebrew is you can't target older versions of macOS. Edit: I do have good sysadmin chops and access to hardware to do MacPorts builds.

@LebedevRI it looks like @zisoft is the new maintainer from what I've read in another thread. Considering my contributions to the project have ranged from nothing to getting in the way/slowing others down I'll take my leave and "git gud" as the kids say. It's going to be a while before I have the skills needed to be useful. I'll dip in and try to help on things where I'm able without being spoonfed while I'm learning. :) I think between @zisoft and @MStraeten this is in good hands. I guess this issue should be closed?

LebedevRI commented 1 year ago

@LebedevRI it looks like @zisoft is the new maintainer from what I've read in another thread.

Link? If that part of the issue is addressed - great!

TLDR;

  • For CI and nightly builds: macos-12/macos-latest GitHub runner using Homebrew, targeting macOS 12 or above.
  • Building releases for older macOS versions requires self hosted runners and MacPorts. That would mean to be dependent on someone who maintains such a machine.

@zisoft am i understanding correctly that the wording i proposed in previous comments, namely:

require newest non-beta XCode that is available on github actions

is acceptable, and we can move forward with the version bump?

leanderhutton commented 1 year ago

@LebedevRI https://github.com/darktable-org/darktable/pull/13817#pullrequestreview-1325065472

Now I need to get off my butt and contribute something meaningful besides chat.

zisoft commented 1 year ago

@LebedevRI

@zisoft am i understanding correctly that the wording i proposed in previous comments, namely:

require newest non-beta XCode that is available on github actions

is acceptable, and we can move forward with the version bump?

this is exactly my understanding as well. To use the tools which gitbhub actions provide. And for the macos-latest runner image that means whe have

MStraeten commented 1 year ago

That combination allows supporting 10.14 X86_64 as well as arm 64 (at least with macports)

LebedevRI commented 1 year ago

@LebedevRI

@zisoft am i understanding correctly that the wording i proposed in previous comments, namely:

require newest non-beta XCode that is available on github actions

is acceptable, and we can move forward with the version bump?

this is exactly my understanding as well. To use the tools which gitbhub actions provide. And for the macos-latest runner image that means whe have

  • macOS 12.6.3
  • Xcode 14.2

Awesome, thank you. I forgot to ask the second part of the question, but @MStraeten's comment reminded me: is there a decision on the oldest supported macOS version, aka backdeployment target? It makes sense to evaluate that at the same time.

zisoft commented 1 year ago

That's my statement above:

Building releases for older macOS versions requires self hosted runners and MacPorts. That would mean to be dependent on someone who maintains such a machine.

So someone with such a setup needs to commit to that. Not possible with GitHub hosted runners.

LebedevRI commented 1 year ago

Yes, but no, that is not what i'm asking. We've established that we'll only support building with newest XCode, which requires new macOS version (12.6 e.g.).

But what will be the oldest macOS version that will be supported to actually run the result? Currently that's at 10.14.

I'm mainly worried about, again, not being able to actually test that it works, so i think it would be good to bump it to macos-11(.???), which is the oldest macOS release avaliable on github actions. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

zisoft commented 1 year ago

Ok, there is still some confusion, I try to summarize.

On GitHub runners we have two choices:

If we want to create binaries targeting older macOS versions we need to build them using MacPorts because the dependencies need to be built from source. This is not possible on GitHub hosted actions due to the maximum allowed execution time of 6 hours. So that would require that someone builds these binaries on a dedicated machine.

LebedevRI commented 1 year ago

Ok, there is still some confusion

Indeed.

If we want to create binaries targeting older macOS versions we need to build them using MacPorts because the dependencies need to be built from source. This is not possible on GitHub hosted actions due to the maximum allowed execution time of 6 hours. So that would require that someone builds these binaries on a dedicated machine.

I get that. That is not my question. My question is, ignoring the issue of how to actually do the build, theoretically, which oldest macOS version do we care to support as the actual deployment target? I.e. how old of an macOS version could a user be running, that we'd care to support?

zisoft commented 1 year ago

We already had a controversial discussion about that in this thread. No one can say how many darktable users are running very old macOS versions. Some facts:

I have a Mac running the most recent macOS 13, so personally I don't care. Do we need a survey on Pixls to find out? Or should we just make an announcement to drop support for macOS 10 or even 11?

We just need to make a final decision. My decision would be to use the macos-11 image with Xcode 13 so we support macOS 11 and above. Or if we really need the newest compiler features then use macos-12 with Xcode 14 and we support macOS 12 and above. That way we can benefit from all the automation features GitHub provides.

Theoretically we can use Xcode 14 and build binaries targeting macOS 10. But then someone needs to do that.

leanderhutton commented 1 year ago 
Apple supports macOS 11 or higher
GitHub supports macOS 11 or higher
Homebrew supports macOS 11 or higher

This was my original though behind the current release - 2 suggestion as well. It gives a predictable and maintainable path forward. This is from my experience at work as a Mac/Linux admin and having to maintain code that's probably only 25% as complex as darktable. That way it's a known predictable upgrade cycle with easy to forecast cut off dates for certain OSes and minimizes time spent chasing support bugs on hardware/old versions that devs and admins might not have around anymore.

That's if anyone wants my input. Feel free to /dev/null it and tell me to go stand in front a train. :)

LebedevRI commented 1 year ago

@leanderhutton

This was my original though behind the current release - 2 suggestion as well. It gives a predictable and maintainable path forward.

Can you link me to the page that mentions the cut-off date for the macOS 11 support? For how many years will we have to support it as a baseline?

zisoft commented 1 year ago

Apple never mentions this officially, but unofficially it is documented here: macOS end of life dates

leanderhutton commented 1 year ago

That's more of our internal policy for support just to keep sanity. We have departments who like to grab old machines out of the boneyard and then complain when it won't run whatever program they need of ours. Dev and support resources are finite be they an open source project or a university and this works well to get maximum use out of our hardware (by the time a machine can't run last year's macOS it's usually ~7+ years old) and not tie up our people trying to deal with software bugs that have been solved in newer versions.

As said above, AFAIK Apple doesn't have official EoL dates like Microsoft or Red Hat.

TiredOfGuessing commented 1 year ago

Apple is oriented to the HW EoL. But here is some info. https://eclecticlight.co/2021/09/22/how-long-does-apple-support-macos/

LebedevRI commented 1 year ago

So in other words, darktable's next major release will happen mid-summer, and after that, macOS 11 will EOL in fall of 2023, followed by dt's next+1 major release. So we only need to support macOS 11 for the upcoming dt's major release, but the next+1 major release will only need to support macOS 12 and newer.

Meh. I don't really like it, but it's a lot better than what we have now. I don't know if that will work out, but we could try going with that i suppose.

leanderhutton commented 1 year ago

With dt's release schedule it does make the oldest version a bit more sticky but it's a predictable cadence, people know what to expect in advance and it can always be tweaked later. IMO maintainability and lack of surprise dropping of support is pretty important. It's better than cleaving off a bunch of things more suddenly and having to deal with all the cruft all at once, at least in my experience. I'm just making suggestions for the important people. :)

Our updates happen over summer mostly as well.

LebedevRI commented 1 year ago

@leanderhutton @zisoft @parafin @TurboGit please verify that i have correctly transcribed all of this here: https://github.com/darktable-org/rawspeed/pull/441

zisoft commented 1 year ago

Exactly what we discussed here. Looks good to me.

LebedevRI commented 1 year ago

Well then.

LebedevRI commented 1 year ago

@kmilos @victoryforce etc Please verify that the dt's CI is using appropriate versions, otherwise the submodule update may be bumpy/troublesome.)

kmilos commented 1 year ago

Windows/Msys2 is already on GCC 12 and LLVM 15.

LebedevRI commented 1 year ago

With 4.4.0 being out, i'd like to mention that according to the guidelines, the plan is to drop support for macos-11 after 4.4.1, since macos-14 will happen (thus, deprecating macos-11) before 4.6.0.

... that being said, a question. @zisoft, is it impossible to use newer SDK than the one natively provided for the XCode version? They are all avaliable (e.g. https://github.com/realjf/MacOSX-SDKs/), and e.g. Julia packages actively uses that approach.

zisoft commented 1 year ago

The newest SDK is 14.0 which comes with Xcode 15 beta. For CI, Github runners already provide Xcode 15 beta, but it requires macos-latest (13) to run.

All those SDK collection sites (like the one you linked above) only provide fairly old SDK versions (up to 12.3).

For all people who want to self-compile darktable that would require to install Xcode 15 beta. No need for an Apple developer account, it can be downloaded for everyone at Xcode Releases but it requires macOS 13 to run.

parafin commented 1 year ago

In general I wouldn’t except to be able to use new SDK with old XCode. It might happen to work, but as a strategy I would advise against it. Apple likes to break things for developers with updates, so better follow their suggested workflow IMHO.

MStraeten commented 1 year ago

what’s the value of using a beta development environment if there’s not a technical demand to do so. Yet obviously all that discussion on supported sdk etc. is a storm in a teacup since according to https://developer.apple.com/support/xcode even the upcoming sdk 14 will support a macOS deployment target beginning with 10.13…

LebedevRI commented 1 year ago

@zisoft @parafin Ignorant question: do we have to use XCode itself? Can we not just use the newest clang from homebrew/macports?

@MStraeten

what’s the value of using a beta development environment if there’s not a technical demand to do so.

[As] it has been previously discussed in this very issue [...]

Yet obviously all that discussion on supported sdk etc. is a storm in a teacup since according to https://developer.apple.com/support/xcode even the upcoming sdk 14 will support a macOS deployment target beginning with 10.13…

[...] the problem is that we then need to custom-build all dependencies, and that takes longer than the max allowed runtime of a free github actions job.

MStraeten commented 1 year ago

there's a difference between a build done via github actions and a build done in a standalone macports environment as currently done by me. If there're no technical reasons using specific programming language features, the dependencies given by the build pipeline should be the limiting factor, not an arbitrary decision. Macports can support a deployment target older then the build machine - so my x86_64 macports environment is built for 10.14 and my arm64 environment is built for 11.0. As long as there's no dependency requiring a newer macOS there's no need to limit the target release. Since github uses homebrew theres a difference for the github built x86_64 package (and maybe in future also with the arm package). The minimum supported macOS version is primarily given by the github configuration - currently theres a macos11 runner, so why changing that?

LebedevRI commented 1 year ago

@MStraeten thank you for your thoughts on the question, but it does not really answer my question. I don't wish to redo this whole thread, but i do want to point out that there may be some cyclic reasoning at play: indeed, there's currently no technical reason to require newer compiler than the required XCode versions, because the currently-required XCode does satisfy all the requirements placed on it by the code, BUT the requirements placed the compiler it by the code are the way they are because if they were different the currently required XCode would no longer be able to satisfy them...

LebedevRI commented 1 year ago

@zisoft @parafin Ignorant question: do we have to use XCode itself? Can we not just use the newest clang from homebrew/macports?

(Cough)

With 4.4.0 being out, i'd like to mention that according to the guidelines, the plan is to drop support for macos-11 after 4.4.1, since macos-14 will happen (thus, deprecating macos-11) before 4.6.0.

(I didn't get any reaction to this snippet. Also, how lossy will that bump (from macos-11 to macos-12) be? We probably don't want to deviate from the just-written guidelines, BUT.)