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?

Poetic: `$ less entropy / entropy: Permission denied`

kenrap: fluffy has a fix for the xorg-server build failure

noice!

ivy: may I have you give me a link to that fix?

kenrap: tl;dr is add -Dsecure-rpc=false to MESON_ARGS lists.freebsd.org/archives/dev-comm…ts-src-main/2025-August/034688.html

Thank you!

apparently this was fixed upstream over a year ago but i guess it takes a while to make it into the various server releases

👍

happiness, [00:01:58] [02] [00:00:40] Finished x11-servers/xorg-server@xorg | xorg-server-21.1.18,1: Success

ivy: thanks again!

don't thank me too much, it was me what broke it :-)

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 :)

It feels good to get my pkg cache rebuilding again

it's definitely been a fun week for 15.0, with this and the gssapi problems and the pkgbase upgrade issue

Yeah, curl was failing to build with gssapi problems. SponiX was also telling me how he was dealing with pkgbase problems too.

this is the least fun review i've ever prepared: reviews.freebsd.org/D51874

i can't wait until we can just require pkgbase and get rid of OLD_FILES :-)

ivy: that must've been a painful cleanup...

ivy: thanks for the help yesterday.. all's good now

3500 lines of diff... fun

scoobybejesus_tl: not the worst/biggest I've ever seen

Had one to do MNLS support back in the 90's that was massive for Java and Corba code

So pkgbase will get rid of that form of maintenance, huh?

(In a product I worked on)

kenrap: in theory, but not for a long time as we can't just remove make installworld even when pkgbase becomes the default

ivy: oh, interesting. So when I build the base from scratch, I'll be able to pkgbase it?

kenrap: yes, just run 'make buildworld buildkernel update-packages' and you'll get a pkg repository for the base system

Interesting

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

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

Would it make sense to have one "WITHOUT" knob and be able to pass in values like "gssd" to simplify things?

maybe

also we can't do everything this way, like lib32

Gotcha

(the gatekeepers at the forums are going to be foaming at the mouths when they learn about the make installworld to pkgbase transition...)

Oh, they're already have. Good. :)

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?

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

or source the system/user profile inside the script

Then call python

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?

phryk: $PATH should be inherited by anything that the script setting the path is running.

... if that makes sense? Maybe could have worded that better.

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.

phryk: You're just setting a PATH= in a ${LOCALBASE}/etc/rc.d script?

aye.

So, only that rc script (and children it runs) with inherit the PATH change(s). Other rc scripts should be fine.

great, thanks. :)

Unless, of course, this particular rc script is run in order to execute other rc scripts? That would be... interesting.

no, i'm just running a python executable. it's multiprocessed, tho. :P

That'll be fine.

now i only have to find out why status is lying…

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…

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.

the rc script i'm currently working on is essentially identical to this: rnd.phryk.net/phryk/prometheus_poud…/main/files/prometheus_poudriere.in

phryk: Just out of curiosity, why aren't you using #!/bin/sh for the rc script?

but i am?

look at the link, literally the first line is #!/bin/sh

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.

ah, no. that sounds painful.^^

Hence the reason I had a raised eyebrow for a bit there. :)

Anyone seen this one? specificly trying to build OpenJDK...

er rather.. running it

Tenkawa: Which one?

Error occurred during initialization of VM

Could not allocate compressed class space: 1073741824 bytes

Tenkawa: I have not.

anything newer than 8 on arm64 here

This is within a VM?

Both

vm and 12 core ARMv9

bhyve?

no

Oh, wait. Doesn't matter.

Vmware host

You're saying in VM and also on non-VM.

Does the same thing happen on non-ARM?

I don't use JDK, so I have no way to test.

Don't have a non-arm machine setup atm..

90% of what I do is either arm or risc-v

What exactly are you running? I can spin up a jail or VM in i386 and/or amd64 real quick.

This is 15-current.. (needs to be for the ARMV9 server)

