Arch Linux User Repository

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.

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

xorg-server-xvfb can be listed as an optional dependency: it's used by the @chauffeur_afni program to take montage pics.

@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."

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

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

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.

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.

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

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

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!