#123 Package mne-cpp
Opened 2 years ago by ankursinha. Modified 2 years ago


Metadata Update from @mhough:
- Issue assigned to mhough

2 years ago

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

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:

  • writing the initial spec and srpm
  • getting it reviewed (to check for correctness and best practices)
  • updating it from time to time when a new version comes out

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

2 years ago

Metadata Update from @ankursinha:
- Issue untagged with: S: Needs packaging
- Issue tagged with: S: WIP

2 years ago

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.

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?

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:

  • it is built correctly (which will be inspected in the review)
  • it functions correctly on the Fedora environment (the build environment---which is the development tool chain, versions of libraries and so on---mirrors the environment users will have when they use Fedora, so rpms built on our build environment will function exactly in the same way on user systems).
  • the binaries that upstream builds may be tested in their environment, but unless they are tested on each fedora release the way our packaging pipleline does it, there is no guarantee that they will work in the same way. (In general, that is not the best practice for using software on multiple platforms IMO.)

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.

Metadata