07:02 <samsepi0l> farkuhar: I just see your message right now, yeah, the idea of use a hard-coded int as an fd was risky, it was more a quick-n-dirt implementation example rather than a full solution :-) The idea of a example in prt-get man page seems good to me too.

07:13 <farkuhar> samsepi0l: I think I found a way to accomplish what you want. Here's a quick-n-dirt sketch of my first attempt http://ix.io/4Ffr (git diff on my forked repo, not the official prt-get source). It compiles, but I haven't tested it yet.

07:22 <farkuhar> unlink(rm_logFile.c_str()) should probably be guarded behind a test for the file's existence. Easy enough to add.

07:22 <samsepi0l> farkuhar: looks great, I will try to test it too by myself later on a CRUX VM

08:49 <cruxbot> [core.git/3.7]: pkgconf: update to 2.0.3

08:57 <cruxbot> [opt.git/3.7]: mupdf: update to 1.23.2

08:57 <cruxbot> [opt.git/3.7]: libunbound: update to 1.18.0

08:57 <cruxbot> [opt.git/3.7]: libsdl2: update to 2.28.3

08:57 <cruxbot> [opt.git/3.7]: libgphoto2: update to 2.5.31

08:57 <cruxbot> [opt.git/3.7]: firefox-bin: update to 117.0

08:57 <cruxbot> [opt.git/3.7]: at-spi2-core: update to 2.48.4

09:00 <cruxbot> [opt.git/3.7]: php: update to 8.2.10

11:35 <r0ni> libgphoto2 i have a discrepancy w/ the footprint 'usr/lib/libgphoto2/2.5.31/docupen.so" was the same with the last release as well... can anyone verify this file exists on x86?

11:55 <farkuhar> r0ni: no footprint mismatch when I built libgphoto2 on x86.

11:56 <r0ni> hrm ok now i must figure out if it's arch specific or a un-specified dep... thx

11:58 <r0ni> "docupen" appears to be a scanner device

12:02 <r0ni> oh well i'll have to rtfm later, its naptime

12:56 <farkuhar> samsep10l: further testing reveals that the PrtGet::remove() function needs to have initRepo() inserted near the beginning, in order to perform the string replacement for "%p". A better option is to not support the %p placeholder in the logFile template, because not all of the installed packages are guaranteed to have a corresponding port in the active repositories.

13:00 <samsep10l> farkuhar: that allows prt-get to remove de logfile even if there is no repository associated with the port?

13:00 <cruxbot> [contrib.git/3.7]: gmime3: 3.2.13 -> 3.2.14

13:00 <cruxbot> [contrib.git/3.7]: python3-dulwich: 0.21.5 -> 0.21.6

13:00 <cruxbot> [contrib.git/3.7]: python3-gevent: 23.9.0 -> 23.9.0.post1

13:05 <farkuhar> samsep10l: yes, because someone might have used prt-get to build and install the package, then commented out the prtdir line for that repo while leaving the package installed. The call to m_repo->getPackage( *it ) will fail in that case, even with initRepo() inserted at the beginning of the function.

13:07 <farkuhar> You could retain support for expanding the "%p" placeholder, but you'd have to insert more safeguards to accommodate the case outlined above.

13:09 <samsep10l> farkuhar: the "%p" placeholder is related to prt-get.conf only or this affect to the placeholder used in other functions, like prt-get printf?

13:12 <farkuhar> The costly routine initRepo() is called when needed, and prt-get printf is one of those situations. It wasn't envisioned that prt-get remove would need access to the repo methods, so initRepo() did not appear at the beginning of PrtGet::remove(). We'd have to add it ourselves, in order to support string replacements for "%p".

13:12 <samsep10l> farkuhar: my bad, I forgot that prt-get.conf has man page too, and the "%p" is related to the package path for the logfile variable.

13:15 <farkuhar> I'm inclined not to support expanding "%p" in the logFile template, for the sake of simplicity. I can't imagine there are too many users who organize build logs under such deep nesting as /var/log/pkgmk/usr/ports/{core,opt,xorg}

13:17 <samsep10l> farkuhar: yeah, I am with you in this. btw, the path is /var/log/pkgmk or /var/log/pkgbuild? right now, is /var/log/pkgbuild or this is only for your custom prt-get?

13:19 <farkuhar> The directory /var/log/pkgbuild is what you find in the prt-get.conf distributed with our core port, overriding the older file that appears in the source tree.

13:21 <farkuhar> Maybe you can find a shallower nesting /usr/ports/{core,opt,xorg}/.buildlogs on some CRUX installations, and those users would feel left out if we stopped supporting "%p" for your new feature. I don't know how common that logFile template is, though.

