[16:23] <ThomasWard[m]> *whistles nonchalantly about abandonware in Debian*
[16:24] <ThomasWard[m]> @Eickmeyer do me a favor check Debian audacity and see if they have a bug about moving to newer versions or if its an orphaned/unmaintained package.  its Universe so unless Debian gets a new version it aint getting updated in Ubuntu :P
[16:25] <ErichEickmeyer[m> @teward001 They do. Dan and I had been working on that aspect.
[16:26] <ErichEickmeyer[m> Unfortunately, Audacity is a lost cause at the moment, and we're going to have to go snap with it in Studio. I'm working with Dani on that one.
[16:26] <arraybolt3> wrt DigiKam, I saw your email about using either 7.x and removing av capabilities (fail) or using 8.0 from Git (now fail thanks to qtav). Is there something keeping us from using 8.0 and removing av capabilities from that?
[16:27] <arraybolt3> (I've been doing a ton of work on KDE and now have some C++ experience, so hacking together a patch to force it to work might be within the realm of possibility.)
[16:27] <ErichEickmeyer[m> The big problem is digiKam.
[16:28] <Eickmeyer[m]> arraybolt3: Unfortunately, Audacity isn't a KDE application, and digiKam is having ffmpeg5 issues, not really a c++ thing entirely.
[16:29] <Eickmeyer[m]> This is all boiling down to ffmpeg5.
[16:29] <arraybolt3> Eickmeyer[m]: I meant that we could use digiKam 8.0 (with ffmpeg5 compatibility) and force it to work without qtav.
[16:29] <arraybolt3> And even if it requires literally changing the source code to make it work without qtav, that might be something I could attempt.
[16:30] <arraybolt3> Even if it's an Ubuntu delta, at least it will work if the av functionality can be patched out.
[16:30] <Eickmeyer[m]> I tried that with the build flags, but it still seems to want it for something.
[16:30] <arraybolt3> Eh, who cares about build flags. It's open source.
[16:30] <Eickmeyer[m]> But have at it, if you want.
[16:30] <Eickmeyer[m]> I'm no good with c++.
[16:31] <Eickmeyer[m]> The biggest challenge is, right now, digiKam, due to being a git snapshot, is a moving target and riddled with bugs, which is why I'm basically uploading weekly.
[16:32] <arraybolt3> Oy. Makes sense.
[16:32] <Eickmeyer[m]> So, even if you do patch, they might not be relevant in a week.
[16:32] <arraybolt3> Hmm. Wow. And we can't just go back to ffmpeg4 because...?
[16:32] <arraybolt3> (Or even have both versions in the archive maybe?)
[16:33] <Eickmeyer[m]> Because ffmpeg4 isn't in the archive. Debian superseded it with 5.
[16:34] <arraybolt3> Blah. And probably having both versions installed side-by-side would be a n!gh7m4r#.
[16:34] <Eickmeyer[m]> Probably.
[16:35] <Eickmeyer[m]> When I asked the digiKam devs about it, I got accosted for moving to ffmpeg 5 "prematurely" when it wasn't even my call.
[16:37] <arraybolt3> We currently have a way to put JACK and PipeWire JACK side-by-side. It may be one seriously difficult packaging job, but if there is someway to allow ffmpeg4 to co-exist with ffmpeg5 and upload version 4 in Ubuntu, then force digiKam to use version 4, that might work. Yes, it may be insanely difficult, but it might be easier than repatching digiKam weekly to make it work without qtav.
[16:37] <arraybolt3> (Or maybe we can ask really nicely for qtav to be put back?)
[16:38] <Eickmeyer[m]> Well, honestly, they didn't even go through the right protocol. They're supposed to inspect the rdepends first and then, if they find it's seeded by a flavor, ask the flavor lead. That didn't happen.
[16:38] <Eickmeyer[m]> Hence my email.
[16:40] <Eickmeyer[m]> It's too late now, though. In order for it to be put back, it has to build. Unfortunately, qtav ftbfs against ffmpeg 5.
[16:40] <arraybolt3> Man, what a mess. What if we forced ffmpeg4 back in, kicked ffmpeg5 out, and blocked Debian syncs of ffmpeg5 until further notice? Is that a possibility?
[16:40] <Eickmeyer[m]> Might be, but then we'd have to rebuild all the things.
[16:40] <arraybolt3> And that could have even worse fallout...
[16:40] <Eickmeyer[m]> Too late in the cycle for that.
[16:40] <arraybolt3> Wow. Well, can we package our own Snap of digiKam?
[16:41] <arraybolt3> Ignoring the KDE snap?
[16:41] <Eickmeyer[m]> That's a possibility, but I only know enough about snap packaging to be dangerous (aka electron/nodejs snaps).
[16:42] <arraybolt3> (I'm probably just being annoying at this point, you already probably walked this mental path yourself, so sorry to be distracting. I'll try patching digiKam later if I get the time.)
[16:42] <Eickmeyer[m]> Nah, you're fine. I have definitely been walking through the mental path all morning, hence my email.
[16:42] <RikMills> you could ask if ffmpeg4 can be revived under a rename source package ffmpeg4? so both that and ffmpeg 5 are available?
[16:42] <RikMills> not sure how practical that is
[16:43] <ThomasWard[m]> Eickmeyer[m]: eickmeyer i can attempt to snap digikam but it might require some postinst config for the proper configurations for devices
[16:43] <ThomasWard[m]> if you want me to try i can i'm bored today
[16:43] <Eickmeyer[m]> RikMills: I'm not sure either. Honestly, that's a stretch at this point.
[16:43] <RikMills> yesh, it would be very last resort
[16:44] <RikMills> *yeah
[16:44] <Eickmeyer[m]> Thomas Ward: Feel free if you're up for the task. I'm taking my family to the fair today and I just don't have the time to do that, sadly.
[16:44] <ThomasWard[m]> i'd use 20.04 as the base though for such a snap so itd still have older deps.  but its a potential option
[16:45] <Eickmeyer[m]> Thomas Ward: For snaps, it doesn't matter. 
[16:45] <Eickmeyer[m]> I'd even be willing to take the 7.8.0 digiKam in a snap.
[16:45] <Eickmeyer[m]> It uses ffmpeg 4 and should work in base 20.
[16:46] <ThomasWard[m]> Eickmeyer[m]: kinda does if the deps arent readily available as snaps :P
[16:46] <ThomasWard[m]> whats in 22.04?
[16:46] <ThomasWard[m]> because thats the latest base i can get
[16:47] <RikMills> ffmpeg 4 is in 22.04
[16:47] <Eickmeyer[m]> 7.6, I believe, but KDE has a snap of 7.8, but I don't know their base.
[16:49] <arraybolt3> So... wait, if we can use earlier bases the way it sounds like you guys are suggesting, what's keeping us from just seeding the KDE snap of digiKam? (I'm probably just misunderstanding something here.)
[16:50] <arraybolt3> I'm guessing there's a difference between using different Snap bases and using different Snap channels.
[16:51] <Eickmeyer[m]> arraybolt3: In order to do so, a "track" has to be opened and closed for a particular release. So, for the stable release of the snap, it has to have had a "stable/ubuntu-22.10" track.
[16:51] <arraybolt3> Ah. OK.
[16:53] <Eickmeyer[m]> It's a way for Ubuntu devs that maintain snaps for them to approve the snap for a particular Ubuntu release. Notice that I maintain Freeshow, and Dani Llewellan maintains Ardour, so the have the "secret sauce" as it were.
[16:53] <arraybolt3> While Thomas attacks the digiKam snap, I'll see about patching the source code in about an hour. (I'm building KWin and its dependencies atm getting ready for an MR in KDE, and my system is sloooooow at that. Hopefully I'll have a much faster system in the near future, if all goes according to plan \o/)
[16:54] <Eickmeyer[m]> Ardour still needs some work though.
[16:54] <arraybolt3> Oh no, Ardour is in trouble too?
[16:54] <Eickmeyer[m]> Ardour FTBFS and was removed, so we're going with the snap. Luckily the snap is in much better shape.
[16:54] <arraybolt3> s/ffmpeg5/whyDidDebianHaveToShredUbuntuStudio/
[16:55] <arraybolt3> Well, hey, at least we have solutions working.
[16:57] <Eickmeyer[m]> and/or in progress. I'm going to keep working with Dani and others on the desktop team on Ardour tomorrow since they own the gtk-common packages.
[16:58] <arraybolt3> Do you think maybe we should try to get future ffmpeg syncs from Debian blocked so that we can avoid this chaos in the future? That way when Debian decides to jump to ffmpeg6 prematurely, we can let them deal with the explosion and then pull everything in once it's stabilized.
[17:01] <arraybolt3> Glad to hear you and your family are going to get a break, sorry to hear about this mess with the distro. God be with you, we got this with His help.
[17:01] <Eickmeyer[m]> I wouldn't worry about it. Major ffmpeg releases are so few and far between that this doesn't happen usually.
[17:03] <Eickmeyer[m]> arraybolt3: Thanks. :)
[17:30] <ThomasWard[m]> snap wont be quick :P
[17:30] <ThomasWard[m]> i have to eat and attend some important family stuff today
[17:31] <ThomasWard[m]> actually
[17:32] <ThomasWard[m]> @eickmeyer looks like KDE is faster.  they already have a digikam snap
[17:32] <ThomasWard[m]> 7.8.0
[17:32] <arraybolt3> ThomasWard[m]: Right, but as Eickmeyer explained, it doesn't have the needed stable/ubuntu-22.10 track.
[17:32] <ErichEickmeyer[m> @teward001 Yeah, but any seeded snap requires a stable/ubuntu-22.10 track (for kinetic) to be opened/closed, so it's not as simple as just adding the snap.
[17:33] <ThomasWard[m]> so ask kde to create a branch then?
[17:33] <arraybolt3> ErichEickmeyer[m: Is it possible to install the digiKam snap on Kinetic as it is? If so, I could go in and ask for the track to be opened.
[17:33] <ThomasWard[m]> i cant create a snap whose name is already taken so
[17:34] <arraybolt3> (Thus saving you from getting peppered with ffmpeg nonsense so you can get a break)
[17:34] <ErichEickmeyer[m> You can always create a snap like "digikam-studio" or something. It's only for a release cycle anyhow.
[17:34] <ThomasWard[m]> *yawns* true.  maybe i'll see if i can pull down their snap and tweak it
[17:35] <arraybolt3> That would save us a lot of work. Pull, reupload, open track, call it a day.
[17:35] <ErichEickmeyer[m> Should be as simple as their yaml, but I couldn't find it.
[17:36] <Eickmeyer> Heh, I see the telegram-matrix bridge is slow today.
[17:37] <ThomasWard[m]> they might not publish the yaml.  I could ask them to provide a copy for me to republish explicitly for Ubuntu Studio's seeding
[17:37] <ThomasWard[m]> see if they're willing
[17:38] <ThomasWard[m]> KDE doesnt hate me (yet)
[17:40] <arraybolt3> I think I just found the snapcraft.yaml
[17:40] <arraybolt3> https://invent.kde.org/packaging/snapcraft-kde-applications/-/blob/Neon/release/digikam/snapcraft.yaml
[17:40] <ThomasWard[m]> where
[17:40] <arraybolt3> link is above
[17:40] <ThomasWard[m]> *takes*
[17:41] <arraybolt3> digiKam repo on invent.kde.org, search for s
[17:41] <arraybolt3> snapcraft, it gave me the link
[17:41] <ThomasWard[m]> got it
[17:41] <ThomasWard[m]> i'm going to email the devs though over at KDE to make sure they're OK with me republishing the current snap as digikam-studio just for Ubuntu STudio
[17:42] <ThomasWard[m]> because i don't want to get a strike
[17:42] <ThomasWard[m]> :P
[17:42] <arraybolt3> Also should you need the snapcraft files for other KDE apps, https://invent.kde.org/packaging/snapcraft-kde-applications
[17:46] <ThomasWard[m]> i sent an email to the person who TIL on that repo so
[17:46] <ThomasWard[m]> i expect a response since it was only a week ago they made snap changes
[17:47] <ThomasWard[m]> asking if they'll add a branch for us or, if not, whether they mind me making a copy of the snap exclusively for Studio to seed.
[17:47] <ThomasWard[m]> if they don't do the first, and OK the second, then I'll get that done as soon as I get a reply since they did all the work for me.  :
[17:47] <ThomasWard[m]> * me.  :P
[17:48] <ErichEickmeyer[m> Well, they can add the stable/ubuntu-22.10 and then promptly close it and we can still seed it.
[17:48]  * arraybolt3 tries to figure out how to type a thumbs-up in IRC
[17:48] <ThomasWard[m]> truth but that's why i asked if they'd make the branch first
[17:48] <Eickmeyer> arraybolt3: Usually an emoji can do that.
[17:48] <ThomasWard[m]> or if not if they'd let me make a dupe
[17:48] <ThomasWard[m]> as i said, better to ask permission than to get forgiveness in this case
[17:48] <ThomasWard[m]> because you know i'm chaotic evil that way :)
[17:49] <ThomasWard[m]> but also it makes sense
[17:49] <ThomasWard[m]> i don't want to step on toes :)
[17:49] <ErichEickmeyer[m> Sure.
[17:49] <arraybolt3> Eickmeyer: Right but Hexchat doesn't have fancy emoji shortcuts like Matrix does, and I'm leery of Matrix for Libera stuff after it exploded last time.
[17:49] <arraybolt3> (Plus IRC is faster and more comfortable)
[17:49] <Eickmeyer> arraybolt3: If you're on Plasma, Meta-. (meta-period)
[17:49] <arraybolt3> Nope, GNOME. :(
[17:49] <Eickmeyer> Ah.
[17:49] <arraybolt3> Will be on Plasma if things pan out though.
[17:50] <Eickmeyer> I'm on gnome too. I can do meta-. and have an emoji selector.
[17:50] <Eickmeyer> But that might be custom.
[17:50] <arraybolt3> (Installing Ubuntu Desktop on this laptop may have been one of the worst not-utterly-catastrophic computer decisions of my life.)
[17:50] <arraybolt3> Must be custom. Doing Meta-. on my system does this: .
[17:50] <Eickmeyer> ANYhoo...
[17:50] <arraybolt3> Right, sorry for offtopic.
[17:51] <ThomasWard[m]> bridge be fubar
[17:51] <Eickmeyer> Bridge be slow as molasses.
[17:51] <teward> ye bridge be broke.  and it's also using the wrong names xD
[17:51] <teward> i'mma just use here or the matrix bridge :P
[17:52] <Eickmeyer> The Telegram bridge is via Matrix, so that's part of it.
[17:52] <teward> mmm well it's fubar so :p
[17:52] <Eickmeyer> 2x fubar
[17:52] <teward> i'll just irccloud here then
[17:52] <arraybolt3> /kick TelegramBridge[m && /invite TelegramBridge[m
[17:53] <Eickmeyer> Mostly it's just slow.
[17:53] <teward> but yeah i emailed the person who TIL on the KDE side so i'll await their reply and see what they say about either them adding a branch or us forking/cloning the snap
[17:53] <teward> either way we'll get an answer
[17:53] <teward> brb food's here
[17:54]  * arraybolt3 portals a U-Haul full of well-flavored coffee over to teward's house
[18:27] <Eickmeyer> Ok everyone. Off to the fair. Keep me apprised. So far, Ardour is looking good from a snap standpoint, should be able to put it in the seed sometime tomorrow.
[18:31] <arraybolt3> Eickmeyer: o/ Stay safe!
[21:58] <OvenWerks> Eickmeyer: (when you are back), just read the above. WRT Ardour snap, do all lv2, vst, lv1 plugins work with that? Does it work with jackd? ALSA?
[21:59]  * OvenWerks is begining to think linux is on it's way into useless land
[22:06] <arraybolt3> OvenWerks: Or ffmpeg, one of the two.
[22:12] <Eickmeyer[m]> OvenWerks: Yes, snap isn't a "container" container like docker and isn't completely isolated anymore.
[22:12] <Eickmeyer[m]> Besides, we have no choice. It's either this or nothing.
[22:12] <OvenWerks> arraybolt3: lbi authors making their libs so old, non-broken, dev complete SW can no longer be used has increasingly become a problem.
[22:12] <OvenWerks> s/lbi/lib/
[22:12] <Eickmeyer[m]> Still at the fair, btw.
[22:13] <Eickmeyer[m]> Where I have a problem is deva refusing to move to newer libs despite deprication warnings.
[22:13] <Eickmeyer[m]> *devs 
[22:15] <OvenWerks> Some of us only have so much time. I kind of like the c++ idea where sw can be compiled with a version flag, even with the newer version.