15:06 <pitillo> hey jue, isn't cleaner to add "--without-iconv" to libarchive configure indtead of "seding" the pc file?

15:16 <jue> pitillo: indeed, thanks for the hint ;)

15:17 <pitillo> yw :)

15:48 <beerman> lmao..

15:51 <beerman> ¯\_(ツ)_/¯ why do i even care

16:11 <jue> what's your problem?

16:20 <beerman> No organisation, no team talk, ignoring Steffen are probably my biggest points

16:21 <jue> well, he had a point with libarchive ...

16:21 <beerman> A point i had fixed after looking at it for 20 minutes yesterday for the first time

16:22 <beerman> But he basically calls us assholes, we ignore it and then he gets his way for something pkgmk doesn't even support as a feature? lol

16:22 <beerman> Whatever, Jürgen

16:27 <jue> indeed

19:01 <stenur> jue can actually export TAR_WRITER_OPTIONS="xz:threads=${JOBS}" in /etc/pkgmk.conf as i do, but note libarchive/bsdtar has a bug so you better only set options for the format you are really about to use

19:02 <stenur> ..i thought i was suggesting this as a commented out line in /etc/pkgmk.conf in the past? good thing!

19:20 <jue> stenur: we decided to ban you from here, the really bad comment in your libarchive report was too much, we will no longer accept your infamies

20:59 <beerman> well, home now. and i can't stop thinking about it so i checked it up again and here we go

20:59 <beerman> first off, i got that working with the cmake build:

21:00 <beerman> the magic ingredient is the CFLAG line passed to cmake: http://dpaste.com/5BYT7QLNM

21:01 <beerman> to follow up: this seems to be the merge which made libarchive understand multithreading -> https://github.com/libarchive/libarchive/commit/41c4da484d3a21ea5be6dbf10d3bf5786caed9dc

21:02 <beerman> https://github.com/libarchive/libarchive/blob/master/CMakeLists.txt#L1475 and this seems to fail the check for it

21:02 <beerman> in anyway, building it with the CFLAG makes it perfectly possible to compress a package multithreaded if using xz

21:04 <beerman> this concludes me to wanting to revert the merge, to not deal with the iconv problem (https://github.com/libarchive/libarchive/pull/1817) and have less la files flying around

21:04 <farkuhar> nice work, beerman! Just to be clear, the CFLAG line was enough, and you don't need to edit the bsdtar command in pkgmk?

21:04 <beerman> also cmake and ninja is both great

21:05 <beerman> oh you still need to edit pkgmk do make use of that, or you can set that option via env flags

21:05 <beerman> it doesn't do that by default if i got that right, it will use one thread. you can set it to 0 for all threads, or define a random number to your likeing I guess

21:07 <farkuhar> export TAR_WRITER_OPTIONS="xz:threads=${JOBS}" in /etc/pkgmk.conf would be preferable to editing /usr/bin/pkgmk, imho

21:10 <beerman> true, like i said, its not like we ever promoted that as a feature or anything 😉

21:14 <farkuhar> anyway, over in #crux Markus is reporting a different soversion when libarchive is built using autotools, so quite a few dependent ports are now needing a rebuild. Reverting back to cmake (with your CFLAG line) would save Markus (and others) from all that recompiling.

21:15 <jaeger> weird that libarchive would behave differently with regards to sonames

21:15 <jaeger> I wonder if other things do that, too

21:15 <jaeger> argh, AFK for more meetings

21:22 <beerman> well, there, and i made a mistake lol

21:25 <beerman> jaeger: indeed weird, it would cause all sorts of problems i can imagine, but anyway, no harm intended and no harm done i guess. multithreading works just fine, anyway, so we could also include it in the default config to make people aware, or write some wiki article or handbook line

21:27 <beerman> farkuhar: maybe you will want to add a line about it in the handbook, i dunno

21:43 <farkuhar> beerman: as you said, it's not like we ever promoted multithreaded compression as a pkgmk feature. If we start advertising it as prominently as the envvars JOBS and MAKEFLAGS="-j $((JOBS-1))", then folks might grow accustomed to that level of control, only to be disappointed when the shiny new tooling comes out and arrogantly ignores such envvars (as meson/ninja are known to do with JOBS).

21:47 <beerman> you know what I say, that's life. we are downstream, drinking whatever gets poured in upstream. and things just change, period. technology moves on, if you want to move or not doesn't matter

22:02 <beerman> jaeger: anyway, i made a few changes in kodi-wayland that i still want to test more, if you still have an interest in it: http://sprunge.us/8Wod2m

22:03 <beerman> fwiw, it's still "just working" on amdgpu, i have to test it on the notebook with i915

22:31 <jaeger> I'll give it a try when I can... got a laptop with i915 and desktop with amdgpu both with wayland stuff installed

22:50 <beerman> works for me again, it seems

23:11 <jaeger> going to fix the pkgutils source and upload a new tarball

23:13 <jaeger> Since there's no functional change I don't think a patch version bump is warranted

23:18 <beerman> i would still vote for the ignore new files options by default, it makes sense

23:18 <beerman> but if not, no problem

23:21 <jaeger> I prefer to let the user decide on that

23:23 <beerman> they probably have a premade decision with ports that force that behaviour, but sure

23:24 <jaeger> Definitely subjective. I personally don't use it

23:24 <beerman> gtk4: builds a "generic printer plugin" so file, but doesn't if it has cups around, then it builds another printer plugin

23:24 <jaeger> I want to see if the footprint diverges, otherwise what's the point of the feature?

23:25 <beerman> yeah, its not ideal in any way, imo

23:25 <jaeger> alternatively, I'm still considering with my pkgutils rewrite stuff to do away with footprints entirely. I'd still keep track of what changed and report it to the user but not stop on it

23:25 <jaeger> Whether new or missing

23:27 <beerman> yep

23:27 <jaeger> pkgutils is bumped... minor inconvenience is that the upstream tarball name doesn't change

23:27 <jaeger> already removed it from my distfiles mirror

23:28 <beerman> i am not sufficently skilled to work on C/C++ stuff, not on that scale anyhow.

23:29 <beerman> maybe we should just patch the core pkg until the next release bump

23:35 <jaeger> I already pushed the update... but if everyone hates it I can revert

23:46 <beerman> it's fine by me

23:47 <jaeger> ok, kodi-wayland did not work for me on the amdgpu system, I get "amdgpu: amdgpu_cs_ctx_create2 failed. (-13)"

23:48 <beerman> mh, both systems worked on my test, no idea what else is missing 😕 my last state before that was that the notebook with i915 didn't work..

23:49 <beerman> i will proably push the changes in the next few days (also to use the mirrored ffmpeg as the upstream repo got deleted)

23:49 <jaeger> It does start... but I get a mostly black window

23:49 <beerman> thats the behaviour i had on the notebook as well, iirc

23:50 <jaeger> I haven't finished building on the laptop here, that was the fast desktop with amdgpu

23:50 <beerman> maybe mesa is at fault? right now, the newest mesa release doesn't work with kodi-gbm over here

23:50 <jaeger> :/

23:50 <beerman> not sure what to make of it, maybe you could try mesa built without lto and see if that makes a difference

23:51 <beerman> maybe that makes it flakey, i can try kodi-gbm with non lto mesa tomorrow

23:52 <jaeger> Is that as simple as passing --disable-lto or something similar?

23:53 <jaeger> or -Dlto=false/disabled?

23:54 <beerman> lto=false should do it

23:55 <beerman> wait, we don't do lto in there anymore anyway, dunno when that went out

23:59 <jaeger> yeah, didn't see it