FSL itself is a standalone tool that also needs to be packaged. fslpy etc are a different set of tools!

The Whats New page describes the many tools that are included in FSL and each requires separate testing.

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/WhatsNew

The FEEDS package will be added as an issue and includes some test data and its script generates output/reports

I'll work on FSL and related tools next. These seem widely used.

The sources for FSL that are made available are 1.5 Gigs in size? Really?

https://fsl.fmrib.ox.ac.uk/fsldownloads/fsl-6.0.0-sources.tar.gz

I cant see us uploading this to the fedora build system and so on.

It bundles all of boost, and the full wiki sources. Any one if one can just get the sources to the tools?!

Let me know how you want to proceed. There are a number of C/C++ tools that can be separated and then there are a number of scripts that combine certain of them together to make a new tool. All these issues will come up with FreeSurfer as well. Like I put in the comments for FIX, it is 2.7GB so you can see why it is kept separate.

Let me also mention something that I think is an important contribution from NeuroDebian. The script fsl_sub is a wrapper on qsub from SGE (now OGE I think?). There are a number of tools that automatically parallelize work with fsl_sub. NeuroDebian has modified fsl_sub (since it was hardcoded for FMRIB's cluster) to work with condor in SGE mode. On a multicore system this can be very useful and at worst is an efficient queuing system.

I'm going to try and build FSL as is. Most of the tar is data---atlas files and so on. If we can't upload it all, we can strip out these:

$ du -sch *
4.0K    build
456K    config
1.4G    data
184M    doc
352K    etc
557M    extras
4.0K    LICENCE
4.0K    README
26M     src
2.2G    total

There's a lot of old software bundled in there, such as newran02 (http://www.robertnz.net/nr02doc.htm#files). I don't think they're used anywhere else at all, so initially, I'll bundle them.

qsub is only useful when running on clusters, right? We use it with torque on ours. Condor doesn't seem maintained now, is it? (http://gridscheduler.sourceforge.net/). We can provide neurodebian's fsl_sub, but given that our primary target audience currently is workstation users, I'm not too worried about it at the moment.

I think we need a few folks that use all the neuroimaging software that we're packaging to help here---not just so they can test it, but also so that they can help us with the packaging.

We can package stuff up, but if we maintainers don't use the software, we're not going to know if it's done correctly etc.

I've started working on it now. I have a decent handle over what the requirements are. Shouldn't be harder than any normal software:

https://github.com/sanjayankur31/rpm-specs/blob/fsl/fsl.spec

Happy to put out emails to the big NI mailing lists and solicit testers rather than packagers. The FEEDS package and the tools it tests would be a start for FSL at least.

newran02 that's a blast from the past. I believe the plan is to move to Armadillo but there are plenty of old tools that will keep that dependency I am sure.

Happy to put out emails to the big NI mailing lists and solicit testers rather than packagers.

That'd be nice. Should we get more stuff in and make a formal annoucement, and that can include our request for testers etc too? I'm going to do the same thing for the comp-neuro tools. I'm just waiting on getting neuron, and Pynn packaged up.

I will check on condor/torque etc.. fsl_sub needs to be modified and given an agnostic default or things will fail out of the box with tools like FEAT, performing OVBM (using FAST scripts) and certain FDT commands when given multiple sessions or subjects. I will check fsl_sub in 6.0 and see if it is at all different. Sorry, I am jumping ahead to user testing in some ways but just a heads up.

E-mailed legal to confirm if the license is appropriate. If not, we cannot include it in NeuroFedora.

https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/YWAKCEOYOMS7EVB6ZVN6KLJLI3CV4ZTD/

The situation is pretty clear: this license is not acceptable. Maybe it would be possible to reach out that university and try to explain the situation and ask them to change the license?

That'd be the way to go. I'll wait for Legal to reply and see if they have any suggestions.

Unfortunately, neuroimaging isn't my area, so I don't have the knowledge, the resources, or the contacts to work on this licensing issue. So, I'm going to drop this for the time being.

@mhough : you'd already indicated that the license may be an issue. Would you know any folks that can help with this?

A temporary workaround would be to document how people can install FSL on their systems, as part of our documentation? Thoughts?

Looking again at NeuroDebian, that=E2=80=99s actually what they are doing w=
ith an
added PPA. If we made a stable NeuroFedora copr that only included tools we
can=E2=80=99t include in Fedora, it would be the same thing NeuroDebian is =
doing,
yes?

There is also working with FMRIB (now WIN) to build a better set of Fedora
binaries and include them through the FSL Python installer.

FYI, NeuroDebian also uses a package to emulate Sun (Oracle) Grid Engine
qsub that should be addressed that is separate from building the binaries.

The other issue that comes up with FSL on NeuroDebian is the lack of GPU
support. It makes a dramatic difference especially with the probabilistic
diffusion processing pipeline. I use RPM Fusion to add CUDA which is of
course another option for FSL distribution or at least the FSL-GPU tool
version.

Also, the data problem becomes even more difficult with FSL FIX but the R
and Octave code is very small. It=E2=80=99s an extremely useful addition to=
FSL but
bundled separately because of the data size.

On Sun, May 31, 2020 at 03:43 Ankur Sinha pagure@pagure.io wrote:

ankursinha added a new comment to an issue you are following:
A temporary workaround would be to document how people can install FSL on their systems, as part of our documentation? Thoughts?

To reply, visit the link below or just reply to this email
https://pagure.io/neuro-sig/NeuroFedora/issue/57

With the current license, we cannot use COPR either:
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr

We may be able to work with RPMFusion but we'll need to check. If we can, I'm not sure if their infra can manage the build:
https://rpmfusion.org/FAQ#What_is_RPM_Fusion.3F

I'd rather not get into GPU packages just yet---that's quite beyond the scope of NeuroFedora. We don't have the man-power and they require lots of work to ensure things work on different hardware. They pretty much also require you to ensure that the binary nvidia drivers work, so that's a black hole we should avoid.

Improvements to FSL that you specify will remain on hold until we have a basic package.

Working with upstream is what the maintainer does and the maintainer really does need to know the tool well and have some idea of how it works. So, until we have a maintainer all the optimisations you mention are also on hold. So, lots that can be done but no one to do it at the moment.

The license is a primary blocker.

I brought up some issues on the FSL mailing list about their current
instructions and installer in response to a question from someone trying to
build on arm.

I asked Matthew Webster if they would be willing to distribute our build.

Can I test the spec file you have with the current 6.0.3 source? Thanks

On Tue, Jun 2, 2020 at 11:43 Ankur Sinha pagure@pagure.io wrote:

ankursinha added a new comment to an issue you are following:
``
With the current license, we cannot use COPR either:

https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr

We may be able to work with RPMFusion, but not sure if their infra can
manage the build:
https://rpmfusion.org/FAQ#What_is_RPM_Fusion.3F

I'd rather not get into GPU packages just yet---that's quite beyond the
scope of NeuroFedora. We don't have the man-power and they require lots of
work to ensure things work on different hardware. They pretty much also
require you to ensure that the binary nvidia drivers work, so that's a
black hole we should avoid.
``

To reply, visit the link below or just reply to this email
https://pagure.io/neuro-sig/NeuroFedora/issue/57

The spec isnt complete so its not in a usable state (im not going to work
on it until we know its worth the packaging effort)

WIP spec: https://pagure.io/neuro-sig/fsl/blob/master/f/fsl.spec

I asked Matthew Webster if they would be willing to distribute our build.

PS: this is not what we want. We want the license changed so that anyone can use + share + distribute our package. Only then can it be part of Fedora/NeuroFedora and the neuro-imaging ISO that we want to release.

Us building it separately for the devs doesn't really serve much purpose. Folks are better off installing it themselves in that case. The installer is quite straightforward to use.

Added to the excluded tools page in docs for the time being.

We can re-visit this when we have resources. Closing for now.

https://pagure.io/neuro-sig/documentation/c/ca80c83e72a5f0639be7736b9fe2dc6d9f9ff881?branch=master

https://docs.fedoraproject.org/en-US/neurofedora/excludedtools/

(will show up after the next docs rebuild)

It can perhaps be included in RPM Fusion (but it won't make it to our ISO).

Noting this here, but not re-opening the issue:

https://rpmfusion.org/FoundingPrinciples