[10:47] <effendy[m]> When I do dig +trace some-domain.com, I can see that dig starts using the root hints. Any ideas where in Ubuntu (22.04) is dig getting that list from? I know that bind comes preinstalled with them, but I'm not sure where dig takes them from.
[11:06] <effendy[m]> I've found it here :) /usr/share/dns/root.hints
[11:09] <JanC> $ dpkg -S /usr/share/dns/root.hints
[11:09] <JanC> dns-root-data: /usr/share/dns/root.hints
[11:09] <JanC> if you wonder what package provides that  :)
[11:11] <JanC> effendy[m]: ^
[11:12] <effendy[m]> Thank you :)
[17:13] <Odd_Bloke> JanC: I'm using a tool which launches the ffmpeg processes for me, so I don't think I could do that (but I agree that if I could it would be better!)
[17:14] <JanC> you mean it has "ffmpeg" hardcoded?
[17:15] <Odd_Bloke> The container ships its own ffmpeg and, yeah, it uses that one directly from its internals (which are written in Node, hence having it in a Docker container :p)
[17:16] <JanC> depending on how it launches ffmpeg, either use and alias (if it launches it from a script) or rename the "real" ffmpeg and put a script named 'ffmpeg' in its place
[17:16] <JanC> that would require editing the container though
[17:17] <Odd_Bloke> Yeah, exactly, I don't really want to get into doing that (because then I can't just `pull` upstream updates etc.): I don't need it to be perfect, this isn't A Production System or anything, so a cron is fine.
[17:18] <Odd_Bloke> I really appreciate your help!
[17:19] <JanC> not sure updates would be really necessary for this container (assuming it only transcodes your existing collection, and doesn't really do anything on the internet)
[17:21] <Odd_Bloke> Well, there may be bugs which are fixed etc.
[17:27] <JanC> from your description it sounds like it does the exact same thing over & over again, so bugs should be the same over & over again too  :)
[17:29] <JanC> and upgrades might add new bugs too
[17:29] <JanC> but, you know best what exactly you try to do, and I'm basically guessing a lot...
[17:31] <Odd_Bloke> It has a management web interface, and supports remote transcoding workers etc., so it's not just the ffmpeg execution that I'm using it for. :)
[19:26] <meatswets> Odd_Bloke: what's the name of the container?
[19:31] <Odd_Bloke> meatswets: It's Tdarr, but I didn't realise it was closed-source when I started using it (it's "on" GitHub, but the public stuff just pulls privately built images behind the scenes) so IDK if I'd really recommend it.
[19:31] <Odd_Bloke> (But as I've already deployed it I'm gonna let it free up some disk space for me until I have time to find a free alternative. :p)
[19:32] <meatswets> cool, thanks
[19:33] <meatswets> how many nodes are you running?
[19:51] <Odd_Bloke> Just one at the moment, I need to configure things to remotely mount my media server's disks on my almost-always-booted-into-Windows desktop to set up a worker there, and I haven't had the time.
[19:51] <Odd_Bloke> (I thought "hmm, I wonder if I could contribute streaming the data from the server to avoid needing to mount disks everywhere" and that was the point at which I discovered it was closed-source, lol)
[21:02] <sarnold> d
[21:02] <sarnold> d'oh :(
[21:25] <athos> I no longer wish to merge https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/squid/+git/squid/+merge/442032. I wonder what I should do with it instead of deleting the MP so we can keep it to track all the history behind the squid MRE
[21:25] <athos> Cc rbasak 
[22:13] <rbasak> athos: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MergeProposal.md#retiring-a-merge-proposal
[22:14] <rbasak> So just mark it Rejected I think?
[22:44] <athos> I see no rejected status option there, rbasak :(
[22:50] <rbasak> athos: apparently you need permissions on the target branch :-(
[22:51] <rbasak> athos: I've done it for you for now. This should be resolved once we have git-ubuntu staging branches.
[22:55] <athos> Oh, thank you, rbasak!