00:28:55 ugh, compiling llvm with -j1... this is gonna be a while 00:30:24 Soni: you got ipv4 disabled? 00:30:51 alepzi: not yet 01:48:53 Soni: i wonder how much ram usage is cut when ipv4 is disabled. and i wonder if ipv6 traffic is any faster 01:49:45 personally? it's not about ram, but about (code) maintenance. unfortunately upstream doesn't see it that way. 01:50:05 what did upstream say? 02:05:36 I've tried googling to no avail, is there somewhere I should check for issues with specific hardware? My X260 works great with both FreeBSD and GhostBSD out of the box, but my screen brightness keys don't seem to be detected. xev is not recognizing them when pressed. 02:30:49 zoid, I don't have one so I can't test, but have you tried the "PMU" "keys" combo described in the devd.conf manual page, devd.conf(5)? 02:31:55 just wrote my first rc.d script, w00t! it works, i can start/stop the service, but for some reasonputting myservice_enable="YES" in /etc/rc.conf doesn't seem to start it automatically. any gotchas? it's in a jail if that matters. 02:32:09 grats 02:34:33 I've not tried that yet! I'll give it a look. 02:38:12 markmcb, going for the easy guess: does your script use the "nojail" keyword? 02:38:43 no, just shutdown 02:40:05 OK. Then I guess it's time to share your script in a pastebin, suitably redacted if it contains confidential or sensitive info. 02:42:00 V_PauAmma_V: here you go https://bsd.to/a6Qu 02:42:01 Title: dpaste/a6Qu (Plain Text) 02:47:14 I just found this in the logs "listen tcp 10.0.1.231:20181: bind: can't assign requested address" ... but I don't get that error when staring manually ... is there a dependency I should list to avoid that? 02:48:23 When you start it manually, is that within the jail or outside? 02:48:59 inside the jail 02:51:00 What assigns 10.0.1.231 to the jail? 02:51:12 i think i solved it adding -r to the list of daemon args 02:52:50 If that makes the problem go away, that's probably because there's a timing issue associated with that IP address assignment. 02:53:25 the IP is assigned by the host as with an epair+vnet config 02:54:39 i tried "REQUIRE: NETWORKING" in the rc script, but that didn't help 02:54:48 i agree, seems like a timing issue 02:55:37 looks like it fails once and starts on the second try, so it's a very narrow miss on timing 02:55:49 OK. We've reached the end of my ability to troubleshoot jail networking issues. :-( 02:56:29 no worries, at least it's working :) 02:57:46 To figure out what caused it if you feel inclined that way, I would suggest 2 things: 1- doublecheck your jail configuration, and 2- wait until someone more knowledgeable than me looks in and answers. 04:01:21 So, it is okay to run the latest git of the ports on FreeBSD 14 release-p6 ? 04:01:54 SponiX: yes, ports is supported on all currently supported freebsd releases 04:02:14 there are no release-specific branches 04:03:03 thanks for the reply 04:03:53 I'm tinkering with FreeBSD 14 in a VM. If I get good enough with it, I might do it as my Host OS eventually 05:13:38 Soni: what do you mean by "upstream doesn't see it that way"? -- freebsd has full support for building without IPv4 code in the system. it sounds like your issue is you don't have enough disk space to build it, which isn't really an upstream issue 05:29:07 we have a -INET4 LINT kernel that gets built regularly so that the option to rip it out doesn't break it, and at least one developer that actively refuses to build with ipv4 included last I checked 05:29:34 LINT-NOINET 05:31:21 kevans: i had to submit 4 patches yesterday to get main to build without INET so it may not be 100% tested at all times :-) 05:31:52 mjg usually complains when it breaks because it breaks tinderbox 05:31:52 i wanted to fix ipfw too, but that's a bit awkward because it uses an AF_INET socket for the user/kernel interface 05:31:55 pretty quickly 05:56:41 I saw there is signal-desktop. Anyone know if there is a Discord package for FreeBSD? 06:24:41 SponiX: i saw this mentioned on fediverse https://github.com/SrWither/DiscordBSD 06:24:43 Title: GitHub - SrWither/DiscordBSD: an attempt at a native discord client for FreeBSD 06:29:46 livestradamus: thanks.. looks promising 06:31:38 iirc discord official policy is kinda dick-ish against unsanctioned clients, so maybe be careful there 06:32:40 kevans: Yeah, I've heard that as well 06:33:02 I might just end up running it within the browser and calling that close enough\ 06:33:30 there isn't any real major advantages to having the electron client vs the browser anyway, from what I understand 06:33:47 Anyone running KDE Plasma 6? 06:43:28 SponiX: RE: electron app. Not for me since I can turn any URL into a launchable app 06:45:35 livestradamus: what method does that? 06:46:08 Can Chromium login with your Google account and sync passwords and so on? Like normal Chrome does (on Linux) ? 06:48:09 Is en-Googled-Chromium not available in The Ports? 06:58:28 is there a utility in the base system to format tabulated data nicely (in ASCII)? 07:43:36 I used to use cordless, It was a good client... either way, there's a telegram client on freebsd. its pretty good, even leaner than discord 07:45:37 lw: format? like column -t ? 07:47:03 nmz: yep, ty 07:49:55 people should use telegram more, the freebsd telegram channel for one is kinda empty, but there's people in it 07:59:06 the Foundation seems to have embraced Discord which is a bit disappointing, even though i understand it's probably because of the low barrier to entry 08:01:07 but... there's no application 08:01:11 for freebsd 08:01:26 I'm using it in chrome because gtkcord is lacking and uses a lot of resources 08:01:35 yeah, but the native 'app' is just the web app in an electron package anyway 08:01:58 not to mention you have to get the auth key from the browser and go into developer mode which is risky of termination of the user as well 10:21:40 lw: we believe freebsd would benefit from officially removing the ipv4 stack 10:23:55 Soni: that seems objectively false since many users still have only IPv4 connectivity. but from your point of view, how would that differ from simply compiling the system WITHOUT_INET? 10:25:01 lw: you don't have to break ipv4-only connectivity to go ipv6-only 10:26:48 since ppl are gonna run ipv6-only networks, then you need to maintain code to support setting up ipv6-only networks, in addition to maintaining an ipv4 stack. isn't that a waste of maintainer effort? you could instead do away with the ipv4 stack and support only the SIIT translation code, and that would be less code to maintain overall. 10:28:32 how is your FreeBSD router going to do SIIT when it doesn't have an IPv4 stack? you'd have to reimplement most of IPv4 inside ipfw or something to do the translation 10:34:34 Soni: but how would you then use freebsd if you have a ipv4-only network for some reason? (or just no ipv6 from your provider, so no internet without ipv4) 10:34:57 through "platd" 10:35:53 (a glorified raw socket that trivially translates ipv4 packets into the ipv6 world that ipv6-only freebsd can handle) 10:36:34 and that works with an ISP that only supports IPv4? 10:36:40 yes 10:37:23 so when dhclient gets an IPv4 address, what does it do with the address? 10:37:24 it's a bit awkward only having enough ipv6 to route the NAT64 prefix, but at least you'd only have a single ip stack, with all the benefits that comes with 10:38:07 dhclient would have to be integrated into "platd" - it needs to know when to attach/detach the NAT64 interface, and you can't send broadcast/multicast over NAT64 10:38:49 ok, and my Xyplex terminal server that only supports IPv4, how does that access the Internet through my IPv6-only router? 10:40:09 painfully 10:40:10 you also need to run a DHCPv4 server internally for devices like Google Chromecast that won't boot on an IPv6-only network, does platd handle that somehow? 10:48:52 Soni: "we believe freebsd would benefit from officially removing the ipv4 stack" This is a very delusional statement. 10:49:53 this would be a lot easier if there were a way to carry broadcast/multicast over nat64, as you could then just use a regular clat-in-libc with regular dhcpv4 tooling and whatnot 10:50:40 how does CLAT in libc help with IPv4-only hosts? 10:51:23 Every single server on the planet has IPv4, but far from all of them have IPv6. How are you supposed to interact with these servers in an immaginary "IPv6-only world"? 10:52:02 with SIIT 10:52:15 remiliascarlet: for servers it's actually pretty easy with 464XLAT (or SIIT or whatever). IPv4-only clients is the problem 10:52:45 a lot of widely-deployed devices, especially in IoT world, are still IPv4-only 10:52:46 "IPv4-only clients is the problem" Alright, good to know I'm the problem then. 10:53:14 ? by 'the problem' i mean 'the problem with running an IPv6-only network', that wasn't some kind of personal attack 10:53:28 My ISP doas supply IPv6 addresses on request, except their request form is forever broken. 10:53:41 s/doas/does 10:54:04 "that wasn't some kind of personal attack" I know, I was just joking. 10:54:30 if i was the only user on our network, i'd have gone IPv6-only years ago, but i have to support other users and they bring their own devices they want to use, i can't really just tell them to spend £££ on new devices because i prefer IPv6 10:56:36 (that said, i did try IPv6-only for a while and it *did* work pretty well... it was mostly the Chromecast that had issues with it, i think we might replace that at some point and i'll try again) 10:56:58 doesn't help that our router vendor (mikrotik) still doesn't support NAT64, but i'm going to replace that with a freebsd box anyway 10:57:21 My previous ISP had a way to request IPv6 addresses, but you had to install something from either App Store or Play Store in order to request, so I thought "fuck that shit!". 11:16:02 honestly we only just set up ipv6-only at home, it'll be a while before we get more going with it 11:16:43 are you familiar with ipv6-mostly? 11:16:57 (dhcp option 108 etc) 11:18:27 you only just deployed IPv6-only network and you already know it would be easier for all FreeBSD users to immediately turn off IPv4? :-) 11:19:17 lw: given our initial experience setting this up, yeah 11:19:33 this was a pain to set up 11:20:02 luckily that was only the initial setup 11:20:20 but yeah, we should make this easier 11:21:09 i'm fine with making ipv6-only networks easier to set up, i'm sure any patches to do that would be appreciated. but that's a whole different thing from removing ipv4 support entirely, which will break things for many, many users 11:21:38 i've actually been meaning to look at making freebsd understand PREF64 in RAs for client-side CLAT setup, like macOS does 11:22:13 (macOS is basically the only mainstream OS that does IPv6-only properly today... Windows only does CLAT on LTE connections for some bizarre reason) 11:26:07 and even macos doesn't support pref64 (at least the last time I checked) 11:26:37 satanist: it does now, it'll configure CLAT automatically if it sees PREF64 in RA 11:26:40 at least since 13.x 11:27:34 ah nice, need to check soon if this allows to disable dns64 (makes problems) 11:28:03 another problem is, pref64 support in routers is not that common 11:28:20 yeah, freebsd rtadvd doesn't support advertising it, that's another thing i've been meaning to fix 11:28:59 hopefully that one should be pretty simple 11:29:34 need to fix if_bridge not loading on a non-INET kernel first 11:33:26 lw: so how can we remove ipv4 without breaking things for many users? 11:33:59 Soni: you can't, because those users depend on IPv4. you can argue they should upgrade to IPv6... sure, i don't disagree. but in real world it's not that simple 11:34:17 Soni: but if *you personally* want to remove IPv4 code from the OS, you can do that, by building WITHOUT_INET 11:34:29 lw: we mean from the kernel, we're not trying to drop ipv4 networks altogether 11:34:45 (not yet anyway) 11:34:50 well, you need to present a solution that works for current users, including users with IPv4-only hosts 11:35:01 (tho we are trying to push for more ipv6 networks) 11:35:31 if you want to create "ipv4d" that provides IPv4 connectivity for IPv4-only hosts by bridging to SIIT or something, you could do that 11:35:47 lw: we believe "platd" would work fine for most freebsd clients 11:36:19 the hard part is routers 11:37:01 you mean clat (client) not plat (provider)? 11:37:16 no, clat is in libc 11:37:46 in freebsd? 11:38:39 satanist: Soni wants FreeBSD libc to do CLAT internally to support IPv4 apps on an IPv6-only host. which is not an unreasonable suggestion, if they wanted to write the code for it... 11:39:12 of course that won't help things like Go that don't use libc, but hopefully there aren't many IPv4-only Go apps around 11:39:31 lw: hasn't go moved to using libc on the BSDs finally? 11:39:33 i do think it makes more sense to implement that in the kernel though, so it just works for everything 11:39:41 i recall seeing it mentioned somewhere 11:39:52 dstolfa: idk, i saw something about that but isn't it just for some syscalls? 11:40:09 (is this why we got libsys?) 11:40:09 no idea, i just saw it mentioned in passing. honestly i don't really care about go 11:40:23 I just don't get why "platd" would work fine for most freebsd clients, on the ipv6-only-client doesn't run a platd 11:40:26 i don't either really but sadly i do have to use some Go stuff, like prometheus 11:41:58 for clat it would be nice to have something like ifconfig bla -clat $ipv4-addr $source $prefix 11:42:38 satanist: i've never tested it, but ipfw does support CLAT already 11:42:38 while $source can also be a prefix and it would do some privacy-extention 11:42:56 satanist: what i was hoping to do with PREF64 was have the prefix show up in ifconfig and then auto-configure ipfw using that somehow 11:43:04 satanist: you don't need an ipv4 stack to put ipv4 packets on the wire 11:44:03 yes of course, but this way it would be quite easy to addopt 11:44:59 Soni: you kind of do, because whatever is sending IPv4 packets *is* your IPv4 stack 11:45:09 if you do it in userland, it's still an ipv4 stack 11:45:14 and could be used to route packegs for clients which doesn't support v6 11:45:55 lw: is a SIIT an ipv4 stack 11:46:22 Soni: every SIIT implementation i'm aware of uses an existing IPv4 stack, yes 11:46:32 lw: well this one wouldn't 11:46:38 what is "this one"? 11:46:54 if you're sending IPv4 packets and doing IPv4 NAT... that *is* an IPv4 stack 11:47:00 the "platd"/"ipv4d" thing or whatever we end up calling it 11:47:18 the fact it's in userland and doesn't depend on kernel IPv6 doesn't mean it's not an IPv4 stack 11:47:31 nah we don't do ipv4 NAT, we use the ipv6 stack for port mapping 11:50:08 i really hate code like this 11:50:11 if (PFIL_HOOKED_OUT(V_inet_pfil_head) 11:50:12 #ifdef INET6 11:50:12 || PFIL_HOOKED_OUT(V_inet6_pfil_head) 11:50:12 #endif 11:50:12 ) { 11:50:45 what's the least worst way to convert this to work without #ifdef INET? like i could add a temporary variable, but... 11:53:13 ifdef INET, if defined(INET) && defined(INET6), ifdef INET6? 11:53:40 i don't like that much duplication of code 11:54:11 i think this is the least worst option https://www.le-fay.org/tmp/30d/eokPZC.txt 11:54:12 this only duplicates the define checks, not the code 11:54:16 lw: could add a macro that does "false" in the case where INET6 is not defined, and the condition if it is? 11:54:37 hmm 11:55:22 e.g. defined a macro INET6_HOOK_CHECK(...) which does different things based on INET6 being defined or not. same thing for INET 11:55:26 if they're not defined, it just does false 11:56:07 and then you can undef them after you no longer need them i guess 11:56:10 if you don't want them to escape the scope 11:56:33 dstolfa: do you really think two macros is easier than my proposed fix above? 11:57:02 lw: no, but i'm fine with what's currently there too, even though it's a bit icky :D 11:57:35 i'm not too fussed about these things unless it's my own code tbh 11:57:39 dstolfa: the issue with what's currently there is it breaks on a non-INET kernel 11:57:46 link_elf_obj: symbol vnet_entry_inet_pfil_head undefined 11:57:46 linker_load_file: /boot/kernel.LFV6/if_bridge.ko - unsupported file type 11:57:48 right, then it needs to be fixed :D 11:58:13 lw: i don't have an opinion on which one is better. was just offering an option without a variable 11:58:31 yeah, sure 11:59:28 dstolfa: i didn't mean that as a criticism, i'm just really not sure what the best fix is :-) 11:59:38 i think i'll just send this version and see what reviewers say 11:59:49 lw: no worries, i don't take code discussions personally :D 11:59:56 it's just code 12:01:05 oh funny, i just found it already does this: 12:01:09 #ifdef INET6 12:01:09 #define PFIL_HOOKED_INET6 PFIL_HOOKED_IN(V_inet6_pfil_head) 12:01:09 #else 12:01:09 #define PFIL_HOOKED_INET6 false 12:01:09 #endif 12:01:19 it's just not used consistently, maybe i'll do it like that instead 12:01:31 (and add the INET version) 12:06:32 the fuck is this https://cgit.freebsd.org/src/tree/sys/net/if_bridge.c#n2647 12:06:33 Title: if_bridge.c « net « sys - src - FreeBSD source tree 12:06:37 don't write code like this :-( 12:07:23 uh oh... doesn't even seem to be a generator of any form, should just be a function probably 12:07:35 wow 12:08:33 dstolfa: i guess someone 'refactored' it to add bpf support and just turned the whole thing into a macro instead of doing it properly... 12:19:05 if_bridge patch (cc dstolfa): https://github.com/freebsd/freebsd-src/pull/1159 ... tested to the extent that i can load if_bridge.ko and create a bridge 12:19:06 Title: sys/net/if_bridge: support non-INET kernels by llfw · Pull Request #1159 · freebsd/freebsd-src · GitHub 12:20:05 actually this is wrong because i mixed out HOOKED_IN and HOOKED_OUT 12:27:02 better patch up 12:57:59 jbo: any idea what's going on this this, i need to build it on arm64... if it's not likely to be committed i'll have to fork a local ports tree to include it https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276996 12:58:01 Title: 276996 – [NEW PORT] databases/postgres_exporter: PostgreSQL metric exporter for Prometheus 14:19:03 lw: stuff like https://cgit.freebsd.org/src/tree/sys/net/if_bridge.c#n2647 is why i'd never participate in open source C :) 14:19:04 Title: if_bridge.c « net « sys - src - FreeBSD source tree 14:20:01 SKull: yeah it made me o_O a bit but i'm sure other OSs have just as worse code... 14:20:40 writing my own OS from scratch is on my todo list but that might take a while 14:34:47 hey, do freebsd 14 has something i need to set, for me to be able to use /etc/jail.conf.d/jailname.conf as placeholder for jails? atm it only accepts /etc/jail.conf and wont see the conf i placed in jail.conf.d 14:55:12 Who's in the Bay Area? 15:02:40 CrtxReavr: Californians 15:02:58 * CrtxReavr kicks lw in the shins. 15:04:19 what's the company called that does FreeBSD stuff and begins with a 'k'? i thought it was Klara but that's some kind of credit provider 15:05:18 What do they sell? 15:05:33 i don't know, like... zfs stuff? or something? 15:06:14 oh, it is Klara 15:06:22 are there two companies with the same name? 15:06:30 Stranger things have happened. 15:26:46 lw: https://klarasystems.com/ 15:26:47 Title: Klara Inc | Open Source Development. Reimagined. 15:27:05 the other one you probably refer to is Klarna (.com) 15:27:36 ah right, the bnpl company is klarna 15:31:35 yeah, the linkedin people page reads like it's grown a good bit 15:32:04 * lw mails klara (not klarna) to beg for a job 15:33:22 AllanJude: which of the eight open positions has the highest priority for you at the moment? 15:53:11 probably the technical project manager, and then the com-rel role 16:27:43 so i just solved a problem i've been having with tmux. the default terminal "e.g., echo $TERM" is tmux-256color in tmux, but FreeBSD doesn't know what that is without terminfo-db installed. should that package be a dependency? i was breaking mouse functionality for me in tmux. not sure how i suggest a change. 16:38:17 I'd e-mail the tmux maintainer 16:40:42 will do 16:53:06 markmcb: yeah, I believe that's the best way (though tmux-256color seems to be in termcap on recent versions) 17:11:51 kevans: when you say recent, do you mean 14p.0p6, or something newer in stable/current? i'm on 14.0p6 17:32:09 current 17:32:12 maybe stable, haven't checked 17:44:17 Yet another reason why I stick to screen. 18:00:28 markmcb, I have tmux-256color in termcap in 13.2R okay. Perhaps the problem is that the termcap entry needs expansion to include a capability that is included in terminfo but not in termcap. 18:01:01 That would be the better solution. Improve the native termcap database. 18:02:01 rwp: maybe so, i'm not so well-versed in this stuff. whatever is missing breaks the tmux "send-keys -M" functionality to pass mouse events to apps in a tmux pane. i'm not sure what/where i'd report. 18:18:50 https://docs.freebsd.org/en/books/handbook/jails/#creating-vnet-jail in the "ADD TO bridge INTERFACE" part of the sample jail config, where do i set 'private' on the epair#a interface? 18:18:52 Title: Chapter 17. Jails and Containers | FreeBSD Documentation Portal 18:25:52 What's the best way to check if a CVE is handled by a freebsd security advisory? 18:26:25 The list of SAs on freebsd.org is not helpful if all I've got is a CVE .. 18:31:55 it seems optional to copy /etc/localtime into a jail so why do docs imply it's necessary? 22:25:41 Ltning, If you subscribe or download the https://www.freebsd.org/security/advisories/ mailbox then you can search the advisories for the CVE number and see what it says. Easier is the source. If you have the git source then you can search the git source for the CVE number. 22:25:42 Title: FreeBSD Security Advisories | The FreeBSD Project 22:38:45 do we need to worry about calcru: runtime went backwards 23:06:14 Soni: it's an issue with the CPU speed, usually called by Intel Speedstep. 23:06:49 Do you have powerd(xx)? running? 23:07:32 no idea, this is a VM 23:07:56 it kinda crashed for a bit (it paused because we ran out of host disk) 23:10:38 Then it's not registering itself properly as a VM, cf. https://cgit.freebsd.org/src/tree/sys/kern/kern_resource.c#n1018 23:10:39 Title: kern_resource.c « kern « sys - src - FreeBSD source tree 23:15:29 I'm specifically going off of https://cgit.freebsd.org/src/commit/sys/kern/kern_resource.c?id=bacb140f31a in making that guess, because otherwise your CPU is probably very fucked. 23:15:31 Title: src - FreeBSD source tree 23:17:20 Ltning: https://marc.info/?l=freebsd-security-notifications&r=1&w=2 23:17:22 Title: MARC: Mailing list ARChives 23:17:56 that'll search in the bodies of the mails sent to the security-notifications mailing list 23:36:51 rwp, debdrup: Yea, I got about that far myself, but it has just came to my attention that a reverse search (cve -> advisory) could make certain peoples jobs a lot easier. I can figure it out, but those people that receive "security testing reports" and need to respond don't necessarily want to search mailing lists or source code. 23:37:20 The nearest I got was vuxml, and for the time being the website can list all SAs by CVE, but that's inefficient and not scalable.. 23:37:45 Ltning: problem is, CVE isn't a universal identifier 23:37:57 (Then again, several of the public CVE databases link back to the advisories - but not always) 23:39:19 I mean, the real answer is that Someone(TM) uses AsciiDoc and/or the ruby scripting it offers to add the CVES from any .asc file that contains it. 23:40:10 Right now the openssh stuff from december or so is causing a fair bit of noise 23:40:19 Because a scan doesn't reveal that systems are update 23:40:21 +d