I can do CURRENT. I just want to see if this is ARM-specific?

Let me check my x86

see if any of my offline vms are fbsd

I don't use them much anymore since I got 2 of these 12 core units and my M1

I suppose I can also test on my silicon Mac.

No.. appears all I have is netbsd on mine

Natively?

Just takes longer. My bhyve hypervisor makes things quick.

Naw. It'd be a FBSD VM on my Mac.

ok..thats close to my Mac M1 VMware VM

Okay. I have a 15-CURRENT VM ready to go right now. What are you running to see this error?

both from ports

oops

darn /

/usr/local/bootstrap-openjdk8/bin/java works... /usr/local/bootstrap-openjdk17/bin/java fails

Okay. Gimme a sec to install some of the ojdk's and bootstrap.

16gb ram allocated to the vm so I know its got plenty of ram to work with....

sure

thanks for checking

So, I don't get a bootstrap-* in /usr/local with ojdk8 from the package.

But, /usr/local/bin/java works just fine.

just a sec.. they are in a specific pkg

let me find it

and unfortunately dependencies of maven

(and others)

Hrm. I've got ojdk 8, 17, and 24 installed. All java(vm) executables seem to be fine on amd64.

This is on 15-C (just updated via pkgbase)

just a sec

searching the db

you need bootstrap-openjdk8-r453316_2 also

and bootstrap-openjdk17-17.0.1.12.1

so bootstrap-openjdk17 and bootstrap-openjdk8

Got 'em.

pkg provides is a great thing :)

Same deal. Both run fine.

Which bins? I want to run the same ones

I just ran:

Want to backtrace to see if something goofy is going on with this thing

/usr/local/bootstrap-openjdk8/bin/java and /usr/local/bootstrap-openjdk17/bin/java

Obviously, it does nothing but provide help. But, there were no errors.

Are you passing additional args that may be the problem?

yeah... one works one breaks here ... really odd

nope.. well this is even "more" odd

if I run them like this:

/usr/local/bootstrap-openjdk8/bin/java ; /usr/local/bootstrap-openjdk17/bin/java

they both dump

I'll pastebin

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*.

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.^^

even more odd

phryk: Is this something you plan on submitting as a port in the future?

ek: not sure yet, but possibly. it's a work project, but i already got the okay to FOSS it from my boss.

Tenkawa: I'm seeing stuff like this in the PR's, but with no noticeable resolution (yet): bugs.freebsd.org/bugzilla/show_bug.cgi?id=265284

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…

phryk: Very cool! You may want to visit #freebsd-ports for additional help/suggestions regarding the creation.

yeah, really not sure about that yet. last time i maintained a port i was happy i could give maintainership away ^^;

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.

phryk: Well, if it's your software/project, you can do whatever you want whenever you please. So, there's that.

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...

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…

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.

ivy: I agree. I'm basically suggesting testing for python3 and IGNORE/BROKEN for python2 (or however specific they'd like to get.)

ek: this is more about 3.10, 3.11, 3.12, etc

(well i assume it is, i don't think anyone cares about python 2 anymore)

ivy: It could be. I have no idea what their code works with. :)

ivy: Exactly.

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"?^^

phryk: That's pretty much the formal way. 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@.

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.

i guess the poudriere exporter might be of interest, the new one not sure – monitors availability, responsiveness and tls expiry of (external) sites.

so potentially more people of whom it would be of interest, but potentially also already existing alternatives.

phryk: Sounds solid. I'd give it a go if it were mine.

ek: I saw that bug too however isn't that the env (M1 Mac) you tested on too?

ek: definitely appears to be the M1 only... works fine on my O6 FreeBSD Native box

(Thats the ArmV9)... I just reset the env and tried it

I got triggered. Is FreeBSD on Apple Silicon a thing?

regis: only in a vm here... I use it natively on a Radxa Orion-O6 though... with great success