# LabelErodeDilate And other remote module failures
**URL:** https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634
**Category:** Engineering
**Created:** [January 30, 2018, 5:06pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634 "2018-01-30T17:06:12Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [January 30, 2018, 5:06pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/1 "2018-01-30T17:06:12Z")
The hash specified for the LabelErodeDilate remote module does not exist in the repository;
[https://open.cdash.org/viewConfigure.php?buildid=5240282](https://open.cdash.org/viewConfigure.php?buildid=5240282)
The InsightSoftwareConstorium repo is the one used by ITK, the repo is also a from from richaredbeare.
I am not sure what is going on here:
> **[InsightSoftwareConsortium/ITKLabelErodeDilate](https://github.com/InsightSoftwareConsortium/ITKLabelErodeDilate/network)**
>
> Erode and dilate operations on label images. Contribute to InsightSoftwareConsortium/ITKLabelErodeDilate development by creating an account on GitHub.
But I think this issue is causing my remote builds to STOP with this module, and not build further.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [January 30, 2018, 5:48pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/2 "2018-01-30T17:48:57Z")
I think @hjmjohnson forked a few repositories into `InsightSoftwareConsortium` recently. That change is a possible culprit.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [January 30, 2018, 7:17pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/3 "2018-01-30T19:17:13Z")
Similarly the MGHImageIO seems to have a similar error:
[https://open.cdash.org/viewConfigure.php?buildid=5240375](https://open.cdash.org/viewConfigure.php?buildid=5240375)
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [January 31, 2018, 2:29pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/4 "2018-01-31T14:29:10Z")
Who is working on fixing the remote module URLS/Hashes?
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [January 31, 2018, 2:35pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/5 "2018-01-31T14:35:01Z")
Before we start working on the fix, it would be good to have @hjmjohnson’s input since he is the one who updated the SHAs. From what I can see on the MGHImageIO module repo, it looks like there are [some PRs pending](https://github.com/Slicer/itkMGHImageIO/pulls) and this is most likely what the new SHA is suppose to point to. Pinging @lassoan and @jcfr on this one too, since `MGHImageIO` is part of Slicer. I am looking at the other one, LabelErodeDilate.
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [January 31, 2018, 2:50pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/6 "2018-01-31T14:50:46Z")
`LabelErodeDilate` master has diverged on [InsightSoftwareConsortium](https://github.com/InsightSoftwareConsortium/LabelErodeDilate/commits/master) from the [original repository](https://github.com/richardbeare/LabelErodeDilate/commits/master).
[A patch](http://review.source.kitware.com/#/c/23129) has been submitted to ITK to point to the upstream repository to download and compile the latest version of the module.
A [new branch has been created in the InsightSoftwareConsortium repository](https://github.com/InsightSoftwareConsortium/LabelErodeDilate/tree/master-InsightSoftwareConsortium-2016.03.13) to keep track of the diverged branch.
If everybody agrees, I will overwrite the InsightSoftwareConsortium master branch with the upstream master branch.
---
### Author:  [@jhlegarreta](https://discourse.itk.org/u/jhlegarreta)
#### Post date: [January 31, 2018, 3:45pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/7 "2018-01-31T15:45:41Z")
@fbudin’s plans looks OK to me.
Although @richard.beare is an active contributor of the community, IMHO we should have some **mechanism, policy or procedure** (e.g. in some `*.md` file of the ITK repo) by virtue of which we **decide when to fork** the repo **to the [InsightSoftwareConsortium](https://github.com/InsightSoftwareConsortium)** (e.g. the original repo has been inactive for a long time) (and thus when to change the repo pointed by `*.remote.cmake`), or why to fork or not a repo (e.g. if by any chance the repo gets removed by its user, do we/does GitHub have ways to get its contents transparently; assume nobody has cloned it/has removed clones?)
May be this is tribal knowledge, but may be when we get some time (e.g. after the current heavy workload period), we should write it down?
Now, we may have forked some of these in the last days to avoid waiting for upstream PR’s be accepted. I guess this is relatively easy to fix for the ones having @richard.beare or @jcfr as their owners.
---
### Author:  [@jcfr](https://discourse.itk.org/u/jcfr)
#### Post date: [January 31, 2018, 3:56pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/8 "2018-01-31T15:56:37Z")
> [@fbudin](#):
>
> From what I can see on the MGHImageIO module repo, it looks like there are some PRs pending and this is most likely what the new SHA is suppose to point to
@fbudin Thanks for the reminder, these will be integrated shortly.
---
### Author:  [@richard.beare](https://discourse.itk.org/u/richard.beare)
#### Post date: [January 31, 2018, 8:14pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/9 "2018-01-31T20:14:00Z")
I’ve recently accepted PR from @hjmjohnson that updated the various override settings. Perhaps there is another change that was never propagated. If so, please send another PR. I’m happy for the InsightSoftwareConsortium versions to become the versions referenced by the build tree. I’m certainly not doing active development on this code. It would be nice if the PRs were sent to keep the repos synced, but obviously not essential.
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [January 31, 2018, 8:25pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/10 "2018-01-31T20:25:31Z")
@richard.beare Thanks for chiming in. The divergence between the two master branches come from the fact that a year ago maybe, the same commit was merged independently in your repo and in the forked repo. Those two different merges ended up having different SHA (probably not the same person merging, different time or day,…), so there is nothing we can do to make these two repo synchronized in a clean way. But what I will do is that I will force push your master branch in the forked repo, so that they are synchronized again. The bad master branch in the fork was moved to [`master-InsightSoftwareConsortium-2016.03.13`](https://github.com/InsightSoftwareConsortium/LabelErodeDilate/tree/master-InsightSoftwareConsortium-2016.03.13).
---
### Author:  [@richard.beare](https://discourse.itk.org/u/richard.beare)
#### Post date: [January 31, 2018, 8:37pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/11 "2018-01-31T20:37:37Z")
Thanks, I’m happy with whatever you recommend.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 2, 2018, 2:12pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/12 "2018-02-02T14:12:26Z")
Thank you for updating the remote!
Looking into further why the nightly remotes are stoping. Some builds are using the following code in the CTest script driver:
```auto
foreach(itk_module ${itk_remote_modules})
set( CTEST_BUILD_NAME "Linux-x86_64-gcc4.8-${itk_module}")
set( CTEST_DASHBOARD_ROOT "/scratch/dashboards/Linux-x86_64-gcc4.8-remotes" )
set( CTEST_NOTES_FILES )
# don't do a list concatination to form dashboard_cache,
# just embed one string inside the other
set(dashboard_cache "${dashboard_cache_base}
Module_${itk_module}:BOOL=ON
")
set(CTEST_TEST_ARGS INCLUDE_LABEL ${itk_module})
include(${CTEST_SCRIPT_DIRECTORY}/../ITK-dashboard/itk_common.cmake)
endforeach()
```
But the itk\_common.cmake driver terminates then there is a build error:
>
So this is why not all the nightly remotes are being build. Likely there was some additional change with the behavior of ctest with the recent updated to 3.10-ish that exposed this issue.
@matt.mccormick @fbudin
Now what is the recommended way to fix this problem with the dashboard scripts?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 2, 2018, 2:16pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/13 "2018-02-02T14:16:07Z")
> [@blowekamp](#):
>
> Now what is the recommended way to fix this problem with the dashboard scripts?
Every CTest script build should be a separate process.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 2, 2018, 2:20pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/14 "2018-02-02T14:20:18Z")
Do you know if [ctest\_run\_script([NEW\_PROCESS]…)](https://cmake.org/cmake/help/v3.10/command/ctest_run_script.html) is used if the current variable context is propagated to the new process?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 2, 2018, 2:30pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/15 "2018-02-02T14:30:19Z")
> [@blowekamp](#):
>
> Do you know if ctest\_run\_script([NEW\_PROCESS]…) is used if the current variable context is propagated to the new process?
Depending on how it is called, that is what the documentation suggests:
> If no argument is provided then the current script is run using the current settings of the variables.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 7, 2018, 3:27pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/16 "2018-02-07T15:27:20Z")
I have not been able to update the script above to preserve the CMake variable while running `itk_common.cmake` multiple time.
It is very convenient running the remote builds in a for loop. Any suggestions on how to update our processes for building the remotes nightly?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [February 7, 2018, 6:15pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/17 "2018-02-07T18:15:01Z")
A Bash or Python script can also be used to run the builds in a for loop.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [February 7, 2018, 6:27pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/18 "2018-02-07T18:27:35Z")
Yes, the limitation of using ctest to call a set of nightly ctest scripts is apparent. I originally choose chest because of these other options not being standard on windows.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [February 7, 2018, 6:28pm UTC](https://discourse.itk.org/t/labelerodedilate-and-other-remote-module-failures/634/19 "2018-02-07T18:28:05Z")
An example script attached.
[corista.sh](https://discourse.itk.org/uploads/default/original/1X/fbff748760a14aa7ac44f18145cd19b3e88feab5.sh) (1.0 KB)