12:49 <jue> FYI, upcoming shadow 4.14 depends on libbsd currently, I've created a ticket -> https://github.com/shadow-maint/shadow/issues/779

12:54 <jue> beerman: your diff for prtsweep is more or less unreadable cause it mostly changes whitespaces

13:16 <beerman> i have raised the question in the past if we want to include libbsd in core as nearly everything loves to link to it already if its available

13:16 <beerman> i'll just re-raise that question now..

13:17 <beerman> jue true, but its also true that all past authors ignored to submit to one style and so there have been multiple different indention styles

13:17 <beerman> sorry, but you'll need to apply it to see the changes I guess

13:29 <farkuhar> beerman: I added support for md5sums in my Perl implementation of prtsweep, for repos that don't have signatures. Thanks for the suggestion.

13:33 <farkuhar> Re: libbsd, the eager linking phenomenon can also be observed with libmd. After having libmd installed for a few months, I tried to uninstall it but then discovered that it had been linked into libarchive (and some other core ports).

13:34 <jue> farkuhar: if your Perl version supersedes prtsweep and prtwash I'd happy to use that instead in our prt-utils?

13:47 <farkuhar> jue: feel free to make the switch. As I said yesterday, I stopped caring about the bash implementations of these utils. In the present form they're too ambitious, violating the CRUX mantra with their lack of scriptability.

13:52 <jue> ok, fine. Please add author informations to the scripts and take a look at the man-pages. Anything to add/change there?

14:06 <beerman> Eager linking, or as somebody told me on GitHub: everybody agrees these functions are just better than what glibc offers. But it's true that glibc includes some of that in the new release, as also noted on GitHub

14:06 <beerman> In the ticket jue linked to

14:11 <beerman> farkuhar: a no signature AND no md5sum option is what I'd want

14:23 <farkuhar> beerman: that option is provided by prtwash. Parsing the Pkgfile is not a reliable operation in native Perl (see Fun's comments in FS#1851), so it requires spawning a bash shell. I preferred to put the expensive operation in only one of the two Perl scripts, leaving the other one relatively clean.

14:24 <beerman> Mh, OK. No idea if perl is such a great fit in that case?

14:41 <farkuhar> jue: scripts have been updated with author information. I also reviewed the man-pages one more time; they look ready for release.

14:46 <farkuhar> beerman: the penalty for spawning an external bash shell is barely noticeable on modern hardware. But it seemed superfluous to duplicate that code across both prtwash and prtsweep. I opted to preserve two distinct solutions to the task, for the sake of diversity.

14:47 <beerman> Okay, fine with me

14:53 <jaeger> I opted to spawn bash to parse Pkgfiles for the repology dump creator, too... doing it in python was buggy and inconsistent :/

14:54 <farkuhar> now I've got to work on debugging a firefox build failure. The targets x11-only and wayland-only were fine, but the x11+wayland target is failing at the custom build command for libdbus-sys. Might need a patch for the custom build command.

15:13 <beerman> jaeger I guess it's a "you have to die one way or the other" type situation

15:13 <beerman> the bash script worked fine for me, but farkuhar perl version looks a lot neater

15:58 <jaeger> I have no objection to replacing it if farkuhar's version is better

16:05 <beerman> any thoughts about pep-0668? https://peps.python.org/pep-0668/

17:01 <jaeger> It seems like a reasonable idea... I wonder how much trouble it might cause while people figure out how to use it/transition smoothly

17:03 <beerman> the message can include all clues for people to figure out what to do. I see two ways which would be fine from a systems perspective: 1) create a port 2) use virtuel environments for python (contrib/python3-virtualenv)

17:27 <beerman> you can easily test what it looks like on a system with pip installed. place a text file in /usr/lib/python3.10/EXTERNALLY-MANAGED and write some lorem ipsum in there, then try install anything with pip.

17:27 <beerman> it returns your lorem ipsum text prefaced by an "× This environment is externally managed" and following with this note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.

17:35 <beerman> ports invoking pip directly (e.g. python3-clikit) seem to keep working fine with that change

17:44 <beerman> https://dpaste.com/EV9N6AC4A i imagine something like this..?

17:45 <beerman> https://dpaste.com/HYXD7YBUG how it looks

17:48 <beerman> jaeger --break-system-packages is almost as good as --my-next-gpu-wont-be-nvidia or whatever it was for sway :P

17:49 <beerman> bet that linus from tech tips will still manage to break it, but oh well

18:05 <jaeger> I try to avoid using pip at all outside of virtualenvs

18:12 <jaeger> So presumably there's some better way to do this after PEP-0668? PIP_CONFIG_FILE=/dev/null /usr/bin/pip3 install --isolated --root=$PKG --ignore-installed --no-deps dist/*.whl

18:12 <beerman> that should keep working fine like that

18:13 <beerman> i only use pip check