00:17:20 nimaje: I using xfe as test to try running an alpine gui program under chroot 00:17:20 I want to know how to fix display :0 error 00:18:29 any progress after sharing /tmp and xauth? 00:19:37 probably easier to first test if it works without the chroot 00:21:23 good idea 00:27:18 Chip1972, There are a lot of articles describing how to run GUI programs from jails. Such as this one: https://tumfatig.net/2024/running-web-browsers-in-freebsd-jail/ 00:32:04 bash 00:32:10 oops. 00:33:43 rwp: just what I need 01:29:30 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 01:36:02 Are you willing the use Linux emu? 01:38:14 er well I guess they have a native port for FreeBSD. 01:38:17 drawio 01:38:31 Could just use the web interface too. 01:46:08 no 01:46:27 drawio is related to graphviz? 01:57:07 Not sure I've only used it on Windows. 02:05:12 can use it offline? 02:05:58 Yeah 02:11:36 ok ty. looks like drawio will work ok 02:23:03 kerneldove_, Take a look at dia which is in ports and has pkgs available for install. It's something like Visio. https://wiki.gnome.org/Apps/Dia 02:23:20 tried it, drawio is easier to use tho 02:24:31 Awesome! I will have to try out drawio the next time I need to draw something. 02:29:54 i'm a fan of https://asciiflow.com/ 02:36:14 i dont want to use an online service 05:45:18 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 05:47:20 ah 05:47:22 I'm sorry 08:56:52 hey 08:57:18 why FreeBSD 15 didn't switched to default 3.12 python version rather than the oldy 3.11? 08:58:33 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 08:59:15 ok! great answer 08:59:20 thank you 08:59:54 but that's crazy that some ports is still not working... on linux, python is version 3.14.. 09:00:00 s/is/are 09:03:15 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 09:03:59 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..) 09:09:48 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 09:12:40 yes, it can do that "Fetch prebuilt packages" synth(1) 09:15:57 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 09:16:49 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. 09:46:43 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 09:46:46 only for 3 ports :) 09:47:36 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 :) 09:48:15 antranigv: yes I see that there are different versions of the interpreter but not for packages? 09:48:51 antranigv: for instance sqlalchemy is only available for py311 09:48:58 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 09:49:46 i understand that 09:49:49 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 09:50:06 that's a very great thing for poudriere! 09:50:20 well, you said you didn't understand it, so i was trying to explain :-) which part of it don't you understand? 09:51:25 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 09:51:38 but maybe I'm wrong and I also installed other packages that depends on it.. 09:52:10 recompiling nginx shouldn't rebuild anything else, except maybe any external DSOs. that might be something synth is doing, i've never used it 09:53:39 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) 09:54:01 but anyway :) I'll have a look on poudriere again.. 09:54:22 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) 09:55:40 that's perfect! I'll try 09:56:48 I'm googling but if you know a good and up-to-date "easy" tutorial for poudriere, i would be interesting in it :) 10:01:37 (i'm reading the vermaden one) 10:11:39 Instead of using poudriere options I recommend to use _{,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 10:11:41 poudriere options 10:14:13 ok good 10:17:27 to give you an example for nextcloud with postgres instead of mysql it would be www_nextcloud_SET=PGSQL and www_nextcloud_UNSET=MYSQL 10:20:39 and I read aboutthat's great! thanks 10:20:55 i think poudriere will become my new friend.. 10:21:40 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? 10:24:54 I only use my poudriere repository, as I make deep changes via OPTIONS_SET and OPTIONS_UNSET (like _{,UN}SET but affecting all ports) for example I disable pulseaudio that way 10:25:33 ok 10:27:43 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) 10:31:09 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. 10:33:15 nimaje: yup 10:33:20 antranigv: what a pity:) 10:33:36 titou always welcome to complain at bugs.freebsd.org :-))) 10:33:48 it would benefit me too :P 10:34:00 but I run a package server anyway, so I'm not worried that much. 10:40:40 (-: 10:41:07 I would complain about that when I'll have enough time to help also.. 10:51:24 [00:00:07] Building 141 packages using up to 8 builders 10:51:26 [00:00:07] Building 141 packages using up to 8 builders 10:51:30 [00:00:07] Building 141 packages using up to 8 builders 10:51:45 "Building 141 packages [...]" for 4 end-softwares.. 10:52:00 (sorry for multiples copy of the same line..) 10:54:05 that's strange since it fetches no packages even with PACKAGE_FETCH_BRANCH=latest set 10:57:00 the .conf.sample says it still needs -b for bulk or testport 10:58:31 ups 11:01:23 it's the same.. but in the log it is written unable to update repository FreeBSD 11:01:26 https://pastebin.com/akLVph44 11:01:30 maybe the problem comes from here 11:04:14 ok, that seems strange, bdrewery do you know more about that? 11:06:17 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 11:06:53 :-( 11:07:38 you might try using poudriere-devel instead and see if that helps 11:10:47 that so greaat it solved the bug and only compiles my updated package! thank you a lot:) 11:38:19 what is strange is that i even ask poudriere to generate package for custom python version without changing the default python version? 11:38:30 for instance py-sqlalchemy@py312 11:38:45 it tells me that there is no py312 flavor and the only flavor available is py311.. 12:04:49 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 12:27:27 nimaje: oh 12:27:58 thank you 12:28:00 i'll try 13:15:21 has anybody got a non-pkgbase FreeBSD 15.0-p1 handy? 13:15:35 I'd like to see what `uname -a` and `freebsd-version -kru` reports on it 13:17:06 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` 13:17:49 dch: this is probably expected, for pkgbase the entire kernel package is updated, for freebsd-update, only the specific modules are updated 13:18:06 ivy yes this is what I was wondering 13:18:21 I have run out of non-pkg base systems to test things on ... 13:18:28 thanks for the clarification 13:19:32 Earlier this week I don't think I even found a -p1 image at all 13:19:59 Gotta install and upgrade before running rtsold 13:20:02 also the different hash of `/boot/kernel/kernel` confused me mightily 15:06:00 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 18:46:52 it's too busy dumping core to create directories 18:50:25 I've always wondered if coredumps (not kernel of course) can be uploaded to NFS, regardless of the user 18:50:42 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. 18:50:44 is root squash enabled? 18:55:05 you mean user map? I think "root sqaush" is a Linux thing, yes? 19:06:32 squashfs is not suported skered 19:08:46 perhaps you meant "-maproot=root" in exports file 19:11:38 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 19:11:59 antranigv: it should work 19:14:49 antranigv: kern.coredump=1 kern.corefile=/path/to/%U.%N.%P.core 19:15:03 the path must be writeable by whatever will dump core 19:27:42 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 19:29:25 sometimes, the app suppresses core creation by itself, it's usually no any issue but limitation 19:30:26 not a problem for me, all the software I write is 100% bug free 19:31:52 it will be also nice to send suspicious signal to a healthy app to collect core just for testing 21:18:18 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. 21:18:21 :P 21:22:28 i'm sorry 21:25:37 lol 21:47:48 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. 21:48:52 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! 21:49:36 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. 21:50:34 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. 21:50:50 That's as zi mentioned of course. 21:51:44 oh yea, trying to kernel dump over nfs, if that's even possible, sounds dumb as fuck to me 21:51:55 You'd want a partition/whatever in the box and to set kern.shutdown.dumpdevname for that 21:52:23 hello, are there any recent issues with the freebsd ports? it seems pkg wants to download packages that are nonexistent at the remote 21:52:49 guess the correct thing would be rc.conf's dumpdev 21:52:57 karolyi: can you elaborate 21:53:46 zi: for example, I wanted to install py311-pymacaroons for testing, and pkg looks for http://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/Hashed/py311-pymacaroons-0.13.0_2~ea8a819f4f.pkg, then bails out on 404 21:54:34 I've never seen these Hashed stuff before 21:56:24 karolyi: pkg update -f and try again? 21:56:44 there's a newer PORTREVISION out there that is current (py311-pymacaroons-0.13.0_3~ee536aa2c7.pkg) 21:57:51 karolyi: what IP does pkg.freebsd.org resolve to for you? 22:00:05 zi: https://pastebin.com/5pUNLMQQ, but just downloaded http://pkg.freebsd.org/FreeBSD:14:amd64/latest/data.pkg and it contains the same hashed url for that package 22:01:06 that's not ideal, one moment 22:08:18 karolyi: wanna retry now? 22:08:30 let's see 22:12:14 zi: normality seems to have been restored, thanks. while I'm already here, are you in the position to help in adding https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292270 ? 22:13:06 karolyi: i cant right this second but if you ping me again in like 2-3hours, i can try to look at it 22:13:09 karolyi: thanks for the report/testing 22:14:32 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 22:15:08 the comment tells it all, the other port is a WIP but relies on this 22:15:29 not pushing things though 22:19:58 I personally would prefer a comment explaining why for stuff like :noninja. And it builds fine in poudriere? 22:20:26 it does, I'm using it locally from my built port 22:20:51 it builds with cmake, that's why btw 22:21:16 but wait until you see the amount of patches I'll deliver with manticoresearch... 22:47:24 nimaje: porters will be familiar with that--no need to comment it 22:50:55 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 22:52:16 zi: I can adjust that patch in no time. can you please leave a reminder comment there? 22:52:52 that is to say, I can make that change in no time 22:52:53 i can! 22:53:29 thank you very much. I gotta run some errands but I can get that done, tomorrow at latest. pretty spent for today 22:56:37 i understand 22:58:29 zi: not what it does, but why it is necessary for that port 22:59:27 uses cmake, disables ninja build 22:59:29 * zi shrugs 23:00:29 yeah, that's the what, but why doen't it build with ninja? 23:02:05 meh 23:02:55 that's why I prefixed that nit with "I personally would prefer" 23:03:23 im gonna assume they didnt put it there for their health 23:38:32 nimaje: it probably does, I just didn't want to pull more deps that aren't even used 23:40:14 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? 23:42:56 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 23:45:19 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 23:46:16 it's even discussed about here: https://github.com/RoaringBitmap/CRoaring/issues/777 23:46:27 cool 23:47:44 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 23:49:03 it's a WIP, will make them review before I'll come up with the actual freebsd port request