=== Eickmeyer is now known as Eickmeyer-Quasse | ||
=== Eickmeyer-Quasse is now known as Eickmeyer[q] | ||
Eickmeyer | OvenWerks: We've lost patchage, they failed to update to Python3 in time. We also lost gmidimonitor and displaycal. | 15:09 |
---|---|---|
studiobot | <azbulutlu> eickmeyer don't we have carla at least for partial coverage? | 15:19 |
studiobot | <azbulutlu> (for patchage I mean) | 15:19 |
studiobot | <Eickmeyer> Yes, we do. | 15:21 |
studiobot | <Eickmeyer> I will miss DisplayCAL, however. :( | 15:22 |
studiobot | <azbulutlu> yeah... :/ | 15:26 |
studiobot | <azbulutlu> what happened to displaycal anyway? package conflict? | 15:26 |
studiobot | <Eickmeyer> No. Displaycal is still on Python 2. | 15:41 |
studiobot | <Eickmeyer> @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 |
studiobot | <Eickmeyer> They've only had over a decade to get it sorted. | 15:43 |
studiobot | <azbulutlu> :( | 15:43 |
studiobot | <Eickmeyer> 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:44 |
studiobot | <Eickmeyer> 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:45 |
studiobot | <azbulutlu> 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 |
studiobot | <azbulutlu> pathage... *is also not surprised* | 15:47 |
studiobot | <Eickmeyer> 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:48 |
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:49 |
Eickmeyer | I'm not upset about that one. The DisplayCAL developers actually get PAID to do that one. | 15:50 |
Eickmeyer | BTW, Patchage and DisplayCAL are both missing from Fedora for the same reason. | 15:51 |
OvenWerks | and arch | 15:51 |
Eickmeyer | Yep. | 15:51 |
Eickmeyer | Unless Dave can miraculously fix Patchage in the next week, people will have to adjust their workflows. We have no control over that. | 15:52 |
OvenWerks | maybe it was me that vanished | 16:03 |
Eickmeyer | You did. Your network took a dump, I think. | 16:03 |
OvenWerks | gmidimonitor is probably more important than patchage | 16:05 |
OvenWerks | my new inet service seems much more flakey than the old... | 16:05 |
Eickmeyer | RE: gmidimonitor: Sadly, there's nothing we can do at this point. It's gone. | 16:07 |
Eickmeyer | Looks like trebmuh has been working on it in Salsa. | 16:10 |
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:11 |
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:12 |
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:14 |
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:16 |
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:17 |
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:18 |
Eickmeyer | Indeed. | 16:19 |
teward | see Debian Bug #943041 | 16:19 |
ubottu | Debian bug 943041 in src:gmidimonitor "gmidimonitor: Python2 removal in sid/bullseye" [Normal,Open] http://bugs.debian.org/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:19 |
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:20 |
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:21 |
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:22 |
Eickmeyer | 9 years old. Yeah, let's let it die. We can't keep resurrecting stuff from the dead. | 16:23 |
teward | > 8 years ago3.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:23 |
teward | gone* | 16:24 |
trebmuh | <OvenWerks> 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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
* OvenWerks hides behind a rock | 16:33 | |
trebmuh | but it's not ready to replace jack and will not soon | 16:33 |
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:34 |
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:35 |
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:36 |
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:37 |
OvenWerks | However, I test all ardour stuff with jack | 16:38 |
OvenWerks | o/ | 16:38 |
OvenWerks | Eickmeyer: what is the status of libfltk in 20.04? | 16:39 |
Eickmeyer | Nonexistant, afaict. | 16:40 |
Eickmeyer | Uh... hold please | 16:40 |
Eickmeyer | I was looking at the wrong package. It's there. | 16:40 |
OvenWerks | Ya it is still there | 16:41 |
Eickmeyer | !libfltk1.3 | 16:41 |
Eickmeyer | !info libfltk1.3 focal | 16:41 |
ubottu | 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:41 |
Eickmeyer | I have it installed as a dep for something. | 16:42 |
OvenWerks | fluid is still there too | 16:42 |
Eickmeyer | Yep, stuff got rebuilt against fluidsynth 2 back in January. | 16:43 |
OvenWerks | fluid as oposed to fluidsynth | 16:43 |
Eickmeyer | Ohhh... | 16:43 |
OvenWerks | looks like infamous plugins uses it | 16:44 |
OvenWerks | (I must have the source in here) | 16:44 |
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:45 |
Eickmeyer | fltk is a bit DE-agnostic, so yeah, I can see that. | 16:46 |
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:47 |
OvenWerks | kmidimon? | 16:51 |
OvenWerks | it is still there in 18.04 still in 20.04? | 16:52 |
OvenWerks | midisnoop? | 16:53 |
OvenWerks | amidi, BTW, will not replace gmidimonitor | 16:54 |
OvenWerks | kmidi mon only goes to disc | 16:56 |
OvenWerks | midisnoop is still there | 16:57 |
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:00 |
ubottu | 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:00 |
Eickmeyer | Yeah, let me sub it out in the seed real quick. | 17:01 |
OvenWerks | Actually it looks nicer | 17:03 |
Eickmeyer | Updated in seed, now updating metas. | 17:05 |
OvenWerks | It has no upstream though :P | 17:06 |
OvenWerks | >>>http://midisnoop.googlecode.com/ | 17:06 |
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:07 |
Eickmeyer | We can include it, but it's not long for this world. | 17:08 |
OvenWerks | and there is no desktop file | 17:10 |
Eickmeyer | *sigh* | 17:10 |
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:11 |
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:12 |
OvenWerks | The source does seem to have a desktop file | 17:13 |
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:14 |
OvenWerks | and python3 | 17:16 |
Eickmeyer | Ok, metas updated and uploaded with FFe attached. | 17:20 |
Eickmeyer | Now the release team does their thing. | 17:24 |
=== dax is now known as ezri |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!