03:52:08 <polyex> meena remember me asking if you freebsd-update production boxes or update the template and redeploy? well same with pkg upgrade, you don't do that on production boxes either right?
07:33:10 <eoli3n> Hi
07:33:18 <eoli3n> where's the guide to major upgrade ?
07:33:21 <eoli3n> that will be my first one
07:37:12 <debdrup> https://docs.freebsd.org/en/books/handbook/book/#updating-upgrading
07:37:14 <VimDiesel> Title: FreeBSD Handbook | FreeBSD Documentation Portal
07:39:33 <eoli3n> debdrup: thanks
07:39:42 <eoli3n> just noticed that 14.0 is not out
07:39:46 <eoli3n> i need to upgrade to 13.2
07:45:03 <eoli3n> i missed the 13.2 announcement
07:45:09 <eoli3n> how to get notified ?
07:47:55 <debdrup> The freebsd-announce@ mailing list: https://lists.freebsd.org/subscription/freebsd-announce
07:47:56 <VimDiesel> Title: FreeBSD Mailing lists: subscription for freebsd-announce
07:48:46 <debdrup> There's also some RSS feeds at the bottom of the website.
07:49:37 <eoli3n> thanks
08:30:54 <emersion> hi! i'm having issues installing xwayland-devel
08:30:56 <emersion> DBG(1)[1401]> curl> fetching http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest/All/xwayland-devel-21.0.99.1.495.pkg
08:31:03 <emersion> < HTTP/1.1 404 Not Found
08:31:08 <emersion> https://www.freshports.org/x11-servers/xwayland-devel
08:31:09 <VimDiesel> Title: FreshPorts -- x11-servers/xwayland-devel: X11 server as Wayland client (development snapshot)
08:31:23 <emersion> this is 13.2-RELEASE-p1
08:32:13 <emersion> (latest, not quaterly)
08:32:18 <emersion> any idea what's going on?
08:33:41 <emersion> full debug logs: https://paste.sr.ht/blob/7aaae62154be3429a5d1710745e4599087c0aed3
08:53:24 <angry_vincent> i seeing version xwayland-devel-21.0.99.1.499 ( not *.495 )
08:53:46 <angry_vincent> maybe, it is needed to update pkg database first
08:55:17 <emersion> i've done a pkg update right before
08:56:07 <emersion> it's been happening for 1 or 2 days (it's breaking the Sway CI)
08:58:17 <meena> emersion: maybe a dependency is requesting that specific version
08:58:29 <bapt> emersion: do you have a proxy cache in front?
08:58:33 <emersion> no proxy
08:58:38 <emersion> (this is builds.sr.ht)
08:58:49 <bapt> yeah I figured
08:58:51 <emersion> hm
08:59:12 <bapt> that means packagesite.pkg is not in sync with the packages available
08:59:31 <bapt> which cannot happen, so it means you somehow get an outdated packagesite.pkg this is weird
08:59:32 <emersion> should i just wait then?
08:59:41 <emersion> eh
08:59:48 <bapt> let me check the cluster
09:02:56 <bapt> emersion: test here I really have .499
09:02:56 <emersion> a minimal reproducer is https://builds.sr.ht/~emersion/job/1032719
09:02:57 <VimDiesel> Title: build #1032719 - failed
09:03:03 <bapt> from my 13 machines
09:03:54 <bapt> I don't understand how you end up with .495
09:04:04 <bapt> I have a builds.sr.ht account
09:04:07 <bapt> let me check
09:04:25 <emersion> you can resubmit that manifest, and then SSH into the machine to inspect it
09:04:32 <emersion> or ask me to run commands for you
09:04:38 <bapt> I can do it
09:04:56 <bapt> hum
09:05:01 <bapt> I bet this is quarterly
09:05:16 <emersion> hm, it shouldn't be…
09:05:29 <emersion> https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/freebsd/genimg#L70
09:05:30 <VimDiesel> Title: ~sircmpwn/builds.sr.ht: images/freebsd/genimg - sourcehut git
09:06:07 <bapt> ah
09:07:01 <meena> how do we get output from the SAT solver?
09:08:50 <bapt> meena: DEBUG_DEVEL=4, but that won't help here
09:18:39 <bapt> emersion: I think I know
09:23:51 <bapt> emersion: if I ssh connect
09:23:54 <bapt> sudo pkg update -f
09:24:00 <bapt> I got the right xwayland
09:24:12 <emersion> so the cache thinks it's up-to-date but it's not?
09:24:21 <bapt> yes
09:24:23 <bapt> but this si weird
09:24:41 <bapt> I don't know where you do getch the bad packagesite.pkg from
09:24:46 <emersion> is this based on modification time?
09:24:50 <bapt> yes
09:24:53 <bapt> url + mtime
09:25:13 <bapt> if url changes
09:25:17 <emersion> we re-generated images from the script linked above each week
09:25:18 <bapt> it forces a update
09:25:22 <emersion> re-generate*
09:25:31 <emersion> and we do nothing else to images
09:26:19 <bapt> I am reading
09:26:51 <bapt> a hack could be to add pkg update -f in /etc/rc.local
09:27:13 <bapt> so at each boot it ensures it has the lastest update
09:28:07 <bapt> another way
09:28:13 <bapt> probably cleaner would be
09:28:30 <bapt> rm /var/db/pkg/repo-FreeBSD.sqlite
09:28:51 <bapt> so the first time you call pkg install something it will install the missing bits
09:29:02 <bapt> s/install.*/update the metadata/
09:29:27 <bapt> right now you have the metadata from the creation of the images and somehow it considers it is to date
09:29:45 <emersion> hm, i'd rather not workaround this
09:29:56 <emersion> i guess i'll just disable freebsd for now
09:29:59 <bapt> :(
09:30:04 <bapt> I use it :D
09:30:08 <emersion> see if it fixes itself in a week
09:30:35 <bapt> hum
09:31:00 <bapt> maybe I should remove the mtime
09:31:15 <bapt> and set the time of the packagesite.pkg file into the metadata of the repo
09:31:22 <bapt> (I am the author of pkg)
09:31:42 <emersion> is there a way to check the bad mtime?
09:31:49 <emersion> from the local cache
09:32:16 <emersion> could this be due to e.g. NTP?
09:32:39 <emersion> (an alternative to mtime would be ETag, but that requires HTTP server support)
09:33:08 <bapt> pkg it fetching the mtime from /var/db/pkg/repo-FreeBSD.sqlite
09:33:27 <bapt> and say "If-Modified-Since: thesaidmtime"
09:33:39 <bapt> what trying to fetch the packagesite.pkg
09:34:27 <bapt> let me try something else
09:35:36 <emersion> in my case:
09:35:36 <emersion> > GET /FreeBSD:13:amd64/latest/packagesite.pkg HTTP/1.1
09:35:40 <emersion>  If-Modified-Since: Fri, 28 Jul 2023 19:04:20 GMT
09:35:46 <emersion> < Last-Modified: Fri, 28 Jul 2023 16:55:38 GMT
09:37:10 <emersion> 2h sounds like too much time for a NTP related issue
09:37:49 <emersion> where does the mtime come from in the cache?
09:38:10 <emersion> does pkg set the mtime from the Last-Modified header?
09:38:29 <emersion> or is it just the current time when the file is downloaded?
09:38:53 <bapt> yes
09:39:00 <bapt> from the Last-Modified header
09:40:25 <bapt> so I bet the mtime is lost at the creation of the image
09:45:15 <bapt> so if I want pkg to be more robust I need to store this date inside the db metadata instead of relying on the filesystem
09:46:37 <emersion> hm, i wonder how this could happen
09:46:44 <emersion> we just bootstrap a filesystem and mount it
09:47:01 <bapt> I don't know :D
09:47:01 <emersion> so FS metadata should be exactly the same…
09:47:44 <bapt> but I can confirm the date on the fs is the one in If-modified-since
09:47:47 <bapt> -rw-r--r--  1 root  wheel  57643008 Jul 28 19:04 /var/db/pkg/repo-FreeBSD.sqlite
09:48:14 <bapt> it is impossible this was the date of the packagesite at the time of creation of the qcow
09:49:15 <emersion> does pkg open the file in read-write mode, when reading it?
09:49:29 <bapt> no
09:49:39 <bapt> at least it should not :D
09:53:08 <bapt> double checked, it does not
09:54:47 <emersion> https://github.com/freebsd/pkg/blob/master/libpkg/repo/binary/update.c#L602
09:54:48 <VimDiesel> Title: pkg/libpkg/repo/binary/update.c at master · freebsd/pkg · GitHub
09:55:14 <emersion> t is a bit weird here, it's set to meta and then overwritten by the db's?
09:55:43 <emersion> but that's not the cause of the bug, since the bug is about the db's mtime
09:56:58 <bapt> emersion: this only happens if you run pkg update or pkg upgrade
09:57:03 <bapt> and if you are root
09:57:13 <bapt> (root being checked elsewhere)
09:58:13 <emersion> suggestion: use TIMEVALUE_LARGE in https://github.com/freebsd/pkg/blob/master/libpkg/fetch_libcurl.c#L466
09:58:14 <VimDiesel> Title: pkg/libpkg/fetch_libcurl.c at master · freebsd/pkg · GitHub
09:58:27 <Demosthenex> arg, so i have a small biz cisco switch, and was using lacp with freebsd 13. it keeps flapping and having terrible response, even when i turn off all the options
09:58:38 <Demosthenex> until i removed 1 of the connections, now it works fine
10:00:58 <bapt> emersion: done (for timevalue_large) would be in the next pkg
10:02:27 <emersion> could this cause mtime bump? https://github.com/freebsd/pkg/blob/master/libpkg/repo/binary/update.c#L603
10:02:28 <VimDiesel> Title: pkg/libpkg/repo/binary/update.c at master · freebsd/pkg · GitHub
10:02:38 <emersion> which goes through here https://github.com/freebsd/pkg/blob/master/libpkg/repo/binary/init.c#L336
10:02:39 <VimDiesel> Title: pkg/libpkg/repo/binary/init.c at master · freebsd/pkg · GitHub
10:03:02 <emersion> because of the W_OK
10:03:41 <bapt> emersion: that would be new
10:04:06 <bapt> this code has been working without any mtime issue since it has been introduced very long ago
10:04:40 <bapt> I agree this is suboptimal and could be greatly improve
10:04:52 <bapt> I need to rewrite this old code since like forever
10:05:18 <bapt> it was designed for a use case which never took off and is clearly over complicated for what it does ;)
10:06:45 <bapt> emersion: I think I do have the bug!
10:06:57 <bapt> this is a regression from the switch to libcurl
10:07:03 <bapt> I will fix it in the afternoon
10:07:14 <bapt> I am able to reproduce it locally now
10:07:24 <emersion> oh nice
10:07:37 <emersion> let me know if i can help
10:11:27 <bapt> sure
10:12:54 <meena> emersion: that thing bapt suggested with removing the SQLite db isn't really a workaround, imo, it's something most Linux distros would do too. To make the image smaller, and cleaner, guarantee the first package install will just work
10:13:27 <emersion> but if i can avoid downloading the index each time a package is built, it's a good thing imho
10:13:39 <emersion> each time a buiold manifest is submitted*
10:13:42 <emersion> build*
10:14:25 <emersion> image size is not a concern here
10:14:51 <emersion> getting the image up and ready as fast as possible is our priority
10:15:26 <emersion> OTOH, most of the time the user will fetch packages, which will probably take a lot of time compared to refreshing the index
10:16:31 <meena> everything is a tradeoff
10:17:18 <bapt> emersion: how often to you update the base image?
10:17:27 <emersion> each week
10:17:38 <bapt> then you approach is sane yes
10:17:44 <bapt> keeping the db
10:17:49 <emersion> ack!
10:17:59 <bapt> as long as I fix the bug ;)
10:18:13 <emersion> yeah, if we don't update the image often, then there's a good chance it'll get outdated and re-downloaded anyways
10:18:32 <emersion> aha :P
10:31:51 <meena> man, i wish bapt would fix my bugs so quickly…
11:45:40 <bapt> emersion: fixed
11:45:54 <bapt> what should I use to credit you on the commit log ?
11:46:25 <bapt> meena: which bug from you is not fixed?
11:46:36 <emersion> Reported-by: Simon Ser <contact⊙ef> maybe?
11:46:42 <bapt> sure
11:46:51 <emersion> or whatever convention the project uses
11:46:55 <meena> bapt: https://github.com/freebsd/pkg/issues/2169
11:46:56 <emersion> thanks a lot!
11:46:57 <VimDiesel> Title: pkg fails to validate rsa signature on 14.0-CURRENT · Issue #2169 · freebsd/pkg · GitHub
11:46:57 <VimDiesel> 2169 – zephyr port disagrees with Kerberos causing compilation error https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2169
11:47:15 <bapt> meena: this is not a bug this is expected
11:47:27 <bapt> I haven't written the comment yet
11:47:31 <meena> why is it expected??
11:47:34 <bapt> openssl3 fallout,
11:47:43 <meena> isn't that a regression then?
11:47:48 <bapt> no
11:47:53 <bapt> or unfixable one
11:48:15 <bapt> things signed by pkg build on openssl3 can sign and be verified on pkg build with openssl 1
11:48:17 <meena> so what does that mean? do i have to change the way I'm signing packages?
11:48:25 <bapt> aka sign from current it will work for everyone
11:48:34 <meena> oh… wild
11:48:39 <bapt> sign from openssl1 it will not work for current
11:48:50 <bapt> we are not forward compatible here
11:49:13 <bapt> this is due to a bad usage of openssl since like forever (only for the pubkey, not the fingerprint)
11:49:30 <bapt> and openssl3 does not allow anymore to abuse its API is this area
11:50:02 <bapt> meaning we cannot recreate validate old signatures anymore when built with openssl3
11:50:11 <bapt> now pkg properly use this API
11:50:37 <bapt> so we are backward compatible but not forward compatible
11:50:46 <bapt> fingerprint usage was and remains ok
11:51:05 <meena> and why can't we properly use that API on OpenSSL 1.1?
11:51:14 <bapt> emersion: FYI: https://github.com/freebsd/pkg/commit/0ec04db349d40f7ee811bfdbcdc6d0eec19889ab
11:51:15 <VimDiesel> Title: curl: ensure curl asked for the filetime of the remote file. · freebsd/pkg@0ec04db · GitHub
11:51:17 <bapt> thanks for reporting
11:51:23 <emersion> <3
11:52:28 <bapt> I'll check for the open issues and will probably issue a 1.20.5 today or tomorrow
11:52:50 <cadmio> are characters like ~ and . special bash characters or only characters that are interpreted by unix command?
11:52:51 <emersion> maybe to make it a bit more robust we could check whether the time we gte back from CURLINFO_FILETIME_T is -1
11:53:13 <emersion> and set fi->mtime to 0 in that case?
11:53:23 <emersion> or do we already check for -1?
11:54:02 <emersion> (just to make things easier to debug if the HTTP server doesn't return Last-Modified for instance)
11:54:14 <bapt> emersion: yes that was my plan
11:54:38 <bapt> the return form CURLINFO_FILETIME_T was CURLE_OK
11:55:10 <bapt> I would have expected an error
11:55:48 <emersion> right, curl doesn't return an error sadly
11:55:51 <emersion> https://github.com/curl/curl/blob/47a3e6e577b019b8dfce8d3f8df764a8dd427fd2/lib/getinfo.c#L372
11:55:52 <VimDiesel> Title: curl/lib/getinfo.c at 47a3e6e577b019b8dfce8d3f8df764a8dd427fd2 · curl/curl · GitHub
11:55:58 <emersion> just -1 and CURLE_OK
11:56:20 <emersion> the example code in the docs explicitly check filetime >= 0
11:56:42 <bapt> yup
12:01:22 <bapt> DBG(1)[91624]> Impossible to get the value from Last-Modified HTTP header
12:01:30 <bapt> now it will be easier to debug ;)
12:02:13 <bapt> should probably not be a debug info but more a warning
12:02:29 <emersion> nice
12:03:44 <bapt> https://github.com/freebsd/pkg/commit/942b46c2aad7e24fb68baeb8b140bac6229e1302
12:03:46 <VimDiesel> Title: curl: warn loudly when not able to provide remote Last modification time · freebsd/pkg@942b46c · GitHub
12:05:47 <bapt> meena: https://github.com/freebsd/pkg/commit/942b46c2aad7e24fb68baeb8b140bac6229e1302
12:05:49 <VimDiesel> Title: curl: warn loudly when not able to provide remote Last modification time · freebsd/pkg@942b46c · GitHub
12:08:39 <emersion> looks good
12:19:51 <bapt> fun it seems python3 -m http.server does not report Last-modified apaprently
12:22:32 <emersion> it sends the header field for me…
12:23:12 <emersion> < Server: SimpleHTTP/0.6 Python/3.11.3
12:23:15 <emersion> < Last-Modified: Mon, 22 May 2023 15:02:21 GMT
12:23:33 <emersion> (not for directory listings, as expected)
12:24:33 <bapt> strange the unit tests complains about it
12:31:04 <bapt> ah no actually the regression tests shows another real issue
12:32:31 <emersion> :^)
12:34:20 <bapt> I was still looking for Last-Modified if I received a 304 :D
12:34:32 <emersion> aha
16:13:43 <polyex> meena remember me asking if you freebsd-update production boxes or update the template and redeploy? well same with pkg upgrade, you don't do that on production boxes either right?
16:17:34 <meena> polyex: i usually find pkg upgrade less troublesome, but other people disagree
16:20:49 <polyex> i'm gonna switch from quarterly to latest repo too, so when i build a new server image it has latest versions, then on server disallow freebsd-update and pkg upgrade, keep immutable in production
17:03:23 <meena> cool
17:05:21 <polyex> question is, in case i forget later my decision, can i somehow disable freebsd-update and pkg from being run?
17:07:10 <meena> you can remove them from the image, but that's not gonna stop anyone who is determined. also doing that disables, or rather breaks, periodic(8) scans for vulnerabilities
17:08:14 <polyex> damn i don't wanna break anything
17:09:47 <meena> well, you can also disable those scans, and only have a few dedicated machines where they run, but chances are, if you're rebuilding images, you will be quick enough to catch CVEs
18:06:44 <RhodiumToad> I don't think anything in periodic runs freebsd-update?
18:07:12 <RhodiumToad> security runs pkg check and pkg audit
18:10:31 <nimaje> crest: as I just saw your wireguard devd / rc.d scripts, why do you use  resolvconf … -x  ? that breaks use cases where the vpn should just be an additional network
18:11:01 <crest> nimaje: because that's what wg-quick does and i emulated it's invocation of resolvconf
18:11:17 <crest> if you don't want this use a PostUp hook
18:12:06 <crest> parser supports multiline scripts including here docs
18:13:42 <crest> nimaje: this should work:
18:13:43 <crest> PostUp  = resolvconf -a %i.wg << EOF
18:13:43 <crest> PostUp  = nameserver 8.8.8.8
18:13:43 <crest> PostUp  = EOF
18:13:43 <crest> PreDown = resolvconf -d %i.wg
18:14:46 <crest> wait better don't use .wg because it could conflict with the dns up/down automation
18:14:48 <nimaje> ah, yes, I remember, I wanted to create a bug report against wg-quick, as they use -x too, but only address being ::/0,0.0.0.0/0 should have that exclusive effect
18:15:22 <crest> i decided against implementing saveconfig because i didn't want to make the script even longer
18:15:41 <crest> and i refuse to implement the insane daemon mode mucking with the routing table
18:16:37 <crest> a shell script "parsing" `route monitor` isn't only to linearly scan the routing table on every change is flawed in so many ways
18:17:34 <crest> just because some warez kiddie couldn't be bothered to learn the correct way to do policy based routing using multiple routing tables or domains before starting a torrent client </rant>
18:18:45 <crest> maybe i could add some resolvconf args to pass through similar to Sticky?
18:19:43 <crest> Sticky (configurable via the wireguard config file or the file mode on the config file) tells the rc.d script to leave the interface around similar to $cloned_interfaces
18:19:59 <crest> e.g. sysrc cloned_interfaces+=gre0:sticky
18:20:27 <crest> would create a gre0 interface that sticks around even after a service netif stop gre0
18:20:47 <crest> in case you want to reference it somewhere e.g. a ipfw or pf configuration
18:21:44 <crest> stealing the sticky bit for this is a dirty trick, but it allows sharing unmodified wireguard configuration files with other operating systems
18:32:09 <crest> nimaje: the PostUp/PreDown hook cover your needs?
18:33:27 <crest> or would say something like SharedDNS = 8.8.8.8,example.org be a lot better for your usecase?
18:34:48 <crest> maybe ExclusiveDNS/SharedDNS/PrivateDNS with DNS as a short alias for ExclusiveDNS?
18:35:10 <crest> corresponding to the -x, nothing and -p?
18:54:57 <CrtxReavr> So. . . I was playing with glances on a FreeBSD VPS I have. . . and it prints this line below the hostname:
18:55:10 <CrtxReavr> Cloud  instance 56f2106129679db187c38ecb36af5417
18:55:23 <CrtxReavr> Where does that get read from?
18:57:26 <CrtxReavr> I thought of sysctl, procfs, or /var/run/dmesg.boot, but all no. . .
18:58:10 <otis> from cloud-init if you use it?
18:58:48 <V_PauAmma_V> I was guessing motd?
19:13:25 <CrtxReavr> I dont' use cloud-init.
19:13:52 <CrtxReavr> And motd is just the OS version string and what else I put there.
19:15:43 <RhodiumToad> what's the exact context of the message?
19:16:22 <CrtxReavr> glances is like a top(1) on steroids, written in python. .. uses shutil modules.
19:17:17 <CrtxReavr> In its default config, in the upper left corner, it prints the full hostname, and below that it says what I pasted above.
19:20:51 <crest> CrtxReavr: grep -r "Cloud.*hostname" /etc /usr/local/etc
19:21:07 <crest> ooops
19:21:23 <crest> grep -r "Cloud.*instance " /etc /usr/local/etc
19:22:20 <RhodiumToad> I'd expect it to be from sysctl or kenv
19:26:11 <CrtxReavr> Found it.
19:26:14 <CrtxReavr> curl -s http://169.254.169.254/latest/meta-data/instance-id
19:26:31 <CrtxReavr> Standardish cloud meta-data convention.
19:28:46 <CrtxReavr> IT's an OpenStack API thing.
19:28:56 <CrtxReavr> But many other things use it too.
19:48:14 <meena> new OpenSSL vulnerability / release
20:21:39 <crest> https://www.openssl.org/news/secadv/20230731.txt
20:22:08 <crest> "Due to the low severity of this issue we are not issuing new releases of
20:22:08 <crest> OpenSSL at this time."
20:25:42 <meena> crest: look, reading is hard, okay
20:26:12 <crest> meena: i was just confused looking for the new release i missed
20:26:33 <crest> and wanted to safe others from following the same path
21:48:10 <nimaje> crest: just saw that DNS is documented as using  resolveconf -x  for some reason, no idea why you would want to use the dns of some vpn in the case of using vpns as additional networks, there you just want to give the dns a part of the hierarchie
21:50:39 <crest> nimaje: imo it depends on your usecase, but i don't want to break the *semantics* of a wireguard configuration by redefining the meaning of the "DNS" property to suite your (or my) usecase a little better
21:51:59 <crest> what is implemented should be compatible to wg-quick(8) to avoid fragmenting the ecosystem. we don't need an other tower of babel like situation (one IPsec is enough)
21:52:56 <kevans> +1
21:54:23 <nimaje> yeah, DNS is documented as using  resolveconf -x  so you should too (but I still think it was a bad idea when they decided that)
21:56:10 <kevans> you're welcome to try and convince upstream otherwise, we just need to coordinate on stuff like that
22:47:57 <meena> when i connect my laptop to $corporate VPN but don't use their DNS I can't access shit on their network
22:58:20 <rwp> That is a typical issue with VPNs.  Private DNS space too.
23:00:01 <rwp> If one does not want to route all DNS through the VPN, or have several VPNs concurrently, it is possible to configure nameservers such as unbound to forward specific domains to specific upstream nameservers.
23:17:56 <mason> ^ that's what I do
23:18:20 <mason> and specific reverse zones
23:24:10 <yuripv> <3: CFLAGS+=        -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang