01:40:22 is anyone on here who manages the website? i'm wondering if maybe we could freshen up the home page a bit. mock up using mkdocs: https://freebsd.markmcb.com/ 01:40:57 anything more responsive would be nice, this is just a quick mock up 01:42:51 markmcb: you forgot the beastie artwork... 01:43:33 also the original contains a brief about the operating system which is crucial IMHO 01:44:08 haha, i knew someone would mention the missing graphic 01:44:10 that web page you made would be fine in freebsd.org/where 01:44:40 it's a copy of the existing home page, with minor additions 01:45:00 but the content isnt the focus, more the useability 01:45:20 the existing site doesnt resize well and is micro sized on mobile 01:45:49 then fix that 01:46:14 i did, lol 01:46:22 this is a responsive template 01:46:30 no you did reworked the front page 01:47:28 i get it, nostalgia ranks high 01:52:35 im sure you can just adjust css for the current webpage so it fits better on mobile 01:53:41 -> https://www.freebsd.org/css/fixed.css 01:54:09 maybe create a new one? :D 07:03:55 voy4g3r2, multiple mount= lines does appear to work for me; all after the first must be += of course 07:56:52 is there anything that would render a vnet jail incapable of pinging 127.0.0.1, with the message "permission denied"? 08:04:47 missing permissions to use raw sockets? 08:20:59 nimaje, i did enable those, if I'm not mistaken 08:21:57 possibly fork nonsense then 08:35:40 MelMalik: ipfw/pf with default drop? 08:36:34 ipfw is in use at host level; however behaviour didn't change when I added a low-numbered rule with "allow ip from any to any" 08:36:56 you added that in the jail, right? not on the host 08:37:33 i will have to try that next. 08:37:38 thanks for the hint. 08:39:43 in unrelated news I am now rebooting the host machine to do an acceptance test of the configuration I have put together.. 08:49:23 on that note: the firewall was misconfigured :') 08:49:31 i have a lot of misluck with firewalls 09:00:59 ivy, it would appear there was a deny rule in ipfw in the jail; unfortunately /etc/rc.d/ipfw does not run inside of a jail so I am going to have to do some hacks (assuming that I can even use the ipfw tools) 09:01:28 can you not just enable ipfw the normal way (in rc.conf)? i don't use ipfw but that works with pf 09:01:49 rc.d/ipfw is nojailvnet which means it should run in a vnet jail 09:02:18 i tried service ipfw start and it complained about a kernel module; I suspect that adding `sh /etc/rc.firewall` to /etc/rc.local will have to do for now 09:02:47 if you have ipfw loaded and it's complaining that it's not loaded, that sounds like a bug 09:04:38 (the way this is meant to work is that if you have the module loaded on the host, or it's in the kernel, it won't try to load it in the jail) 09:06:16 ok so I think we have found the point where it's fork nonsense; in HBSD kldstat doesn't work in gaols 09:06:47 now I need to go open a window, holy hell it's hot in here 09:08:04 ok, so it is a bug, just not in freebsd :-) 09:14:58 working as intended, but creates bugs downstream. so, yes. as a workaround, as I said, I have put sh /etc/rc.firewall into rc.local. 09:20:52 hm, but you can observe some kernel modules being loaded in some other way, so is there really a point to hide these? especially if there is a reason to use them in a jail? how about a whitelist approch, where a module can be declared useable in a jail and then kldstat reports it? 09:32:00 p'rhaps 09:32:28 I might give that a shot in my own fork of the fork at some point. Or modify the script to detect ipfw by other means, as I'm weird that way 12:37:50 any idea if the forum is having issies ? 12:37:56 issues * 16:54:05 hello! 16:54:41 the pixman port is currently outdated (latest stable release is 0.46.0), where should I properly report this? 17:00:09 badkat: i made it more "as-is" https://freebsd.markmcb.com/ 17:01:04 i find it interesting that the foundation has branding guidelines and the project site ignores them, e.g., fonts, logs, etc. 17:01:20 bitblt: You should report this in either ports@ on the mailing list or on bugs.freebsd.org (especially if you can provide a patch update.) 17:03:23 ek: I see that here https://cgit.freebsd.org/ports/tree/x11/pixman/Makefile the maintainer is listed as x11⊙Fo, maybe this is a more appropriate email? 17:04:52 bitblt: Yes. You can email them directly and bring it the issue. However, that is also just a dev group for X11 on FBSD. Not a singular person. 17:05:46 If you can patch and test the updated version and provide that info, that will certainly get their ears perked up, though. 17:06:37 I generally find it easiest to create a PR on bugs.freebsd.org, and then email the maintainer address to let them know about it. 17:06:52 I'm not directly a user of freebsd, but a project that I currently contribute to (wlroots) has a freebsd CI, that currently needs the latest pixman port to pass :) 17:07:04 This way things can be easily tracked via Bugzilla as opposed to email. 17:07:26 I'll try to make the version bump myself, I'm just trying to find the correct way to report/communicate this 17:07:37 I also found this mailing list: https://lists.freebsd.org/archives/freebsd-x11/ 17:08:02 bitblt: there isn't really a way to report an out of date package other than mailing the maintainer (the list, in this case), if you do decide to update it yourself then you need to open a PR on bugzilla, the porter's handbook describes how to do that 17:08:03 Is freebsd-x11⊙Fo a different group from the x11⊙Fo? 17:08:04 The correct way is bugs.freebsd.org ports PR. 17:09:09 bitblt: x11@ and freebsd-x11@ should be associated with the same group. 17:09:29 thank you 21:44:48 how can I (from CLI) determine if there is a new freeBSD release to be used with freebsd-update upgrade -r .... ? 22:29:34 guntbert: freebsd-update fetch 22:29:44 will output: 22:29:47 No updates needed to update system to 14.2-RELEASE-p3