Update: Slicer 4.10 release will be initiated tomorrow morning

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:

  • fix for issue 4513 done
  • pull request 1029 will be integrated after the release
  • few fixes to the extension manager restore tab done

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.



Great news, the dashboard is green [1] and packages can be installed on all platforms, we will tag the repo shortly.


[1] with a splash of orange because of warnings. These will be addressed or ignored with CTest exceptions later.

1 Like

3 posts were split to a new topic: Why don’t we see Linux test result reported on CDash?


Remaining tasks:


  • 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: http://slicer.cdash.org/viewBuildError.php?buildid=1402918.


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


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

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

Original post in French

Hello JC

Tu as une date pour les binaries de Slicer 4.10 ?




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

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


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


  • 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


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


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


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 https://bugreports.qt.io/browse/QTBUG-61413.

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: https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-TNTAG201

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.

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.


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

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.


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


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.


Here it is :tada:


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.


:white_check_mark: External websites updated


  • 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



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


we should update the slicer.org top page.