Package Details: fsl 6.0.7.7-1

Git Clone URL: https://aur.archlinux.org/fsl.git (read-only, click to copy)
Package Base: fsl
Description: A comprehensive library of analysis tools for FMRI, MRI and DTI brain imaging data
Upstream URL: http://www.fmrib.ox.ac.uk/fsl/
Licenses: custom
Submitter: fishburn
Maintainer: tobac
Last Packager: tobac
Votes: 12
Popularity: 0.000000
First Submitted: 2012-07-02 23:36 (UTC)
Last Updated: 2024-03-03 11:32 (UTC)

Dependencies (1)

Required by (4)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 15 Next › Last »

tobac commented on 2019-10-05 18:17 (UTC)

@maciex: Any progress?

This is a build.log from a successful build: https://gist.githubusercontent.com/tobac/8f2662b22510a0dd812250943d542539/raw/87c5d7b433f373558fab40768d8f4ed5d74c0c1c/build.log

As our log files' lines are suspiciously non-aligned when they describe the failing/working build of "fslsurfaces": Have you tinkered with the build script in any way? Did you try and parallelise the build? This would also make sense in the context of your error message: "file truncated" and I remember similar things happening when I tried to be clever and speed things up (not with FSL though).

Anyway, if you can't get it to work, I can upload my successfully built package and you could install that (if you trust me enough, that is). In that case I'd still recommend running the test suite FEEDS to ensure reliable results on your machine.

relo13 commented on 2019-10-04 11:32 (UTC)

Thanks a lot! I will work on that.

tobac commented on 2019-10-04 11:23 (UTC)

That's the exact same error Martin had a while back: https://aur.archlinux.org/packages/fsl/?O=20&PP=10#comment-687148

He solved it by installing python-deprecation: https://aur.archlinux.org/packages/fsl/?O=10&PP=10#comment-687271

If nothing else helps, you could try modifying the check() function of my PKGBUILD to exclude FEAT: change "time ./RUN all" on line 75 to "time ./RUN fdt fugue susan sienax bet2 melodic first fnirt" -> which runs all the checks except for FEAT. That's not a solution, but a workaround. At least we will know if any other checks fail.

relo13 commented on 2019-10-04 11:11 (UTC)

The build.log was successful, the error in check() is as follows:

Starting SIENAX (including testing BET and FLIRT and FAST) at vie oct 4 12:40:43 CEST 2019 child process exited abnormally while executing "fsl:exec "${FSLDIR}/bin/imcp $FEEDSDIR/data/structural $FEEDSDIR/results/structural"" invoked from within "if { $feeds(sienax) } {

puts "\nStarting SIENAX (including testing BET and FLIRT and FAST) at [ exec date ]"

fsl:exec "${FSLDIR}/bin/imcp $FEEDSDIR/..." (file "./RUN" line 233) ==> ERROR: A failure occurred in check(). Aborting...

real 0m16,620s user 0m16,092s sys 0m0,294s Error making: fsl

tobac commented on 2019-10-04 11:04 (UTC)

Are you in the right directory? Are you building the package manually (i.e. with makepkg) or are you using an AUR helper? With yay, for example, the "." in "./src/fsl" would be "~/.cache/yay/fsl".

Could you post the entire error message? The one you posted seems incomplete.

relo13 commented on 2019-10-04 11:00 (UTC)

The build worked fine but I got an error in the check when checking SIENAX: fsl:exec "${FSLDIR}/bin/imcp $FEEDSDIR/..." (file "./RUN" line 233)

Also there is no ./src folder, still could not check the build.log file...

tobac commented on 2019-10-04 10:34 (UTC) (edited on 2019-10-04 10:41 (UTC) by tobac)

@relo13: build.log is in ./src/fsl/

If there is no error, you probably just need more patience. It does take a long time to compile. (You can, of course, check for progress in build.log)

@maciex: Seems like the project genuinely failing to build is "fslsurface". All the other failed builds seem to depend on either "fslsurface" or one of the consequently failing projects. I'm trying to debug this..

maciex commented on 2019-10-03 17:23 (UTC)

https://raw.githubusercontent.com/maciexZ/test/master/build.log

tobac commented on 2019-10-03 08:20 (UTC)

It would be helpful if you pasted your entire build.log somewhere (e.g. use one of those pastebin services or whatever best practice is at the moment).