Package Details: afni 22.1.09-1

Git Clone URL: https://aur.archlinux.org/afni.git (read-only, click to copy)
Package Base: afni
Description: An open-source environment for processing and displaying functional MRI data
Upstream URL: http://afni.nimh.nih.gov
Licenses: custom
Submitter: crmullins
Maintainer: liamtimms
Last Packager: liamtimms
Votes: 1
Popularity: 0.000000
First Submitted: 2016-06-29 01:28 (UTC)
Last Updated: 2022-05-10 20:56 (UTC)

Pinned Comments

liamtimms commented on 2022-05-10 20:27 (UTC)

AFNI releases get tagged with a frequency approaching individual git-commits (sometimes multiple times in one day). I update this package semi-regularly to keep it current but do not update it for every single AFNI release tag to avoid excessive burden on users. Please do not flag this package "out-of-date" without some technical justification. If the constant bleeding edge is required for your use case, I recommend using a -git package or using this PKGBUILD as a base and updating to each release tag yourself.

ptaylor.afni commented on 2022-01-21 15:02 (UTC)

@keiichiiownsu12 :

  • Sure, workflow for reporting ArchLinux-AFNI issues could certainly go in that order (i.e., start this forum). I can also be pinged, too, though packaging questions will likely have to be dealt with by smarter folks...

  • Re. packaging: All the datasets for the distribution should just be in one places now (https://afni.nimh.nih.gov/pub/dist/atlases/atlases_current.tgz), whether you unpack+distribute it (which is what we do with the main distributions) or you ask people to get it separately. So, whatever you decide, hopefully it is simpler now.

Latest Comments

liamtimms commented on 2022-05-10 21:16 (UTC)

@ptaylor.afni sorry for the confusion; a user flagged the package as out of date despite being on the current major version number. That happens occasionally, and I commented so I would have a notice pinned on this page to reduce the number of times the package is flagged "out-of-date."

ptaylor.afni commented on 2022-05-10 20:55 (UTC)

@limmtimms: I am not sure to whom this comment is directed: https://aur.archlinux.org/packages/afni#comment-864477 ... but re. AFNI build frequency: it is true, we do "micro-version-number-level" builds fairly often, probably once a week on average or occasionally more rapidly.

We do "minor-version-number-level" builds 4 times per year: those happen on the first build after Jan. 1, Apr 1, Jul 1, and Oct 1.

liamtimms commented on 2022-05-10 20:27 (UTC)

AFNI releases get tagged with a frequency approaching individual git-commits (sometimes multiple times in one day). I update this package semi-regularly to keep it current but do not update it for every single AFNI release tag to avoid excessive burden on users. Please do not flag this package "out-of-date" without some technical justification. If the constant bleeding edge is required for your use case, I recommend using a -git package or using this PKGBUILD as a base and updating to each release tag yourself.

liamtimms commented on 2022-01-25 20:59 (UTC)

@ptaylor.afni great, thanks for the info. I will try to look at this week. I recognize that Arch Linux is not an intended target for AFNI and appreciate your time and attention.

ptaylor.afni commented on 2022-01-21 21:13 (UTC)

Hi, again, @liammtimms and @keiichiiownsu12:

And already, an update on packaging: at our group meeting today, we decided that if we were going to change the packaging of the datasets distributed with the binaries, then we might as well make the file/directory name more meaningful. Therefore, the now-and-hopefully-future place to get the datasets for distribution is: https://afni.nimh.nih.gov/pub/dist/atlases/atlases_current.tgz

The webpage docs are rebuilding to reflect this. Sorry for the hassle, and we promise not to change it again for at least a half hour.

liamtimms commented on 2022-01-21 15:18 (UTC) (edited on 2022-01-21 15:20 (UTC) by liamtimms)

Hi @ptaylor.afni thanks for your helpful comments. @keiichiiownsu12 if you want to help with packaging let me know and we can collaborate on that. If you can, email me patches. I'll add you as a co-maintainer if you want to take the lead on this. Most of my free time dealing with AUR Neurimaging/MRI fixes has been focused on trying to get FSL working recently.

ptaylor.afni commented on 2022-01-21 15:12 (UTC)

@keiichiiownsu12 and @liammtimms:

Re. Python, PyQt4 and uber_*py GUI programs in AFNI:

  • All AFNI Python programs are both Python v2 and v3 compatible (*excepting the distributed "meica.py" program, which is a bit of a legacy program for multi-echo FMRI from Kundu et al. (2011), which that first author wrote but not longer maintains---there are newer MEICA code projects around, so we keep this code available for comparisons for them).

  • PyQt4 should technically be available in Python v3 --- see https://pypi.org/project/PyQt4/ --- but in practice it is difficult to install. I have been trying some basic conda environment building with it, but there are glibc conflicts and some other package conflicts (even though AFNI's Python module dependencies are very light at present---basically just MatplotLib, and maybe a bit of NumPy). So, this is still slightly an 'in progress' check for how to get this to work in Python3 at present.

  • But, this Python3-PyQt4 issue has not been such a burning one, because we mostly recommend that people go to the afni_proc.py example list from the program help (https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/programs/afni_proc.py_sphx.html#ahelp-afni-proc-py) or the Codex of examples (https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/codex/main_toc.html) or the Bootcamp tutorial scripts as starting points, and build from there. Those show much more flexible and complete sets of options to start from. So, we basically don't consider PyQt4 a dependency, and don't worry about it (sorry, uber_subject.py)---even the "afni_system_check.py" doesn't bother about it as a Fix for users anymore.

  • That being said, we do have plans to go back to the GUI-for-setup analysis, probably with PyQt5 or some other basis, in the future. But it will have a more modern dependency.

ptaylor.afni commented on 2022-01-21 15:02 (UTC)

@keiichiiownsu12 :

  • Sure, workflow for reporting ArchLinux-AFNI issues could certainly go in that order (i.e., start this forum). I can also be pinged, too, though packaging questions will likely have to be dealt with by smarter folks...

  • Re. packaging: All the datasets for the distribution should just be in one places now (https://afni.nimh.nih.gov/pub/dist/atlases/atlases_current.tgz), whether you unpack+distribute it (which is what we do with the main distributions) or you ask people to get it separately. So, whatever you decide, hopefully it is simpler now.

keiichiiownsu12 commented on 2022-01-21 14:53 (UTC)

Thanks so much for taking the time to comment @ptaylor.afni . Re:atlases, @liamtimms, maybe we could use the provided tgz links as a separate package? (maybe call it afni-data or afni-atlases).

Re Issue reporting: it might be good for people to still first report here if they have issues, since those usually arise from packaging-specific things (e.g. build dependencies).

If I find any issues in compilation or non packaging issues, I'll be sure to report on the github page!

ptaylor.afni commented on 2022-01-21 14:27 (UTC) (edited on 2022-01-21 14:28 (UTC) by ptaylor.afni)

Re. the atlases distributed in AFNI (relevant for @liamtimms):

  • we have simplified the packaging of these, so that the single tarball "atlases_current.tgz" from https://afni.nimh.nih.gov/pub/dist/atlases/ should be all that is needed. Note that untarring that file should not splash files around the PWD, either, anymore... yikes.

Re. this comment "REALLY wish they'd make this easier to find...: link to other atlas files..." (relevant for @keiichiiownsu1 and @kcdah):

  • We have added a new webpage to the main documentation (https://afni.nimh.nih.gov/pub/dist/doc/htmldoc/template_atlas/other_tas.html), listing+linking all the templates and atlases (it is under the "Templates & Atlases" section, as well as under the "Non-human processing" one, because both human and non-human datasets are contained there). We do welcome helpful suggestions---again, we have a higher chance of seeing them on the project github page.

ptaylor.afni commented on 2022-01-21 14:19 (UTC) (edited on 2022-01-21 14:19 (UTC) by ptaylor.afni)

Hi- We are happy to see this project of building+distributing AFNI on ArchLinux systems. Please ping us with any questions, as they arise. It might be easiest to do so via an Issue on the project's main github page: https://github.com/afni/afni

A couple of notes about issues raised here already, since the discussions did make it to the github page (and sorry, I don't see how to reply to a thread directly):

nikinbaidar commented on 2022-01-11 02:07 (UTC) (edited on 2022-01-14 12:23 (UTC) by nikinbaidar)

Hello, I am very new to AFNI. I installed it with yay and updated my path var as PATH=${PATH}:/opt/afni. AFNI runs and all but I cannot find the 3DSkullStrip program. The output of ls /opt/afni | grep -i skull is @NoisySkullStrip @SkullStrip_TouchUp

Where can I find the 3DSkullStrip? Or is it even installed?

Edit:Okay turns out suma needs to be installed to run that program. But I am not sure how to do that either.

liamtimms commented on 2021-12-20 17:06 (UTC)

Running into this error on the latest version of AFNI and have not had time to investigate further so I'm not updating the PKGBUILD to the most recent release for a while:

/usr/bin/ld: ./libcoxplot.a(pwritf.o):(.bss+0x80): multiple definition of `zzzplt_'; ./libcoxplot.a(ppak_commons.o):(.bss+0xc0): first defined here
/usr/bin/ld: ./libcoxplot.a(pwritf.o):(.bss+0x0): multiple definition of `zzpltr_'; ./libcoxplot.a(ppak_commons.o):(.bss+0x40): first defined here
/usr/bin/ld: libXmHTML.a(LZWStream.o): in function `LZWStreamInit':
LZWStream.c:(.text+0xdd3): warning: the use of `tmpnam' is dangerous, better use `mkstemp'

liamtimms commented on 2021-07-02 16:50 (UTC)

@keiichiiownsu12 thanks I generally only use the CLI and haven't done any GUI testing. If you figure out what is causing those segfaults and how to fix them I'd gladly add you as a co-maintainer. For question about python2 and python3 there's a concept in Arch to handle that called "split packages" which can provide both versions, however I haven't tested or looked at whether that actually makes sense here.

keiichiiownsu12 commented on 2021-07-01 00:04 (UTC)

@liamtimms some afni python programs are able to open a GUI (e.g. uber_ttest.py), but they require python-pyqt4 as a dependency. Maybe you can include it as an optional dependency? (or a similar package). Though some GUI python commands (e.g. uber_subject.py) segfault when run... Maybe there is a package that can work for BOTH python3 and python2?

More of an advisory: most python programs appear to be written in python2 (for whatever reason). Python3 compatibility seems to be...variable for most. If you run into problems, just execute them with a python2 interpreter python2 `which <cmd>.py`

kcdah commented on 2021-05-06 23:01 (UTC)

Oh geez my bad, yes that did it @keiichiiownsu12. Thanks so much!

keiichiiownsu12 commented on 2021-05-05 22:00 (UTC)

@liamtimms the first atlas tar.gz file I linked is ~134 M uncompressed. Might be better to include as a separate package. However, things get a little dicey, since the atlas_latest.tar.gz file does not contain all atlases included in the normal binary package. and unfortunately afni doesn't exactly say which file is preferred...I'll do some more digging if you like me to find out.

keiichiiownsu12 commented on 2021-05-05 21:47 (UTC)

@kcdad have you added afni to your path? if you type export PATH=$PATH:/opt/afni, are you able to run the afni command?

kcdah commented on 2021-05-05 20:31 (UTC)

I'm sorry, I must be doing something obviously wrong. But after I install this, I cannot get afni to start (afni is not seen as a command). I tried to follow steps on the afni website seen on other installations (installed R, for example) but it is not clear to me what else I need to do in order to get afni to be a command and get the program to start. Thanks for the help.

liamtimms commented on 2021-05-05 15:50 (UTC) (edited on 2021-05-05 15:53 (UTC) by liamtimms)

@keiichiiownsu12 cheers, thanks. Do you think it would make more sense to try to include these in the default install from this AUR PKGBUILD or in a separate PKGBUILD? How much disk space are they taking after install (and unpacking?) on your machine?

For reference, here is the Neurodebian package I mentioned: https://neuro.debian.net/pkgs/afni-atlases.html?highlight=afni

The Arch "KISS" approach seems to imply these should probably be included here rather than separated out but if they end up being too massive it might make sense to keep them separate.

keiichiiownsu12 commented on 2021-05-05 03:25 (UTC)

REALLY wish they'd make this easier to find...: link to other atlas files

keiichiiownsu12 commented on 2021-05-02 23:33 (UTC)

@liamtimms looks like it's much simpler than either of us thought. There is a file called "atlases_latest", found here. After the files are extracted, if one places them in /opt/afni (or whichever location afni binaries are stored), the atlases are immediately available for use.

liamtimms commented on 2021-05-02 21:53 (UTC)

@keiichownsu12 I made a PKGBUILD for python-datalad if you want to try to testing it with that afni_data repo.

liamtimms commented on 2021-05-01 19:52 (UTC) (edited on 2021-05-02 00:06 (UTC) by liamtimms)

hi @keiichiiownsu12 I'm actually not sure as I'm mostly using FSL for atlas fitting. There might be a flag as you suggest but it's not obvious from the documentation. You could try packaging a binary version of it and sharing it on the AUR, it seems like the binaries include the atlases based on the AFNI site.

Poking around a little I did just find this: https://github.com/afni/afni_atlases but I'm not sure why they have it "archived." It might be a good idea to check upstream to see what they recommend. If you can find out the best way to do it with that, I'd be happy to include an atlas download step in this PKGBUILD or you could make a separate AUR entry for the atlases (I think Neurodebian does this).

edit: looks like they have them over here now https://github.com/afni/afni_data it uses DataLad which we definitely should package for Arch if it hasn't been yet. Maybe that's the right place to start.

keiichiiownsu12 commented on 2021-04-30 23:36 (UTC)

How might I go about installing some of the default atlases afni is shipped with? E.g. the Talairach daemon. Is it a flag I need to set in the Makefile? Can I just download the atlas from the afni website and drop them into /opt/afni?

martin3141 commented on 2019-03-15 21:00 (UTC)

afni gui was complaining about the USE_LESSTIF flag not being enabled in compilation. I fixed this and made a few other minor changes to the package available from : https://github.com/martin3141/afni_arch

fishburn commented on 2018-03-09 20:39 (UTC)

Ran into a couple of issues: Current version is: 18.0.25 In build, "make" should be changed to "make all" I had to add the following to the beginning of package(): cd ${srcdir}/afni_src make install

Happy to add these changes if you want to make me a co-maintainer

rmelo commented on 2017-06-27 22:06 (UTC)

afni_src.tgz failed validation