=== Eickmeyer is now known as Eickmeyer-Quasse === Eickmeyer-Quasse is now known as Eickmeyer[q] [15:09] OvenWerks: We've lost patchage, they failed to update to Python3 in time. We also lost gmidimonitor and displaycal. [15:19] eickmeyer don't we have carla at least for partial coverage? [15:19] (for patchage I mean) [15:21] Yes, we do. [15:22] I will miss DisplayCAL, however. :( [15:26] yeah... :/ [15:26] what happened to displaycal anyway? package conflict? [15:41] No. Displaycal is still on Python 2. [15:43] @azbulutlu [what happened to displaycal anyway? package conflict?], Developer didn't see the value in updating to Python 3. https://hub.displaycal.net/issue/17813/ [15:43] They've only had over a decade to get it sorted. [15:43] :( [15:44] Indeed. I'm not happy about that one, as a photographer. Now I have to boot into Windows in order to do any sort of calibration, then take the profile over to my LInux install(s). [15:45] As for patchage, it's kinda been limping along and on its death bed, so I'm not too surprised. At least we have Carla. [15:47] I mean more and more screens come out of factory calibrated. but yeah having display cal as an option was a good thing. :( is there an alternative out there? [15:47] pathage... *is also not surprised* [15:48] I've looked for alternatives to DisplayCAL, and there really is none. [15:48] patchage has commits in feb 2020 [15:48] OvenWerks: Yes, but no release, and still needs Python 2. [15:49] Python 2 is officially gone. [15:49] Dave is pretty busy with real work. [15:49] I agree, but the archive doesn't care. [15:50] I'm not upset about that one. The DisplayCAL developers actually get PAID to do that one. [15:51] BTW, Patchage and DisplayCAL are both missing from Fedora for the same reason. [15:51] and arch [15:51] Yep. [15:52] Unless Dave can miraculously fix Patchage in the next week, people will have to adjust their workflows. We have no control over that. [16:03] maybe it was me that vanished [16:03] You did. Your network took a dump, I think. [16:05] gmidimonitor is probably more important than patchage [16:05] my new inet service seems much more flakey than the old... [16:07] RE: gmidimonitor: Sadly, there's nothing we can do at this point. It's gone. [16:10] Looks like trebmuh has been working on it in Salsa. [16:11] Huh, looks like it might just be a build-dep issue. [16:11] Unfortunately, without the upstream code, I don't know how to fix it. [16:12] it is really quite a simple gui and app for that matter [16:12] The source home doesn't even exist anymore. [16:14] I guess I could play around with the salsa repo and see if there's a fix that way. [16:14] Oh... it builds with waf. That's why. [16:14] Same issue as we had with Ardour. [16:16] I wonder if Nedko is still around [16:16] Well, with my experience fixing Ardour, I *might* be able to fix this, but don't hold your breath. [16:17] Additionally, it's WAY late in the cycle. [16:17] teward: Might need your help. [16:17] backports is fine [16:17] TL;DR: gmidimonitor was removed from the repos due to ERR:Python2. [16:18] And it was removed 1) after Beta freeze, and 2) after Feature freeze. [16:18] * teward yawns [16:18] hmm? [16:18] i'll need more details here [16:18] gmidimonitor was in the repos until sometime within the past week. It was removed due to Python2's removal. [16:18] It FTBFS. [16:18] it was also removed in Debian [16:19] Indeed. [16:19] see Debian Bug #943041 [16:19] Debian bug 943041 in src:gmidimonitor "gmidimonitor: Python2 removal in sid/bullseye" [Normal,Open] http://bugs.debian.org/943041 [16:19] But all this was after Feature Freeze. [16:19] And Beta Freeze. [16:19] Turns out, according to OvenWerks, this is a rather important application. [16:19] and...? The Py2 removal has been an "Ongoing Task" with freeze exemptions since the dawn [16:19] the only way to fix it is to port it to Python 3, or find a replacement [16:19] Well, it's just the build system that's Python. The rest is c. [16:19] in both cases, it needs to be an -ng variant probably because it's a 'new' replacement [16:20] i'm confused then, what do you need from me? [16:20] i can't veto a removal in this case [16:20] I might need you to sponsor an upload. [16:20] Eickmeyer: i'll need to heavily vet it first [16:20] and i'll need to coordinate with Archive Admins and Release Team [16:20] That's assuming I can get it to build, of course. [16:21] It's the exact same issue we had with Ardour. [16:21] Except it got removed (annoyingly) much later. [16:21] Eickmeyer: we may want to concider it dead of bitrot... useful as it is. [16:22] if some one really wants that function they can use amidi in the terminal [16:22] OvenWerks: If you're OK with that... you seemed to give me the impression that it is necessary. [16:22] it is 2011 [16:22] https://repo.or.cz/gmidimonitor.git [16:23] 9 years old. Yeah, let's let it die. We can't keep resurrecting stuff from the dead. [16:23] > 8 years ago 3.6 | commit | log < yikes [16:23] yeah i'm not sponsoring bitrot [16:23] :p [16:23] maybe something to add to -controls [16:23] Maybe, if you want to take the code and give them credit. [16:23] I would just add a gui layer to amidi [16:23] unrelated, its homepage is one lol [16:24] gone* [16:25] I wonder if Nedko is still around -> yes those days he's on #lad [16:25] he's right now [16:25] trebmuh: yes but I have not seen comments from him in ages [16:26] he's not involved too much in the linuxaudio community since the ladish VS jack-session debacle [16:26] both have basically gone away [16:27] but if you want to catch up with him about gmidimonitor, you've got an answer to your initial question [16:27] The days of using a pile of applications all connected via jack are basically gone with LV2 and lxvst [16:28] Eickmeyer, y'es I've been adding a few little things : https://salsa.debian.org/multimedia-team/gmidimonitor/-/commits/master/ [16:28] I don't believe so OvenWerks [16:29] it might be right that some stuff are done now with an host/plugin approach [16:29] not going to argue that one, it is true that people still route via jack [16:30] but one still need jack for using lets say using hydrogen with ardour with rosegarden [16:30] yes [16:30] jack transport rocks [16:30] and it does so because it has not changed :) [16:30] if we would loose the jack approach, then the linuxaudio realm would be f*cked up [16:31] and we would end up with the same crap than on proprietary system [16:31] remind Paul and Robin of that once in a while... [16:31] ie : you're bloody stuck with the host/daw you started with [16:31] I know, I know [16:31] but hey, they aren't the center of the universe [16:32] both have commented about how easy things would be if they just removed the jack backend] [16:32] and moreover, they're community driven [16:32] they're ardour/mixbus driven [16:32] Just throwing this out there: pipewire supports the Jack API now. [16:32] (even if they are doing a great job within the community IMHO) [16:32] Eickmeyer, no [16:32] Eickmeyer, it supports parts of the API [16:33] * OvenWerks hides behind a rock [16:33] but it's not ready to replace jack and will not soon [16:34] trebmuh: I agree that those who use jack for gluing daws, trackers etc. together would not like PW [16:34] trebmuh: That's true. I have it in Fedora Jam 32 as an optional, experimental component. [16:34] OvenWerks, why hiding? you work for mixbus/ardour maybe? [16:35] OvenWerks: Talking to the devs, they are working on the same glue that Jack uses in terms of patching/routing together different audio applications. [16:35] that wasn't a "they are the evil" thing from me, just a fact that you're not driven by the same thing when doing thing freely or doing thing for money [16:35] I do work on Ardour but do not agree jack is dead. No hiding because I really don't want to even begin arguing that one [16:35] Including apps that only use Pulseaudio. [16:36] OvenWerks, you do work as a paid work ? [16:36] (it doesn't use the Pulse APi yet). [16:36] no [16:36] that the full point OvenWerks [16:36] at least the one I'm talking about here :) [16:36] The OSC surface stuff is mostly mine though [16:37] The foldback bus/send stuff is mine [16:37] oh yeah, I remember a bunch of commits from you on the github ardour tracker now [16:37] great job BTW [16:37] anyway guys, I've got to go now [16:37] TTYL [16:37] Bye trebmuh o/ [16:38] However, I test all ardour stuff with jack [16:38] o/ [16:39] Eickmeyer: what is the status of libfltk in 20.04? [16:40] Nonexistant, afaict. [16:40] Uh... hold please [16:40] I was looking at the wrong package. It's there. [16:41] Ya it is still there [16:41] !libfltk1.3 [16:41] !info libfltk1.3 focal [16:41] libfltk1.3 (source: fltk1.3): Fast Light Toolkit - main shared library. In component universe, is optional. Version 1.3.4-10build1 (focal), package size 532 kB, installed size 1520 kB [16:42] I have it installed as a dep for something. [16:42] fluid is still there too [16:43] Yep, stuff got rebuilt against fluidsynth 2 back in January. [16:43] fluid as oposed to fluidsynth [16:43] Ohhh... [16:44] looks like infamous plugins uses it [16:44] (I must have the source in here) [16:45] So, the only things that got removed when I updated the metas this morning were the packages I listed, only after Ross told the ML DisplayCAL was gone. [16:45] * OvenWerks prefers fltk to gtl or qt [16:45] Patchage fell victim, and gmidimonitor died of bitrot. [16:46] fltk is a bit DE-agnostic, so yeah, I can see that. [16:47] gmidimonitor make come back it seems but I think it would be better look for something that being maintained [16:47] I saw a qt equivalent at one point. [16:51] kmidimon? [16:52] it is still there in 18.04 still in 20.04? [16:53] midisnoop? [16:54] amidi, BTW, will not replace gmidimonitor [16:56] kmidi mon only goes to disc [16:57] midisnoop is still there [17:00] Eickmeyer: Can we at this time substitute midisnoop for gmidimonitor as being the same feature? [17:00] OvenWerks: I think we can. Let me check.. [17:00] !info midisnoop focal [17:00] midisnoop (source: midisnoop): MIDI monitor and prober. In component universe, is optional. Version 0.1.2+git20141108.bc30f600187e-1build1 (focal), package size 166 kB, installed size 642 kB [17:01] Yeah, let me sub it out in the seed real quick. [17:03] Actually it looks nicer [17:05] Updated in seed, now updating metas. [17:06] It has no upstream though :P [17:06] >>>http://midisnoop.googlecode.com/ [17:07] Lovely. :P [17:07] googlecode is gone [17:07] It's only moved: [17:07] https://github.com/surfacepatterns/midisnoop [17:07] Except... latest commit was 2014. [17:07] yeah [17:08] We can include it, but it's not long for this world. [17:10] and there is no desktop file [17:10] *sigh* [17:11] thats ok I think [17:11] not nice but ok [17:11] Yeah, we can backport something in -menu to fix that. [17:12] I was considering an emergency bugfix to that, but it is SO late in the cycle, the changes to -meta are sure to annoy the release team. [17:12] As it is, I am going to be filing a FFe for the metas. [17:12] Eickmeyer: is there anyway to tell which libs it actually chose as deps? [17:13] The source does seem to have a desktop file [17:14] https://packages.ubuntu.com/focal/midisnoop [17:14] The deps aren't outlandish by any means, and I think stuff we already carry. [17:14] Nice that it's already Qt5. [17:16] and python3 [17:20] Ok, metas updated and uploaded with FFe attached. [17:24] Now the release team does their thing. === dax is now known as ezri