Bug 1723013 - Review Request: mne-cpp - A Framework for Electrophysiology
Summary: Review Request: mne-cpp - A Framework for Electrophysiology
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-22 02:16 UTC by b38ghk29
Modified: 2021-08-09 02:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---


Attachments (Terms of Use)

Description b38ghk29 2019-06-22 02:16:12 UTC
Spec URL: https://drive.google.com/file/d/1SxTNt7ZTMgHkEihgUvZhtjR0vny5XQPo/view?usp=sharing
SRPM URL: https://drive.google.com/file/d/1e3Y5CKKvGXYrKF6qw-WsudN2al0MRcQE/view?usp=sharing
Description: The mne-cpp (cpp = c++) code base is a framework for acquiring/capturing electrophysiology data (in real-time) and/or browsing and analyzing such data.  It is a re-write of the original C code base.  See this URL for some of the different programs available in the mne-cpp distribution, https://www.mne-cpp.org/index.php/info/

Fedora Account System Username:  redhat bugzilla email b38ghk29@contbay.com

I have done build and install so far only on fc28 updated to have Qt 5.11.3.

"sudo dnf builddep mne-cpp.spec" installed dependent Qt packages for build.

"mock -v mne-cpp-master-1.0.fc28.src.rpm" built the source RPM and existed with status 0.

Comment 1 David Auer 2019-06-22 14:13:52 UTC
These are not direct download links, did you read https://fedoraproject.org/wiki/Package_Review_Process ?

This way the fedora-review tool works and people need less clicks:
Spec URL: https://drive.google.com/uc?export=download&id=1SxTNt7ZTMgHkEihgUvZhtjR0vny5XQPo
SRPM URL: https://drive.google.com/uc?export=download&id=1e3Y5CKKvGXYrKF6qw-WsudN2al0MRcQE

I am also a bit confused about your Fedora account system username and the fact you are using Fedora 28 (it is end of life).

Comment 2 David Auer 2019-06-22 14:41:57 UTC
Okay, it turns out that fedora-review looks for the file ending, so maybe this hack works:

Spec URL: https://drive.google.com/uc?export=download&id=1SxTNt7ZTMgHkEihgUvZhtjR0vny5XQPo#.spec
SRPM URL: https://drive.google.com/uc?export=download&id=1e3Y5CKKvGXYrKF6qw-WsudN2al0MRcQE#.src.rpm

Comment 3 b38ghk29 2019-07-02 02:00:56 UTC
I have rebuilt/created RPM's on fc29 and have direct download URL's, but where do you edit the previous URL entries?

Comment 4 David Auer 2019-07-02 10:28:08 UTC
AFAIK you can not edit previous messages. Just post the URLs in a new comment. Unfortunately my tries to convert your URLs to direct download weren't successful. 

When I last commented I took a short peek at your spec file and if I recall correctly there are some things that need to be fixed, if you haven't already please make sure your Version/Release, License and makro usage meets the guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/). I will try to make a full unofficial review in the next days. (I am not a packager yet so all of this is unofficial!) 

I think downloading sources via curl in %setup is not allowed, but not entirely sure in this case, because it wouldn't happen for Fedora but only for rhel builds. 

Additionally it would be a good idea to do a koji sratch build (also post a link when it's done) and I personally ran the fedora-review tool on my own package, it might just help you to find some mistakes and fix them yourself.

Comment 5 b38ghk29 2019-07-02 18:14:07 UTC
Thank you for the info and the update.  I saw in the packaging docs that downloading is discouraged, but given there is no release yet of the code (or official package), then I was not sure what else to do besides fetch the source from github.  I did run mock, but I will look at the other things you mentioned.  For now here are the updated URLs,

Spec URL: https://drive.google.com/uc?export=download&id=1SxTNt7ZTMgHkEihgUvZhtjR0vny5XQPo
SRPM URL: https://drive.google.com/uc?export=download&id=1Os82KO4Bmqv5uARWZa-PUm3cXOsrH1sV

Comment 6 Artur Frenszek-Iwicki 2019-07-06 10:38:14 UTC
>Version:        master
>Release:        1.0%{?dist}
You should use the upstream version number (1.0.0) and include snapshot info in the Release field. See the Versioning Guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/

>Source0:        https://github.com/mne-tools/mne-cpp/archive/master.zip
Related to the point above - you should explicitly name a specific commit here. "master.zip" is a moving target.

>curl -s https://raw.githubusercontent.com/jcfr/qt-easy-build/5.10.0/Build-qt.sh -o Build-qt.sh
This will fail since official package builds are done with disabled Internet access. Everything that's needed for building the package should be listed in Source: and Patch: tags.

Comment 7 Robert-André Mauchin 🐧 2019-07-13 14:14:21 UTC
 - This is a no: you don't have internet access in Koji/Mock during the build


%if 0%{?rhel}
echo in_setup_for_RedHat
curl -s https://raw.githubusercontent.com/jcfr/qt-easy-build/5.10.0/Build-qt.sh -o Build-qt.sh
chmod 755 Build-qt.sh
./Build-qt.sh -y -c -j4 -q $HOME/qt
%endif
pwd

Comment 8 Package Review 2020-07-13 00:45:28 UTC
This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

Comment 9 b38ghk29 2020-07-17 15:26:05 UTC
OK, so per your feedback above on 2019-07-13 14:14:21 UTC, then the current Qt distribution has to be built from source prior to building the software applications that use it?

Comment 10 Robert-André Mauchin 🐧 2020-07-18 15:41:16 UTC
# CentOS/RedHat needs Qt 5.10 to be downloaded and built (no rpm for install)
%if 0%{?rhel}
echo in_setup_for_RedHat
curl -s https://raw.githubusercontent.com/jcfr/qt-easy-build/5.10.0/Build-qt.sh -o Build-qt.sh
chmod 755 Build-qt.sh
./Build-qt.sh -y -c -j4 -q $HOME/qt
%endif
pwd


If Qt > 5.10 is required then you can't support RHEL < 7. You can target RHEL 8 (not sure of Qt's version here, please check).

 - Secondly you need to use nacros:

