[Discuss-gnuradio] [GSOC 2018] Packaging tasks (was: Ideas please!)

[Marcus Müller]

Hi Martin,

ah, yeah, can see that. We couldn't (and really, shouldn't) abuse a GSoC
student to do e.g. server maintenance, either, so yeah, infrastructure
is a dangerous area.

I think that extending the newmod template to hold the packaging
scripts, write those and write a tool to initiate local or "cloud"
package builds would indeed be pretty fine; the
splitting-into-subpackages idea might be a bit off-boundaries. And,
thinking about this, would be impressive luck to find a student that is
so much into Fedora/Arch/… distro packaging that they could actually
contribute well.

Best regards,
Marcus

(PS: tried to change the subject line in order to keep things structured)

On 15.10.2017 03:08, Martin Braun wrote:
> As far as the packaging task goes, it's
> important that we keep it within well defined *coding* tasks. For
> example, GSoC clearly states that documentation changes are not for
> GSoC. Scripting/maintenance falls into a grey zone, gr_modtool updates
> are OK.
>
> On 10/14/2017 03:21 AM, Marcus Müller wrote:
> <snip>
>>   * Packaging: While that does sound like a core dev team/maintainer's
>>     job, packaging is important, and there's a lot of interesting
>>     footwork to be done that's less of a coordinating and more of a
>>     read-the-docs/implementation thingie:
>>       o Write scripts (CMake, bash, Python?) and add them to the
>>         gr-modtool template that
>>           + automatically generate a good-style Deb, RPM, Arch Pkg,
>>             Whatever-the-brew-we-use on OS X, maybe even an MSI that
>>             works with Geoff's Windows port/ /
>>           + a minimal script/git branch you can merge/diff to add that
>>             functionality to existing modules
>>           + a script to upload the resulting package (source packages)
>>             to the respective build services of major Distros (that
>>             being COPR, Launchpad, build.opensuse.org…)
>>           + maybe even: CGRAN gets an interface that checks whether a
>>             OOT module has native packages, and on which platforms these
>>             build correctly according to above build services
>>       o Make GNU Radio main tree packaging good (again) for people who
>>         aren't on debian(oids): adopt Maitland's great "gnuradio is a
>>         package depending on libgnuradio-runtime, libgnuradio-fft,
>>         libgnuradio-audio, libgnuradio-uhd…" for all distros
>>           + Entails writing RPM specs, arch pkg, and
>>             the-rest-of-what's-realistic-from-above
>>           + benefit: People can install gnuradio-runtime, and exactly
>>             these in-tree modules they need. No need to install UHD and
>>             QT5 on a raspberry pi that doesn't have a USRP nor a screen
>>           + From there on, kind of a maintainer's job to keep in touch
>>             with the distro maintainers to push out the results, XOR
>>           + keep things on our own repos (not that hard with above build
>>             services) and have our own package trees that explicitly
>>             conflict with stock distro packages (not good in the FOSS
>>             community sense, but will work out for users if we also
>>             build the application packages the distros package (mainly:
>>             GQRX, I guess, maybe gr-airmodes))
>>