[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] [GSOC 2018] Packaging tasks (was: Ideas please!)
From: |
Wunsch, Felix (CEL) |
Subject: |
Re: [Discuss-gnuradio] [GSOC 2018] Packaging tasks (was: Ideas please!) |
Date: |
Mon, 16 Oct 2017 06:31:59 +0000 |
Hi Marcus,
could you make this an idea on the list? As gr-modtool is used so widely, any
improvements in this area will have quite high (and positive) impact on a large
portion of GNU Radio users. Maybe we can flesh out more of the bullet points on
the gr-modtool overhaul idea (Py3k, API, GUI, ...).
Cheers,
Felix
________________________________________
Von: Discuss-gnuradio <address@hidden> im Auftrag von Marcus Müller
<address@hidden>
Gesendet: Sonntag, 15. Oktober 2017 15:50
An: Martin Braun; address@hidden
Betreff: [Discuss-gnuradio] [GSOC 2018] Packaging tasks (was: Ideas please!)
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))
>>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!, Benny Alexandar, 2017/10/16