01:06:42 I am running a camcontrol sanitize -a overwrite command on a disk. The manpage states that by default if -w is not given, that I am in immediate mode and I should have control of my shell. That’s not what I see though, Instead I see Sanitizing Progress.. Can I exit out of here and let the sanitize keep going? 06:42:16 Poetic: `$ less entropy / entropy: Permission denied` 14:16:49 kenrap: fluffy has a fix for the xorg-server build failure 14:19:04 noice! 14:22:41 ivy: may I have you give me a link to that fix? 14:23:49 kenrap: tl;dr is add -Dsecure-rpc=false to MESON_ARGS https://lists.freebsd.org/archives/dev-commits-src-main/2025-August/034688.html 14:23:59 Thank you! 14:24:10 apparently this was fixed upstream over a year ago but i guess it takes a while to make it into the various server releases 14:24:27 👍 14:27:42 happiness, [00:01:58] [02] [00:00:40] Finished x11-servers/xorg-server@xorg | xorg-server-21.1.18,1: Success 14:27:52 ivy: thanks again! 14:28:06 don't thank me too much, it was me what broke it :-) 14:36:00 ivy: I understand every change in the src tree is done with good intention in some way. It's -CURRENT, even though sometimes it can make me go "Gaaaaaaaahh!" That's what I have to accept for being on the bleeding edge :) 14:42:47 It feels good to get my pkg cache rebuilding again 14:49:37 it's definitely been a fun week for 15.0, with this and the gssapi problems and the pkgbase upgrade issue 14:58:17 Yeah, curl was failing to build with gssapi problems. SponiX was also telling me how he was dealing with pkgbase problems too. 15:12:48 this is the least fun review i've ever prepared: https://reviews.freebsd.org/D51874 15:13:03 i can't wait until we can just require pkgbase and get rid of OLD_FILES :-) 15:19:47 ivy: that must've been a painful cleanup... 15:19:52 ivy: thanks for the help yesterday.. all's good now 15:20:07 3500 lines of diff... fun 15:21:06 scoobybejesus_tl: not the worst/biggest I've ever seen 15:22:07 Had one to do MNLS support back in the 90's that was massive for Java and Corba code 15:22:08 So pkgbase will get rid of that form of maintenance, huh? 15:22:28 (In a product I worked on) 15:22:51 kenrap: in theory, but not for a long time as we can't just remove make installworld even when pkgbase becomes the default 15:31:38 ivy: oh, interesting. So when I build the base from scratch, I'll be able to pkgbase it? 15:32:35 kenrap: yes, just run 'make buildworld buildkernel update-packages' and you'll get a pkg repository for the base system 15:33:39 Interesting 15:34:19 i vaguely want to remove a lot of WITHOUT_FOO knobs and instead use the pkgbase metadata to handle that even for non-pkgbase users 15:34:44 i'm not sure how that would work, but i guess you'd say make WITHOUT_GSSD=yes and it would just not build things that are in the gss package 15:36:51 Would it make sense to have one "WITHOUT" knob and be able to pass in values like "gssd" to simplify things? 15:37:09 maybe 15:37:39 also we can't do everything this way, like lib32 15:37:52 Gotcha 16:00:41 (the gatekeepers at the forums are going to be foaming at the mouths when they learn about the make installworld to pkgbase transition...) 16:01:59 Oh, they're already have. Good. :) 20:34:27 env shebangs ('#!/usr/bin/env python3' for example) don't seem to work properly from rc scripts. i assume PATH doesn't contain the stuff from /usr/local/ – how do i best work around this? 20:54:45 back in the old days before people used /usr/bin/env, they would just specify the full path to the language binary, like /usr/local/bin/python3 20:56:50 or source the system/user profile inside the script 20:57:15 Then call python 20:58:18 mhh, i have that part working now, but it's ugly… I just overwrote PATH in the rc script… does that propagate to outside the rc script? 21:24:54 phryk: $PATH should be inherited by anything that the script setting the path is running. 21:25:07 ... if that makes sense? Maybe could have worded that better. 21:25:34 ek: yeah, but that's not my question. my question is whether this might bubble out into the state of other rc scripts for example. 21:26:26 phryk: You're just setting a PATH= in a ${LOCALBASE}/etc/rc.d script? 21:26:38 aye. 21:27:17 So, only that rc script (and children it runs) with inherit the PATH change(s). Other rc scripts should be fine. 21:27:32 great, thanks. :) 21:28:03 Unless, of course, this particular rc script is run in order to execute other rc scripts? That would be... interesting. 21:28:29 no, i'm just running a python executable. it's multiprocessed, tho. :P 21:28:43 That'll be fine. 21:28:54 now i only have to find out why status is lying… 21:30:40 forums say "something something command_interpreter", but the docs in man 8 rc.subr on that option is sparse and only leaves me with more question… pidfile is created fine and contains the correct pid… status claims service isn't running when it actually is… 21:33:22 if i set it to /usr/local/bin/python3 it complains that it's not just "python3" as in the env shebang of the executable. if i set it to just python3 it doesn't report any problems, but in both cases 'onestatus' falsely claims the service ain't running. 21:33:52 the rc script i'm currently working on is essentially identical to this: https://rnd.phryk.net/phryk/prometheus_poudriere_port/src/branch/main/files/prometheus_poudriere.in 21:41:30 phryk: Just out of curiosity, why aren't you using #!/bin/sh for the rc script? 21:42:04 but i am? 21:42:30 look at the link, literally the first line is #!/bin/sh 21:47:05 Ah. You said it was essentially identical to that. I didn't know it *WAS* that. I guess I misunderstood from the beginning. I thought you were creating a python rc script. 21:48:30 ah, no. that sounds painful.^^ 21:49:04 Hence the reason I had a raised eyebrow for a bit there. :) 22:14:18 Anyone seen this one? specificly trying to build OpenJDK... 22:14:55 er rather.. running it 22:14:57 Tenkawa: Which one? 22:14:57 Error occurred during initialization of VM 22:14:57 Could not allocate compressed class space: 1073741824 bytes 22:15:21 Tenkawa: I have not. 22:15:22 anything newer than 8 on arm64 here 22:15:37 This is within a VM? 22:15:42 Both 22:15:57 vm and 12 core ARMv9 22:16:21 bhyve? 22:16:33 no 22:16:38 Oh, wait. Doesn't matter. 22:16:38 Vmware host 22:16:47 You're saying in VM and also on non-VM. 22:16:55 Does the same thing happen on non-ARM? 22:17:13 I don't use JDK, so I have no way to test. 22:17:23 Don't have a non-arm machine setup atm.. 22:17:38 90% of what I do is either arm or risc-v 22:17:50 What exactly are you running? I can spin up a jail or VM in i386 and/or amd64 real quick. 22:18:18 This is 15-current.. (needs to be for the ARMV9 server) 22:18:42 I can do CURRENT. I just want to see if this is ARM-specific? 22:18:54 Let me check my x86 22:19:07 see if any of my offline vms are fbsd 22:20:01 I don't use them much anymore since I got 2 of these 12 core units and my M1 22:20:31 I suppose I can also test on my silicon Mac. 22:20:37 No.. appears all I have is netbsd on mine 22:20:49 Natively? 22:20:50 Just takes longer. My bhyve hypervisor makes things quick. 22:21:13 Naw. It'd be a FBSD VM on my Mac. 22:21:27 ok..thats close to my Mac M1 VMware VM 22:21:41 Okay. I have a 15-CURRENT VM ready to go right now. What are you running to see this error? 22:22:18 both from ports 22:22:21 oops 22:22:25 darn / 22:22:31 /usr/local/bootstrap-openjdk8/bin/java works... /usr/local/bootstrap-openjdk17/bin/java fails 22:23:14 Okay. Gimme a sec to install some of the ojdk's and bootstrap. 22:23:16 16gb ram allocated to the vm so I know its got plenty of ram to work with.... 22:23:18 sure 22:23:25 thanks for checking 22:26:02 So, I don't get a bootstrap-* in /usr/local with ojdk8 from the package. 22:26:09 But, /usr/local/bin/java works just fine. 22:26:33 just a sec.. they are in a specific pkg 22:26:35 let me find it 22:27:20 and unfortunately dependencies of maven 22:27:37 (and others) 22:30:13 Hrm. I've got ojdk 8, 17, and 24 installed. All java(vm) executables seem to be fine on amd64. 22:30:33 This is on 15-C (just updated via pkgbase) 22:30:59 just a sec 22:31:06 searching the db 22:32:16 you need bootstrap-openjdk8-r453316_2 also 22:32:37 and bootstrap-openjdk17-17.0.1.12.1 22:33:26 so bootstrap-openjdk17 and bootstrap-openjdk8 22:34:00 Got 'em. 22:34:27 pkg provides is a great thing :) 22:34:36 Same deal. Both run fine. 22:35:14 Which bins? I want to run the same ones 22:35:37 I just ran: 22:35:40 Want to backtrace to see if something goofy is going on with this thing 22:36:05 /usr/local/bootstrap-openjdk8/bin/java and /usr/local/bootstrap-openjdk17/bin/java 22:36:24 Obviously, it does nothing but provide help. But, there were no errors. 22:36:35 Are you passing additional args that may be the problem? 22:36:39 yeah... one works one breaks here ... really odd 22:37:30 nope.. well this is even "more" odd 22:37:40 if I run them like this: 22:37:51 /usr/local/bootstrap-openjdk8/bin/java ; /usr/local/bootstrap-openjdk17/bin/java 22:37:57 they both dump 22:38:01 I'll pastebin 22:39:42 ah, found the root of my problem: $_procname in rc.subr's _find_processes() containts the process *title* if one is set instead of the process *name*. 22:41:39 worked around it by further abusing that i've already overriden PATH – now my procname is just the executable name and status actually matches it because the process title begins with the executable name and the match is non-greedy. hella ugly, but it works.^^ 22:42:13 https://gist.github.com/arakeen/29436106c46c480163dddd3a838ba9ab 22:42:31 even more odd 22:44:19 phryk: Is this something you plan on submitting as a port in the future? 22:44:45 ek: not sure yet, but possibly. it's a work project, but i already got the okay to FOSS it from my boss. 22:45:05 Tenkawa: I'm seeing stuff like this in the PR's, but with no noticeable resolution (yet): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265284 22:45:24 it's another prometheus exporter, but i was already too lazy to officially submit the previous one (prometheus_poudriere) because i didn't have the energy to figure out how to test for all supported python versions… 22:46:10 phryk: Very cool! You may want to visit #freebsd-ports for additional help/suggestions regarding the creation. 22:47:14 yeah, really not sure about that yet. last time i maintained a port i was happy i could give maintainership away ^^; 22:47:49 phryk: If it work with python3.11~, you should be fine. FBSD isn't too keen on supporting non-supported software. I honestly wouldn't bother with anything too old. 22:48:40 phryk: Well, if it's your software/project, you can do whatever you want whenever you please. So, there's that. 22:49:06 ek: it should work with every python version in ports or else have a minimum python version set. but this is quite a pain to test... 22:49:12 ek: well, last time i maintained a port, testing it for all currently used python versions was a requirement to get an updated version of the port merged and i don't have the energy to figure out how to do that. and with this project in particular there isn't even a test suite yet, so i'd know even less how i can assure that it works… 22:49:22 Otherwise, you can always submit the port and once it's in place you can request non-ownership and it'll fall into committer's/user's hands. 22:50:13 ivy: I agree. I'm basically suggesting testing for python3 and IGNORE/BROKEN for python2 (or however specific they'd like to get.) 22:50:30 ek: this is more about 3.10, 3.11, 3.12, etc 22:50:50 (well i assume it is, i don't think anyone cares about python 2 anymore) 22:50:58 ivy: It could be. I have no idea what their code works with. :) 22:51:06 ivy: Exactly. 22:52:07 ek: is there a formal way of doing that, or do i just end my port submission with "btw i don't want to maintain this port"?^^ 22:53:28 phryk: That's pretty much the formal way. https://bugs.freebse.org, submit a new port request and just say you have no interest in maintaining it. If it gets approved, it'll like just be assigned to ports@. 22:54:05 Of course, that is if there's enough interest. Otherwise, you can be the maintainer and if it bothers you down the road, just submit a report saying you don't want it anymore. 22:59:45 i guess the poudriere exporter might be of interest, the new one not sure – monitors availability, responsiveness and tls expiry of (external) sites. 23:00:19 so potentially more people of whom it would be of interest, but potentially also already existing alternatives. 23:04:16 phryk: Sounds solid. I'd give it a go if it were mine. 23:34:23 ek: I saw that bug too however isn't that the env (M1 Mac) you tested on too? 23:47:51 ek: definitely appears to be the M1 only... works fine on my O6 FreeBSD Native box 23:48:27 (Thats the ArmV9)... I just reset the env and tried it 23:55:57 I got triggered. Is FreeBSD on Apple Silicon a thing? 23:58:15 regis: only in a vm here... I use it natively on a Radxa Orion-O6 though... with great success