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