09:39 <beerman> jaeger does virt-manager really need vtk3? It builds fine without it

09:43 <beerman> sorry, vte3 :D

12:35 <beerman> --enable-slirp in opt/qemu fails for me when git is not installed

15:48 <jaeger> It would build fine without but it was needed for serial consoles

15:49 <jaeger> If you don't use that functionality you could build without, certainly

15:56 <beerman> i see :)

16:05 <jue> beerman: thx for the report, will fix

16:05 <beerman> cheers :)

16:43 <beerman> neat, openjdk20 fixes some really weird font bug on wayland for me, finally

16:54 <beerman> farkuhar i was looking into slimsizing gstreamer ports even further, it looks like gst-plugins-base could look like this https://dpaste.com/FK32S36JP have you looked in that direction by any chance already?

16:55 <beerman> this trickles down to a lot of ports, e.g. qt5 https://dpaste.com/ELMGJKFFD

16:56 <beerman> consequently, other gst-plugins port may change: https://dpaste.com/6E4MWPTVB

17:50 <farkuhar> beerman: I haven't looked into gstreamer so deeply, but like r0ni I trust you'll do a good job on slimsizing those ports.

17:51 <farkuhar> right now I'm focusing more on the outstanding Flyspray reports. ukky and I came up with something for FS#380, and now I'm investigating FS#1074.

17:52 <beerman> I've seen your comment on that issue today. would be great to have a few of these old standing tickets solved

17:56 <farkuhar> Fun's patch for FS#1074 mentions the drawback that pkgrm will "leak" files into the filesystem (when a new version removes files from paths excepted from upgrades). But you can avoid this side-effect by changing the function signature of db_rm_pkg and customizing its behaviour depending on whether an upgrade is happening.

18:06 <beerman> if you are asking me then my answer has always been I don't want it to be "just my decision" :) i'd like votes from other core members as well to make the best choice here

18:12 <farkuhar> beerman: I'm simply offering one possible approach to the problem, not asking you to cast an up/down vote right now. There's not yet any working code to test, anyway.

18:19 <beerman> i am not casting anything, I trust you to do the right things at the right time like you do with me for slimsizing ports

18:22 <farkuhar> But to flesh out my idea: the current two-argument db_rm_pkg respects the keep list in the obvious way, by keeping the files in place. But what if we told a three-argument db_rm_pkg to stash those "keep list" files under /var/lib/pkg/rejected when a package is about to be upgraded? After the upgrade, a user can run rejmerge and decide whether the outdated configs (FS#1074 example) are worth

18:22 <farkuhar> preserving.

18:25 <farkuhar> The downside of this solution is that it reverses the usual roles of the sysroot and /var/lib/pkg/rejected. Probably too likely to confuse the typical rejmerge user.

18:31 <beerman> which could be mitigated if the tool was redesigned to make it clear or the average user reads the manual (what i typically would expect from somebody running CRUX)

20:39 <farkuhar> ukky's proposal for FS#1074 is more versatile. A third type of pkgadd.conf rule would allow preservation of modified config files even when doing a simple pkgrm, not only when doing pkgadd -u.

20:45 <farkuhar> rejmerge in its present form simply deletes any file in the reject dir that has no corresponding file on sysroot. If we implemented my first idea (three-argument db_rm_pkg) then rejmerge could be tasked with doing something more useful in this situation.

20:47 <farkuhar> s/useful/interactive/

23:54 <farkuhar> rough draft for a fix of FS#1074 by changing the function signature of db_rm_pkg: https://dpaste.com/FUDY2YLCA . Still needs to be tested, but the basic idea is there.