Re: [hatari-devel] hatari.app from cirrus-ci (was: Re: One scanline short in ST fullscreen)

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Andreas,

I tested it with the version you uploaded to your Dropbox yesterday. I downloaded it again after deleting the old version. I changed the app name from “Hatari” to “hatari”. I received the same message that I previously had with yesterday’s Hatari app. It tells me Apple cannot scan for malicious software, but I can click Open to open the app anyway. After that, I could run “hatari” without a problem. Therefore, I think the best answer is to let CMake build a macOS version with an app name of “hatari”. It can then be manually renamed to Hatari as most Mac users would expect. That could be done when the macOS version of Hatari is uploaded to the official download page.

For the nightly snapshots, I do not see a problem with the user manually renaming the app to Hatari. I do not know if the manual “mv hatari.app Hatari.app” can be put into the YML file or if it needs to be done by a user. That might be worth checking if it can be added to the YML file by Thomas. I admit I am not sure what can be inserted into a YML file.

Bob C

On Dec 17, 2023, at 3:58 PM, Andreas Grabher <andreas_g86@xxxxxxxxxx> wrote:

You could test is with the signed upper case version that I posted. If changing to lower case does not break it, the same will certainly be true changing it the other direction. 

Am 17.12.2023 um 23:00 schrieb Bob Carpenter <hatari@xxxxxxxxxx>:


Andreas,

I think manually is good enough. If someone needs to download a development snapshot, I think they’ll know enough about the Mac to manually change the name. 

For an official release, it can be manually renamed before it is put on the download page. 

If we can manually change the name for macOS, then the naming will be correct on both macOS and Linux. 

Bob C

On Sun, Dec 17, 2023, at 2:21 PM, Andreas Grabher wrote:
I think it is possible to do it manually. But I don‘t know how to automatically do it using CMake. 

Am 17.12.2023 um 22:08 schrieb Bob Carpenter <hatari@xxxxxxxxxx>:

Andreas,

Can you build the app as hatari (lowercase) and manually rename it to Hatari (capitalized) after the build?

I thought the user could manually rename the app after it has been code signed. Is that wrong?

Bob C

On Sun, Dec 17, 2023, at 11:48 AM, Andreas Grabher wrote:
After a few more experiments it seems that the entries in the Info.plist inside the bundle must match the name of the bundle and the name of the executable to allow signing.

The current (unpatched) code produces hatari.app on macOS with lower case hatari executable inside the bundle. It is not possible to produce Hatari.app with hatari executable. At least I don’t know how. If you prefer hatari executables it will be hatari.app.


> Am 17.12.2023 um 19:24 schrieb Bob Carpenter <bobc@xxxxxxxxxx>:

> Thomas,

> As a former Linux user and current macOS terminal user, I completely agree with you. On Linux, the executable should be lowercase. I do not remember if Hatari is capitalized on Windows or not. I do not use Hatari on Windows enough to remember.

> Furthermore, on macOS, the executable inside the Hatari.app bundle (appears as a directory when viewing it on non-macOS systems) should be lowercase. If you run a command from Terminal, we should be able to keep the hatari executable in lowercase and only have Hatari.app with a capital letter. This is helpful when a Hatari developer suggests a command-line to a macOS user. They could get confused wondering why the command did not run if the macOS executable is named Hatari instead of hatari because you will get an error stating that “hatari” is not found if the executable is called Hatari.

> I am very grateful to Andreas for finding the underlying problem on why I could not run the cirrus-ci binaries on macOS Sonoma. With his help, it should be possible to make a macOS Hatari binary that works for end users easily.

> If I am reading your diff correctly, why are you changing Hatari.app to hatari.app? I think the only part of the CMakefile that needs to have Hatari capitalized is any reference to Hatari.app. If the CMakefile refers simply to hatari, I think we can leave that in lowercase. 

> Bob C

