https://github.com/mne-tools/mne-cpp
Metadata Update from @mhough: - Issue assigned to mhough
@mhough - as soon as your review submission for this is approved in principle, I will request that you be added to the packagers group as a neuro-sig co-maintainer. Does that sound OK?
Absolutely. Sounds good.
This is a more complicated package than I think I should start with. Using the Qt5 system libs and the latest stable branch, the instructions to build specify using the QtCreator app which is available in Fedora 29. Following the instructions at the link below:
http://wiki.mne-cpp.org/index.php/Compile_the_MNE-CPP_source_code
cd mne-cpp qtcreator mne-cpp.pro
does bring up the QtCreator gui but I am hunting around to follow the instructions currently.
Ah, yikes---one never knows how hard they'll be until one begins to package them XD.
Maybe start with something python based? They're generally easier and we have a template spec to aid with packaging too (check the files section of this repo).
I think I was also just getting tired and just not familiar with the Qt framework really. I decided to ignore the build instructions and followed DSI-Studio's instructions which just use
qmake-qt5 ../ cd mne-cpp/ make
which seems to properly produce the binaries without errors. I will check with upstream and see if there are any concerns about building this way and see if they have any additional command line instructions I can use in lieu of their Qt-creator instructions.
Here is the test dataset that I am using for all the non-DICOM testing as it has MEG, EEG, DWI, MRI and FMRI data. It is also used by SPM and mne-python.
https://legacy.openfmri.org/dataset/ds000117/
That's great. There are lots of scenarios where we cannot use upstream's instructions. It's why packagers are expected to have knowledge of the build projects (Cmake/autotools/..) so that they can use other correct ways of building the software.
The user-end testing is welcome, but that is not going to be enough. Upstreams must have their own exhaustive tests. Our user-end testing cannot replace those. We can work with upstreams to improve their testing, of course (we've done this in multiple cases already).
Hey there. I am working on MNE-CPP. Happy to help.
Hi @lorenze : welcome to NeuroFedora!
Are you on the MNE-CPP development team?
Yes, I am.
Great! As you see from the comments above, @mhough began working on packaging it for Fedora and has made some progress. Would you maybe have the time to co-maintain the package with us in Fedora? This requires:
As a developer, you'd already have the required skills, and we can help you navigate the Fedora side of things (mostly the processes and infrastructure).
Unfortunately, I do not have enough time at the moment to contribute the whole package. However, I am interested in seeing MNE-CPP in NeuroFedora. Let me see if I can find someone in our team who is able to spend more time on this than myself.
Thank you. That would be most useful. We'll keep working on it in the meantime.
Hello - I work with Lorenze who commented above, and per his request have looked at building mne-cpp. I've had some success building it with qmake and make on fc28 after installing some qt5 packages. Did you have in mind creating an mne-cpp rpm ?
Hello @buildeng: yes, it is on our list, but currently our list is quite long so we're not sure when we'll get to it. Would you, by any chance, like to make the rpm and maintain it in Fedora? The main work is only the initial packaging and review. We'll be happy to help you navigate the process and the tools that are needed to provide mne-cpp in Fedora.
I'd be happy to start the process of trying to package up what the mne-cpp developers currently have in their dev tree; maybe you could suggest some preferred links to the packaging tools, docs, etc. Thanks in advance for any info.
That sounds great, @buildeng. I've put some links up on this page to get people started with packaging:
https://fedoraproject.org/wiki/User:Ankursinha/PackagerSponsor
You could start there, and e-mail me to clarify any issues you run into? How does that sound? We can help you with the rpm(s), and we can sponsor you to the packager group when the time comes too.
Thanks very much, Ankur
@buildeng hello: how is this going? Is there anything we can help with?
(We've added you to the pagure group now so you can modify tickets and so on)
Metadata Update from @ankursinha: - Issue assigned to buildeng (was: mhough)
Metadata Update from @ankursinha: - Issue untagged with: S: Needs packaging - Issue tagged with: S: WIP
After reading some docs, I started to create a spec file that can download the source and compile it using make from Qt5. But after talking to developers it seems they would prefer a binary only rpm for a release. Is this acceptable?
... should have said "qmake" and not make.
So, do they want that users only have access to a binary? If that is so, that's fine. While we build from source, end-users only receive the binary rpms from the repos (they can also fetch the sources, but that is not part of the general set up).
If upstream only wants users to use the binary they provide, that's a problem. As you'll see in the packaging guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/ , all software included in Fedora must be built from source. This is to ensure that:
To update, I have a prototype spec file that does a source build and creates a binary rpm file via rpmbuild on CentOS7 (which is currently their linux reference platform). I have just reviewed the binary rpm install with developers and need to make some changes w.r.t newer versions of Qt and adding some files to be installed. Once I have something dev approves for CentOS7 I can follow up again on fc28.
if it builds on CentOS7, there's a good chance it'll build on Fedora as well. I'd target rawhide first, since that's the platform new packages are added too. Once it builds there, we can work on F30 and F29 (F28 will be EOL in a month now that F30 was released).
You can use mock to test your builds on different Fedora etc releases, or COPR too:
https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds https://copr.fedorainfracloud.org/
I updated my fc28 VM, and ran the mock command "mock -v mne-cpp-master-1.0.fc28.src.rpm " to build the source RPM (which exited with status 0). I also ran the dnf command w/o the BuildRequires packages installed to see if everything would get installed (and all the installs worked), i.e., "sudo dnf builddep mne-cpp.spec". If you would like to get an idea of what is currently in the spec file, you can get it from the URL below. I can remove the ifdef/comments for redhat (CentOS7), further test, edit, cleanup etc. as you like. https://drive.google.com/file/d/1RWNkZSyL93U0tRcxLWcZpYfl9LOkVwd0/view?usp=sharing
If you submit if for review, one of us can review it and sponsor you @buildeng . What do you think?
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
It looks like I can use COPR to allow review of the spec file and source RPM?
Yes. You can use any build service to test your spec/srpm, and you can make them available however you want (if COPR provides a link to the spec and srpm, that will work too). The only requirement is that it must go through the review process. So from this step on now, I think:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Upload_Your_Package
Here is a recent example of the python-elephant review: https://bugzilla.redhat.com/show_bug.cgi?id=1651824
Login to comment on this ticket.