jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
beerman has quit [Remote host closed the connection]
beerman has joined #crux-devel
<beerman> jaeger can you adopt gtk-engine-murrine? only arc-theme depends on it, otherwise I would've marked it unmaintained for now
<beerman> farkuhar only taker for glfw3 is libplacebo
<farkuhar> beerman: I'm planning to adopt today glfw3, cgit, asciidoc, enchant.
<beerman> sounds great
<farkuhar> speaking of asciidoc, it might not need to be a hard dependency of qutebrowser any more. See the latest changelog.
<beerman> did i miss that?
<beerman> 8-)
<farkuhar> under the Fixed section it says "The asciidoc2html.py script now correctly uses the virtualenv-installed asciidoc rather than requiring a system-wide installation." I haven't tested this claim myself, though.
<beerman> I'll give that a test in a bit
<beerman> thanks for noticing
<beerman> while adopting and making changes to contrib/distcc I found an error stating libiberty was not found, which was weirdly fixed after rebuilding binutils
<beerman> while looking further into this i found this neat script from some gentoo repository: https://github.com/InBetweenNames/gentooLTO/blob/master/app-portage/lto-rebuild/files/lto-rebuild
<beerman> its easily adopted for CRUX/prt-get+
<beerman> pkinfo and it spat out a bunch of other packages
<beerman> https://dpaste.com/6N9Z7CP56 if anybody is interested
<beerman> there sure are ways to improve that further, might make sense to include it with prt-utils even
<farkuhar> `readelf -p .comment /usr/lib/libiberty.a` does indeed reveal it was built using the older gcc. Nice find, beerman!
<beerman> i didn't know that, and it's certainly helpful
<beerman> alright, done with marking romsters ports unmaintained in contrib then
<farkuhar> cleanup is good. What timeline do you have in mind for actually dropping the ports marked unmaintained?
<beerman> i dunno, from my point of view they have been rather unmaintained for a long time, wherever i could i included fixes but i doubt anybody picking them up
<beerman> a month should suffice twice imo
<farkuhar> a month should give any downstream users the chance to copy the ports into their personal overlays, if they haven't already. Sounds good.
<jaeger> beerman: sure
<beerman> jaeger cheers
<beerman> farkuhar building qutebrowser without asciidoc still fails for, probably because its hardcoded in the Makefile https://github.com/qutebrowser/qutebrowser/blob/main/misc/Makefile#L7
<beerman> jaeger: does docker-compose fails to build for you to with go 1.21? contrib/go misses "install -Dm644 go.env $PKG/usr/lib/go/go.env" for me
<farkuhar> beerman: thanks for checking. I think this issue might be related. https://github.com/qutebrowser/qutebrowser/issues/7835
<jaeger> I'll take a look this evening
<farkuhar> although issue 7835 is only loosely related to the need for a systemwide a2x, in that both are instances of the qutebrowser changelog promising more than what actually got shipped.
<beerman> i guess its something look out for in the next point release or if its a single commit, maybe that
<beerman> so long its fine to finally switch this over to qt6-webengine
<jaeger> farkuhar: hrmm, no issue with docker-compose here, works both in a container and on the host
<farkuhar> beerman: i haven't tried docker-compose yet, but if you were missing $PKG/usr/lib/go/go.env when building go 1.21, why didn't it trigger a footprint mismatch?