[00:22] <OvenWerks> Eickmeyer[m]: can we find out if libffi has been updated and python3-cffi or python3-jack-client has not?
[00:23] <OvenWerks> The error in #ubuntustudio does not look like an autojack error.
[00:23] <Eickmeyer> !info python3-jack
[00:23] <ubottu> Package python3-jack does not exist in disco
[00:23] <Eickmeyer> Do you know the source name? 
[00:24] <Eickmeyer> !info python-jack groovy
[00:24] <ubottu> Package python-jack does not exist in groovy
[00:24] <Eickmeyer> I can't find out right now, no computer in front of me. I'm on my phone typing this, OvenWerks. 
[00:24] <OvenWerks> https://packages.ubuntu.com/groovy/python3-jack-client
[00:25] <OvenWerks> no hurry I guess
[00:26] <OvenWerks> !info python3-jack groovy
[00:26] <ubottu> Package python3-jack does not exist in groovy
[00:26] <OvenWerks> !info python3-jack-client groovy
[00:26] <ubottu> python3-jack-client (source: python-jack-client): JACK Audio Connection Kit (JACK) Client for Python 3. In component universe, is optional. Version 0.5.0-1 (groovy), package size 34 kB, installed size 177 kB
[00:27] <Eickmeyer> OvenWerks: No diff between focal and groovy. 
[00:27] <Eickmeyer> https://launchpad.net/ubuntu/+source/python-jack-client
[00:28] <OvenWerks> !python3-cffi
[00:29] <OvenWerks> !info python3-cffi goovy
[00:29] <ubottu> 'goovy' is not a valid distribution: bionic, bionic-backports, bionic-proposed, cosmic, cosmic-backports, cosmic-proposed, disco, disco-backports, disco-proposed, eoan, eoan-backports, eoan-proposed, focal, focal-backports, focal-proposed, groovy, groovy-backports, groovy-proposed, kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-p
[00:29] <OvenWerks> !info python3-cffi groovy
[00:29] <ubottu> python3-cffi (source: python-cffi): Foreign Function Interface for Python 3 calling C code. In component main, is optional. Version 1.14.0-2 (groovy), package size 68 kB, installed size 403 kB
[00:29] <OvenWerks> !info python3-cffi focal
[00:29] <ubottu> python3-cffi (source: python-cffi): Foreign Function Interface for Python 3 calling C code. In component main, is optional. Version 1.14.0-1build1 (focal), package size 68 kB, installed size 403 kB
[00:50] <studiobot> <teward001> sounds like maybe minor packaging differences
[00:50] <studiobot> <teward001> in -cffi anyways
[00:50] <studiobot> <teward001> but otherwise no core code problems/changes
[00:53] <studiobot> <teward001> OvenWerks in case you are wondering
[00:54] <studiobot> <teward001> -1 was a new upload release, 1build1 in Focal was no change rebuild dropping Py 3.7 (-2 in Debian)
[00:54] <studiobot> <teward001> but Groovy has a newer version
[00:54] <OvenWerks> teward: SystemError: ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)
[00:55] <studiobot> <teward001> groovy has 1.14.2 thoug hso there is a difference
[00:55] <studiobot> <teward001> (I dumb xD)
[00:58] <teward> OvenWerks: any chance there's a bug on this?  Also is this in Groovy or Hirsuite you notice?  (Curious where you found it)
=== IchabodCrane is now known as WrathOfAchilles
[01:33] <OvenWerks> teward: it is from someone on #ubunutustudio. Operating SystemUbuntu 20.10
[01:35] <OvenWerks> the irc logs seem to have missed most of the conversation
[01:36] <OvenWerks> https://irclogs.ubuntu.com/2020/10/31/%23ubuntustudio.html nope I was wrong it seems to be two days back
[01:37]  * OvenWerks heads for supper cooking
[15:43] <Eickmeyer[m]> teward: Any chance you have time for a quick, rather trivial, upload (by comparison to other stuff I've flung your way): https://launchpad.net/agordejo
[15:43]  * Eickmeyer[m] hopes to apply for MOTU by the end of this month to take that burden
[15:45] <studiobot> <teward001> changelog is wrong.  Hirsuite is the target
[15:46] <studiobot> <teward001> not Groovy
[15:46] <studiobot> <teward001> since that cycle's over
[15:46] <studiobot> <teward001> Eickmeyer[m]: ^ error #1
[15:46] <Eickmeyer[m]> teward: Oof, I may not have pushed that. 2 secs.
[15:47] <Eickmeyer[m]> teward: Now try.
[15:47] <Eickmeyer[m]> teward: s/hirsuite/hirsute ^
[15:48] <studiobot> <teward001> hirsute*
[15:48] <Eickmeyer[m]> hehe
[15:48] <studiobot> <teward001> lol
[15:48] <studiobot> <teward001> building local sbuild env now
[15:49] <Eickmeyer[m]> 👍
[16:01] <studiobot> <teward001> looks like it didnt fail to build in hirsute, but there's Lintian warn level things (and it doesn't come as 'clean')
[16:01] <studiobot> <teward001> but that may be my fault
[16:04] <Eickmeyer[m]> @teward001: Might be, had a clean PPA build.
[16:05] <studiobot> <teward001> i think it's a typo on my end before i repulled
[16:05] <studiobot> <teward001> running build again
[16:05] <Eickmeyer[m]> eesh.
[16:05] <studiobot> <teward001> but i think the no-man-page error is still grave enough
[16:05] <Eickmeyer[m]> Upstream is notified.
[16:06] <studiobot> <teward001> E: agordejo changes: bad-distribution-in-changes-file hirsute <— wow, hirsute lintian needs fixed xD
[16:06] <studiobot> <teward001> W: agordejo: no-manual-page usr/bin/nsm-data <— also yeah this is a failure case
[16:07] <Eickmeyer[m]> @teward001: We've had things go through without manpages, and I literally just ran lintian and got no warnings at all.
[16:08] <Eickmeyer[m]> Holup... nm, I see that. We can lintian-override it pretty easily explaining that upstream is aware.
[16:10] <Eickmeyer[m]> @teward001 I did get an error for sensible-utils against the binary, so I'll have to fix that for d/control.
[16:20] <studiobot> <Eickmeyer> @teward001 Feel free to re-pull, got those lintian issues hammered out. Realized I didn't exactly file an upstream issue, I told the developer directly in #lad.
[16:46] <studiobot> <teward001> lol
[16:46] <studiobot> <teward001> ok
[16:46] <studiobot> <teward001> give me a few - lunchtime
[16:48] <Eickmeyer[m]> 👍
[17:24] <studiobot> <teward001> yep no lintian errors here
[17:26] <studiobot> <teward001> uploaded to hirsute new
[17:38] <Eickmeyer[m]> @teward001 Thanks!
[17:44] <OvenWerks> Eickmeyer: I was thinking it would be nice to use zita-mu1 as a jack backend. This would allow an overall audio level setup... however, zita-mu1 has no remote control possibilities: MIDI, OSC, Keyboard shortcuts, etc.
[17:45] <Eickmeyer[m]> Yeah, that's not good for any MIDI devices, clearly.
[17:46] <OvenWerks> Eickmeyer: I was thnking more of the keyboard media controls (mute, vol+, vol-)
[17:46] <Eickmeyer[m]> Oh, right. Can't do that anyway except for with pulse.
[17:47] <Eickmeyer[m]> I have a MIDI controller that I pretty much use to control jack-mixer launched via Agordejo.
[17:47] <OvenWerks> It is easy enough to capture the keystrokes and change them to whatever (midi, OSC etc) if that was available.
[17:47] <OvenWerks> mu1 has nice metering :)
[17:48] <Eickmeyer[m]> I mean, do we want to use that as an expermental backend?
[17:48] <OvenWerks> and 20.04 has no jack-mixer
[17:48] <Eickmeyer[m]> I backported jack-mixer to the PPA.
[17:49] <OvenWerks> I guess I have that turned off so it doesn't affect my work on controls.
[17:49] <Eickmeyer[m]> Gotcha. You can always cherry-pick the .deb.
[17:51] <OvenWerks> no nsm?
[17:51] <OvenWerks> no ubuntustudio-menu?
[17:52] <Eickmeyer[m]> new-session-manager is in there....
[17:52] <OvenWerks> I guess it is not an update
[17:52] <OvenWerks>  :)
[17:53] <Eickmeyer[m]> The binary name had to be linuxaudio-new-session-manager
[18:11] <Eickmeyer[m]> OvenWerks: Just backported -menu for the jack-menu and elisa fixes.
[18:11] <Eickmeyer[m]> *jack-mixer
[18:21] <OvenWerks> jack-mixer suggests patchage?
[18:23] <Eickmeyer[m]> That's a leftover.
[18:23] <Eickmeyer[m]> All I did was update the Debian package.
[18:23] <OvenWerks> Eickmeyer[m]: I thought there was suppoed to be a link from nsm to linuxaudio-new-session-manager for compatability
[18:24] <Eickmeyer[m]> There is. It's built-in to the binary.
[18:24] <Eickmeyer[m]> It's merely a symlink.
[18:24] <OvenWerks> Command 'nsm' not found,
[18:24] <Eickmeyer[m]> Because it's not nsm. It's "non-session-manager".
[18:25] <Eickmeyer[m]> It's never been nsm.
[18:25] <OvenWerks> ah
[18:26] <Eickmeyer[m]> Either way, I'd rather directly support new-session-manager anyhow, or via agordejo (new-session-manager is used as its backend). The non-* tools need to die in a fire.
[18:26] <OvenWerks> Eickmeyer[m]: in controls the button should say new session manager then
[18:27] <Eickmeyer[m]> Indeed. Directly execute new-session-manager, not the symlink. The symlink is just there for backwards compatibility.
[18:27] <OvenWerks> ok. And I will have it point at linuxaudio-new-session-manager directly
[18:27] <Eickmeyer[m]> No, the binary executable is new-session-manager.
[18:28] <Eickmeyer[m]> The package name is linuxaudio-new-session-manager by archive admin request.
[18:28] <OvenWerks> ok
[18:29] <OvenWerks> $ new-session-manager
[18:29] <OvenWerks> new-session-manager: command not found
[18:29] <Eickmeyer[m]> Sorry, nsm-legacy-guiu
[18:29] <Eickmeyer[m]> *nsm-legacy-gui
[18:30] <OvenWerks> I wonder how that works in arch...
[18:31] <Eickmeyer[m]> Should be the same, that's the generated binary name.
[18:31] <OvenWerks> ok
[18:46] <OvenWerks> fixed in controls (on my machine ;)
[18:47] <Eickmeyer[m]> Cool.
[18:47] <Eickmeyer[m]> With as much activity as we're seeing (merge requests, etc.) I'm not going to tag it for pre-release until you feel ready.