00:02:00 correction: location is /usr/local/jails/classic and the command I'm running is chflags -R 0 /usr/local/jails/classic. 00:04:13 tp512: does it come up in dmesg / usbconfig ? 00:05:12 nevermnind, I've been staring at this for too long... I got it figured out. location is /usr/local/jails/containers/classic. all is good 00:11:34 rtprio: in dmesg it shows up as ugen1.3: at usbus1 00:11:53 I could check usbconfig, but presumably it will show up, dunno how much useful information it might have 00:12:24 it's just the message about it being registered on the bus, no messages from a driver loading and configuring the device 00:12:25 that means there's no driver for it, 00:12:41 unless sdl is smart enough to use it as is, which i doubt 00:15:10 well as-is, SDL just doesn't recognize it. honestly pretty disappointing, I had just assumed this is something FreeBSD would have support for by now 00:15:39 especially since PS4 and PS5 controllers appear to work 00:17:44 unless a developer fancied a game of tuxracer and took the effort to do it, thre's no reason to think that it would work 00:19:44 stop assuming that everything works, just because it happens to work on linux 00:23:36 well it was an assumption based on the fact that 360 controllers work, and that NetBSD already has support in their driver. I guess NetBSD shouldn't really be used as an indicator, but I don't really expect it to have better support than FreeBSD for anything from like the last decade 00:24:02 for vintage hardware, sure 00:24:25 you can check, it might be as easy as just adding the device identifier to the xbox driver 00:24:31 or it might be a whole new driver 00:25:45 I'm going to look at their driver. I *think* I tested with my 360 controller on NetBSD as well and it loaded the same driver as it did for the Series X|S controller, though this was months ago 00:26:19 unfortunately my 360 controller is out of commission or I'd just use it 00:27:10 needs to have the cable replaced, at the very least, and I don't have any soldering equipment. probably not a tough repair if I got that set up 00:31:27 NetBSD's anonhg sure is sluggish, bleh 00:36:04 so the driver is uhidev, uhidev_match gives the exact same return value for XInput controllers and Xbox One controllers, promising sign that maybe it's a really simple change to add support 01:19:14 tp512: i've never found 360 controllers very comfortable but maybe it's just me. i had problems using the dpad on them so stopped using them. 01:20:50 the d-pad is really the only thing I actively dislike on the 360 controller, but they improved that quite a bit on the Xbox One and Series S|X controllers 01:21:29 the d-pad on these has like microswitches for the buttons, it's not just a mushy disc like the 360's 01:23:00 is the software interface still based on the 360? 01:23:13 i was never really clear how joysticks were implemented as hardware devices 01:24:30 I don't really know the details either, it seems like NetBSD at least is using the old code for the newer controllers, just adding the new device IDs to get the driver to associate with the controllers 01:46:20 I am running latest for packages and I would like to take snapshots before upgrading them. It looks like there is a separate default zfs dataset for /usr. Should I snapshot this dataset? All packages installed by pkg go into /usr/local right? 01:48:03 the /usr dataset isn't actually mounted, it only exists for /usr/ports and /usr/src 01:48:31 had to have that cleared up for me like last month, heh 01:49:00 oh, so then I should snap zroot/ROOT? 01:49:18 zroot/ROOT/default I think actually 01:49:34 yes, though I might suggest using boot environments 01:50:35 I've just been creating BEs to make bootable snapshots of the system state before I run OS upgrades 01:58:41 tp512 https://forums.freebsd.org/threads/updating-freebsd-with-zfs-boot-environments-beadm.84866/ is this a good starting point? 01:58:42 Title: Updating FreeBSD With ZFS Boot Environments (beadm) | The FreeBSD Forums 02:06:22 you don't really need beadm, the base system comes with bectl 02:07:26 but other than that, basically seems like the process I'm using 02:07:45 yes I see that freebsd-update/upgrade is creating boot environments already 02:08:25 so I can manually create a new boot environment with bectl? 02:10:07 I don't know anything about freebsd-update creating BEs, I haven't run -RELEASE in like a decade 02:10:22 oh you're on CURRENT? 02:10:36 but yeah, you can manage BEs manually with bectl 02:10:52 I run STABLE any time I use FreeBSD, basically 02:11:15 STABLE is CURRENT merges after they are deemed "stable", I was just reading about that I think 02:11:34 sort of like gentoo's stable policy after packages pass testing/certain time period? 02:12:22 CURRENT is the main (aka "master") branch, each release series gets its own stable branch, and yeah some stuff is pulled back from main to stable 02:12:46 right, and then STABLE eventually becomes the next RELEASE? 02:15:54 the releng branches are where RELEASE versions come from. I don't know the exact relationship between the stable branches and corresponding releng branches 02:16:45 no prob, I am probably close to the right answer, I'd imagine stable factors in somewhere 02:18:30 like I'm guessing releng is branched off of stable, but someone more familiar with release engineering would have to chime in 03:12:50 so, system has been stable all day on drm-510-kmod. pretty sure drm-515-kmod's amdgpu.ko was causing page faults 03:14:26 hopefully the LinuxKPI stuff from CURRENT gets brought back into STABLE so that drm-61-kmod can be used, I'd kinda like to test with that 03:24:16 tp512: my understanding is there is CURRENT which is the current version and periodically branches off the trunk are made ("releng") which are numbered 10,11,12,13,... 03:24:54 so you would have e.g. 10.0, 10.1, 10.2, then on the 11 branch 11.1, 11.2, etc. STABLE refers to the latest version on one of those branches. so 13-stable would be the next version of 13 03:26:26 so in git the branch tag would say stable/10 or stable/13 and the build name would be like FreeBSD 10.1-STABLE 03:29:41 but releng/14.1 would be branched from stable/14, I presume, basically freezing the state of that point of the stable/14 branch and only pulling down stuff like bug fixes? 03:30:16 no it's the other way. releng release refers to the initial 14.0 release. then stable is the "latest" 14 up to that point 03:30:45 I'm not talking about 14.0 03:31:12 oh i see releng is used as a tag for all the releases on a branch 03:31:17 each point release has its own releng branch 03:32:08 guessing the patched updates that get periodically released for RELEASE are developed on top of releng, pulling down like low risk commits from stable 03:32:14 right. CURRENT is the dev version of the main trunk. STABLE is the dev version of a given branch. like 10-STABLE 03:32:37 the terminology is weird because "stable" is actually development version 03:33:50 what I'm confused about is the initial .0 release, like were stable/14 and releng/14.0 created from the same commit on main? did one predate the other? 03:34:09 Yeah, but if you are just tracking the RELEASE, and not following STABLE - You are missing out on security patches for CVEs and the like aren't you? 03:34:40 release gets patched 03:34:44 SponiX: no, RELEASE is periodically updated 03:35:01 my understanding is releng/14.0 is created as a branch, then 14-stable is the dev version of that on that branch 03:35:20 so you'd have releng/14.0 -> 14-STABLE on the git tree. can someone tell me if i'm right 03:35:36 CowboyNeal: oh, this where they do like 13.1-p4 and stuff? 03:35:40 yeah 03:35:42 $ uname -r 03:35:44 14.0-RELEASE-p5 03:35:51 Nice 03:35:59 patches can be pushed backwards from CURRENT or STABLE as well yes 03:36:05 i'm not sure how it works exactly 03:36:07 Sorry for the ignorance. I haven't actually played with FreeBSD in a decade or so 03:36:40 I'm basing what I said off the Lucas book and it is fairly current 03:37:35 hmm 2018 07:55:44 johnjaye: almost but not quite 07:56:09 14-STABLE is the branch that 14.0-RELEASE is created from. 07:56:40 typically patches go to CURRENT branch (actually called main in git) and stew for a few days 07:56:43 or weeks 07:57:17 and then these are moved (often called MFC, or Move From Current) into the STABLE branches for each supported release train 07:57:25 13-STABLE and 14-STABLE 07:57:41 these are called STABLE because the ABI should be ... stable .... over time 07:57:50 what I'm wondering about personally is whether the stable branch shows up before or after the release engineering for the next major release 07:58:04 like at what point in the process will stable/15 be branched 07:58:04 thus you should always be able to build/run 14.0-RELEASE ports and packages on a 14-STABLE kernel if you want 07:59:24 the official release branches are named releng/ e.g. releng/13.3 releng/13.2 07:59:51 and any FreeBSD 13.2-p4 patches are landed explicitly on those branches only by re@ or security@ teams 08:00:16 so: CURRENT -> STABLE-x -> releng/x.y 08:03:34 so even in the alpha/beta/RC stages of a new major release, is there still things filtering through a stable branch forked off from main? 08:04:56 tp512: new 15.0-RELEASE appears in accordance with this policy https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html 08:04:57 Title: [FreeBSD-Announce] Changes to the FreeBSD Support Model 08:05:02 "A new stable/ branch release will not occur before two years after the X.0-RELEASE from the prior branch" 08:05:53 tp512: sort of. it starts off quite loose, and gets "slushier" as we get closer to a release 08:06:42 tp512: oh I misread your question. Yes, stuff is MFC'd all the time from current->stable branches. 08:06:50 you can see this atm as 13.3 was released just a week ago 08:07:22 e.g. commits on 13-stable https://cgit.freebsd.org/src/log/?h=stable/13 08:07:26 Title: src - FreeBSD source tree 08:13:49 dch: what I mean isn't current to stable merges, but like, what happens with releng/x.0, does stable/x start at the exact same point to serve as an upstream of releng/x.0? or does stable/x not exist until after x.0-RELEASE is out 08:14:06 tp512: aah right 08:14:15 so:we start with CURRENT 08:14:19 we start with CURRENT 08:14:27 then 15-STABLE would be created 08:14:35 and CURRENT becomes the new 16-CURRENT 08:14:40 then we want a release 08:16:13 so releng/15.0 is created off 15-STABLE 08:16:38 and we do the alpha -> beta -> rc -> release -> patches dance 08:16:44 see https://www.freebsd.org/releases/13.0R/schedule/ for a concrete example 08:16:45 Title: FreeBSD 13.0 Release Process | The FreeBSD Project 08:17:23 so stable/x exists first and is the branch that specific releases for releng/x.y will be taken from 08:17:54 kinda just seems like releng/15.0 and stable/15 would be redundant during those very early phases, having trouble thinking of what differences they'd have 08:18:10 like what changes to STABLE at that point wouldn't make it into the 15.0 release 08:19:54 unless the releng branch is just to slow things down, add an extra barrier for things that could make it into stable but might not be fully ready until the .1 release 08:20:09 tp512: I think in practice you're correct. 08:20:26 as the release moves towards completion, requests to move from the stable branch (where committers can just push), to the releng/x.y branch (where committers need explicit approval from re@ ) need a progressively higher bar to go ahead 08:21:01 and eventually it's like unless this breaks something critical like boot process for everybody, then the release goes ahead 08:21:36 and your patches either go through an Errata process and an official -p0 patch, or you wait for the next minor release 08:22:07 makes sense reading the 13.0 release schedule 08:22:08 its helpful to have the same process for all releases 08:22:51 and after, say, 15.0-RELEASE, releng/15.0 will become the branch from which patches are released? 08:23:11 yes, for 15.0-RELEASE-p0...pX 08:23:28 so following the releng branch would end up getting the same things that get bundled into the next patch 08:23:45 unless something manages to get through that does need to be reverted 08:24:13 tp512: yes. releng/x.y is *exactly* x.y-RELEASE-pZ 08:25:35 see https://cgit.freebsd.org/src/log/?h=releng/14.0&showmsg=1 for example 08:25:40 Title: src - FreeBSD source tree 08:29:11 seems like overall this is similar to how NetBSD does things except they don't seem to use releng branches at all, but on my one NetBSD machine I'm using what's effectively the 10-stable branch, though the builds get labeled as RCs since that's the phase 10.0 release engineering is in 08:30:16 like the stable branch effectively serves the same function as releng leading up to a point release 08:33:00 https://decmini.com/ can take a latte panda (intel's take on rasbpi size system) https://www.dfrobot.com/product-2594.html?tracking=62f46c260c041 08:33:01 Title: DEC Mini, a lovely 3D-printable retro computer 08:33:14 my birthday is coming up, I DESERVE THESE TOYS 08:33:38 kinda wish they'd incorporate LinuxKPI. 10.0 isn't even out yet and it's gonna be stuck on DRM drivers from Linux 5.6. if you want newer ones during the lifetime of 10.x you'd have to use current after new drivers get merged 08:35:19 with FreeBSD I like how the drivers are modular and allows for new ones to show up through a release series 08:37:12 oh huh so releng/14.0 isn't even a trickle of commits, they're merged in batches when the patch releases are to be pushed out? 08:41:21 yep you commit to 14-stable then beg re@ for approval, and when a sufficiently urgent patch arrives, the batch will be released 09:24:28 I gotta get bluetooth audio up and running at some point. plugging my laptop into this bluetooth speaker through the aux input while also charging the speaker through the laptop, I guess it forms some kind of ground loop? 09:25:04 I hear whining and hissing from the speaker 09:45:18 ugh thats bad yeah 09:45:21 the 50Hz whine? 09:50:38 well, 60Hz mains here, but the whine is regardless of whether I'm plugged in to AC 09:52:39 might not be a loop, maybe the noise is just going away when I unplug it from the speaker, because it mutes when it isn't plugged in. could just be a normal case of poorly isolated power components 09:56:57 like a case of the power signal coming over the USB cable getting into the amp's input 10:17:00 these archives do not show everything that is happening on this list https://lists.freebsd.org/archives/freebsd-jail/ is there another place with complete and uptodate archives? thanks! 10:17:01 Title: freebsd-jail⊙Fo 10:30:17 nevermind, I was looking at the wrong month I think, carry on :) 13:28:06 Trying to find which man-page I can read about the parameters mentioned in this thread; https://forums.freebsd.org/threads/resource-limits-for-jails.73187/ 13:28:07 Title: Resource limits for jails | The FreeBSD Forums 13:29:06 for example rctl -a jail::vmemoryuse:deny=512M <- the parameter/setting vmemoryuse. Where do you guys find the list of settings. 13:32:23 drobban: you can also get rctl to show current resource limits 13:33:06 drobban: in rctl(8) 13:33:22 thx nimaje 13:33:32 tykling: interesting. 13:34:27 drobban: so you can just run "sudo rctl -hu jail:1" where 1 is a jail id 13:34:40 I said limits above, I meant usage 13:35:55 nice tip. this is kinda cool to be able to control resources for every jail 13:37:02 yes it is fantastic 13:38:17 hum. pcpu is interesting, but is there a way to limit number of cpu-cores used? doesnt seem to be the case. 13:38:57 on the other hand. the percentage could just be adjusted to get on equivalent levels. 13:39:08 *I guess* 14:49:28 Testing Testing 14:49:34 ok i think its on wow 16:54:34 dch: so if i were to try and restate what I said. the stable branch is created and then the 15.0-RELEASE is a leaf budding from that branch 16:55:23 moreover as it is built up to release you need more and more permission from the team to add things to 15.0-RELEASE. then finally it is released. so you have 16-CURRENT, then 15.0-RELEASE on its branch with STABLE being the development "growing" along that branch 16:56:07 and due to the definitions you can always build 15.0 ports and use them without changes on 15.x leafs in the future 17:01:53 what pw useradd settings do i need for a user that won't get a pass and can only ssh in with a key in .ssh/authorized_keys 17:02:17 just -w no, then put key in authorized file? 17:02:36 because man page says -w no disables login 17:02:44 so that's prolly wrong 17:05:22 alepzi, Is it practical for you to configure ssh to disable all passwords and only use ssh keys? Setting "PasswordAuthentication no" in /etc/ssh/sshd_config file? 17:06:01 got that already 17:06:43 kbdinteractiveauth is no too 17:06:51 In that case all passwords will be blocked, unless they can get physical access to the system. Unless some access other than ssh is installed. (ftpd, telnetd, other) 17:06:52 just wondering the right pw useradd settings 17:07:15 but why set a pass at all if i only wanna allow auth via ssh key? 17:08:02 One thing that annoys me about FreeBSD is that they use a password database account system rather than /etc/{passwd,group,shadow} files. It's simple with the use of the files. And I can remember how it works. But with pw I don't remember and always must read the documentation. 17:23:48 pw is just a utility, you can edit those files manually and use pwd_mkdb if you want, well using vipw is probably better, as you don't need to remember to run pwd_mkdb then 17:27:27 just tried leaving -w no in, NOT setting a pass, and i can still ssh in as long as the key is in authorized_keys 17:27:55 so the man page for pw is kinda incorrect. -w no doesn't disable login, it disables password auth 17:28:03 isn't login via ssh considered login? 18:09:07 johnjaye: yes exactly 18:17:18 alepzi: yes `pw usermod name -h -` will disable login as user via console, whilst still allowing ssh 18:17:45 alepzi: you can add additional controls in ssh as well, I like having both 19:20:35 hey dch, did you ever experiment with FreeBSD on hetzner? (I did in the end) - seemed OK, and was able to install in various ways. 19:23:55 I'm thinking to replace Debian with FreeBSD on hetzner, but haven't looked into that yet 19:30:37 giro - yeah, I've done it, it works! 19:31:42 I hope it shouldn't be complicated. Did you encounter any tricks? 20:17:54 I did a lot of weird things, crazy dd's in place, there were maybe three tutorials, and ultimately even though Hetzner claimed no FreeBSD support, there were FBSD images that I could use to attach and boot against. So, go figure, you can do it the easy way or the hard way, giro. :-) 20:36:01 dch so since the man page for pw is a lil misleading should it be fixed? 22:46:17 It has been a "long" time since my last freebsd upgrade. How long did it take to install all the base system after the first reboot? It has been more than 15 mins and I'm getting nervous of not seeing any output. I'm running htop on a different tmux screen and I see many "install -S -o 0 -g 0 -m 0444 d84414e3a6f52b9356690670dbda249d265d7a1c067aa67fe2ebe90e76281e1f ///usr/share/man/man5/ypldap.conf" 22:47:29 s2r, I spent a long time staring at my screen too. Better not to watch. Get up. Go for a walk. It will be done when you get back. That's the less stressful way. 22:48:22 libXdmcp-1.1.5 is broken on latest, is there a way to rollback to 1.1.3 without local backup 22:48:23 ? 22:49:38 Are you installing binary pkgs? Look in /var/cache/pkg for /var/cache/pkg/libXdmcp-1.1.3.pkg pointing to the previously installed still cached package. 22:50:13 yes but accidentally clean ... 22:50:49 Do you have any other systems that you can look around to see if they have it available for you? 22:50:54 rwp it finished. 22:51:23 ho perhaps my laptop 22:51:31 * Teraii is seeing ... 22:52:08 Teraii, https://bsd.to/e6Gg/raw 22:52:09 Title: e6Gg 22:52:11 * Teraii using cygwin xorg :p it's very slow 22:52:13 s2r, Yay! \o/ 22:52:42 Teraii, That's on my quarterly updated system btw... 22:52:57 libXdmcp-1.1.5.pkg -> libXdmcp-1.1.5~8a86b45642.pkg 22:53:01 etc 22:54:26 I value stability and therefore quarterly is more reliably stable and I'll see the latest updates on average 6 weeks later anyway. 22:54:52 Though I should spend time on the tip-of-the-spear and debug and file bug reports on latest to do my duty on the frontline too. 22:55:57 indeed 22:57:18 Teraii, Oh, I forgot to ask if you were on ZFS and if so if you had snapshots? 22:57:20 seems to be a recent lib because no version of this pkg is in my laptop 22:57:42 rwp, helas :) 22:58:35 but now all packages downloaded will be in backup 22:58:59 well no Xorg for a time 22:59:23 So, does "helas" mean yes or no there? And by your next I assume that the answer was no? 23:00:06 rwp, ho sorry "helas" => no 23:00:13 i'm sad 23:00:31 I mean helas might have meant hella good too. 23:00:47 is there a repo lately sync ? :) 23:00:53 And you have no snapshots either? 23:01:01 no 23:01:28 it's all my fault, i know 23:01:53 But you are still running Latest? Me shakes my head. Life! You get the test first and the lesson second! :-) 23:02:07 :) 23:02:32 Fortunately this is a pretty mild problem that will definitely sort itself out within a day or so in the worst case. So things could be worse. 23:02:44 yes 23:03:03 probably solved on next build 23:03:28 If you are interested in any of the files from my paste above I would make them available to you trivially on my web site tmp area. But I don't know if those quarterly pkgs are compatible with your Latest system. I don't know. But you could try the latest of them to see. 23:04:27 i think not 23:04:34 but good news :) 23:04:48 i have found a backup of the repo :) 23:05:03 Excellent! Backups are a good thing. 23:05:07 hope the file is not too old 23:05:16 multiple backup are better :p 23:05:21 +s 23:05:47 The backup rule is 3-2-1. At least 3 copies. On at least 2 different types of storage. At least 1 off site. 23:05:52 yes ! found ! 23:06:08 indeed :) 23:06:32 the first backup is broken but the second one is working :) 23:07:42 hoping my xorg work again 23:10:07 hum :( semm not 23:10:14 seam not 23:12:47 rolling back all other packages 23:24:09 ok issue found and corrected :) 23:24:31 the faulted pkg was : libxcb 23:24:54 last working version : libxcb-1.15_2.pkg 23:28:45 Glad to hear you are back up with X working again. And that you were able to diagnose the problem to the problem package. 23:29:09 Maybe make snapshots before upgrading next time? :-) 23:30:41 indeed, moved on my new X :) 23:30:59 yes allready added on my scripts ;) 23:31:17 my X seems to be faster than before :p 23:33:04 now the backup work exactly like my poudriere :p 23:33:49 only branch working are pushed in prod :p 23:36:08 rwp, thank you for moral support ;) 23:36:14 :-) 23:46:02 ChatGPT is unable to describe correctly what each option in "portmaster -adBG" stands for. 23:46:33 Gemini Advnaced is unable to do it either. 23:48:11 wow, the man page can probably describe it 23:48:56 I asked ChatGPT, "what option should I pass to portmaster on FreeBSD if I want it to do the same thing as "make rmconfig?" It responded, "To achieve the same effect as make rmconfig with portmaster on FreeBSD, you would use the --rmconfig option." 23:51:37 I told it, "Illegal option --rmconfig". It responded, "portmaster doesn't have a direct equivalent to make rmconfig. However, you can manually remove the configuration for a port by deleting its options directory under /var/db/ports." 23:52:14 ok, read the man page, unless you really enjoy being told the wrong things 23:54:13 Given the statistical nature of the LLMs, it seems consistent with the response to such a question will statistically likely to be "read the man page". Though it does seem one thing lacking about the current trendy LLMs is the lack of ability to say when they don't know something and to go elsewhere 23:58:54 I am reading the man page and still can't figure out what portmaster's equivalent to "make rmconfig" is.