Update: Slicer 4.10 release will be initiated tomorrow morning

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.

1 Like

Updates:

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

https://github.com/Slicer/Slicer/commit/b5386721e8162d5a3c07575d3335359039a4a38d

Hello JC
Do you have a date for slicer 4.10 binaries?
Thank you!
Sonia

Original post in French

Hello JC

Tu as une date pour les binaries de Slicer 4.10 ?

Merci!

Sonia

Updates

  • Release packages are back with the expected name. See CDash report

  • Windows package has been signed and is available for download.

image

  • Linux package has been marked as release and re-upload, it should shortly appear in the Nightly category.

image

  • Note that the macOS is NOT listed yet because I am looking into way for signing it.

Next steps

  • Hopefully sign the macOS package and mark it as release.
  • Update external website: nitrc and wikipedia
  • Finalize release announcements
  • Version NA-MIC data Update external website
  • Update ExtensionStats extension

More details

Release packages

image

The one test failure is related to test test_FiducialLayoutSwitchBug19141 and is most likely a false positive:

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:

  • 123 build reports on October 19th with the remaining 20 build reports on the October 18th on Linux
  • 143 build reports on macOS on October 19th
  • 131 build reports on Windows on October 19th. Not submitted are 12 extension reports:
    • DiffusionQC
    • DTIAtlasBuilder
    • LesionSpotlight
    • MatlabBridge
    • OpenCVExample
    • PathReconstruction
    • PortPlacement
    • ShapeQuantifier
    • ShapeVariationAnalyzer
    • SlicerPathology
    • SlicerVASST
    • SlicerVideoCameras
2 Likes

Update:

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

1 Like

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.

2 Likes

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.

Thanks for your patience,

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.

Source: Code Signing Tasks

To check that files are quarantined after downloading, you could do this:

$ ls -l@ ~/Desktop/Slicer.app/Contents/
total 8
drwxr-xr-x@  2 kitware  staff    68 Oct 19 00:33 Extensions-27501
        com.apple.quarantine      61
drwxr-xr-x@ 24 kitware  staff   816 Oct 19 01:54 Frameworks
        com.apple.quarantine      61
-rw-r--r--@  1 kitware  staff  1377 Oct 18 22:48 Info.plist
        com.apple.quarantine      61
[...]

improved signing scripts

Further testing revealed issues with the script that should new be addressed.

https://github.com/jcfr/macos-codesign-scripts/commits/master

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.

1 Like

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.

1 Like

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

My 2 cents
Andinet

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.

3 Likes

Et voila. macOS package is now signed and uploaded, it should be available on download.slicer.org shortly.

In the mean time, you can download if from http://slicer.kitware.com/midas3/folder/5380

image

Thanks to my colleague Chuck for his help setting up our macOS signing server as well as @ihnorton, @fedorov, @pieper and @rkikinis for testing.

We can now resolve issue 2708: Gatekeeper - Mac OSX 10.8 - Can’t open because it s from an unidentified developer opened back in 2012.

For more details, see updated Manually sign package step from the Slicer Release Process.

3 Likes

Here it is :tada:

image

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.

3 Likes

:white_check_mark: External websites updated

wikipedia.org

  • Updated version of Slicer. Page has also been updated to remove Tcl has an external dependency.
  • And worth noting the Critisism section has been removed by some third party. Details here

image

nitrc.org

  • Updated date of release associated with nitric download list.
  • Updated the Update_external_website step of the Slicer Release Process with corresponding details.

image

we should update the slicer.org top page.

I downloaded slicer and installed it. Everything works like a charm on the MAC. No error messages, just the notification that the software was downloaded from kitware.com

I am very happy. Thanks to all who contributed to this.

Best

Ron

2 Likes

This is indeed the last step of the release process. See Publish_Slicer_Announcement

Unless you think differently, I suggest we finalize the update as soon as we are ready to publish the document “Slicer 4.10: Summary, Highlights and Changelog”. See Slicer 4.10: Summary, Highlights and Changelog

Hi JC

Thanks for the clarifications.
Sounds good.

Best

Ron

I have updated the brew cask:

3 Likes

@jcfr just realized that nightly packages are not still signed. I guess this was expected, but took me a bit by surprise.