%build
PATH=/usr/lib64/qt5/bin:$PATH
qmake --version
qmake -makefile -recursive
make

→

%{qmake_qt5}
%make_build

 - Do not install in /usr/local, use %{_prefix} macro which is /usr

 - No idea what you are trying to do here:

%install
# echo %{buildroot}
# copy over subdirs from build
mkdir -p %{buildroot}/%{_prefix}/mne-cpp
tar cpf - ./bin ./lib ./doc | (cd %{buildroot}/%{_prefix}/mne-cpp; tar xpf -)

 - Also

Source0:        https://github.com/mne-tools/mne-cpp/archive/master.zip

you can't just pount to master like this, you need to d/l a specific release, if not are provided, then target a specific commit. It seems 0.1.4 is the latest release.

Comment 11 b38ghk29 2020-09-25 00:50:26 UTC
Please correct me if I am wrong, but my understanding is that a *src* rpm is still required, and so the source code must build from scratch (apart from subsequently creating a binary RPM).

Also please advise on what Fedora releases are acceptable to compile/test on, i.e., fc31 or fc32.  The reason I ask is because with newer compilers, the current 0.1.6 pre-release may not compile w/o warnings.

Comment 12 Artur Frenszek-Iwicki 2020-09-25 07:36:45 UTC
I don't think we have a requirement as to which release one has is allowed to use for building SRPMs for review, though I guess the unspoken expectation is "something that's not EOL". That being said, you can use mock, or koji scratch builds to verify that your package builds fine on Fedora Rawhide.
https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds
https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

Once you have a successful scratch build, it's good to add a link to it alongside the SPEC and SRPM - just for showing reviewers that the package builds fine.

Comment 13 Package Review 2020-11-13 00:47:06 UTC
This is an automatic action taken by review-stats script.

The ticket reviewer failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we reset the status and the assignee of this ticket.

Comment 14 Package Review 2020-11-14 00:45:21 UTC
This is an automatic action taken by review-stats script.

The ticket reviewer failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we reset the status and the assignee of this ticket.

Comment 15 Package Review 2020-11-15 00:45:36 UTC
This is an automatic action taken by review-stats script.

The ticket reviewer failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we reset the status and the assignee of this ticket.

Comment 16 Package Review 2020-11-16 00:45:18 UTC
This is an automatic action taken by review-stats script.

The ticket reviewer failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we reset the status and the assignee of this ticket.

Comment 17 Ben Beasley 2020-12-28 14:25:58 UTC
Are you still working on this? It looks like the actual software is probably feasible for inclusion in Fedora, but you will need to take the time to do quite a bit of listening to feedback and reading the guidelines to get there.

Comment 18 b38ghk29 2021-08-06 03:03:25 UTC
Please advise as to the current version of fedora core in use for package testing/review.

Comment 19 Ben Beasley 2021-08-09 02:38:45 UTC
(In reply to b38ghk29 from comment #18)
> Please advise as to the current version of fedora core in use for package
> testing/review.

Reviews are generally done using Rawhide, the development version of Fedora Linux. Reviewers use the “fedora-review” tool to help find things that need a second look, and you can run it too; it saves a lot of time if you’ve already handled the issues that the tool can find automatically.

Rawhide is where an approved package would initially appear. You could then request branches for other supported releases (f34, f33), or for EPEL (epel8/epel7). See https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/.

You can do your development on another version, like Fedora 33 or 34, using mock (https://github.com/rpm-software-management/mock/wiki). Some people even use CentOS or RHEL. You’ll have the best results using a release that’s currently receiving updates rather than one that’s end-of-life (Fedora 32 or older).

Please see https://fedoraproject.org/wiki/Package_Review_Process and https://fedoraproject.org/wiki/New_package_process_for_existing_contributors, and https://fedoraproject.org/wiki/Join_the_package_collection_maintainers if you are not yet a Fedora packager.

(The name “Fedora Core” was last used for Fedora Core 6, in 2006.)

Comment 20 Ben Beasley 2021-08-09 02:42:23 UTC
Note that a source RPM built on Fedora 33 or 34 works just fine as an input for a Rawhide mock build; there’s no expectation that your source RPM has to have a “.fc35” (soon “.fc36”) in its name.


Note You need to log in before you can comment on or make changes to this bug.