Tonight we will let the regular nightly build take place, then after we confirm the build complete on all platforms with all tests passing and package successfully created and working, we will abort the nightly build script and initiate the build of the release package.
In the mean time, few more commits will be integrated:
pull request 1029will be integrated after the release
few fixes to the extension manager restore tabdone
Also, since we will abort the nightly build, you should not expect all nightly extensions to be available, instead they will be available with the upcoming release.
The dashboard project has not been renamed from Slicer4 to SlicerStable. This will happen for either Slicer 4.10.1 or Slicer 5.0.0. This is tracked by issue 4644
@jcfr I do not know if this is a transient issue, and whether it is related to the new release (the name of the build directory includes ‘4100’), but there is this new build error for the dcmqi extension: CDash.
Good catch. This is fixed in the following commit, I will delete the current extension build tree on factory-south-macos and re-launch the extension build script.
As a side note, the build were submitted on SlicerPreview but they should have been submitted on Slicer4 (soon to be SlicerStable). This is where the next submission will be posted.
Wiki has been updated. The News page has been updated with a banner at the top to reference the Slicer forum. History of the transition has also been documented on that same page.
mantis release list has been updated
A priori no nightly build tonight. Indeed, in the process of signing the package, I also realized they had the wrong name, the dashboard driver script has been fixed and package are being regenerated.
Checking the difference between fiducial RAS position [33.4975, 79.4042, -10.2143] and volume RAS as derived from the fiducial display position (33.857864050053124, 78.85677006484119, -11.214302062988281) : 1.19563619402
RAS coordinate difference is too large as well!
Expected < 1 but got 1.19564
Extension packages
There are a total of 143 description files in the 4.10 branch of the extensions index repository.
A total of 397 build reports were submitted on October 19th and the remaining on October 18th including:
sign the macOS package: This will wait Monday, the manager of our Apple account need to accept the updated Apple Developer Program License Agreement before we can access our existing certificates. (Note that the tagged package will still appear as generated on October 19th like the Linux and Windows one.)
nightly build: after we are done investigating the extension build failure on Windows, the nightly will be restarted.
To follow up, now that the new license terms have been accepted, I was able to download the signing certificate. Next step will be to also get the associated private key and this should happen tomorrow.
Nightly build have been resumed on all platforms. I will share more details about extensions build failure later.
Good news, we were able to sign the DMG package along with all the executables, libraries and frameworks. (thanks to my colleague Chuck A.). Basically the process is:
Extract the eula from the DMG
Mount the DMG
Fix up broken embedded frameworks
Sign the app bundle with --deep
Unmount the dmg
Re-insert the eula
Sign the DMG
That said, when starting the application, the verification process was still failing complaining that the identity of the developer cannot be confirmed which was surprising because command like spctl -a -t exec -vv ./Slicer.app returned that the application was accepted.
It turns out that the libraries and executables bundled in the package still contain references to rpath referencing the build directories. This is causing the verification process to fail. Until now, this was not an issue because the library loader tries all paths until it finds a good one.
Inspecting the system log revealed error like this one:
Oct 24 23:50:08 factory-south CoreServicesUIAgent[3231]: Error -60005 creating authorization
Oct 24 23:50:24 factory-south CoreServicesUIAgent[3231]: File /Users/kitware/Desktop/Slicer.app/Contents/lib/Slicer-4.10/cli-modules/libACPCTransformLib.dylib failed on rPathCmd /Volumes/Dashboards/Stable/Slicer-4100-build/CTK-build/CMakeExternals/Install/lib/lib/Slicer-4.10/libMRMLCore.dylib
Oct 24 23:50:24 factory-south CoreServicesUIAgent[3231]: Fails dylib check
An internet search then revealed a similar error within Qt (that is now fixed), see Loading....
Later tomorrow, we will patch all libraries removing references to the build tree and re-sign.
definitive way to check that the signature is correct
Further reading revealed that to check if code-signing on macOS works as expected, the package must be downloaded from a website or sent by email, this ensures that the downloaded package is quarantined and will ensure that gatekeeper proceed to the verification.
Also, after we are done with this release, the Slicer build system will be improved and the script will be simplified.
why does it take so long ?
It is the first time we sign Slicer-based macOS package, after we are done addressing the issues with this release. Follow-up macOS releases of Slicer will happen more quickly.
next
Later this evening or tomorrow, I should have access to our dedicated code-signing macOS workstation, this should allow us to code-sign the current release as well as more efficiently sign packages in the future.
Thank you Jc for working on this. This will make Slicer installation much easier on MacOS.
Instead of packaging of 4.10.0, would it be possible to release 4.10.1 instead (from the content of current master)? There have been a few fixes (freesurfer surface reading, updates of imported nodes in subject hierarchy tree, vector to scalar volume converter, vector volume segmentation fix, etc. ) which are all low risk and would be useful to have in the stable version.
I would suggest finishing packaging 4.10 properly first. So, we do everything right and fully.
Then after a week or two, we can start looking at 4.10.1 release. In the meantime, folks will have more time to test and report issues on the 4.10 release
Good news. I now have access to our macOS signing station and a quick test this afternoon confirmed I could unlock the keychain and access the key from the hardware token.
But in the mean time, the hardware token was un-plugged from the keyboard USB plug and plugged on the back of the wrong macOS workstation … (indeed there are multiple macOS stacked).
This will be addressed tomorrow morning.
In the short term we will be able to manually sign all future macOS stable releases like we already do for windows releases.
And longer term, we will also have our infrastructure ready for automatically signing macOS and windows releases every night.
And as you may notice, the built date appears as 2018-11-01 which in fact set based on the creation date of the item in the data system and not the build date. See here and here.
External websites updated
