DevHeads.net

Potential module for wxGTK3.1 unstable series / Audacity

Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 release.
Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).

I would like to be able to release the next Audacity (once tested) when
it drops.

I've been reading about Fedora modules, and am wondering whether the
following would make sense as a potential solution ?:

$ dnf modules list wxGTK3

Fedora Modular 30 - x86_64
Name Stream Profiles Summary
wxGTK3 3.1.n-unstable default [d], devel GTK wxWidgets GUI library

If the module was setup like this, then could the normal repo
audacity.spec package:
BuildRequires: wxGTK3:3.1.n-unstable/devel

Requires: does this get sorted out magically like in a normal package ?

I don't know whether any other wxGTK using packages could or should be
using the wxGTK devel series.

As I'm not on the wxGTK3 package team, can I do this without their
approval/assistance ?

Advice ? Am I on the right track ?

Cheers, Dave.

Comments

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Scott Talbert at 11/11/2019 - 09:51

Hi, one of the wxGTK maintainers here. Where is the requirement to use
wxGTK 3.1 documented? Like Kevin, I can't find that documented. And if
it is definitely required, *why* is it required?

I would be strongly opposed to using a module for this. If you absolutely
*must* have wx 3.1, we should just use a regular (non-modular) package.
Note that we've already had one request for wx 3.1 [1], but I've been
hesitant to package it since it has unstable API/ABI and we typically
don't package development releases.

Can you provide amplifying information on the wx 3.1 requirement from
audacity first?

Thanks,
Scott

[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1714714" title="https://bugzilla.redhat.com/show_bug.cgi?id=1714714">https://bugzilla.redhat.com/show_bug.cgi?id=1714714</a>

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/11/2019 - 16:08

On 12/11/19 1:51 am, Scott Talbert wrote:
Dave.

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Christopher Eng... at 11/11/2019 - 10:36

On 11/11/2019 3:51 PM, Scott Talbert wrote:
On Archlinux audacity-git [1] builds against the default repo version of
wxGTK, i.e. 3.0.4, so it does not seem to be required.

Christopher

[1] <a href="https://aur.archlinux.org/packages/audacity-git/" title="https://aur.archlinux.org/packages/audacity-git/">https://aur.archlinux.org/packages/audacity-git/</a> (ignore stated pkg
version, package pulls master on install)

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/11/2019 - 16:05

On 12/11/19 2:36 am, Christopher Engelhard wrote:
Cheers, Dave.

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/11/2019 - 16:22

On 12/11/19 8:05 am, David Timms wrote:

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Kevin Kofler at 11/11/2019 - 08:39

David Timms wrote:
Does it really? I cannot find this requirement in their git repository.

Ewww! Why is nobody complaining to Audacity upstream about that (assuming
that they really do require 3.1)? Requiring an unreleased/unstable wxGTK (I
would not count a development release as "released") makes no sense
whatsoever for a stable release of Audacity. Why are they not maintaining a
stable branch based on a stable wxGTK release? They should.

