`icu4c_wasm.patch` is build by :
- Copying config.sub from liblzma source as new version of config.sub there
knows about wasm architecture.
- Copying `mh-linux` on `mh-unknown` as specified in (origin) `mh-unknown`.
This is because icu4c configure doesn't detect `emscripten` platform and
"fallback" to `mh-unknown`.
By uploading read-only archive, we prevent potential (implicit) re-upload.
A re-upload will always be possible if we remove the archive and rerun
the workflow. But it will be clearly explicit in this case.
While it is ok to build all libkiwix android builds in one step,
the "release system" upload only one archive per platform.
So we need 4 platforms to do 4 uploads.
As we don't build on "android" platform now, we can clean up our scripts.
When build_release_nightly calls codesign to sign libzim.7.dylib, it appears to be
hanging forever.
What's most likely happening is that Keychain Access is prompting a password request
without any possibility to answer, given this is running on the CI.
It's unclear whether Keychain Access wants to confirm codesign can access the certificate
or if it is trying to unlock another (System) keychain to find the certificate or key.
This addresses the former.
SSH server which was used to receive file uploads (CI, nightly and release) has been
migrated to a new one on a different address.
Username, Key and paths are unchanged.
Most notable changes are the use of `master.download.kiwix.org` as the target in
replacement of `mirror.download.kiwix.org` (although it would still work) and the
Port to which SSH is listening on (30022 instead of 22)
Xenial's python is 3.5 and recent versions of used python modules are
not supporting python 3.5 anymore.
We have to force specific versions for gcovr and its dependencies.
For the past week, the Release&Nightly workflow failed on macOS native_mixed
(but not on native_dyn) when calling ntp to sync clock before signing.
Calling time.apple.com resulted in a DNS error, leading to an error in ntp call
Why this fails on native_mixed is unknown. Maybe because it's being called twice
from the same (I guess) host in a short interleave?
This attempts to fix this by:
- using google's time server instead of Apple's
- correctly setting the timeout param before the server name (although not relevant
for this dns-based error)
- Ignore failures to sync time. We're doing it to minimize chances of unsynched clocks
to fail the signature but this is not absolutely required all the time.
This adds the notarization (see #469) of the libzim binary for macOS during the build.
It it not dependent on RELEASE so it benefits all builds.
It basically does two things:
- sign the build with our Developer ID certificate from Apple.
- Request notarization from Apple for the binary.
At the moment, it concerns only libzim. Might expand that to libkiwix and the zim/kiwix tools
once we start releasing those.
Github Actions prepare the certificate and environment, and signing+request is done in `notarize_macos_build()` (common.py)
It required the following new secrets:
| secret | value |
|---|---|
| `APPLE_SIGNING_CERTIFICATE` | base64 of the P12 certificate |
| `APPLE_SIGNING_P12_PASSWORD` | password for the P12 certificate (we chose that when exporting to P12. Apple doesnt provide P12) |
| `APPLE_SIGNING_IDENTITY`| Common name of our certificate. Not a private info but seems better suited there than in the CI |
| `APPLE_SIGNING_TEAM`| Apple Developer Team ID (mentionned in the signing identity) |
| `APPLE_SIGNING_ALTOOL_PASSWORD`| app-specific password created to request notarization |
| `APPLE_SIGNING_ALTOOL_USERNAME`| username associated with the app-specific password. Must be an Apple ID with perms on the Certificate. Currently mine. |
This triggers a `workflow_dispatch` event on the `docker.yml` workflow or the matching
repository for both `zim-tools` and `kiwix-tools` targets that supports it.
Matthieu Gautier
renaud gaudin
Veloman Yunkan
ChrisLi
renaud gaudin