00:14:38 do any of you run kodi without loading either x11 or wayland first? 00:15:15 I am asking this because on the console, I can't use either the keyboard or the mouse in kodi. 10:12:59 After pkg moved to curl it no longer trusts the CA used on my package server (fetching via https). What's the current/new way of specifying trust? 10:30:45 *sigh* certctl hackery... 10:47:17 I believe it can still be done using environment vars, but the names of the vars changed 10:47:23 haven't tested it myself though 10:47:42 Some of them can, like http_proxy (lowercase), but I have had no luck with the CA stuff 10:47:49 Not even curl's own vars actually work 10:47:54 however, specifying a client cert is no longer possible as far as I can see 10:48:12 are you setting them in PKG_ENV or in the outer environment? 10:48:37 Neither works 10:48:53 huh. that's a problem 10:50:27 I only tried once, so there may have been effups on my part. 14:41:46 i believe bapt is quite receptive to feedback on it 14:42:21 yeah, the memory issue with pkg add was fixed pretty fast 14:42:33 and pkg 1.20.2 just landed in the tree 15:16:44 if anyone has issues with self signed certificate please test: people.freebsd.org/~bapt/patch-compat-libfetch (adding to ports-mgmt/pkg/files/) 15:17:00 Ltning: ^^ I have been told you have issues 15:17:24 the bapt has been summoned! 15:17:33 bapt: I am told I have issues too :D 15:17:37 * debdrup puts away his robe and summoning paraphanalia 15:18:56 Ltning: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272406 if your issues are similar to the one there, then they are either addressed by 1.20.2 or by this patch, if not then I need to create another patch :D 15:18:58 Title: 272406 – ports-mgmt/pkg: pkg-1.20.1 does not work with FreeBSD-13.1-RELEASE-p8 GENERIC amd64 15:20:45 bapt: That's related but not quite the same. I was trying to use the CURL_CA_BUNDLE to get around the issue, but honestly I had expected it to use /etc/ssl/cert.pem as it did before. 15:20:59 We ended up in a situation where dozens of systems auto-upgraded pkg only to have pkg subsequently fail horribly 15:21:09 ..requiring manual intervention on all of them :D 15:21:15 erg 15:21:52 And when pkg fails, puppet fails, and mayhem ensues. Config management rocks as long as nobody changes anything :D 15:22:13 so libcurl bundled in pkg expects to find its certificates in /etc/ssl/certs/ 15:22:14 sounds like you simply need to reduce the number of hosts you run 15:22:24 compliants to certctl 15:23:01 which is supported and should be the default for all freebsd supported version 15:23:22 that said I bet if you have your own /etc/ssl/cert.pem is because you have your own CA right? 15:23:31 kevans: Yea but nobody wants to sell me the hardware I need to do that :P 15:23:38 bapt: Yeah. :) 15:24:13 Ltning: ampere? I imagine you guys don't do a whole lot that's x86-specific, at least? 15:24:25 I can make an option so that you can speficy your own .pem path 15:24:32 like SSL_CA_PATH 15:24:38 would that fit with you ? 15:24:40 160 cores and lots of RAM == lots and lots of jails or VMs 15:24:53 kevans: Yea, but .. Nobody will sell me any on this side of the pond. Delivery times counted in years. 15:24:58 yikes 15:25:31 "by the time it's delivered, they'll have already released the new and improved next generation" 15:25:34 bapt: I *could* also simply rip everything out and "fix" my puppet manifests .. but I'd prefer not to do such a big thing starting in production :P 15:25:42 yeah, europe might have the only company that makes the machines capable of doing the lithography for high-performance cpus, but we don't got anything else 15:26:04 kevans: So we're stuck with all this epyc garbage until someone decides Norway is important enough 15:26:11 well, up to when china stole the ip of that company 15:26:26 sorry, a chinese citizen who then moved to china 15:26:28 I am not against SSL_CA_PATH, tbh I think it will serve a lot of people 15:26:37 who do not want to know how certctl works 15:26:51 bapt: Yeah, it would be a lot easier for us, that's for sure. Is that the same var fetch would respect? 15:26:54 so if this is ok for you I will can add it, it will take me a few minutes 15:26:57 there's still a lot of cases where certctl could integrate better with ports to make it more compelling 15:27:27 SSL_CA_CERT_PATH 15:27:29 is SSL_CA_PATH because the cert bundle already uses a similar naming scheme? because "SSL" is kinda.. a misnomer nowadays 15:27:31 this is what fetch expects 15:27:41 I will use that variable so it is compatible 15:27:57 kevans: We were discussing that here today. We really don't like how it does practically nothing for half of base and most of ports because of the reliance on cert hashes 15:28:16 bapt: It'd be good if it follows what fetch expects (which I believe worked for old pkg). 15:28:27 Since that's how we have been doing this until now .. 15:28:54 michael osipov has a wishlist for certctl because they use a custom CA or two or so, but I don't really have free time to work on this and I don't know that anyone's willing to sponsor that when the old way works-ish for them 15:29:45 Depends what "sponsor" entails. We'd certainly like a certctl that does (more) useful things. Just not as a surprise. 15:29:56 kevans: You're too busy with the mbp? ;) 15:30:01 * Ltning hides 15:30:18 hehe :-) that's one of the projects, kinda waiting on stable/14 to branch to drop the next important changes 15:30:32 I started landing some of the work and have another review or two open 15:30:52 looks like my laptop is toast, kevans are you implying I should wait a few weeks and get a fruity one instead? 15:31:03 maybe 6 months t oa year 15:31:03 Uh-oh, now what did I do 15:31:12 Ltning: https://github.com/freebsd/pkg/commit/f59cb51be575ff34532a9a4efc6c8e98a51a624d 15:31:13 Title: curl: allow to specify the CA to use via env var · freebsd/pkg@f59cb51 · GitHub 15:31:57 bapt: while you're here, I had timeouts on large packages today (llvm, lumina-themes etc) using pkg1.20.1 on 13.2-RELEASE-amd64 15:31:58 Ltning: can you try with this patch? 15:32:08 dch: already fixed by kevans 15:32:09 bapt: Looks sane to me. I'm not able to test that in any useful environment on short notice 15:32:11 do you want me to re-try later with 1.20.2? 15:32:35 dch: after 1.20.3 15:32:45 I might be on a plan to NZ by then 15:33:26 erg 15:33:32 I miss read fetch3 15:33:49 SSL_CA_CERT_FILE is the right thing 15:34:25 yea I just realised 15:34:57 Both are probably useful though, if we want backwards compatibility 15:35:17 It's also possible our way of doing this has been batshit all the time, and we need to stop. :) 15:35:46 I don't intend to be 100% compatible with libfetch, only on what make sense :D 15:35:54 with my own definition of what make sense 15:36:31 The power of definition is among the mightiest. 15:36:49 that said we are now probably 90% compatible, the latest 10% might not hurt to implement 15:37:47 anyway I will a batch of tests during the night and issue a 1.20.3 tomorrow 15:42:45 bapt: while pkg add is using much less memory now than in 1.20, it still uses enough that it's impossible to run it on a 1GB system even for small packages 15:42:56 yes 15:43:01 (1GB system without swap) 15:43:14 the problem is the ports tree uses pkg add 15:43:21 and pkg add should die in hell 15:43:36 pkg add is a dirty thing made to mimic pkg_add 15:43:57 which was looking for its dependencies around itself 15:44:07 on the filesystem 15:44:24 meaning all dependencies are hardcoded name and version number 15:44:36 (which is why it is still hardcoded in pkg right now ...) 15:44:55 I modified it long ago so it accept only names without version 15:45:06 and it started globbing for name*.pkg 15:45:11 and only keep the newest one 15:45:25 but that does not fit with provides/requires 15:45:36 as I don't know in advance the name of all the candidates 15:46:02 so now pkg look up for all the .pkg around itself, extract the information and keep those information in memory 15:46:13 and this is where it kills kittens 15:46:38 loading all thos manifest in memory including plist was the initial issue 15:46:46 now I load the compact version so it is better 15:46:54 but still not good enough 15:47:15 but in poudriere you can end up with a quite large number of packages around the package you are trying to add 15:47:17 for what the ports tree is doing, is provides/requires even appropriate? 15:47:31 yes it is 15:47:56 I want to kill all the LIB_DEPENDS from the manifest 15:48:04 and use shlibs_provides/shlibs_requires instead 15:48:22 does anyone else want that? 15:48:27 it will make things way more flexible 15:48:52 there's already an issue with shlibs with the same names but different directories, I think 15:49:07 yes and no 15:49:10 but this is covered 15:49:20 anyway this is a different story 15:49:30 yes the provides/requires path is not easy 15:49:53 the right thing would be to make repository on the fly 15:50:10 I need to mesure how much memory this cost if the repository is "inmemory" 15:50:11 maybe, but fucking up the RAM usage in the meantime is not polite 15:50:18 agreed 15:50:58 if we do things well we can actually safe a lot of build time and memory 15:51:13 but my initial approach was not done well 15:51:22 so I need to think more about it 15:51:24 also, how long does it take to read all those manifests, and given how many times pkg add is run in a poudriere build, how much time and disk access is it costing? 15:51:42 it is actually quite fast 15:52:11 and if we do build a repository it can be done only once for the entire make *-depends phases and save a lot of time 15:52:19 I'm noticing nontrivial times spent in the *_depends build phases, though I don't have any "before" times for comparison 15:52:40 RhodiumToad: right now it is too much, because my approach has been too dumb 15:53:00 if by the end of the week I could not find a better approach I will just entirely back out the feature 15:53:13 thanks 15:53:31 and bring it back (hopefully fixed) for 1.21 :D 15:54:28 the thing is doing it right will be done in 2 phases 15:55:01 a first one which will be cost a bit, aha only modifiy pkg, then later modify the ports tree to use it properly and save lot of time 15:55:30 aka having one dep will be slower, but every package with multiple deps will be way faster 15:56:24 byw the best place to complain^Wdiscuss pkg is #pkg on libera :D 15:56:33 s/byw/btw/ 15:56:44 I haven't previously had reason to :-) 15:56:48 :D 15:57:38 I actually have an idea which would mean modify the package format 15:57:51 but long to implement 16:02:14 ok, I think I have an example of the shared lib issue 16:03:30 I have two packages that both say they provide a shared lib, but they do not include the path and they are not interchangeable 16:04:07 (in fact they install the lib to different dirs, neither of which should be on any ldconfig path) 16:04:52 (unfortunately they're not committed yet, since this is part of the guile flavors work which is STILL being ignored) 16:22:00 So if I want a lightweight 14"-class high-resolution laptop for FreeBSD use today, what do I get? :) 16:27:04 Do you want wifi to work? 16:27:25 er well I guess there's that wifibox thing now... 16:27:26 nm 16:47:15 I think the only thing standing in the way of FreeBSD on modern laptops the the performance cores? 18:31:27 Ltning: i've been eyeballing the 13" framework. in the end i'll probably pre-order the 16" -- https://community.frame.work/t/freebsd-on-the-framework-laptop/14823 18:31:29 Title: FreeBSD on the Framework Laptop - Framework Laptop 13 - Framework Community 18:38:01 I have a 13" frame.work, and it's been the biggest rollercoaster I've ever been on 18:39:22 same experience with my 13" framework. really bumpy ride 18 months ago, but mostly all just works now. 18:39:51 mine still gives me heartburn to this day, and I started actively using it... at the beginning of last year, I think 18:41:05 it locks ups if I try to use it on battery 18:41:38 it didn't boot the linux image we tried at bsdcan (and that particular image on that particular drive worked fine on another frame.work earlier in the week); it's simply cursed. 18:41:40 yikes, never had that issue. my struggle was mostly wifi driver support. 18:42:32 if you set a charge limit in the firmware, there's no low watermark so it constantly cycles between discharging/charging to maintain the set point 18:51:12 ah that's unfortunate to hear 18:51:55 that said, it's still been a pleasant experience as long as I keep it plugged in 18:52:29 to be clear, i have a first gen framework, so a newer model may be a different experience. 18:52:30 I have a hack to acpi_cmbat to limit notifications from being passed on past the kernel to mitigate the cycling problem 18:53:06 so upowerd only gets a snapshot every 5 minutes of what the laptop thinks it's doing 18:53:45 i was mostly under the impression markmcb alluded to. it works except wifi/bluetooth and someone on that forum just swapped out the wnic (there is a different follow up post about giving the option for wnic choice on the build out) 18:56:46 kevans: are you still working on getting freebsd running on mac m1? 18:59:26 yuripv oh I would be interested in that! 19:00:12 i'm just thinking to get rid of that stupid mbp, and get myself a frame.work, it really sounds like a lot of fun :D 19:26:37 yuripv: yeah, we're getting there slowly 19:36:34 yuripv i wonder if framework and FreeBSD are good together now. 19:43:49 antranigv: What was the FreeBSD on framework experience like before? 19:44:23 mexen when we got one it was brand new and there were some problems, specifically, as always, WiFi. 19:44:52 but I gave that laptop to an employee and he's running Gentoo on it, with frequent OpenBSD. OpenBSD doesn't seem to have any issues. 19:45:09 Oh I see 19:49:08 the wifi driver issue with the original framework was simply lack of support for the wifi6E AX210 card. that's resolved for awhile now. 19:50:02 speaking of wifi, doesn't freebsd support WPA3 yet? that was the other pain i recall as i couldn't join a wifi network that was WPA3 only. 20:52:56 so it seem that FreeBSD current is switched to OpenSSL3.0 --- is there a list of apps that needs to be migrated ? do we have a way of their status with regard to migration ---- obviously pkg needed OpenSSL so I have to reinstall FreeBSD 14 (I assume) ---- but wonder if there is an overview of the process in general ... 20:54:13 I assume FreeBSD current will brake while this transition ---- I was trying to use clonos/cbsd which is build on 14 - so I might need to delay 20:55:36 i've been rebuilding / rebooting from HEAD the last couple of months and didn't have much break but I don't run anything mission crit on this box 21:17:40 kevans: You didn't report anything related to the pkg timeout? 21:46:02 skered: ? 21:46:27 skered: bapt pointed out what he really wanted and I PR'd it. https://github.com/freebsd/pkg/commit/546b43dfe65c08c5e38a964afbb212aa561f9957 21:46:28 Title: libpkg: more accurately implement FETCH_TIMEOUT with libpkg · freebsd/pkg@546b43d · GitHub