nimaje: I using xfe as test to try running an alpine gui program under chroot

I want to know how to fix display :0 error

any progress after sharing /tmp and xauth?

probably easier to first test if it works without the chroot

good idea

Chip1972, There are a lot of articles describing how to run GUI programs from jails. Such as this one: tumfatig.net/2024/running-web-browsers-in-freebsd-jail

bash

oops.

rwp: just what I need

anyone know a diagramming tool that works on freebsd? i need to be able to place squares, connect them with arrows, move squares around, scroll vertically and horizontally, and zoom in/out

Are you willing the use Linux emu?

er well I guess they have a native port for FreeBSD.

drawio

Could just use the web interface too.

no

drawio is related to graphviz?

Not sure I've only used it on Windows.

can use it offline?

Yeah

ok ty. looks like drawio will work ok

kerneldove_, Take a look at dia which is in ports and has pkgs available for install. It's something like Visio. wiki.gnome.org/Apps/Dia

tried it, drawio is easier to use tho

Awesome! I will have to try out drawio the next time I need to draw something.

i'm a fan of asciiflow.com

i dont want to use an online service

Ah, the feeling of troubleshooting a slow VNET bridge just to realize after a few hours it's a bandwidth issue between certain ISPs and fully out of my control

ah

I'm sorry

hey

why FreeBSD 15 didn't switched to default 3.12 python version rather than the oldy 3.11?

titou: Python isn't part of FreeBSD operating system. it's part of the ports collection, which is independent of OS version - all version of FreeBSD use the same ports. i believe the reason ports hasn't updated to python 3.12 by default yet is due to a few ports still not working with it

ok! great answer

thank you

but that's crazy that some ports is still not working... on linux, python is version 3.14..

s/is/are

and for 3 ports I need custom port configuration. I'm using synth since several years but it's quite boring since I need to give to him all my needed ports and it only download part of them but recompile MOST of them.. it takes huge time. For only 3 ports, that's really boring

would you have another idea? (ports are: nginx for only two extra plugins, nextcloud to get it using postgresql rather than mysql and scponly to get rsync and scp working..)

hm, can synth use the official repos for packages with default options (like poudriere can)? If yes, then use that and keep the commit of the ports tree you are building in sync with the official builders

yes, it can do that "Fetch prebuilt packages" synth(1)

titou: it's probably rebuilding all dependencies when one of their dependents changes. perhaps try poudriere, which recently had logic added to avoid doing that so often

titou new version(s) of Python are available on FreeBSD as well, typically even before they are available on mainstream Linux distros. the question here is more abut the default flavor of Python set in Ports.

thank you for all your answers. I had a look on poudriere long years ago but it let me afraid because its configuration looked very hard

only for 3 ports :)

ivy: it's what the synth developer answered to me but i don't understand why 50 packages needs to be recompiled for an "end software" like nginx :)

antranigv: yes I see that there are different versions of the interpreter but not for packages?

antranigv: for instance sqlalchemy is only available for py311

titou: if a package containing a shared library is updated, such as cURL, it will rebuild everything that depends on cURL to make sure they're using the most recent version of the library, then it will rebuild everything that depends on those things (because they might contain shared libraries themselves), and so on, so a single update can resulting in a lot of packages being rebuilt

i understand that

the change poudriere made is that if the shared library version hasn't changed, it won't rebuild all the dependents, which is correct in 99% of cases and saves a lot of rebuilding

that's a very great thing for poudriere!

well, you said you didn't understand it, so i was trying to explain :-) which part of it don't you understand?

thank you. the part about the fact that I though nginx was not used by other packages and are installed because I need it so if I update its compilation options, it would only recompile itself

but maybe I'm wrong and I also installed other packages that depends on it..

recompiling nginx shouldn't rebuild anything else, except maybe any external DSOs. that might be something synth is doing, i've never used it

it should be the same thing for nextcloud and scponly which are "end software" (I mean software which use others but are not used by my other packages)

but anyway :) I'll have a look on poudriere again..

well, both synth and poudriere can fetch packages from the official repos as long as versions and options match, so if you enable that you should only rebuild your three leaf ports (as long as there was no versions update for some transitive dependency between the commit of the ports tree the official builder build and the commit you are building)

that's perfect! I'll try

I'm googling but if you know a good and up-to-date "easy" tutorial for poudriere, i would be interesting in it :)

