14:46 <beerman> jaeger: https://dpaste.com/6R9ESBTKU it seems that docker depends on btrfs-progs (?), but even with it, it fails to build for me on one machine

14:47 <beerman> oh, it already does pull in btrfs-progs, silly me. sorry. the paste is still relevant. I am currently trying inside my container

15:07 <jaeger> yeah, discovered that last night. Recent btrfs-progs update broke it, maybe? I haven't looked into it yet

15:09 <jaeger> https://github.com/moby/moby/issues/44698

16:51 <beerman> dunno, need to test

17:18 <jaeger> just tested here, downgrading btrfs-progs to 6.0.2 fixes the docker build

17:19 <jaeger> Based on the comments in that issue I don't think the docker folks are rushing to fix it, so it might be a while. We could either revert the btrfs-progs update or disable btrfs support in docker temporarily, perhaps.

17:58 <jaeger> Looking at yet another ffmpeg/kodi breakage for kodi 19.5 (which I know you already work around by using an older ffmpeg tarball) and I'm wondering if we should introduce a Pkgfile option to skip unpacking specified things in the source array for situations like this.

17:59 <jaeger> Instead of overriding unpack_source, which feels messy even though I've also done it a few times

18:25 <jaeger> We've probably talked about this before, I don't recall

19:20 <farkuhar> jaeger: the renames array can be used for that purpose, as seen in this diff http://ix.io/4jOx

19:23 <farkuhar> This tactic might be criticized for violating the KISS principle, by "hiding one function inside another". It does avoid having to add new subroutines to pkgmk, though.

19:31 <jaeger> I'll take a look, though from a logical standpoint I think I'd rather handle it in unpack_source, no new subroutine

19:31 <jaeger> It would just be something simple like "if this source filename exists in nounpack=(), then just copy it instead of unpacking it"

19:36 <farkuhar> The original unpack_source function already makes the distinction between files that get copied intact, and files that get unpacked. It just uses the crude mechanism of filename extensions to make that distinction. So I figured, let's play along with its crude method, and give it a filename that doesn't match what it likes to unpack. Then we can tidy up the mess on the other side of unpack_source (in the build function).

21:45 <jaeger> Yeah, looking at SKIP I'm not a fan of it for this... it works but it's not intuitive and requires specifying the entire source array as renames, seems like

21:54 <beerman> including the entire source array is kind of a hassle with a few things, i agree, but its the best tool we have so i'm gladly using that one

21:59 <beerman> about btrfs-progs and docker.. dunno, might sense to wait a bit. docker folks seem a bit odd, at times.

22:01 <jaeger> I'm not saying we shouldn't use SKIP, I just don't like it for this particular use case. I'm going to play with another solution to see how I like it

22:02 <beerman> sure, i'd take anything better in a heartbeat

22:03 <ivandi> imho downgrading btrfs-progs is a better option than disabling btrfs. we don't lose functionality in docker. on btrfs filesystem docker uses the btrfs storage driver by default.

22:13 <beerman> not one of my use-cases

22:25 <beerman> jaeger: https://github.com/moby/moby/pull/44707/files applying this patch on the moby source dir fixes the build for me with current btrfs-progs

22:42 <jaeger> I'll give it a look, thanks

22:43 <beerman> sure

22:48 <jaeger> playing with a "nounpack" array currently

22:49 <beerman> where is that?

22:49 <beerman> python?

22:49 <jaeger> pkgmk/Pkgfile

22:51 <jaeger> Ironically I did add a single subroutine for this to check if a value exists in an array, but it could be a one-liner instead of its own function if that really annoys people

22:59 <jaeger> I love the little quality of life things like being able to add ".patch" to a github commit URL, for example https://github.com/moby/moby/commit/ffbbe3d103b045c3f8ec5f74aa71b7a314fd57fe.patch

23:03 <beerman> true 🙂 but it failed once for a day, might make you wonder when elon aquires github and takes that particular server down that does it, or whatever else might happen 😄

23:04 <jaeger> I only use it to get patches, not in Pkgfiles

23:09 <beerman> you don't use it to rename distfile names?

23:10 <jaeger> Not the .patch functionality, which is what I assumed you were talking about since your comment came right after that

23:34 <beerman> ah, well, patches i'd download and proably rename too

23:40 <ivandi> beerman: weechat build fails with ruby-3.2. sed -i 's/ruby-3.1/ruby-3.2 ruby-3.1/' $name-$version/cmake/FindRuby.cmake fixes it.

23:40 <beerman> thanks, will look into it tomorrow, probably

23:41 <ivandi> np

23:50 <jaeger> yeah, that's what I'm doing with a couple of patches now... one for kodi and one for docker