00:29:23 <Demosthenex> hrm. so i'm using virtual_oss and the software dsp is my default sound device. it works for mpd and virtualbox, but firefox still insists on going to my laptop speaker. i've already set the cubeb to oss. any ideas?
00:32:58 <mason> Demosthenex: I think you need to select a sound back-end in Firefox's config.
00:33:36 <Demosthenex> mason: i have, the media cubed oss thing
00:33:54 <mason> Demosthenex: in the context of about:config?
00:33:59 <Demosthenex> about:config, media.cubeb.backend = oss
00:34:07 <mason> kk
00:34:38 <mason> That's the only thing that comes to mind then. Hopefully someone else will have an idea. As usual, the devout X folks are in efnet:#freebsd-xorg
00:36:05 <jauntyd> Demosthenex, 'media.cubeb.backend "OSS"' in about:config for FF
00:37:41 <mason> Case matters?
00:37:58 <jauntyd> i have never tried any other way ;-;
00:38:08 <jauntyd> would be interested to know as well
00:41:34 <Demosthenex> nope, still laptop speakers
00:41:51 <Demosthenex> oss and OSS
00:41:55 <Demosthenex> and restarted ff
00:42:01 <jauntyd> oh hmm
00:48:25 <jauntyd> what is the output of "cat /dev/sndstat"
01:37:06 <eborisch> stable/14 branched: https://lists.freebsd.org/archives/freebsd-current/2023-August/004425.html
01:37:07 <VimDiesel> Title: HEADS-UP: stable/14 branched
03:12:48 <torbo> Can I run an LLM on an Nvidia 3090 on FreeBSD?
04:40:06 <kenrap> RhodiumToad: on a related note from our discussion about usb3, I'm using sata-to-usb adapters for SSDs that I use as external storage and the chipset of those adapters allow me to pass TRIM to them. Recently I decided to reformat one of my drives to using UFS+SU but I couldn't use trim with it, despite having done so with them formatted with ntfs.
04:41:00 <kenrap> Would you know what's going on there?
04:42:02 <RhodiumToad> what does  sysctl kern.cam.da.N.delete_method   show?
04:43:17 <kenrap> Ah: kern.cam.da.0.delete_method: NONE
04:48:20 <kenrap> Okay, so I need to assign it with ATA_TRIM
04:54:45 <kenrap> I suppose that's a thing that should have been detected already and not a tunable.
05:09:04 <RhodiumToad> it looks like you can only set it to values that were detected as supported, except for DISABLE and ZERO
05:09:21 <kenrap> Gotcha
05:09:46 <kenrap> I might want to make a report for this for the adapter chipset.
10:30:42 <nerozero> just found btop - mind blown....
11:47:30 <Demosthenex> nerozero: yeah, btop rocks
11:47:34 <Demosthenex> but the zfs stats dont work
11:48:21 <Demosthenex> regarding sndstat, https://termbin.com/9dsl  pcm0 is the laptop speaker, and dsp (no number) is virtual_oss
12:07:47 <Beladona> Question: If i put one database or one part of table (a partition) on another disk via tablespace, the system shuts down, at reboot freebsd tries to recover db data but finds that one of the disks are unavailable as those were encrypted disks (not yet decrypted). They are manually decrypted after the system starts. Any ideas how safe and sane is
12:07:47 <Beladona> it?
12:44:09 <Demosthenex> Beladona: just means you'll have to enter a password
12:44:22 <Demosthenex> and maybe not autostart your db
12:44:35 <Beladona> no, those are geli disks with pools, i decrypt manually
12:45:03 <Demosthenex> so i set the ifconfig debug flag on my wlan0 using iwm, and i'm only seeing wpa_supplicant messages, any way to see additional data? i'm curious about abnormal retries or state changes
12:45:21 <Demosthenex> Beladona: ok, so it just means you have no automatic startup
12:47:33 <Demosthenex> dont' start the DB at boot, or it'll complain it's missing the FS
12:57:48 <Beladona> ok, how can I disable autostartup of postgres? Demosthenex
12:58:54 <Demosthenex> Beladona: disable it in sysrc
12:59:16 <Demosthenex> maybe sysrc postgres_enable=NO
13:00:12 <Beladona> ok
13:00:25 <Beladona> then service start postgresql manuall?
13:00:33 <Beladona> Demosthenex where is sysrc?
13:01:07 <Demosthenex> edit /etc/rc.conf by hand, or use the sysrc command
13:01:20 <Demosthenex> /usr/sbin/sysrc postgres_enable=NO
13:01:24 <Demosthenex> and i'm only guessing at the service name
13:01:33 <Demosthenex> check what's in the /etc/rc.conf first
13:01:42 <Demosthenex> later you can do service postgres onestart
13:01:47 <Demosthenex> later you can do "service postgres onestart"
13:35:16 <meena> Beladona: my recommendation is to use service <service_name> enable
13:35:39 <meena> it uses sysrc underneath, but it also makes sure the service you're trying to enable actually exists
13:35:51 <kenrap> Neat!
13:38:44 <kenrap> That needs to be documented in the help usage and man pages
13:41:14 <Demosthenex> meena: but it shouldn't autostart, does enable set that or just start it?
13:41:30 <CmdLnKid> man service
13:41:33 <meena> enable enables it for autostart
13:41:50 <Demosthenex> then that's wrong. needed to disable it
13:42:07 <meena> Demosthenex: service <service_name> disable
13:42:10 <CmdLnKid> try onestart
13:42:19 <meena> i misread.
13:42:29 <dstolfa> Demosthenex: in that case onestart is what you want, but you'll have to do it every time
13:42:36 <dstolfa> (obviously)
13:43:04 <CmdLnKid> seems all those descriptions are missing from the man page for service
13:43:17 <kenrap> Yep
13:43:38 <CmdLnKid> someone didn't have the time for the BSD way
13:44:14 <CmdLnKid> bet its mentioned in the handbook though
13:45:42 * meena needs to submit that patch
13:46:07 <CmdLnKid> only mentioned once from a brief cursory
13:46:18 <CmdLnKid> service nginx onestart
13:48:57 <CmdLnKid> thx meena
13:49:41 <CmdLnKid> 🍺
13:50:08 <kenrap> I appreciate it as well
13:51:20 * CmdLnKid <<< no good at manpages. I usually end up copying another section and then hack it into place with machette
13:55:25 <meena> all I've done for the past week or so was write man pages https://github.com/freebsd/freebsd-src/pull/827
13:55:27 <VimDiesel> Title: document pmap_kextract/vtophys and optionally improve the code by igalic · Pull Request #827 · freebsd/freebsd-src · GitHub
13:56:33 <CmdLnKid> high respect
13:56:49 <meena> but low income
13:57:06 <CmdLnKid> see something commit something
14:06:16 <dstolfa> meena: write the software: 2 days. write the man page: 1 month. at least that's how it goes for me usually
14:11:22 <CmdLnKid> service has been around since how long tho
14:11:43 <CmdLnKid> one month turns into a decade
14:28:14 <Beladona> meena so I disable it? I mean how to disable it at boot
14:28:48 <CmdLnKid> you know how rc.conf(5) works ?
14:29:05 <CmdLnKid> $EDITOR /etc/rc.conf
14:29:42 <CmdLnKid> you can use (service disable) but its important that you know where that comes from
14:30:02 <CmdLnKid> and that you can verify that
14:30:42 <CmdLnKid> a front loader doesn't ask if the shovel is attached
14:31:39 <CmdLnKid> only said it that way cause there is one driving down the street right now an im annoyyed
15:11:13 <Beladona> CmdLnKid so I put postgresql_enable=no" in /etc/rc.conf and it will not run it at boot time. Thats all? I can then run manually by `service start postgresql` later?
15:11:43 <CmdLnKid> just make sure that var doesn't appear and youll be in the right place
15:11:59 <Beladona> ok.
15:12:11 <Beladona> CmdLnKid so I delete postgresql_enable=yes" in /etc/rc.conf and it will not run it at boot time. Thats all? I can then run manually by `service start postgresql` later?
15:12:19 <CmdLnKid> but in the least if set no then yes the service will not start
15:12:34 <CmdLnKid> correct
15:12:36 <Beladona> thanks
15:13:15 <CmdLnKid> whatever appears last in rc.conf will be the last evauluated statement
15:13:20 <rtprio> *onestart, rather than start, but yes
15:13:43 <CmdLnKid> if you have more than one then the whats above will take effect
15:15:03 <CmdLnKid> grep 'postgresql_enable' /etc/rc.conf will show
20:22:40 <iomartin> Hello, I'm creating a new port to FreeBSD and I want to split it into multiplace packages (one package with main program and shared libraries, another with development headers, another pkg with optional features, etc.). I'm thinking about using slave ports, is this the right way to go?
20:22:40 <iomartin> https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-masterdir
20:22:41 <VimDiesel> Title: Chapter 5. Configuring the Makefile | FreeBSD Documentation Portal
20:23:27 <iomartin> Essentially I want to build it once, but have a different pkg-plist for each subpackage
20:39:25 <RhodiumToad> iomartin: there's a #freebsd-ports channel; but the short answer is that currently, one build can only produce one package
20:39:56 <RhodiumToad> slave ports or flavors can produce separate packages from a single distribution, but each is built separately
20:42:48 <iomartin> RhodiumToad: I see, thanks for the explanation. That's unfortunate, but I think I can live with it it, my port doesn't take too long to compile
20:44:08 <RhodiumToad> it's not conventional in freebsd to split out development headers/libs into separate packages from the runtime
20:44:41 <RhodiumToad> splitting out optional features is good especially if it reduces the number of dependencies on the main package
20:50:48 <iomartin> Yeah, this is what I'm trying to achieve. I'm porting something that on Debian/Red Hat is split into 6 packages so I was thinking I'd replicate it on FreeBSD. Some features are useful just for a handful of users
20:51:27 <iomartin> But some have distinct "make" targets so I can avoid compiling everything for all of them
20:51:55 <costly> you can use options in ports
20:52:24 <RhodiumToad> options are... often problematic
20:52:45 <RhodiumToad> firstly, the package builders build only with default options
20:53:03 <RhodiumToad> secondly, packages depending on it can't specify which options they need
20:53:50 <costly> maybe I missed it, but what package does iomartin want to port?
20:54:11 <RhodiumToad> they didn't say
20:55:34 <RhodiumToad> I'm pretty sure that the ability to produce multiple packages from one build is a feature that people want, but I don't think anyone's done the work to see what kind of modifications to the framework would be needed
20:56:12 <RhodiumToad> flavors have existed for a long time and there is still a _ton_ of framework stuff that doesn't handle them properly
20:57:31 <iomartin> costly: can you elaborate on how I could use options?
21:01:30 <costly> iomartin: have you seen the porter's handbook? https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-options
21:01:31 <VimDiesel> Title: Chapter 5. Configuring the Makefile | FreeBSD Documentation Portal
21:03:32 <costly> iomartin: it really depends on what you are porting, for "normal" applications, I suggest you use Options, for more complex libraries or apps which become dependencies see RhodiumToad's comment, they may not be suitable
21:11:19 <iomartin> costly: I had somehow missed that section, let me take a look
21:14:05 <iomartin> costly: but it is an application to interact with the hardware my company makes. It is not particular large but logically the packages are different parts. For example, there is a documentation package that is large-ish. Or a prometheus-exporter package. So stuff that not everyone will need
21:16:47 <iomartin> costly: I'm getting the impression that options is better suited to allow an user to configure their build once and then they'll always get the same "parts" when they recompile. Is this right? That's not quite what I'm looking for though. The packages will be distributed only on binary form, so there will be no configuring done by the user
21:18:59 <RhodiumToad> oh, this is a private port?
21:19:07 <iomartin> Yes
21:19:17 <RhodiumToad> in that case options are of no use
21:32:12 <costly> iomartin: agreed with RhodiumToad
21:35:57 <meena> "Or a prometheus-exporter package. So stuff that not everyone will need"
21:37:20 * meena has somehow avoided getting into that that particular hole 
22:26:52 <meena> this is very exciting: https://freshbsd.org/freebsd/src/commit/1554ba03b651319ab0e1cde8492ea4516afc648b
22:26:53 <VimDiesel> Title: FreeBSD / src / 1554ba0 / Add mac_grantbylabel - FreshBSD
22:38:06 <creith> hey folks, good evening
22:38:17 <jauntyd> \o
22:40:28 <Freaky> meena: that looks cool
22:40:40 <creith> is there any chance that FreeBSD get something like OpenBSD's pledge(2) and unveil(2) ?
22:42:21 <yuripv> i guess it's better to describe the functionality you need instead of saying names not everyone is familar with :)
22:43:09 <creith> Oh ok, I'm sorry
22:43:51 <creith> basically, pledge is a system call which allows a program to limit it's access to system calls
22:45:10 <creith> the basic observation was that most programs (ok, especially daemons, but also things like tcpdump) need high privileges only during initialization phase
22:45:47 <creith> so the OpenBSD guys grouped system calls in groups (stdio, inet, wpath, rapth ...)
22:46:07 <RhodiumToad> freebsd has capability mode, which has some similarities but is probably somewhat harder to use
22:46:22 <creith> capsicum is difficult
22:46:54 <creith> and it it not used ... well, obvious there were some tries with some simple programs
22:47:13 <creith> capsicum is too difficult
22:47:40 <creith> it was an academical exercise as far as I can see
22:48:24 <creith> though it would defintely serve FreeBSD's security, if applied to the base system consequently
22:48:43 <creith> I would volunteer, if this is the strategy
22:51:09 <creith> unveil(2) is a way to limit file system access (it is strongly interwined with the FS with OpenBSD) ... it might be hard
22:51:38 <creith> you can say: unveil("/home/user/", NULL)
22:51:57 <creith> This will limit the file system name space
22:53:03 <meena> some people are trying to make capsicum easier to use. but making it possible to kind of capsicumize a program blindly
22:53:40 <Freaky> https://papers.freebsd.org/2020/bsdcan/stone-oblivious_sandboxing_capsicum_ebpf/
22:53:41 <VimDiesel> Title: Oblivious Sandboxing with Capsicum and EBPF :: FreeBSD Presentations and Papers
22:54:09 <creith> The error messages will be the normal ones: ENOENT
22:54:24 <RhodiumToad> take a look at, for example, commit b4d2c3385c  (which adds capsicum to tail(1))
22:54:46 <creith> that's cool
22:55:16 <creith> are there any priorities I can have a look at or help ?
22:56:53 <creith> eBPF makes my stomach hurt ...
23:06:56 <creith> "How can we run 3rd party software within a capsicum sandbox without modifying their source code ?" (from the presentation)
23:07:06 <creith> wrong approach, imho
23:08:16 <creith> firefox and chrome run with pledge and unveil on OpenBSD ... upstream
23:19:22 <creith> sorry, I'm not good at intercting with people
23:19:50 <creith> I love FreeBSD ... but I love some features of OpenBSD, too
23:20:11 <creith> and I would love to have them in FreeBSD, too
23:20:33 <creith> again, I would like to help, if I can
23:21:05 <checkpoint> creith: can you please name a few feature ?
23:21:22 <creith> well, pledge and unveil
23:21:37 <creith> unveil will not be possible
23:21:51 <creith> but maybe pledge would be feasible
23:23:17 <creith> capsicum is not the solution, it's too complicated imho
23:24:28 <creith> otherwise FreeBSD should probably have a more restrictive way to let new features in
23:25:14 <creith> don't get me wrong, I try to be nice
23:26:06 <creith> I think to look at Linux is not the BSD way, Linux has become a "Windows badly reinvented"
23:28:16 <RhodiumToad> not sure why you think unveil wouldn't be possible
23:31:29 * checkpoint has read man on unvail() and is now trying to figure out any decent usecase
23:34:57 <creith> unveil needs a very deep implementation in the file system
23:35:18 <creith> that's easy when you just support one file system
23:35:42 <creith> I don't think it will be easy with ZFS
23:37:04 <creith> The use case is simple, chromium on OpenBSD (well the appropriate process to be precise) is only allowed to read or write in ~/Downloads
23:37:37 <creith> no more unvoluntary backups of your .ssh/<name your key>
23:38:04 * checkpoint thinks a syscall like unvail can be imlemented independently of file system type
23:38:35 <creith> if you have a good idea, great !
23:38:40 <checkpoint> creith: how is it any better than chroot ?
23:39:38 <creith> there are some differences, you can gradually unveil
23:40:31 <creith> the error messages you get are normal, which is not the case in a chroot all the times (it is such no file or directory)
23:41:54 <creith> are you interested in this ? I can have a look for a presentation of Theo, but it was in 2015 or 2016 ... I am not so much organized with my backups :-=
23:42:08 <checkpoint> the problem is that it takes quite some effort from application developers and quite a lot of it for things like Chromium
23:42:39 <creith> chromium was pledged in less than 7 days ...
23:43:18 <checkpoint> pledge is for system calls, not for file system access, right ?
23:43:21 <creith> do you know how many SELinux projects I have been through which failed ?
23:43:33 <creith> @checkpoint: yes
23:43:50 <creith> it must be in the source code
23:44:09 <checkpoint> so, yes pledge is way easier to integrate
23:44:25 <creith> if you try it from the outside, you'll always miss one path of execution
23:44:44 <creith> and it is the one your manager wants definitely to have
23:45:12 <creith> @checkpoint: yes, unveil is pretty difficult
23:49:02 <checkpoint> I read that unvail makes app just to segfault if it tries to access restricted path. Now imagine how many surprizes one can get using poorly unvailed Chromium. It will take ages to fix all the possible crashes unvail causes till the app can be usable again.
23:52:57 <creith> no, unveil will not segfault ... if a process tries to access a file or directory outside of which is unveiled, he will get a  ENOEN
23:53:09 <creith> T
23:53:13 <creith> sorry
23:53:36 <creith> No such file or directory
23:54:02 <creith> if you want to play with it, I have an OpenBSD server ...
23:55:34 <creith> in practice, if you want to download a file, you can download it to ~/Downloads
23:55:57 <creith> The file selection dialog will not show you anything else
23:56:35 <creith> you can configure it, if you feel like