(i'm reading the vermaden one)

Instead of using poudriere options I recommend to use <option_name>_{,UN}SET in some -make.conf as poudriere options will save all options as you currently have selected them and with -make.conf you can just change those you care about and if defaults change for options you don't care about, you will automatically get that change instead of still using the value from the time you used

poudriere options

ok good

to give you an example for nextcloud with postgres instead of mysql it would be www_nextcloud_SET=PGSQL and www_nextcloud_UNSET=MYSQL

and I read aboutthat's great! thanks

i think poudriere will become my new friend..

when you use it, do you configure all the packages you need and then only use the poudriere repository? Or do you use a mix between freebsd repository and poudriere's one for custom packages?

I only use my poudriere repository, as I make deep changes via OPTIONS_SET and OPTIONS_UNSET (like <option_name>_{,UN}SET but affecting all ports) for example I disable pulseaudio that way

ok

If I didn't do that I would probably enable that fetching from the official repo and use only poudriere, to make sure the repos can't go out of sync (but probably not as important)

titou yes, packages are compiled only for the main flavor for Python. I think the PHP team, on the other hand, compiles it for multiple versions.

nimaje: yup

antranigv: what a pity:)

titou always welcome to complain at bugs.freebsd.org :-)))

it would benefit me too :P

but I run a package server anyway, so I'm not worried that much.