I would recommend against doing that (unless you can get it to build against
wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and
available in Fedora.

No, that would be a very bad idea, because it means Audacity would then
conflict with all other wxGTK applications, or at least force them to run
with the unstable wxGTK with which they were not tested (depending on
whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).

Modules are always the wrong solution for libraries because they are not
parallel-installable.

No, building against a module does not work like that, it is more
complicated. But a module is a bad idea anyway, see above.

No, you definitely need to find a solution together with them.

Kevin Kofler

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/11/2019 - 16:01

On 12/11/19 12:39 am, Kevin Kofler wrote:
1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
wxWidgets project:
<a href="https://github.com/audacity/wxWidgets/" title="https://github.com/audacity/wxWidgets/">https://github.com/audacity/wxWidgets/</a>....
"

I missed the fact that they build against their fork of wxWidgets from
their own repo; I'm not sure whether it started as 3.1.1 or not.

I would prefer to follow Audacity teams requirements, as otherwise any
issue reported in Fedora - I get the "did you build it like we said ?"
response.

Dave

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Scott Talbert at 11/11/2019 - 16:32

Ouch. So now you're talking about wanting to package a *fork* of a
development release of wxGTK. I would strongly suggesting talking to
Audacity team about why they need a fork of wx 3.1.x and why they cannot
get their fixes/changes upstreamed (and backported to wx 3.0). Upstream
wx is usually pretty good about backporting fixes to 3.0 if you request
it.

Scott

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Scott Talbert at 11/11/2019 - 16:46

I just took a quick look at the changes in their wx 3.1.1 fork. It
appears they are all Windows and Mac related. So, their instructions to
use their fork when building on Linux make no sense.

I would recommend doing as Kevin suggested and continue to build against
wx 3.0.4 in Fedora. If you run into a bug that has been fixed in wx
3.1.x, feel free to report it and we will get the fix backported.

Scott

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/12/2019 - 08:14

On 12/11/19 8:46 am, Scott Talbert wrote:

While the above is what I've already done locally and what I'll do...

I think it's a good idea to make available these (advanced) build
environments, without requiring a whole "rawhide" machine to do this on
(which currently still only has the old version anyway).

Don't we want to make it easier for all sorts of people to contribute to
open source development. Modules sound like an easy way for that to
happen (for the user of the module). We need tester's and developers
using future "pieces" that interest them without foregoing an otherwise
stable machine.

And this usage can be the impetus that allows library development to be
well tested by multiple real applications and issues
known/fixes/improvements in place before the library hardens it's
ABI/API interfaces at the release.

In this case extending this idea to also make other Fedora packaged,
wxGTK3 using applications [1] built with the (hopefully soon) to be
released library would allow more thorough testing of the library, and
give us ahead of time the things that need work - in either the library
or the applications.

Given it would be me doing the work - although I'll need some guidance -
are any guidelines etc. actually being broken if I was to do the
modularity thing for wxGTK/Audacity ?

ps. I haven't come across the docs on the packaging side of modules -
any pointers, please ?

Dave.

[1] <a href="https://paste.fedoraproject.org/paste/nAopftRQuTcxokDbHP~nkw" title="https://paste.fedoraproject.org/paste/nAopftRQuTcxokDbHP~nkw">https://paste.fedoraproject.org/paste/nAopftRQuTcxokDbHP~nkw</a>

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Kevin Kofler at 11/11/2019 - 16:30

David Timms wrote:
They have been writing this all this time, this is not new in 2.3.3. Just
ignore it, as usual when an upstream recommends using bundled libraries.

Those are not your job as the Audacity packager to fix. Just build it
against 3.0.4. We will get wxGTK 3.2.x when it is actually released.

Those examples are bad. The Modularity team wants to push modules for this
use case, but they are absolutely not suitable. See the recent threads about
Modularity.

Kevin Kofler

Re: Potential module for wxGTK3.1 unstable series / Audacity

By =?ISO-8859-1?Q?... at 11/11/2019 - 09:06

Dne 11. 11. 19 v 14:39 Kevin Kofler napsal(a):

In the mean time, you can use Copr to provide updated wxGTK + Audacity.
Keeping the resolution of possible conflicts on the users.

Vít

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Fabio Valentini at 11/11/2019 - 09:33

I think the easiest solution would be to introduce a wxGTK "compat package"
for 3.1, assuming it wouldn't conflict with the stable versions, and
provide both the compat package and audacity builds based on it via COPR
for testing.

Fabio

Re: Potential module for wxGTK3.1 unstable series / Audacity

By David Timms at 11/11/2019 - 16:19

On 12/11/19 1:33 am, Fabio Valentini wrote:
<a href="https://trac.wxwidgets.org/wiki/Roadmap" title="https://trac.wxwidgets.org/wiki/Roadmap">https://trac.wxwidgets.org/wiki/Roadmap</a>

Perhaps calling a compat package 3.2.0.develseries.3.1.3 etc would make
sense to indicate to consumers that they are using what will soon (TM)
become the main version.

Dave.

Re: Potential module for wxGTK3.1 unstable series / Audacity

By Kevin Kofler at 11/11/2019 - 17:45

David Timms wrote:
Please no. There is a numeric version, please use that, not some ugly
version hack.

What would be acceptable, I suppose, is:
Name: wxGTK3.2
Version: 3.1.3
though some might even object to that (and demand Name: wxGTK3.1 instead).

Kevin Kofler