midiwala doesn't work on Arch Linux

rafrombrc commented

2024-12-24 00:20:11 +01:00

(Migrated from github.com)

I've got midiminder working on my up-to-date Arch Linux machine, but when I try to run midiwala nothing happens. Running midiwala --list give the following output:

rob@<hostname>:~$ midiwala list
Ports:
cannot switch from manual to automatic argument indexing

I've also built midiminder on a Libre Computer Le Potato single board computer running a version of Raspbian based on Debian 11.11, midiwala works as expected in that environment.

I've got midiminder working on my up-to-date Arch Linux machine, but when I try to run `midiwala` nothing happens. Running `midiwala --list` give the following output: ``` rob@<hostname>:~$ midiwala list Ports: cannot switch from manual to automatic argument indexing ``` I've also built midiminder on a Libre Computer [Le Potato](https://libre.computer/products/aml-s905x-cc/) single board computer running a version of [Raspbian](https://hub.libre.computer/t/raspbian-12-bookworm-and-11-bullseye-for-libre-computer-boards/82) based on Debian 11.11, `midiwala` works as expected in that environment.

mzero commented

2024-12-24 18:20:35 +01:00

(Migrated from github.com)

can you run the following two command on the Arch linux set up and paste the output here?

dpkg -l '*fmt*'
aconnect -l

can you run the following two command on the Arch linux set up and paste the output here? ```sh dpkg -l '*fmt*' aconnect -l ```

rafrombrc commented

2024-12-24 19:32:08 +01:00

(Migrated from github.com)

Arch doesn't use dpkg or any of the apt/deb tools, but I pacman -Q fmt shows that I have fmt 11.0.2-1 installed, including the header files needed for development.

My aconnect output differs depending on what I have connected at any given moment. Currently it shows the following:

rob@<hostname>:~/.local/share$ aconnect -l
client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
        Connecting To: 129:0, 128:0, 130:0
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
        Connecting To: 130:0[real:0]
        Connected From: 130:0
client 32: 'Model 12' [type=kernel,card=4]
    0 'Model 12 MIDI OUT'
        Connecting To: 130:0[real:0]
        Connected From: 130:0
    1 'Model 12 DAW Control OUT'
        Connecting To: 130:0[real:0]
        Connected From: 130:0

Like I said, midiminder itself is working. Here's the output from midiminder save -:

# Profile rules:
RtMidi Input Client <-x- *
RtMidi Output Client -x-> *

UM --> katana_proxy
KATANA:=0 --> katana_proxy
katana_proxy:out_to_katana --> KATANA:=0
katana_proxy:out_to_controller --> UM

"X-Touch":=0 --> xtouch_proxy:in_1

These work as expected... I have some udev rules (example) set up to automatically start a service when certain hardware is plugged in. When that happens, midiminder sees the new MIDI ports and makes all of the specified connections. It's only midiwala that fails. Typing midiwala by itself does nothing... no output, it just returns me to the command prompt. midiwala list outputs the two lines I included in the original bug report.

Hope this is helpful!

Arch doesn't use dpkg or any of the apt/deb tools, but I `pacman -Q fmt` shows that I have fmt 11.0.2-1 installed, including the header files needed for development. My aconnect output differs depending on what I have connected at any given moment. Currently it shows the following: ``` rob@<hostname>:~/.local/share$ aconnect -l client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' Connecting To: 129:0, 128:0, 130:0 client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' Connecting To: 130:0[real:0] Connected From: 130:0 client 32: 'Model 12' [type=kernel,card=4] 0 'Model 12 MIDI OUT' Connecting To: 130:0[real:0] Connected From: 130:0 1 'Model 12 DAW Control OUT' Connecting To: 130:0[real:0] Connected From: 130:0 ``` Like I said, midiminder itself is working. Here's the output from `midiminder save -`: ``` # Profile rules: RtMidi Input Client <-x- * RtMidi Output Client -x-> * UM --> katana_proxy KATANA:=0 --> katana_proxy katana_proxy:out_to_katana --> KATANA:=0 katana_proxy:out_to_controller --> UM "X-Touch":=0 --> xtouch_proxy:in_1 ``` These work as expected... I have some udev rules ([example](https://github.com/rafrombrc/katana_midi_proxy/blob/main/sysfiles/etc/udev/rules.d/90-katana-proxy.rules)) set up to automatically start a service when certain hardware is plugged in. When that happens, midiminder sees the new MIDI ports and makes all of the specified connections. It's only midiwala that fails. Typing `midiwala` by itself does nothing... no output, it just returns me to the command prompt. `midiwala list` outputs the two lines I included in the original bug report. Hope this is helpful!

mzero commented

2024-12-25 04:11:07 +01:00

(Migrated from github.com)

Found it! There was a API breaking change in libfmt 11.0!

Please checkout the fmt11fix branch and see if this works for you, too.

Found it! There was a API breaking change in libfmt 11.0! Please checkout the **fmt11fix** branch and see if this works for you, too.

👍 1

rafrombrc commented

2024-12-26 20:13:25 +01:00

(Migrated from github.com)

Yep, I built the fmt11fix branch and now midiwala works as expected. Thank you!

Since this is a breaking API change, I'm guessing you might not be merging this back into the main branch and/or making a release with the libfmt 11.0 fix right away? I've put together a PKGBUILD file setup that installs midiminder as an Arch package. It's currently pulling down the 1.0 release tarball, but I can change that so it pulls down a specific commit from the fmt11fix branch instead, if midiwala on the main branch will only work with libfmt 10.x for a while longer.

Yep, I built the fmt11fix branch and now midiwala works as expected. Thank you! Since this is a breaking API change, I'm guessing you might not be merging this back into the main branch and/or making a release with the libfmt 11.0 fix right away? I've put together a [PKGBUILD file setup](https://github.com/rafrombrc/PKGBUILDs/tree/main/midiminder) that installs midiminder as an Arch package. It's currently pulling down the 1.0 release tarball, but I can change that so it pulls down a specific commit from the fmt11fix branch instead, if midiwala on the main branch will only work with libfmt 10.x for a while longer.

mzero commented

2024-12-26 21:54:58 +01:00

(Migrated from github.com)

The breaking change in libfmt was to drop support for a particular kind of format string usage. The fixed format strings are compatible with older libfmt - and I've checked that they build and work on the oldest systems I support (Debian Buster).

SO - I merged that, and another pending tiny fix, into master. If you want me to tag it I can - or if you just want your PKGBUILD to build head of master, that seems fine to me, too. (And I think aligns with Arch's approach?)

The breaking change in libfmt was to drop support for a particular kind of format string usage. The fixed format strings are compatible with older libfmt - and I've checked that they build and work on the oldest systems I support (Debian Buster). SO - I merged that, and another pending tiny fix, into master. If you want me to tag it I can - or if you just want your PKGBUILD to build head of master, that seems fine to me, too. (And I think aligns with Arch's approach?)

rafrombrc commented

2024-12-26 22:19:19 +01:00

(Migrated from github.com)

Oh good, I'm glad it can be safely merged. 👍

Arch has a convention of having <package-name>-git packages that build from the latest commit, but in most cases a package release points to a fixed, reproducible build. That's what I'd prefer for mine, anyway. You don't need to take any additional action on my account; I'll update my package to pull from the commit where the libfmt fix landed for now, and then I'll switch back to using a tarball after your next release.

Thanks again for taking a look!

Oh good, I'm glad it can be safely merged. :+1: Arch has a convention of having `<package-name>-git` packages that build from the latest commit, but in most cases a package release points to a fixed, reproducible build. That's what I'd prefer for mine, anyway. You don't need to take any additional action on my account; I'll update my package to pull from the commit where the libfmt fix landed for now, and then I'll switch back to using a tarball after your next release. Thanks again for taking a look!

Rows
Columns

midiwala doesn't work on Arch Linux #21