(-:

I would complain about that when I'll have enough time to help also..

[00:00:07] Building 141 packages using up to 8 builders

[00:00:07] Building 141 packages using up to 8 builders

[00:00:07] Building 141 packages using up to 8 builders

"Building 141 packages [...]" for 4 end-softwares..

(sorry for multiples copy of the same line..)

that's strange since it fetches no packages even with PACKAGE_FETCH_BRANCH=latest set

the .conf.sample says it still needs -b <branch> for bulk or testport

ups

it's the same.. but in the log it is written unable to update repository FreeBSD

maybe the problem comes from here

ok, that seems strange, bdrewery do you know more about that?

if this is on 15.0, there is no "FreeBSD" repository - perhaps the fix for that in poudriere didn't make it into the release yet

:-(

you might try using poudriere-devel instead and see if that helps

that so greaat it solved the bug and only compiles my updated package! thank you a lot:)

what is strange is that i even ask poudriere to generate package for custom python version without changing the default python version?

for instance py-sqlalchemy@py312

it tells me that there is no py312 flavor and the only flavor available is py311..

you can set BUILD_ALL_PYTHON_FLAVORS="YES" in a -make.conf to have all flavors available, without that python ports only have a flavor for the default python version to avoid having so many copies which mostly aren't needed in a bulk -a

nimaje: oh

thank you

i'll try

has anybody got a non-pkgbase FreeBSD 15.0-p1 handy?

I'd like to see what `uname -a` and `freebsd-version -kru` reports on it

my pkgbase systems report 15.0-RELEASE-p1 for all of these, and I have 1 non-pkgbase system that only shows -p1 for `freebsd-version -u`

dch: this is probably expected, for pkgbase the entire kernel package is updated, for freebsd-update, only the specific modules are updated

ivy yes this is what I was wondering

I have run out of non-pkg base systems to test things on ...

thanks for the clarification

Earlier this week I don't think I even found a -p1 image at all

Gotta install and upgrade before running rtsold

also the different hash of `/boot/kernel/kernel` confused me mightily

hm, sad that when using sysctl kern.corefile=/var/coredumps/%U/%N.core (as in the example in core(5)) the directories for the uids aren't created on need, but have to be created before

it's too busy dumping core to create directories

I've always wondered if coredumps (not kernel of course) can be uploaded to NFS, regardless of the user

the reason why I'm asking is because we have a lot of programs in our HPC env that I'd like to collect and see what the bugs are.

is root squash enabled?

you mean user map? I think "root sqaush" is a Linux thing, yes?

squashfs is not suported skered

perhaps you meant "-maproot=root" in exports file

please guys don't escalate, dumping core is hard task for the OS, thus it's only possible to dump cores into existent dump directory

antranigv: it should work

antranigv: kern.coredump=1 kern.corefile=/path/to/%U.%N.%P.core

the path must be writeable by whatever will dump core

if you have dumping cores enbled, core directory exists, and is writeable, but your core still doesn't show up, consider turning on one more sysctl knob: kern.sugid_coredump

sometimes, the app suppresses core creation by itself, it's usually no any issue but limitation

not a problem for me, all the software I write is 100% bug free

it will be also nice to send suspicious signal to a healthy app to collect core just for testing

rtprio my software is also 100% bug free... but my team uses other people's software because mine is not "user friendly" whatever that means.

:P

i'm sorry

lol

There are kernel dumps and there are userland process core dumps and those are two very different things. I think the previous discussion mixed those two different things together.

One can dump core over NFS. I almost said no problem but it does create problems because the core dumping process is in the kernel and if the core is a 256GB memory image then it preempts other activities until it is done. That sometimes creates other problems!

Since the userland core dump is done as the user not root the root mapped user is a don't care for userland process core dumps.

The directory must be writable and all other normal permissions apply. If one makes a directory called "core" for example and the core is called core too then it blocks the core dump. That's an old workaround for running processes which might dump core but the user had no way to disable the feature and no disk space to hold the result either.

That's as zi mentioned of course.

oh yea, trying to kernel dump over nfs, if that's even possible, sounds dumb as fuck to me

You'd want a partition/whatever in the box and to set kern.shutdown.dumpdevname for that

hello, are there any recent issues with the freebsd ports? it seems pkg wants to download packages that are nonexistent at the remote

guess the correct thing would be rc.conf's dumpdev

karolyi: can you elaborate

zi: for example, I wanted to install py311-pymacaroons for testing, and pkg looks for pkg.freebsd.org/FreeBSD:14:amd64/la…pymacaroons-0.13.0_2~ea8a819f4f.pkg, then bails out on 404

I've never seen these Hashed stuff before

karolyi: pkg update -f and try again?

there's a newer PORTREVISION out there that is current (py311-pymacaroons-0.13.0_3~ee536aa2c7.pkg)

karolyi: what IP does pkg.freebsd.org resolve to for you?

zi: pastebin.com/5pUNLMQQ, but just downloaded pkg.freebsd.org/FreeBSD:14:amd64/latest/data.pkg and it contains the same hashed url for that package

that's not ideal, one moment

karolyi: wanna retry now?

let's see

zi: normality seems to have been restored, thanks. while I'm already here, are you in the position to help in adding bugs.freebsd.org/bugzilla/show_bug.cgi?id=292270 ?

karolyi: i cant right this second but if you ping me again in like 2-3hours, i can try to look at it

karolyi: thanks for the report/testing

zi: I'll be sleeping by then probably :) that new port is a part of another (a much bigger one), that is manticoresearch, a local elasticsearch replacement

the comment tells it all, the other port is a WIP but relies on this

not pushing things though

I personally would prefer a comment explaining why for stuff like :noninja. And it builds fine in poudriere?

it does, I'm using it locally from my built port

it builds with cmake, that's why btw

but wait until you see the amount of patches I'll deliver with manticoresearch...

nimaje: porters will be familiar with that--no need to comment it

karolyi: the port should probably be named differently--CRoaring--as that is the project name. if, in the future, someone else wants swiftroaring or roaring-rs they would all be in conflict following roaringbitmap as the port name

zi: I can adjust that patch in no time. can you please leave a reminder comment there?

that is to say, I can make that change in no time

i can!

thank you very much. I gotta run some errands but I can get that done, tomorrow at latest. pretty spent for today

i understand

zi: not what it does, but why it is necessary for that port

uses cmake, disables ninja build

yeah, that's the what, but why doen't it build with ninja?

meh

that's why I prefixed that nit with "I personally would prefer"

im gonna assume they didnt put it there for their health

nimaje: it probably does, I just didn't want to pull more deps that aren't even used

zi: what do you mean by "If you haven't already, I'd submit upstream patches for the __FreeBSD__-related patches"? the porters handbook said to submit the patch to "Ports & Packages" but maybe I'm missing something?

karolyi: the idea would be to get upstream (the git project) to adopt the patches you needed (under files/) so that they can be removed in the next update

zi: oh, I get it now. that's planned as a next version whenever this patch gets accepted, if I'd do it now it would enter a kinda "deadlock" state, so I'd rather get one working after another, and not at the same time

it's even discussed about here: RoaringBitmap/CRoaring #777

cool

the manticore changes are so huge I'm not even sure they would be accepted. lots of cmake changes to fetch the internal dependencies at the fetch stage, and so on

it's a WIP, will make them review before I'll come up with the actual freebsd port request