00:00:02 <RhodiumToad> (because POSIX says so)
00:00:40 <rwp> It used to be that POSIX was not a design by committee document but was instead a standardization of existing practice.  Basically an operating system feature nonproliferation treaty.
00:00:53 <sfox> I wasn't aware that I could have printing without cups.
00:00:59 <RhodiumToad> right, but in this case it standardized lp rather than lpr :-)
00:01:19 <xtile> The standards are mostly just a description of System V.
00:01:41 <sfox> RhodiumToad, I am
00:02:02 <sfox> but this printer works with standard subroutines built into computer's BIOSes
00:02:03 <rwp> sfox, Sure!  CUPS is the "new" (in the grand scheme of things) Apple dynamic configuration printing system.
00:02:07 <sfox> and works with DOS
00:02:27 <RhodiumToad> uh, no BIOS that I ever used had any printer support
00:02:44 <RhodiumToad> sfox: do you have an lpd process running?
00:03:00 <rwp> That BIOS comment throws my head into a tizzy too...
00:03:04 <sfox> RhodiumToad, it's called printscreen. it's what that button is supposed to do on PS/2 & compatibles
00:03:07 <RhodiumToad> sfox: and/or  lpd_enable="YES"  in /etc/rc.conf ?
00:03:11 <sfox> i did not
00:03:34 <sfox> thankyou, i will look into that
00:03:39 <rwp> PrintScreen is an OS feature not a BIOS feature.  Though in DOS it was usually a TSR terminate stay resident routine
00:03:46 <RhodiumToad> don't enable it if you weren't using it before
00:03:48 <sfox> is there any way to make the printer available over the network without cups too?
00:04:22 <RhodiumToad> lpd supports remote access as I recall, but it's ancient and useless with most modern printers
00:04:37 <xtile> Yes, I've done remote lpr/lp printing before with an HP printer, ages ago
00:04:43 <sfox> rwp I have a laptop here from which my friend wrote a bootsector hex editor for REAL mode. When you press printscreen button the printer goes to work.
00:04:46 <xtile> by ages I mean a couple years ago
00:05:16 <xtile> Never did non-remote printing with lpr or lp, actually
00:05:16 <RhodiumToad> sfox: that says nothing about how you're expecting the printer to work from within freebsd.
00:05:22 <xtile> only over the network
00:05:47 <rwp> sfox, Does it boot that program or is that program invoked from DOS?
00:06:11 <sfox> I was talking to rwp about the BIOS feature. rwp, it's booted from a raw floppy.
00:06:45 <rwp> Booted what exactly from a raw floppy?  DOS?  Probably.  I am thinking it is booting DR-DOS, MS-DOS, or FreeDOS from a floppy.
00:07:04 <sfox> the hex editor that was written in assembly
00:07:08 <sfox> in a bootsector
00:07:15 <RhodiumToad> it. doesn't. matter.
00:07:34 <RhodiumToad> how you use the printer in freebsd is not in any way related to how you use it in any other OS
00:08:13 <sfox> rwp we should probably take this to private message for further discussion on how it's implemented. I think it's annoying RhodiumToad
00:08:16 <rwp> Agreed.  It's OT here.  We should be in -social or something talking about museum pieces.
00:09:48 <polyex> seems like tracking latest pkgs isn't any less stable than quarterly because quarterly pkgs sometimes have problems too, and when latest pkgs have problems they get fixed faster. am i wrong?
00:10:43 <RhodiumToad> latest gets more updates
00:11:21 <RhodiumToad> this sometimes means that security fixes take longer because the latest package set is taking days to finish a build cycle
00:11:44 <polyex> security fixes sometimes hit quarterly sooner than latest?
00:12:02 <rwp> If it is a security problem then that will get fixed as an errata.  Or at least should.
00:12:43 <RhodiumToad> in terms of the package repo rather than the ports tree, the quarterly might or might not be faster, it's dependent on the build cycle
00:13:09 <rwp> Mostly there is nothing that I use daily that I want daily changes.  All of that ends up being wasteful thrash for me.  Disruptive to me.
00:14:17 <polyex> well my thing is i've run into broken (temporarily) packages on both quarterly and latest. but another problem i've had is quarterly packages taking a long time to get a version update i wanted. so it feels like latest is better than quarterly
00:14:30 <polyex> for me
00:15:24 <rwp> Can you give an example of a package that you use that you enjoy getting the daily changes?  No judgement here.  ykinmkbykiok.  Just curious.
00:16:01 <polyex> i didnt say anything about daily updates. when there's a new version of something i want, it obviously hits latest faster, rather than having to wait up to 3 months like on quarterly
00:16:16 <RhodiumToad> if you want control over what you get, then build your own repo
00:16:43 <polyex> ya i dont wanna do that. yet anyway
00:16:47 <RhodiumToad> otherwise if you want latest, then use latest
00:20:13 <xtile> I use quarterly but probably should switch to latest.  I trust software devs to know their own software best.
00:27:28 <polyex> my only concern about latest is with quarterly, i can provision a few servers over a few hours and know they all have the same or pretty close versions, but with latest a package could be updated in between those servers getting provisioned and end up with pretty different versions between them
00:27:42 <polyex> bit more of a moving target
00:28:04 <RhodiumToad> well yes
00:28:15 <RhodiumToad> if you want to avoid that you'd have to maintain your own repo
00:28:16 <rwp> Yes.  That is the way latest works.  Always in motion.
01:25:29 <sfox> I'd like to network my mail server over High Frequency radio, does FreeBSD still support UUCP?
01:28:40 <xtile> sfox: freebsd-uucp package
01:32:35 <sfox> thanks
07:45:55 <vkarlsen> I think that was way faster than rm: rsync -a --delete /empty/ /usr/ports/  0.30s user 3.84s system 5% cpu 1:18.47 total
07:53:48 <meena> oh, cool!
11:31:09 <debdrup> sfox: I hope for your sake nobody sends you a PGP encrypted email, or that your mail daemon isn't configured to support TLS or any form of encryption..
11:39:49 <tercaL> When having a PF rule in FreeBSD like "block in from no-route to any", should I remove the other line of mine related to that; nonrout = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4, 255.255.255.255/32 }" (and block in quick on $ext_if from $nonrout to any + block out quick on $ext_if from any to $nonrout) ? Does having "block in from no-route to any" do that all?
12:02:49 <V_PauAmma_V> I think they do different things. RFC1918 addresses (private/not globally routable) may still be reachable from your host, and public addresses may still be unreachable from your host.
15:53:18 <n-st> hi, i've got a freebsd installation that was forgotten for some time… can i freebsd-update -r it directly from 12.2 to 13.2, or do i need to take the/some intermediate steps too? (can't seem to find any mention of that in https://docs.freebsd.org/en/books/handbook/cutting-edge/)
16:08:57 <phryk> what's the version string for freebsd-update to upgrade to 14? 14-LATEST?
16:09:16 <yuripv> it's not supported
16:09:49 <yuripv> (and man page says that)
16:10:02 <nimaje> freebsd-update can only update to releases and CURRENT has no releases
16:14:05 <phryk> so, to upgrade i download and mount the boot image for 14, extract kernel and base.txz over my mounted system and reboot?
16:27:40 * yuripv eyes #271281
16:41:50 <meena> yuripv: that person seems angry
16:42:22 <meena> phryk: or else, build
16:46:19 <meena> (usually, at this point i would advertise my PkgBase repo, however, that's defunct)
17:21:13 <gzar> if i want to built-in a kernel module, do i put 'device linux' etc. in the kernconf ?
17:37:30 <trev> gzar: yeah. that's how i did it at least.
17:38:06 <gzar> alright, i'll try
17:39:05 <trev> gzar: not sure which arch you are on but this is the generic conf: https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/GENERIC
17:39:07 <VimDiesel> Title: freebsd-src/GENERIC at main · freebsd/freebsd-src · GitHub
17:39:30 <gzar> i know, i am modifying that one
17:39:56 <gzar> do i include the `options COMPAT_LINUX` or can i just leave it out
17:40:33 <trev> also this: https://man.freebsd.org/cgi/man.cgi?query=config&sektion=5&format=html
17:40:35 <VimDiesel> Title: config(5)
17:41:55 <gzar> thanks thats what i was looking for
17:41:56 <trev> gzar: it's already there in the generic one
17:43:31 <gzar> yeah but idk if its necessary if i am causing the module to be built-in
17:43:33 <nimaje> (the question read to me like compiled in linux support is wanted, instead of the default of a loadable kernel module)
17:43:44 <gzar> yes exactly
17:44:43 <trev> ah yes, sorry.
17:44:51 <trev> what benefit does that give? faster boot time?
17:44:58 <gzar> i want to check what happens if i compile it in and then try again compiling with gcc. it should do something even if it panics i'll at least have a crash log of whats happening
17:45:18 <trev> oh ok
17:46:22 <gzar> cause it was segfaulting, the linux compat
17:46:40 <gzar> if i understand correctly, this will either work or panic with gdb trace output
17:47:39 <nimaje> but that was a userland process (?), it shouldn't matter if you have a loadable kernelmodule or have that compiled in
17:48:53 <gzar> oh, well my hope it is it will work
17:49:03 <gzar> if not then i'll just use clang for the time being
17:50:37 <gzar> i could mix and match it by not compiling the linux compat module with gcc but the compile it separately with clang but that just seems unnecessarily complicated
17:51:34 <gzar> it may have been a userland process nimaje but the problem disappeared when i rebooted into a kernel built with clang instead of gcc
17:58:49 <parv> As long as FreeBSD project allows use og GCC to build world, thing not working as a result should be reported as bugs
17:59:28 <gzar> build world with gcc doesnt compile on 13.2
17:59:40 <gzar> the linker complains about an executable stack
18:00:22 <gzar> and i dont know where to put the flag to silence the linker, cause its a warning treated as an error i believe
18:01:02 <parv> Could be due to options used (/etc/{make,src}.conf.?
18:01:04 <gzar> and gcc12 doesnt work at all due to -fformat-extensions flag not being recognized anymore
18:01:26 * parv throws a ")" ...
18:01:50 <gzar> i had no options in src.conf. i only added them later when it wouldnt compile without -Wno-error=redundant-decls
18:03:26 <gzar> clang seems to tolerate a lot more errors
21:26:00 <gzar> i narowed down the segfault to __vdso_gettimeofday()
21:26:30 <gzar> seems like programs calling a time function are the ones to crash
21:27:51 <RhodiumToad> well, that looks like it's not so much a time problem as the whole __vdso thing
21:29:27 <RhodiumToad> where exactly is the fault? do you have a backtrace?
21:33:51 <gzar> i have a core and backtrace and sessioin output
21:34:28 <gzar> but its with color so its kinda messy
21:38:48 <gzar> https://dpaste.com/EDSMNG48S
21:38:49 <VimDiesel> Title: dpaste: bash_segfault_linux_compat_gcc.session.txt
21:41:49 <RhodiumToad> can you disassemble what's at  0x7fffffffecf0  ?
21:42:23 <RhodiumToad> you can disassemble a range of bytes if it doesn't correspond to a function
21:43:19 <RhodiumToad> e.g.  disass 0x7fffffffecf0,+512
21:44:10 <gzar> hand on, i'll try
21:46:31 <gzar> RhodiumToad: https://dpaste.com/4NJ8QGKZA
21:46:32 <VimDiesel> Title: dpaste: bash core paste 2
21:47:18 <RhodiumToad> and the output of   info reg
21:49:31 <gzar> https://dpaste.com/DTMLF8D7Q
21:49:32 <VimDiesel> Title: dpaste: bash core paste 3
21:49:43 <gzar> that should also be in the first mess i posted
21:49:53 <gzar> rsi is 0x7fff0000000
22:12:07 <RhodiumToad> hm
22:12:40 <RhodiumToad> kernel was compiled with gcc, or just userland, or both?
22:20:54 <gzar> just kernel
22:21:33 <gzar> i could try getting debugging symbols into my linux chroot for bash or other programs
22:21:45 <gzar> but im preparing a better session of the whole thing
22:22:03 <RhodiumToad> so my guess is this is something to do with the kernel's construction of the shared vdso page
22:23:16 <gzar> thats outside my knowledge, but i can provide the core file along with the binary with the symbols
22:24:49 <RhodiumToad> what cpu is this, btw?
22:25:01 * RhodiumToad guesses AMD
22:25:17 <gzar> this is intel
22:25:44 <gzar> intel core2quad q6600
22:26:28 <RhodiumToad> huh
22:29:14 <gzar> this paste is significantly better, included disassemblies in both syntaxes and followed frames around: https://dpaste.com/35M38XGL2
22:29:16 <VimDiesel> Title: dpaste: bash_gcc_linux_segfault_session
22:29:25 <gzar> still stupid color codes got in but oh well
22:29:38 <gzar> most of it is color-free
22:29:45 <RhodiumToad> do you have the same system compiled by clang running?
22:30:27 <gzar> yeah, using my clang compiled kernel right now
22:30:37 <gzar> the gdb output is from the chroot actually
22:30:55 <gzar> well, gdb from inside the devuan chroot linux compat
22:31:14 <RhodiumToad> what's the output of  procstat -v $$
22:31:27 <RhodiumToad> er,  procstat -v $$ | tail -1   will do
22:33:00 <gzar>  1966     0x7ffffffff000     0x800000000000 r-x    1    1  66   0 ----- ph
22:33:18 <gzar> inside the chroot? or host
22:33:23 <gzar> this is from host
22:34:34 <RhodiumToad> host
22:34:46 <RhodiumToad> hmm.
22:35:57 <RhodiumToad> the segfault is for linux binaries only?
22:36:13 <gzar> yes, and only inside chroot i think
22:36:45 <gzar> when i tried to run a linux-java-runtime it works fine
22:36:49 <gzar> outside a chroot
22:38:26 <RhodiumToad> hmm.
22:50:05 <RhodiumToad> the chroot is /compat/devuan, do you also have the usual files in /compat/linux ?
22:56:24 <gzar> yeah i mean, /bin/bash should be there
22:56:54 <gzar> i dont have compat/linux core files though
22:57:28 <gzar> and i dont have gdb installed in that chroot either
23:07:06 <RhodiumToad> running gdb on the core, is a symbol kern_timekeep_base visible anywhere?
23:21:16 <RhodiumToad> gzar: do you have the files for your gdb-compiled kernel around?
23:21:44 <gzar> let me check
23:21:56 <gzar> i have the core files if that is what you mean RhodiumToad
23:21:59 <RhodiumToad> no
23:22:09 <RhodiumToad> I mean the actual kernel and module binaries
23:22:11 <gzar> but i cleared my build dir
23:22:14 <RhodiumToad> oh
23:22:16 <gzar> oh, yeah i think i have it
23:23:33 <RhodiumToad> did you build again since then? in particular, do you have debug files in /usr/lib/debug/boot/kernel* corresponding to the gcc-built one?
23:25:08 <gzar> i think i didnt build, i just used an older kernel i had
23:25:54 <RhodiumToad> compare the file times for the gcc-built kernel+modules with the files in /usr/lib/debug/boot/kernel
23:27:08 <RhodiumToad> what I want to see is the output from doing  kgdb linux64.ko   and  disass elf64_linux_vdso_fixup
23:27:16 <gzar> my kernel.old matches with the files in that debug dir
23:27:20 <RhodiumToad> on the gcc-built version of linux64.ko
23:27:40 <gzar> ah i see, but idk how to identify which kernel is built with clang and which not
23:27:51 <RhodiumToad> matches /usr/lib/debug/boot/kernel or /usr/lib/debug/boot/kernel.old ?
23:27:55 <gzar> readelf -a |grep -i gnu gives me no helpfull result
23:28:01 <gzar> kernel.old
23:28:31 <RhodiumToad> try  strings /boot/kernel.old/kernel | grep -i gcc
23:29:33 <RhodiumToad> (or grep -i clang)
23:29:44 <gzar> gcc version 9.5.0
23:29:56 <RhodiumToad> that's the version you used?
23:30:08 <gzar> yes
23:30:22 <RhodiumToad> ok. so see if you can do   kgdb linux64.ko   and  disass elf64_linux_vdso_fixup
23:30:24 <gzar> so i have both the kernel and the .ko debug files
23:30:38 <RhodiumToad> on /boot/kernel.old/linux64.ko  that is
23:31:20 <RhodiumToad> basically this function is the one responsible for storing the value that's causing the segfault.
23:31:55 <gzar> yeah i can do it
23:32:12 <gzar> but its just a bunch of add instructions
23:32:59 <RhodiumToad> hm
23:33:24 <gzar> https://dpaste.com/822ALW5L3
23:33:25 <VimDiesel> Title: dpaste: 822ALW5L3
23:33:45 <gzar> those are padding bytes
23:33:59 <RhodiumToad> yeah
23:34:45 <gzar> so what do i do next
23:34:48 <RhodiumToad> did it say it was reading symbols from both /boot/kernel.old/... and /usr/lib/debug//boot/kernel.old/...  ?
23:35:09 <gzar> i did specifically do file /usr/lib/debug/boot/kernel
23:35:36 <gzar> my debug/boot/kernel matches up with my kernel.old
23:35:55 <gzar> because i just swapped the kernel dirs after my recent compile
23:36:18 <gzar> warning: the debug information found in "/usr/lib/debug//boot/kernel.old/linux64.ko.debug" does not match "/boot/kernel.old/linux64.ko" (CRC mismatch).
23:37:00 <RhodiumToad> right, you need to rename the dirs in /usr/lib/debug/boot to match the actual /boot
23:37:28 <gzar> alright
23:38:32 <gzar> alright, it found the right symbols
23:39:17 <gzar> ok, i see the function
23:40:23 <gzar> RhodiumToad: https://dpaste.com/B85FLVVH4
23:40:24 <VimDiesel> Title: dpaste: B85FLVVH4
23:41:19 <gzar> want me to print the source code as well? i assume that should be unchanged tho
23:41:40 <RhodiumToad> no need
23:42:02 <RhodiumToad> what exact fbsd version, though?
23:42:35 <gzar> FreeBSD blackbsd 13.2-RELEASE FreeBSD 13.2-RELEASE GENERIC amd64
23:44:20 <gzar> https://dpaste.com/52KC393ZE
23:44:21 <VimDiesel> Title: dpaste: /etc/src.conf
23:44:38 <gzar> ^-. that is the /etc/src.conf i compiled it with