mbox series

[bug#52946,0/2] Update Audacity to 3.1.3.

Message ID aea82058a1f09d10b0e0d64dd807e0bb3b43cdf2.camel@gmail.com
Headers show
Series Update Audacity to 3.1.3. | expand

Message

Liliana Marie Prikler Jan. 2, 2022, 9:42 a.m. UTC 
This series updates wxwidgets-3.1 and thereafter audacity.  Both packages
come with a series of adjustments to things changed in the build system
in newer versions.

Particularly concerning is that audacity relies on linux-internal headers
in order to do file magic.  Would it be feasible to patch their code so
that it works in terms of the file package?

Cheers

Liliana Marie Prikler (2):
  gnu: wxwidgets-3.1: Update to 3.1.5.
  gnu: audacity: Update to 3.1.3

 gnu/local.mk                                  |  2 -
 gnu/packages/audio.scm                        | 66 ++++++++++++-------
 .../patches/audacity-add-include.patch        | 15 -----
 ...audacity-build-with-system-portaudio.patch | 62 -----------------
 gnu/packages/wxwidgets.scm                    | 29 ++++++--
 5 files changed, 66 insertions(+), 108 deletions(-)
 delete mode 100644 gnu/packages/patches/audacity-add-include.patch
 delete mode 100644 gnu/packages/patches/audacity-build-with-system-portaudio.patch

Comments

Leo Famulari Jan. 3, 2022, 4:11 a.m. UTC | #1 
On Sun, Jan 02, 2022 at 10:42:52AM +0100, Liliana Marie Prikler wrote:
> This series updates wxwidgets-3.1 and thereafter audacity.  Both packages
> come with a series of adjustments to things changed in the build system
> in newer versions.

Thanks, it works for me using Guix on Debian.

> Particularly concerning is that audacity relies on linux-internal headers
> in order to do file magic.  Would it be feasible to patch their code so
> that it works in terms of the file package?

I don't know about this subject, but I noticed the same thing while attempting
this update. Do you think it's a problem?
Liliana Marie Prikler Jan. 4, 2022, 8:43 p.m. UTC | #2 
Am Sonntag, dem 02.01.2022 um 23:11 -0500 schrieb Leo Famulari:
> On Sun, Jan 02, 2022 at 10:42:52AM +0100, Liliana Marie Prikler
> wrote:
> > This series updates wxwidgets-3.1 and thereafter audacity.  Both
> > packages come with a series of adjustments to things changed in the
> > build system in newer versions.
> 
> Thanks, it works for me using Guix on Debian.
Good to know.

> > Particularly concerning is that audacity relies on linux-internal
> > headers in order to do file magic.  Would it be feasible to patch
> > their code so that it works in terms of the file package?
> 
> I don't know about this subject, but I noticed the same thing while
> attempting this update. Do you think it's a problem?
I'd like to avoid it if possible.  Audacity uses it to determine
whether a particular file system is FAT so as to determine its
limitations -- I'm sure there are better ways of doing that.

Cheers
Leo Famulari Jan. 4, 2022, 9:04 p.m. UTC | #3 
On Tue, Jan 04, 2022 at 09:43:37PM +0100, Liliana Marie Prikler wrote:
> I'd like to avoid it if possible.  Audacity uses it to determine
> whether a particular file system is FAT so as to determine its
> limitations -- I'm sure there are better ways of doing that.

I agree that it would be nice to avoid it. On the other hand, if that's
how Audacity made their program work, we should accept it unless it
causes serious problems. I don't think that feature development of
packaged programs should happen in the distro.

I don't know what problems it could cause, just that it's unusual. A few
packages do refer directly to "kernel-headers" from the build
environment.
Liliana Marie Prikler Jan. 19, 2022, 8:16 p.m. UTC | #4 
Am Dienstag, dem 04.01.2022 um 16:04 -0500 schrieb Leo Famulari:
> On Tue, Jan 04, 2022 at 09:43:37PM +0100, Liliana Marie Prikler
> wrote:
> > I'd like to avoid it if possible.  Audacity uses it to determine
> > whether a particular file system is FAT so as to determine its
> > limitations -- I'm sure there are better ways of doing that.
> 
> I agree that it would be nice to avoid it. On the other hand, if
> that's how Audacity made their program work, we should accept it
> unless it causes serious problems. I don't think that feature
> development of packaged programs should happen in the distro.
> 
> I don't know what problems it could cause, just that it's unusual. A
> few packages do refer directly to "kernel-headers" from the build
> environment.
Since it is just one header which is unlikely to change between kernel
versions, I now pushed this as-is.  Thanks