13:23 <samsep10l> farkuhar: yeah, if some user has a log configuration like that, it will be bad if they lose it.

13:24 <farkuhar> Granted, it's not a logFile template whose logs would survive a sync with the git driver (FS#1313), but even a longtime user like SiFuh was still using rsync until a day ago, so I don't think it would have caused any problems.

13:28 <samsep10l> farkuhar: maybe adding a warning note in prt-get/prt-get.conf man pages (or even in prt-get.conf) can be useful to warn the users? also, the option it will be left commented by default in prt-get.conf, I assume, like the rest of the log options in a default installation, right?

13:28 <farkuhar> The speed of modern hard drives makes it almost trivial to call initRepo() even in functions that might never use it, so for the handful of users who might store build logs according to a template with "%p", there might be no real harm in adding initRepo(). But we could protect it behind a test of the boolean m_config->removeLogOnUninst(), so that it doesn't get called unless someone is using your new feature.

13:33 <farkuhar> samsep10l: the note I want to add in the prt-get man-page is related to a possible discrepancy between the string replacements for "%v-%r" (from m_pkgDB), and the actual filenames of the logs on disk. If someone bypasses prt-get and manually updates a package with pkgmk/pkgadd, then the old logfile (created by prt-get) might not match a template that uses "%v" or "%r".

13:33 <samsep10l> farkuhar: yes, I like the idea of protect the function call.

13:36 <farkuhar> samsep10l: okay, I think I have a roadmap for implementing your new feature. Give me an hour or so, and I'll share a new patch.

13:36 <samsep10l> farkuhar: thanks you very much! :-)

14:10 <ukky> How to properly resolve 'python-libxml2' vs 'libxml2' when updrading from 3.7 ISO to current versions?

14:12 <ukky> 'libxml2' from 3.7 ISO does not have 'usr/lib/python3.10/site-packages/libxml2.py', it is part of 'python-libxml2'

14:13 <ukky> Latest 'libxml2' has 'usr/lib/python3.10/site-packages/libxml2.py' included.

14:16 <farkuhar> samsep10l: here's the latest draft http://ix.io/4Fhg Once again the git references are specific to my forked repo, but merging the new code by hand shouldn't be too difficult if you want to test it.

14:19 <samsep10l> farkuhar: thanks you! I will test it as soon as I can and tell you about the results :-)

15:30 <cruxbot> [contrib.git/3.7]: rhit: 2.0.0 -> 2.0.1

15:35 <cruxbot> [compat-32.git/3.7]: at-spi2-core-32: 2.48.3 -> 2.48.4

15:35 <cruxbot> [compat-32.git/3.7]: libsdl2-32: 2.28.2 -> 2.28.3

15:36 <cruxbot> [contrib.git/3.7]: i3status-rust: 0.32.0 -> 0.32.1

15:49 <cruxbot> [contrib.git/3.7]: libadwaita: 1.3.4 -> 1.3.5

15:57 <cruxbot> [opt.git/3.7]: libxslt: updated .footprint

17:20 <farkuhar> samsep10l: there's an annoying asymmetry in the string replacements for logFilePattern. When prt-get installs a package P, obviously P must appear somewhere among the active repos, and so m_repo->getPackage(P) will succeed. But removing a package that has been dropped from the repos (the eventual fate of most items on https://crux.nu/Main/OrphanedPorts) is a common scenario, and then we won't know what to substitute for "%p" appearing in logFilePattern.

17:25 <farkuhar> as Guest_Trulala so elegantly summarized, the best guess for "%p" in the case of a dropped port is the path to the contrib repo, but automagic guessing is not something we should be hard-coding in prt-get. Better to make it a no-op in that case, and in the man-page deprecate even more emphatically the use of "%p" in the logfile pattern.

17:29 <cruxbot> [contrib.git/3.7]: gitui: 0.24.1 -> 0.24.2

17:29 <cruxbot> [contrib.git/3.7]: python3-mutagen: 1.46.0 -> 1.47.0

18:20 <farkuhar> samsep10l: See http://ix.io/4FiF for my latest attempt to address the possible failure modes of your requested feature.

18:22 <SiFuh> Hah, just like a re-write of the Mahabharata

21:59 <r0ni> open-vm-tools has dep "libdnet" - not found in ports tree

22:00 <r0ni> last i recall that dep isn't needed anyway, but ya

22:01 <r0ni> bonus tho, build completes on arm, so yay

23:21 <farkuhar> SiFuh: nah, I prefer to think of it as Midrash.

23:26 <farkuhar> SiFuh wrote a cronjob to send himself weekly reminder emails about making backups. If I'm ever again tempted to append -Werror to $CXXFLAGS in my pkgmk.conf, I should schedule a reminder to revert that change.