Bug 2036166

portmidi is optional for darktable.

As for the version: Does darktable really require portmidi 2.0.1? After all, darktable 3.8.0 was released a week before portmidi 2.0.1.

Note that the portmidi on GitHub that you are pointing to is a complete reorganisation of the legacy portmidi from SourceForge (which is in Fedora). The original author and the various forks' authors have spent the last couple of months finding a way forward. Version 2.0.1 is the *first* release of that effort (and does not include python bindings, for example).

Which brings me to the question: Are you sure that darktable really needs (or even works with) this new portmidi which did not exist between DT 3.6 and 3.8?

As you know, there are koji and copr builds of darktable in Fedora against the current portmidi. They do build fine. Have you tested midi functionality (I can't)?

It does look as if portmidi on GH will be the future supported version, but switching to it requires quite some effort. We have to check all consumers, especially the bindings. It might very well be that we end up with a new package portmidi2, or have to keep the existing one as portmidi-compat or such.

A copr build (mjg/darktable, from the updated DT dist-git PR) of DT 3.8.0 against the existing portmidi-devel and SDL in Fedora gives this with `-d input':

```
1.220106 [gamepad_open_devices] SDL initialized
1.403444 [midi_open_devices] PortMidi initialized
1.403472 [midi_open_devices] found midi device 'Midi Through Port-0' via 'ALSA'
1.403477 [midi_open_devices] found midi device 'Midi Through Port-0' via 'ALSA'
```

So, I take it that darktabke works with the current portmidi in Fedora (and that my soundcard provides a MIDI port that I didn't know).

I will have "portmidi new world" on the radar, but getting it into Fedora in the right way may take quite some time. I'll keep this bz open and assigned (though the reasoning for the update seems to be "invalid") to track any progress.

Sorry, for the misunderstanding. This is a package which will be required by darktable to support midi devices. The last release is 10 years old and in the last days we helped portmidi to get their things working and shape a release.

Take a look at https://github.com/PortMidi/portmidi/issues/13 for possible packaging issues.

(In reply to Andreas Schneider from comment #3)
> Sorry, for the misunderstanding. This is a package which will be required by
> darktable to support midi devices.

Sure, it is required for (optional) midi support, and darktable works with the current portmidi package. That's why I should close this bz as "invalid" if I read it as "darktable needs portmidi 2.0.1".

> The last release is 10 years old and in

And it's been working all these years. (And it's been worrying me that it seemed dead, too; but it worked.)

> the last days we helped portmidi to get their things working and shape a
> release.
> 
> Take a look at https://github.com/PortMidi/portmidi/issues/13 for possible
> packaging issues.

Exactly. As far as I can see, all that 2.0.1 does is revamp the build system, rip out the python bindings and put them into a separate repo, declare the python bindings repo "probably obsolete", be undecided about the java bindings and the defaults tool, and all this while keeping the same 10 year old code base.

So, what benefit do Fedora users have from portmidi 2.0.1? I see none.

2.0.1 does not fix any bugs, does not provide new functionality and creates packaging issues. (Apparantly, the new upstream just recently changed .so versioning scheme ...) Being released 10 years after r217 with the same core code does not make it any better, does it?

I'd be happy to take into account patches if there is functionality to patch. For example, the SF svn repo seems to have some fixes on top of the last released version (r217 of portmidi) - before the reorg frenzi - even though the portmedia release seemed to pack r217.

I'd also be happy to switch to "portmidi new world" at some point, but it has been so much in flux over the last few weeks - and only structurally so, not functionally - that I do not see it fit for rawhide: At this point, it's not clear to me whether it can even be an update or needs to be a new package. Quite some dust has to settle first. Why the rush?

Once the path forward is clear, we can test dependent packages in a "portmidi2 copr" which I'll set up.

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.