00:10:36 * ek raises an eyebrow 00:10:45 rwp: Emacs!? Bro... (kidding, of course.) 00:38:13 https://paste.rs/UCGO5 why is the freebsd-base repo not accessible via http? 00:41:02 is there an mirror of that repo that is accessible via http? i would like to do so for caching reasons with squid 00:45:17 emaccin across the universe 00:48:45 ek, I have used Emacs for everything for years. I am using an Emacs IRC to type this in right now! Emacs erc makes a pretty good IRC client. 00:50:06 I mean, emacs being my text weapon of choice and irc being all text this gives me all of the fancy text things like dynamic abbreviation expansion and other things. Spell checking of course but I think all clients do that now. 00:57:17 rwp: Yeah. I have friends that use Emacs. It's like it's own little OS. 00:58:54 I just use tmux+weechat for IRC. For text editing, I decided to go the vi route (only because it was already on everything.) So, neovim with ungodly amounts of plugins for coding, vi/vim for regular editing. 00:59:43 The vi commands are just ingrained after so many years and I don't need to remember other editor commands. Either vi, vim, or nvim is almost always available. So, I just use it. 01:01:58 ek, I started with qed at university. So moving from there to vi was trivial. Play rogue if you want to really learn the movement keys. :-) Then switched to emacs. And stopped there. Never needed to go anywhere else after that. 01:02:35 I am pretty much multi-lingual fluently with the standard editors. I can switch between them without thinking about any of them. 01:03:27 I did try using Emacs for a while. But, I just kept messing things up because I'd default to vi key commands. Again, it just made sense. I'd never really need to install a 3rd party editor to be comfortable. 01:05:06 I don't badmouth anyone's choice. There's a reason we have choices and that's the whole point! 01:08:13 vortexx: iirc you run OpenBSD + bhyve, have you tried running the latest version of EDKII for bhyve-firmware with OpenBSD 01:09:05 https://bpa.st/GHLQ 01:09:12 I get the following error 01:18:23 this happens on both 7.8 and 7.9 01:38:37 polarian: You're seeing errors using OpenBSD on a FBSD bhyve host? 01:40:04 yes 01:49:02 polarian: Hrm. I don't use bhyve directly, but I do use vm-bhyve and I have no problem installing/running OBSD 7.X. 01:49:21 I just tested a 7.9 install just to be sure I wasn't missing anything. 01:49:25 Using UEFI? 01:49:38 It looks like it based on your provided paste. 02:03:06 this goes out to the poudriere and freshports people.. has anyone tried to compile python311 in the last 2-3 days? I am getting a checksum "issue" but when I look at the changelog.. it says it is fine: https://www.freshports.org/lang/python311/ 02:03:23 i am asking but may put a bug report in as i need python311 to compile llama.cpp 02:05:53 voy4g3r2: I built python311 today via Poudriere. No issues. 02:37:06 hrm.. must has some old files or something 02:37:12 thanks for info ek 02:38:23 voy4g3r2: Sure thing. It could be. I did pull a fresh repo before building. But, it didn't build without any issue on 13.5, 14.4 and 15.0. 02:38:30 s/didn't/did/ 02:38:56 No problems on any versions of FBSD (even unsupported versions). 02:53:55 yeah, i am not getting why it is happening to me 02:53:58 everything looks "okay" 02:54:33 and the latest changelog about a diff "issue" i am fixating on, probably improperly 03:00:04 ek, As an emacs user these days I just expect to get abuse! :-) I just own it! :-) 03:03:07 hrm.. so the checksums are not matching the commit 03:08:26 voy4g3r2: What is the error you're seeing? 03:08:48 rwp: Might as well! It is what it is. If you like it, use it. 03:09:26 [00:02:21] [01] [00:00:01] Finished lang/python311 | python311-3.11.15_2: Failed: checksum 03:09:29 haha 03:09:31 failed: checksum 03:09:58 and looking at the distfiles output and comparing to the git commit off freshports.. they are NOT matching 03:12:14 Are you positive that your ports tree is completely up-to-date? What does "sudo git -C /usr/ports log -1" show? 03:12:39 ek: yes using UEFI, that is what EDKII is for :) 03:12:40 Err... -sudo 03:14:11 polarian: Yep. I'm using edk2-bhyve-g202508. Works just fine. 03:14:22 hmmm 03:14:24 welp 03:14:27 I have no clue then 03:14:27 This is an Intel machine, though. 03:14:41 ek: try the following config: 03:18:36 ek: https://bpa.st/A3OA there you go 03:19:04 if you have EDK2@bhyve installed you should be able to run this no problem 03:19:12 `kldload nmdm` as well 03:19:34 make sure to `set tty com0` in the loader 03:19:42 see if it drops you into the installation media 03:22:02 polarian: Yeah. That's what I do. But, I don't use zvol or some other options. 03:22:19 hmmm 03:22:24 maybe it is an AMD issue then 03:22:33 I have had no issues virtualising on intel 03:23:30 I could make a post to the virtualisation mailing list, but that will likely go ignored lol 03:23:37 bugzilla is prob an option 03:24:01 ek: it shows a commit for openbabel 03:24:18 does anyone have a ryzen based device, and willing to try running the OpenBSD miniroot? 03:24:47 polarian: Have you tried using vm-bhyve at all? 03:25:07 I can give you my config for OBSD 7.9 that I literally just booted to test. 03:25:23 It's just a little CLI front-end to bhyve. But, it's handy. 03:25:37 vm-bhyve is great! 03:25:54 ek: if it doesnt work with bhyve it wont work in vm-bhyve 03:26:42 polarian: That is true. But, the options may be different. I can share my OBSD config. Gimme a second. 03:27:03 voy4g3r2: The date of the latest commit on that is what? 03:27:23 I am too tired to do this right now, maybe tomorrow 03:27:57 wed may 27 19:37:15 2026 -0700 03:28:09 voy4g3r2: openbabel should be correct. Sounds up-to-date 03:28:24 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278318 03:28:26 hmmm 03:28:31 I will try this in the morning 03:28:34 its 4:30am I need to zzzzzz 03:28:46 poudriere bulk -j 150Ramd64 -p default -c misc/ggml misc/llama-cpp 03:28:47 polarian: Yowza! Get some sleep. 03:29:26 thx for the help 03:29:27 maybe i will tackle making a new jail.. but does not seem to make sense since the jail is created and destroeyd each run 03:29:45 voy4g3r2: A new jail shouldn't matter. 03:29:56 ah ek this is likely the problem 03:29:58 > 03:30:00 0xc0011029 is MSR_DE_CFG, and I suspect that OpenBSD's applying a mitigation for zenbleed. FreeBSD doesn't do this if it detects that it's running as a guest. 03:30:00 thanks for the confirmation, did not seem to be the issue 03:30:03 polarian: Sure thing. I'm quite sure it'll get resolved. 03:30:14 so I bet if I add -w to the flags it will work flawlessly 03:30:17 and thats why intel works without issue 03:30:20 zenbleed is amd based 03:30:30 and OpenBSD obviously doesnt detect its running as a guest 03:30:34 AH! That very well may be! 03:30:48 will see in the morning :) 03:30:54 * polarian crosses his fingers 03:30:54 ek: i know it is the second diff command: https://cgit.freebsd.org/ports/commit/?id=d81083b3702ace55f1b777c36047101ad0a211c2 03:30:58 gn 03:31:00 Have a great sleep/morning. 03:31:05 because when i look at my local file, it does NOT match that one.. 03:37:16 but the brain says.. tackle this tomorrow.. thanks for the help ek 03:37:22 gives me a challenge tomorrow 03:38:50 voy4g3r2: Of course! What isn't matching? The version? 03:39:19 the SHA256 and SIZE for the 2nd entry 03:39:53 wait a secon.. now it does 03:39:54 i swear 03:40:09 voy4g3r2: You're saying your ports doesn't match the 3.11.15 entry for the makesum? 03:40:20 that is what it was.. 03:40:32 i have it running again.. if i wake up and this is still being an issue.. ill look at 03:58:55 forgive my ignorance, but does the fact that efibootmgr returns anything indicate im using efi booting? as opposed to the old bios way? 03:59:24 linux install it asked me grub or systemd-boot but freebsd just breezed thru 04:00:21 for some reason getting i have less confidence getting answers from web search about freebsd 04:00:45 i really should read the handbook 04:01:36 ive always assumed its outdated, thats a bad attitude i think 04:39:40 Does anyone know when firefox will be in pkgs again? 04:52:29 It's there for all except 14 latest 05:10:54 It's not unusual for pkgs to fail during a build and then need a fix and build again. It's a little tricky though to decode the build machine status in order to figure out exactly what happened. 05:32:59 polarian: I don't use the edk-bhyve package, not sure what it's for. Looks like you're getting an AMD issue there 07:30:38 hm https://portsfallout.com/fallout?port=www%2Ffirefox%24 extract/timeout so probably it gets build next time 07:31:48 rwp: nimaje: thanks 07:45:33 elivoncoder: if it shows BootCurrent: then you should be booted via uefi 08:03:50 imm_, freshports didn't have information earlier but the builder has progressed far enough that now freshports has a build matrix on firefox. https://www.freshports.org/www/firefox/ 08:04:15 For 14:latest only aarch64 has a build done. The others are still pending. 08:28:35 rwp: yes, I saw that quarterly has it built, but not latest, so something probably failed 08:28:47 Or is ongoing 08:36:21 my guees from the extract/timeout would be that the system did too much in parallel at that time and on the next bulk it should build fine, but I haven't looked into the log nor have I access to other monitoring of the builders to confirm my guess 10:01:28 polarian: scratch that, I *do* have edk2-bhyve installed 10:01:43 and it just got upgraded too 10:09:58 Hmm, llvm22 seems to be missing C++23 modules support i.e. libc++.modules.json is missing. Thatis mildly annoying. 10:10:54 Actually, llvm22 seems to gave been built to use system libc++ 10:11:33 That...sort of defeats the purpose. 10:12:39 There are more modern libc++ in pkgs, but only for wasm. How odd. 11:28:38 elivoncoder: use `sysctl machdep.bootmethod` to see how the system booted 11:41:11 ah, I should have used --ignore-case with sysctl -a | grep efi … 12:31:29 hello everyone, i am experiencing a checksum error with the most current python311 package, based on freshports metdata, and when i run the build I am receiving a checksum error. I looked at distinfo files and says it should match but when the poudriere environment runs i get this: https://pastebin.com/az8b401G my brain is telling me it NOT a checksum issue but more of a downloading issue. Anyone have 12:31:35 any tips to help confirm/deny this hypothesis 12:50:31 hm, seems like the patches didn't get redownloaded after the re-roll, can you move them out of distdir and try again? 13:18:15 i should be able to, let me see where they are 13:25:15 i did a distclean, lets see if that works.. i honestly thought it would rebuild EVERYTHING from teh ports tree, thanks nimaje 13:31:30 seems like in the fetch phase it just sees, that a file with the correct file name exists and then skips fetching without checking that the file has the correct checksum and later in the checksum phase it notices the wrong checksum and doesn't try to redownload as poudriere sets a variable do disable redownloading in checksum phase. I would say that is a bug in make fetch as it doesn't verify 13:31:32 files that are already there 13:33:58 hrm.. failed again 13:34:34 i got to be doing some step wrong 13:58:25 as you moved the old file away, it should have been redownloaded now, can you compare the two versions? 15:33:34 voy4g3r2: its a rebuild, nothing major 15:33:40 the update that is 15:33:48 The latest version change was in Jan iirc 15:33:56 I will do some more testing shortly 15:54:51 For the past there days I've had a kernel panic a day. One in the middle of the day (I believe the machine was idle) then the next two I believe during periodic daily. The backtrace is something DRM related but from the cases I seen it might not the real cause but maybe zfs. 15:54:53 https://gist.github.com/derekschrock/42e8f4b7e8445e048d6ebdaf3ed28491 15:55:06 Anyone seen something like this before? 15:55:33 I tried to just run daily by hand and it ran without issue this morning. 15:55:55 Scrubing all zfs pools were fine as well. 15:56:55 Nothing interesting leading up to the set of message ~21:00pm ~3am... 15:57:31 What version? Have you run memtest recently? 15:57:54 14.4-p5 15:58:03 boru: I haven't but that's a good idea. 15:58:06 polarian: i am not following? you are the author of this freshports entry? 15:58:22 Ran it when I first got all the RAM for the machine. 15:58:45 Worth ruling that out. It's happened to me before. 15:59:10 Wonder how long a 64G run will be :( 15:59:28 voy4g3r2: sorry, I was meant to ping vortexx, tab completion (your nicks both start with vo) 16:08:34 skered: it will run as long as you let it 16:09:52 rtprio: There's an end. 16:10:20 I've ran it over night on smaller systems and it's "done" the next with (without errors). 16:38:36 But I think in all cases it will be a long time. 17:00:18 voy4g3r2: How are providing the ports to Poudriere? Did you create a separate ports tree for Poudriere or are you using the host's /usr/ports or something? 17:01:34 What does "poudriere ports -l" show? 17:06:09 oi, does anyone use lagg0 to fallback from wifi to wired? and how does that work with a usb wired nic? is there devd secret sauce involved? 17:09:37 ek: I have a host 15.0 -> thick jail -> run poudriere within jail 17:09:51 the ports try is within the main jail and i ahve it under /usr/local/poduriere/ports/default 17:10:42 i manage the port, udpate, through this poudriere ports -u -p default -m git+https -B main 17:11:14 i intentionally isolate the poudriere environment from host, so no conflicts/confusions with my lackluster abilities to manage "issues" running poudriere 17:11:46 the kicker is, it is for one package.. llama.cpp which i need to have special build options because i have an intel i3 and the ports was built defaulting to xeon cpu and freature sets the i3 does not have 17:19:07 rtprio: for a lapto I presume 17:23:36 voy4g3r2: So, Poudriere actually uses jails to do all of its work. So, if you're running Poudriere in a jail, you're running a build jail inside of another jail. 17:24:06 It's not a problem. Just likely an unneeded step as Poudriere keeps everything separate from the host already. 17:24:32 I'm guessing the /usr/local/poudriere/ports/default is in the jail and not on the host? 17:29:31 Unneeded but easier to backup perhaps 17:29:59 skered, Your symptoms seem like a hardware problem to me. Probably failing a RAM DIMM. But also possibly something on the motherboard. I saw that you ran memtest on it. 17:30:04 skered, If it were me I would pull half the ram out and see if the problem persists or not. Either way note the result and swap to the other half of the ram and repeat the experiment. Hopefully it is simply a bad ram dimm. If the problem continues regardless of ram then likely it is a failing cpu or motherboard. 17:31:00 How did you write your second message in five seconds? :-o 17:33:18 I wrote it all at once, realized it was more than 400-some characters the limit of IRC where it would have split the line, split it manually into two messages where each made sense, then posted them one line after the other so that they would post together. 17:43:25 takacs: yep 17:44:13 stupid lenovo only has external/usb NICs so i'm assuming lagg would not care for getting jilted like that 17:44:42 rtprio: I use this, however none of my NIC's are usb. Used example 46 from this section. https://docs.freebsd.org/en/books/handbook/book/#network-aggregation 17:47:08 rtprio, the Lenovo Thunderbolt docking stations are pretty nifty and have an ethernet port. 17:53:02 rwp: I install a newer drm kmod too 17:53:16 See if I get the same thing tonight or sooner. 18:04:18 Good luck! 18:14:29 Lets hope 18:15:09 I'm getting hundreds of "pkg: getgrnam_r(wheel): Result too large" whenever I upgrade packages on a lot of systems. This also applies to systems running 15 and having quite recent packages installed, so there are only a few packages to upgrade. 18:15:14 Anyone else seeing this? 18:16:07 i ran pkg update/upgrade but dint see anything like that 18:16:26 That would likely be a local system dependent failure. getgrnam_r() searches the passwd/group database. Something corrupted there? 18:17:11 Maybe those databases need to be rebuild? pwd_mkdb? 18:17:12 Could be an out-of-sync world/kernel. Are you using pkgbase? 18:17:20 What does "freebsd-version -kru" show? 18:17:20 No, and I've had this issue for years 18:17:26 On many systems, not just one 18:17:37 I've never seen that error before. 18:17:58 I could easily have a problem on a lot of my systems where I have done the same configuration on all of them causing that systematic failure that only I would ever see. 18:18:20 rwp: We've all been there. 18:18:21 The only thing I can think of is that the 'wheel' group has a lot of members (few dozen) 18:18:24 Run this and see what it says: getent group wheel 18:18:29 But this is only supposed to return an integer 18:19:10 You might have exceeded the number of allowed members for a group. That would be systematic across all of your systems. 18:19:27 What/where is that limit? 18:19:53 Pick one system. Trim the wheel group down to just you. (Don't lock yourself out.) Then update. The error will likely not appear. Add back in members counting the number until it appears again. Then you will know where the limit is experimentally. 18:22:21 https://forums.freebsd.org/threads/group-file-line-too-long.55909/ - "In older implementations, a group cannot have more than 200 members. The 18:22:21 maximum line length of /etc/group is 1024 characters. Longer lines will 18:22:21 be skipped. This limitation disappeared in FreeBSD 3.0." 18:22:22 The "man 5 group" does not list any current limitations. 18:23:30 Perhaps it is one bad user configuration? 18:23:42 There are issues with that group line though, there are duplicate users in it 18:23:53 Wonder how I can fix that -- this is all puppet-managed, not manually 18:24:12 CrtxReavr: sure, they have an ethernet port, but as soon as i pull it out of the docking station the nic dissapears 18:24:19 so what does lagg do when that happens 18:25:30 But yea, number of users seems to be a problem here 18:25:39 Unsure. . . but I don't know why you'd try to use lagg with a single ethernet port. 18:29:13 But yea, number of users seems to be a problem here 18:29:30 ~61 users, or ~500 characters, not sure which is triggering 18:29:52 But so far pkg is the only tool reporting it 18:30:21 (gotta go, back in a bit) 18:30:24 What does this say? Errors? Or works normally? getent group wheel 18:30:48 getent returns the user list, complete, with no complaints 18:31:00 And in any other situation it works - these people are able to sudo etc. 18:31:49 I was hoping getent group would report an error which would make it easier to debug. But, oh well, something is going on. Maybe use truss to trace through a pkg ugprade and see what system call fails? Anyway... Later! 18:31:58 And also good luck! 18:35:01 I guess this company just grew too large. ;) 18:36:18 You said there's duplicates in the group line? 18:38:31 rtprio: lagg would need both nics to be present. But using the config I posted earlier, when the master interface loses connectivity lagg will fail over to the addtiional interface. 18:39:35 ok, so then lagg wouldn't work in this case 18:39:39 it sounds like 18:40:19 Sounds like the concern is what happens when the interface just disapears? 18:40:31 which it does when i unplug from the docking station 18:41:36 Yeah, I can't say that I have that scenario 18:44:14 My nic is removeable though, I could test. 18:44:24 i suppose i could try it 18:45:01 I would hope that when lagg loose the active nic, it would just fail over. 18:46:58 ek: not any longer. Didn't help. 18:49:23 Ltning: I wouldn't think 60-ish users in a group would be an issue anyway. 18:51:46 Just as a test, what happens if you remove everyone but you from the wheel group? 18:51:52 rtprio, have you looked at lagg(4)? 18:52:08 I know you said it was Puppet maintained so it'll be replaced at some point, I would assume. 18:52:14 But, a quick test should be doable. 18:55:22 nothing about the interface going missing, just the interface going down 18:55:28 as i recall 19:00:03 Give it a test? 19:25:41 I keep looking for `nvi` walkthroughs or reviews and I get neovim/vim stuff instead. 19:25:47 Sad 19:26:28 nvi isn't that different from vim, beyond vim's auto-formatting & syntax highlighting ability. 19:27:21 I alwys though of nvi has a bug-free version of the original Bill Joy vi, which had its share of quirky issues. 19:27:45 Like crashing if you made your terminal too wide. 19:29:23 ek: It works as long as I don't go past ~61 users or ~500 bytes -- It also works with just me in the list, as one would expect 19:30:16 wavefunction: Like CrtxReavr mentioned, it's basically the same as vi/ex. So, anything that works for those, should work for nvi. 19:30:24 In entirely other news: Holy *crap* the new iwlwifi/linuxkpi stuff in stable/15 is *awesome* 19:30:29 So, you can just follow an ex/vi walkthrough. 19:30:36 Ltning, you mean limitations with the actual /etc/group file? 19:31:23 CrtxReavr: Well - pkg (and the message I pasted above) is the only place it's a problem. The wheel group works fine for all its members for all other purposes - chiefly sudo 19:31:40 Ltning: Maybe request the Puppeteers to clean up the wheel group? I'm not sure why that many people would need to be in wheel, but it may be required. 19:31:46 There used to be a port called vilearn - it had five lession to vi comfort - was actually quite decent. You can prolly find a version of it archived somewhere. 19:32:16 Also, if you can submit a PR to bugzilla regarding this issue, perhaps someone can take a look and update FBSD to fix this as it should be a non-issue at this point. 19:32:57 Could also grand sudo access to groups other than wheel. 19:33:40 CrtxReavr: Yeah. That's kind of my thought. But, it might not be sudo-related at all. I have no idea why they want so many users in the wheel group. 19:33:46 Could be something completely unrelated. 19:34:48 Regardless, a limitation of 61 users in the wheel (or maybe any?) group seems... not right. 19:35:10 Yea it's got nothing to do with sudo per se, it was just the easy way to manage these users. A lot of files/dirs are only accessible to people in the wheel group, and the same users also need sudo access, so ... 19:35:39 I'll happily discuss our choices here, but you bring the beer. ;) Fact is getgrnam_r(wheel) should not fail like this. 19:36:02 Ltning: Makes sense. Personally, I wouldn't use the wheel group for this. But, it is what it is. 19:36:08 Please submit a PR. 19:36:16 I will once I dug a bit more. 19:36:27 Excellent! 19:36:52 Shouldn't truss -f show the actual invocation of getgrnam_r ? Because all I see is a geteuid() followed by opening /etc/spwd.db and /etc/group, after which it write()'s this error message. 19:37:39 https://pastes.io/eggM3DoX 19:38:16 wavefunction, I think you can figure out how to make it work: https://bpa.st/A5YA 19:42:50 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295672 19:50:03 wavefunction, it was actually stupidly easy: https://bpa.st/6ZBQ 19:53:17 Sorry, thank you ek and CrtxReavr -- I _know_ vim and use it regularly. It's just that there are clear vim-isms in my brain. :-D 19:53:27 Where does one get `vilearn`? 19:53:54 wavefunction, the first link I pasted literally shows you how and where I got it. 20:16:29 CrtxReavr: -facepalm- I pulled up your second link first. My bad. 20:22:41 hi everyone, I have an app of mine that freezes completely on my FreeBSD server. Completely stops exporting metrics, the http socket sends back "broken pipe", and then after half an hour or so, it goes back to life. 20:23:13 I have limited knowledge about how to debug such things, and I'm wondering if learning DTrace probes would be good? Or would they not report anyting useful perhaps? 20:23:46 I'm quite lost regarding this, I've been a happy FreeBSD tourist for some years now, but it's my first obscure failure mode that I experience while on the platform :) 20:33:14 If you know it only happens after at least a half hour, start an strace at ~20mins in and write to a file (as a first approximation)? 20:34:01 or maybe the better question is, Hecate, can you still access the machine while the app is frozen? 20:51:32 wavefunction: yes absolutely. ssh, btop, tmux, nginx, postgresql, varnish 20:51:42 everything is A-OK except for this godforsaken application 20:52:21 wavefunction: the freeze happens for 30mn, I have to see a bit more if there is any regularity to it. 20:52:31 but I'll keep strace in mind ok 20:54:17 wavefunction: this is what the metrics look like: https://i.imgur.com/wk1cQfs.png 21:26:10 ek: sorry for dleay work got the best of me.. yes the /usr/local/poudriere/ports/default is inside the jail and agree it is just another layer of abstraction.. probably not ncessary but helps me focus on the particular focus and not muddy the waters in my brain.. and server 21:41:56 voy4g3r2: No problem. Just trying to get to the bottom of why your Poudriere ports tree seems to differ from what it should be using. 21:43:25 If you're inside the jail (jexec), what does "git -C /usr/local/poudriere/ports/default log -1" show? 21:46:09 the openbabel from wednesday 21:46:17 i have NOT updated the ports tree since we talked yesterday 21:48:52 part of me wonders if i should blow away the whole tree and rebuild it 21:49:16 it makes no sense, especially when i see the commit and shows the "right" thing 21:53:02 made a new tree.. kept default around and lets see what happens :) 21:54:39 well same result.. son of a gun 21:58:15 voy4g3r2: How did you create the new tree? 22:14:39 poudriere ports -c p HEAD 22:14:43 poudriere ports -c -p HEAD 22:35:03 voy4g3r2: So, that new tree should be in /usr/local/poudriere/ports/HEAD, correct? 22:35:34 If you run a "git -C /usr/local/poudriere/ports/HEAD pull" what happens? 22:36:09 Does the port you're trying to work with look correct in that tree? 22:41:53 Hecate: What application is this? 22:57:09 ek: yes that location is correct and when i just did a pull.. i got a few updates: rabbitmq, pluma-plugin, engrampa 22:57:46 Should I save the OS from Ironport devices I just got? It's freebsd with custom software on top 23:00:53 voy4g3r2: So, now, if you run a "poudriere bulk -b latest -j jail-name -p HEAD -f /usr/local/etc/poudriere.d/list-of-ports" what happens? 23:01:21 i do somewhat of a similar command 23:01:25 Obviously changing "jail-name" to the jail you'd like to use and "list-of-ports" to a file with a list of the ports you're trying to build. 23:01:40 i will run poudriere bulk -j 150Ramd64 -p HEAD -c misc/ggml misc/llama-cpp 23:02:12 it is my understanding it will rebuild ALL packages because the -c makes it happen 23:02:24 HEAD is the tree i just made 23:02:51 ohh i did myself a disservice.. -b i do not have that 23:04:07 Sure. That should work. The "-c" just cleans all the previous stuff out. Shouldn't be a problem. 23:04:55 And, yes, "-b latest" helps quite a bit if you don't absolutely have to build everything from ports. 23:05:10 On big builds, it saves me a couple hours. 23:05:16 oh wow.. yeah it just downloaed a bunch of "stuff" 23:05:39 well it is running.. fingers crossed 23:05:43 Ltning, truss traces system calls but getgrnam_r() is a function call. Different layer. 23:11:00 Yeah I realised too