current OSX Build

[olivier]

I added a new thread with an Automator workflow to remove the quarantine bit of darktable. No need to use the Terminal.

MacOS Build : removing darktable Quarantine attribute (Workflow)

Hi, For those who are using darktable (or any unsigned application) on MacOS, and using unsigned version of darktable: MacOs is adding a quarantine attribute to new files as the permission bits (linux users know them as the -rwxrwxrwx permissions, MacOS uses extra bit on top of these). To avoid using the command line I’m using an Automator workflow I created for that use. Installation unzip the attached file below open a Finder and navigate to you home directory and Library/Services/ direct…

Hope this helps

[MStraeten (MartinSt)]

PTGUIbatch doesn’t sound like a part of darktable - so you need to check your configuration

[zisoft (Mario Zimmermann)]

No need to use the Terminal.

Ctrl-click on the app and then choose “open”. This clears the quarantine flag as well.

[MStraeten (MartinSt)]

feature freezed current 4.3.0 master + a couple of RF lensfun data from: Kameratrollet + corrected raw whitepoints for Canon M6

darktable-4.3.0+2460~g735230d807_arm64.dmg
darktable-4.3.0+2465~g8a9f77909a_x86_64.dmg

both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "

darktable 4.3.0 will update the database, so there’s no way back to darktable 4.2.
so my usual reccommendation for doing a backup of your libraries (and xmp files if you’re using darktable with temporary :memory database).

upcoming 4.4 releasenotes see darktable/RELEASE_NOTES.md at master · darktable-org/darktable · GitHub

[zurdo]

Hi, two observations to see if someone else had the same issues. When using color zones I have random crashes, it happens but not all the time that I this modules. The other observation is that when using retouch, selecting shapes does not results in the highlight of the selected shape, but the shape is correctly selected. Same observations with the nightly pkg. Otherwise working very nicely.

[MStraeten (MartinSt)]

feature freezed current 4.3.0 master + a couple of RF lensfun data from: Kameratrollet + corrected raw whitepoints for Canon M6

built with deployment target 10.14

darktable-nightly+16~gabc22aca3f_x86_64.dmg

since 10.14 isn’t supported and i don’t have access to a 10.14 machine any feedback is helpful.

[lhutton (Leander)]

Fired it up on my 2015 MacBook Pro I keep on Mojave 10.14 and so far so good. Haven’t run into any bugs doing an image import and poking around in the darkroom so far.

[olivier]

Hi,

This is the message I get when opening with the right mouse button and click on “open” in the contextual menu (that’s in french)

“Impossible to open darktable.app because the developper can’t be verified. macOS can’t verify that this app contains bad software”…Move to the bin / Cancel

[MStraeten (MartinSt)]

it’s an unsigned package so works as designed

[olivier]

Macbook Pro M1 on Ventura 13.4. After database migration, the OpenCL alert message, it seems to work for now.

[olivier]

Yes, I know That’s why I created the Automator workflow for all unsigned apps I’m using

[zisoft (Mario Zimmermann)]

@olivier

This is the message I get when opening with the right mouse button and click on “open” in the contextual menu

Use ctrl-leftclick and choose open to clear the quarantine flag.
This needs to be done only once.

[g-man]

There is a section in the darktable FAQ for Mac that we could use to add this info. I’m not a mac user. Is this something that will always happen even in the release version?

Starting darktable gives me an error message: Impossible to open darktable.app because developer can´t be verified.

• darktable is an unsigned package and mac OS will display this message. You need to Ctrl+Left click and choose to open to clear this message. This only needs to be done once.

faq

[zisoft (Mario Zimmermann)]

Is this something that will always happen even in the release version?

It will, if the package is not signed by a developer with an official Apple developer account. Apple charges a membership fee for that accounts and as long as there is no one in the team with such an account, this will happen on release versions too.

Since this is a usual way for many open source Mac software it should not hurt anyone but it is a good idea to put this in the FAQ.

[lhutton (Leander)]

@zisoft

Apple charges a membership fee for that accounts and as long as there is no one in the team with such an account, this will happen on release versions too.

I’ve got an Apple Dev account, let me know what you need.

[zurdo]

Update, the two issues I reported before, with color zones and retouch, are gone in build 2508 and the previous night build (947). Great, thanks to the developers. Will keep testing

[MStraeten (MartinSt)]

feature freezed current 4.3.0 master + a couple of RF lensfun data from: Kameratrollet + corrected raw whitepoints for Canon M6

darktable-4.3.0+2513~g7c0124ac4a_arm64.dmg
darktable-4.3.0+2512~gbaaf3bd39a_x86_64.dmg (macOS min 10.14)

both packages are unsigned, you might need to allow execution via terminal: " xattr -c <path/to/application.app> "

darktable 4.3.0 will update the database, so there’s no way back to darktable 4.2.
so my usual reccommendation for doing a backup of your libraries (and xmp files if you’re using darktable with temporary :memory database).

upcoming 4.4 releasenotes see darktable/RELEASE_NOTES.md at master · darktable-org/darktable · GitHub

[lhutton (Leander)]

Hey @MStraeten I managed to get signed versions of 4.4.0 built tonight for X64 and ARM with MacPorts. Now looking at GitHub runners and how to integrate code signing certs on that side. Tried to make a universal binary but so far no luck there.

Do you mind if I post those builds? I figure signed App packages might go some distance to make darktable look more “official.”

[MStraeten (MartinSt)]

why not - but please also talk with Pascal so further relaeses can provide signed packages.

[kmilos]

@MStraeten

please also talk with Pascal

and @zisoft