3.8 Packaging: Test buildability and inform Distro maintainers

[marcusmueller]

We'll need to verify that the current build specifications for

• Debian (hence Ubuntu)
• Fedora / CentOS
• Arch
• Gentoo

can and will be adapted to 3.8.

@noc0lour did deb builds, I think, and we have Maitland, who is generally pretty awesome.

I have specs that have become dated from the next merge period.

For Gentoo, we need to reach out to the maintainer, whom we know (whose IRC handle I just can't remember right now).

For Arch: we need to figure out.

[michaelld]

I recently worked with a customer recently getting GR to build on CentOS ... we did eventually, once all of the correct dependencies were installed. I don't know if chatting with this person would be useful ... but, if you think so I'm happy to do introductions.

[marcusmueller]

ah, @ZeroChaos-, this might be a thing you're interested in

[ZeroChaos-]

I can already build from any branch you like, and I'm happy to help the upstream project set up the same if desired. I'm on irc basically all the time, so feel free to reach out whenever and I can help by testing or getting an environment set up for you.

[marcusmueller]

@yarda I'm afraid we'll have a big chunk of things coming up for you. The two of us should cooperate in modfying the Fedora .spec to suit Py3 / Qt5 / gobject…/.

[yarda]

@marcusmueller that's great, I am looking forward to 3.8 and py3 switch for some time :) We are phasing out py2 in Fedora and I have now quite a hard time adding and maintaining new 3rd party gr packages in Fedora.

[marcusmueller]

awesome! As you might know, I'm using fedora as my dev system myself, and I used to have a not-very-up-to-fedora-standards spec, but it broke a year ago or so.

Reworking the current spec might be harder than writing it from scratch for 3.8. Would that be an option?

[yarda]

The spec is quite short and not too complex (in comparison with other packages :) But no problem for rewrite from the scratch. I will be happy to be compat with upstream - this is our goal in Fedora - to stay the most close upstream as possible.

One more thing for consideration, are you also going to fix the library sonames in 3.8? E.g.:
/usr/lib64/libgnuradio-runtime-3.7.13.5.so.0.0.0
This complicates gnuradio rebuilds. It would be great to have correct sonames there.

[marcusmueller]

I'd have to double-check, but I think we did that on master already, like this:

 libgnuradio-runtime.so.3.8git

[yarda]

That's great.

[marcusmueller]

we now use a stricter versioning scheme (see the VERSIONING file) that uses

MAJOR.API.ABI.PATCH

(and the git suffix should just be a clutch for unreleased versions)

[yarda]

BTW for the CentOS / RHEL we have the EPEL repository [1]. In the EPEL-7 the gnuradio package isn't so old (gnuradio-3.7.11-7.el7). EPEL-8 is not yet ready, but we could start with the 3.8 there.

[1] https://fedoraproject.org/wiki/EPEL

[marcusmueller]

The 3.8.0.0-rc1 release candidate is out.

[yarda]

@marcusmueller I tried to build the 3.8.0.0-rc1 on Fedora Rawhide (f31), but I wasn't successful to get over the configure phase.
Build log: https://paste.fedoraproject.org/paste/XRg2Pi2WHh3khk3EwrfOBA
Packages installed in the buildroot: https://paste.fedoraproject.org/paste/8lWdp9oMTWYr3bzEsSqqDA

[yarda]

Despite the errors there are the following packages installed:

mpir-devel-3.0.0-6
gmp-devel-1:6.1.2-10
gsl-devel-2.5-1

[marcusmueller]

@yarda I'll look into it, thanks!

[marcusmueller]

all: I've merged a patch that fixes the fact that we broke python/native/swig .so installation paths on multiple platforms, including Ubuntu, shortly before I did RC1.

I can't do a RC2 today or tomorrow, but dedicate to doing RC2 on Saturday.

[marcusmueller]

@yarda hm, this looks like a successfull CMake run, and is if the gsl detection fails (we only use either MPIR or GMP, if I'm not 100% mistaken; MPIR is the replacement we have to use on windows)

[marcusmueller]

@noc0lour can you have a look at the CMake log above? we have a modern CMake target gsl::gsl finding problem.

[marcusmueller]

@yarda My Dockerfile, which I forgot to add git to: https://paste.fedoraproject.org/paste/jO5gGtYojsasVEY~YOTV~w

I build that with

 podman -t gr-fed31 -f fedora-31.Dockerfile

haven't quite gotten qtgui and gtk to work straight out of the box (this is a modified fedora29 py2 & py3 buildbot dockerfile by @noc0lour).

It seems to cmake and make just fine so far, except for the Qt and GRC stuff and sphinx (we're probably getting rid of sphinx anyway):

podman run -it --rm -t gr-fed31 /bin/bash
dnf install -y git
git clone --recursive https://github.com/gnuradio/gnuradio
cd gnuradio
mkdir build
cd build
cmake .. && make -j8

[englishm]

I've submitted a patch to update the FreeBSD comms/gnuradio port to RC1 since it was already on a tech preview release:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239345

[marcusmueller]

all: The 3.8.0.0-rc2 release candidate is out.

[yarda]

@marcusmueller I successfully built 3.8.0.0-rc2 on Fedora Rawhide .

[englishm]

3.8.0.0-rc2 builds on FreeBSD 12.0-RELEASE-p7. I've updated the bug I opened to update the port.

[marcusmueller]

@englishm thanks!

[marcusmueller]

@yarda that is pretty awesome; I think that means I can't really help you write a SPEC file for https://src.fedoraproject.org/rpms/gnuradio/ ?

[yarda]

@marcusmueller I successfully built it, but I have trouble to install it:

...
/usr/lib/python3.7/dist-packages/gnuradio/gr/_runtime_swig.so
...

I guess on Fedora 64 bit this should be:

/usr/lib64/python3.7/site-packages/gnuradio/gr/_runtime_swig.so

I.e. lib64 and site-packages.

This is the specfile I used https://paste.fedoraproject.org/paste/54YW8zgObKUEcy4pa2Rrrw
But feel free to write new from the scratch if you think it's needed.

[yarda]

This is the build log for reference:
https://kojipkgs.fedoraproject.org//work/tasks/9839/36409839/build.log

[michaelld]

@yarda Well at least all of the Python parts are installed into the same directory now (which is different than with rc1). even if it's not what you want! You'll need to tweak the GR_PYTHON_DIR setting for what this OS needs.

[yarda]

@michaelld OK, I will workaround it downstream, but I think it should autodetect the correct paths similarly how it was done in GR 3.7 rather than hardcoding Debian defaults.

[michaelld]

@yarda I was guessing you/"we" figure out what's going on & fix it in GR itself. In MacPorts, I externally set the GR_PYTHON_DIR, overriding whatever possible default GR might set. For other package managers, having GR "do the right thing" seems important ... so, yes, if we can get the setting to what GR37 was doing then I think that's wise.

[marcusmueller]

I'd agree this should work. I really expected this to work with rc2! It's interesting that it works for me with a CMAKE_INSTALL_PREFIX. hmm.

[marcusmueller]

@michaelld maybe https://github.com/Kitware/CMake/blob/master/Modules/GNUInstallDirs.cmake is the solution?

[michaelld]

@marcusmueller do you know how this setting was implemented in GR37? I honestly don't ... lemme look at your link ... (I dishonestly might know LOL)

[yarda]

@michaelld maybe https://github.com/Kitware/CMake/blob/master/Modules/GNUInstallDirs.cmake is the solution?

I quickly check it and it seems it resolves the lib/lib64 problem. But I think it needs more work:

• it should use site-packages dir not dist-packages dir on Fedora
• arch specific libraries should go to /usr/lib64 on 64 bit on Fedora
• arch independent libraries should go to /usr/lib on Fedora

Interestingly from the build log, the volk stuff seems to install to correct location:

...
-- Installing: /builddir/build/BUILDROOT/gnuradio-3.8.0.0-0.1.rc2.fc31.x86_64/usr/lib64/libvolk.so.1.4.1git
...
-- Installing: /builddir/build/BUILDROOT/gnuradio-3.8.0.0-0.1.rc2.fc31.x86_64/usr/lib64/python3.7/site-packages/volk_modtool/__init__.py
-- Installing: /builddir/build/BUILDROOT/gnuradio-3.8.0.0-0.1.rc2.fc31.x86_64/usr/lib64/python3.7/site-packages/volk_modtool/cfg.py
...

So some detection code is already there. Now I am a bit confused :)

[yarda]

So some detection code is already there. Now I am a bit confused :)

Could you consolidate it to behave the same way for all installed files? Preferably the way how it is handled in volk.

[yarda]

FYI Fedora downstream bug for the gnuradio rebase to 3.8:
https://bugzilla.redhat.com/show_bug.cgi?id=1732400

[marcusmueller]

FYI: We released VOLK 2.0.0, which will still be in-tree source code for GNU Radio 3.8 by default, but will be an external library only in 3.9 and later. Hence, packaging VOLK separately soon would be worth a consideration – GNU Radio releases will ALWAYS ONLY depend on VOLK released versions, so that GNU Radio can use VOLK as a proper external dependency.

Regarding VOLK: it's our Vector Optimized Library of Kernels, which is a spin-off from GNU Radio, containing the hand-optimized code / intrinsics and assembler implementations of single-instruction, much data DSP. I know of a few users outside of GNU Radio, so I'm optimistic libvolk would be a useful package to a larger swath of software. It has a stable C API.

[marcusmueller]

@yarda re: implement GR install like VOLK: sorry, can't. GR is way harder to install due to generated Python in the loads of submodules. But I'll be honest: I think we're trying too hard to be smart in the cmake path detection stuff.

[marcusmueller]

Release 3.8.0.0 is out

And we've also uploaded the tarballs to

https://www.gnuradio.org/releases/gnuradio/

[englishm]

FreeBSD comms/gnuradio has been updated to 3.8.0.0!

• patch submitted: PR: ports/239793
• and committed: ports r508731 (freebsd/freebsd-ports@c43599c))

[marcusmueller]

Thanks, @englishm!