>> On Dec 17, 2023, at 1:23 AM, Thomas Huth <th.huth@xxxxxxxxx> wrote:
>> 
>> Am Sun, 17 Dec 2023 01:23:45 +0100
>> schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:
>> 
>>> Great! This is normal behaviour for applications signed by non-paying developers. Problem solved!
>>> 
>>> The quarantine problem was caused by signing failing silently. Hatari was not signed at all. The signing failed because of the big hatari-Hatari-mess in the CMakeLists. The appended patch2 fixes the issue. I also appended patch1 again to make sure patches are applied in the correct order.
>> 
>> So the problem is simply about a "hatari.app" vs. "Hatari.app" naming issue?
>> Ouch!
>> Ok, thanks a lot for your investigation, Andreas! But I think your second
>> patch is not the right way for Hatari, since this also renames the binary
>> on Linux and other OSes which is not what we want (at least it's not what
>> I want).
>> 
>> So I think for Hatari we should go the other way round and find the right
>> spots where we have to rename "Hatari" to "hatari" in the macOS parts of
>> the code.
>> 
>> Could you please check whether this fixes the issue, too:
>> 
>> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
>> index 30630b69..ba26b693 100644
>> --- a/src/CMakeLists.txt
>> +++ b/src/CMakeLists.txt
>> @@ -98,9 +98,9 @@ if(ENABLE_OSX_BUNDLE)
>> set(MACOSX_BUNDLE_ICON_FILE Hatari.icns)
>> set(MACOSX_BUNDLE_GUI_IDENTIFIER org.tuxfamily.Hatari)
>> if(CMAKE_GENERATOR MATCHES "Xcode")
>> - set(BUNDLE_CONTENTS ${CMAKE_CURRENT_BINARY_DIR}/\${CONFIGURATION}/Hatari.app/Contents)
>> + set(BUNDLE_CONTENTS ${CMAKE_CURRENT_BINARY_DIR}/\${CONFIGURATION}/hatari.app/Contents)
>> else()
>> - set(BUNDLE_CONTENTS ${CMAKE_CURRENT_BINARY_DIR}/Hatari.app/Contents)
>> + set(BUNDLE_CONTENTS ${CMAKE_CURRENT_BINARY_DIR}/hatari.app/Contents)
>> endif()
>> if(PNG_FOUND)
>> set(COPY_PNG cp -R ${PNG_LIBRARY} ${BUNDLE_CONTENTS}/Frameworks/)
>> diff --git a/src/gui-osx/Info-Hatari.plist b/src/gui-osx/Info-Hatari.plist
>> index eea99de6..b6d87bc2 100644
>> --- a/src/gui-osx/Info-Hatari.plist
>> +++ b/src/gui-osx/Info-Hatari.plist
>> @@ -54,7 +54,7 @@
>> </dict>
>> </array>
>> <key>CFBundleExecutable</key>
>> - <string>Hatari</string>
>> + <string>hatari</string>
>> <key>CFBundleIconFile</key>
>> <string>Hatari.icns</string>
>> <key>CFBundleIdentifier</key>
>> @@ -62,7 +62,7 @@
>> <key>CFBundleInfoDictionaryVersion</key>
>> <string>6.0</string>
>> <key>CFBundleName</key>
>> - <string>Hatari</string>
>> + <string>hatari</string>
>> <key>CFBundlePackageType</key>
>> <string>APPL</string>
>> <key>CFBundleShortVersionString</key>
>> @@ -71,7 +71,7 @@
>> <string>HATA</string>
>> <key>CFBundleVersion</key>
>> <string>2.4.1</string>
>> - <key>Hatari</key>
>> + <key>hatari</key>
>> <string>SDL Cocoa App</string>
>> <key>LSMinimumSystemVersion</key>
>> <string>10.9.0</string>
>> diff --git a/src/gui-osx/en.lproj/InfoPlist.strings b/src/gui-osx/en.lproj/InfoPlist.strings
>> index 8e9661ea..6e36b535 100644
>> --- a/src/gui-osx/en.lproj/InfoPlist.strings
>> +++ b/src/gui-osx/en.lproj/InfoPlist.strings
>> @@ -1,6 +1,6 @@
>> /* Localized versions of Info.plist keys */
>> 
>> -CFBundleName = "Hatari";
>> +CFBundleName = "hatari";
>> CFBundleShortVersionString = "Hatari version 2.4.1";
>> CFBundleGetInfoString = "Hatari version 2.4.1 , Copyright 2022, T. Huth.";
>> NSHumanReadableCopyright = "Copyright 2022, T. Huth.";
>> diff --git a/src/gui-osx/fr.lproj/InfoPlist.strings b/src/gui-osx/fr.lproj/InfoPlist.strings
>> index 0c25a2dd..06c3e018 100644
>> --- a/src/gui-osx/fr.lproj/InfoPlist.strings
>> +++ b/src/gui-osx/fr.lproj/InfoPlist.strings
>> @@ -1,6 +1,6 @@
>> /* Localized versions of Info.plist keys */
>> 
>> -CFBundleName = "Hatari";
>> +CFBundleName = "hatari";
>> CFBundleShortVersionString = "Hatari(fr) version F 2.4.1 ";
>> CFBundleGetInfoString = "Hatari version 2.4.1 , Copyright 2022, T. Huth.";
>> NSHumanReadableCopyright = "Copyright 2022, T. Huth.";
>> 
>> ?
>> 
>> Thanks,
>> Thomas
>> 
>> 










Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/