do any of you run kodi without loading either x11 or wayland first?

I am asking this because on the console, I can't use either the keyboard or the mouse in kodi.

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?

*sigh* certctl hackery...

I believe it can still be done using environment vars, but the names of the vars changed

haven't tested it myself though

Some of them can, like http_proxy (lowercase), but I have had no luck with the CA stuff

Not even curl's own vars actually work

however, specifying a client cert is no longer possible as far as I can see

are you setting them in PKG_ENV or in the outer environment?

Neither works

huh. that's a problem

I only tried once, so there may have been effups on my part.

i believe bapt is quite receptive to feedback on it

yeah, the memory issue with pkg add was fixed pretty fast

and pkg 1.20.2 just landed in the tree

if anyone has issues with self signed certificate please test: people.freebsd.org/~bapt/patch-compat-libfetch (adding to ports-mgmt/pkg/files/)

Ltning: ^^ I have been told you have issues

the bapt has been summoned!

bapt: I am told I have issues too :D

Ltning: 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

Title: 272406 – ports-mgmt/pkg: pkg-1.20.1 does not work with FreeBSD-13.1-RELEASE-p8 GENERIC amd64

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.

We ended up in a situation where dozens of systems auto-upgraded pkg only to have pkg subsequently fail horribly

..requiring manual intervention on all of them :D

erg

And when pkg fails, puppet fails, and mayhem ensues. Config management rocks as long as nobody changes anything :D

so libcurl bundled in pkg expects to find its certificates in /etc/ssl/certs/

sounds like you simply need to reduce the number of hosts you run

compliants to certctl

which is supported and should be the default for all freebsd supported version

that said I bet if you have your own /etc/ssl/cert.pem is because you have your own CA right?

kevans: Yea but nobody wants to sell me the hardware I need to do that :P

bapt: Yeah. :)

Ltning: ampere? I imagine you guys don't do a whole lot that's x86-specific, at least?

I can make an option so that you can speficy your own .pem path

like SSL_CA_PATH

would that fit with you ?

160 cores and lots of RAM == lots and lots of jails or VMs

kevans: Yea, but .. Nobody will sell me any on this side of the pond. Delivery times counted in years.

yikes

"by the time it's delivered, they'll have already released the new and improved next generation"

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

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

kevans: So we're stuck with all this epyc garbage until someone decides Norway is important enough

well, up to when china stole the ip of that company

sorry, a chinese citizen who then moved to china

I am not against SSL_CA_PATH, tbh I think it will serve a lot of people

who do not want to know how certctl works

bapt: Yeah, it would be a lot easier for us, that's for sure. Is that the same var fetch would respect?

so if this is ok for you I will can add it, it will take me a few minutes

there's still a lot of cases where certctl could integrate better with ports to make it more compelling

SSL_CA_CERT_PATH

is SSL_CA_PATH because the cert bundle already uses a similar naming scheme? because "SSL" is kinda.. a misnomer nowadays

this is what fetch expects

I will use that variable so it is compatible

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

bapt: It'd be good if it follows what fetch expects (which I believe worked for old pkg).

Since that's how we have been doing this until now ..

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

Depends what "sponsor" entails. We'd certainly like a certctl that does (more) useful things. Just not as a surprise.

kevans: You're too busy with the mbp? ;)

hehe :-) that's one of the projects, kinda waiting on stable/14 to branch to drop the next important changes

I started landing some of the work and have another review or two open

looks like my laptop is toast, kevans are you implying I should wait a few weeks and get a fruity one instead?

maybe 6 months t oa year

Uh-oh, now what did I do

Ltning: freebsd/pkg f59cb51

Title: curl: allow to specify the CA to use via env var · freebsd/pkg@f59cb51 · GitHub

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

Ltning: can you try with this patch?

dch: already fixed by kevans

bapt: Looks sane to me. I'm not able to test that in any useful environment on short notice

do you want me to re-try later with 1.20.2?

dch: after 1.20.3

I might be on a plan to NZ by then

erg

I miss read fetch3

SSL_CA_CERT_FILE is the right thing

yea I just realised

Both are probably useful though, if we want backwards compatibility

It's also possible our way of doing this has been batshit all the time, and we need to stop. :)

I don't intend to be 100% compatible with libfetch, only on what make sense :D

with my own definition of what make sense

The power of definition is among the mightiest.

that said we are now probably 90% compatible, the latest 10% might not hurt to implement

anyway I will a batch of tests during the night and issue a 1.20.3 tomorrow

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

yes

(1GB system without swap)

the problem is the ports tree uses pkg add

and pkg add should die in hell

pkg add is a dirty thing made to mimic pkg_add

which was looking for its dependencies around itself

on the filesystem

meaning all dependencies are hardcoded name and version number

(which is why it is still hardcoded in pkg right now ...)

I modified it long ago so it accept only names without version

and it started globbing for name*.pkg

and only keep the newest one

but that does not fit with provides/requires

as I don't know in advance the name of all the candidates

so now pkg look up for all the .pkg around itself, extract the information and keep those information in memory

and this is where it kills kittens

loading all thos manifest in memory including plist was the initial issue

now I load the compact version so it is better

but still not good enough

but in poudriere you can end up with a quite large number of packages around the package you are trying to add

for what the ports tree is doing, is provides/requires even appropriate?

yes it is

I want to kill all the LIB_DEPENDS from the manifest

and use shlibs_provides/shlibs_requires instead

does anyone else want that?

it will make things way more flexible

there's already an issue with shlibs with the same names but different directories, I think

yes and no

but this is covered

anyway this is a different story

yes the provides/requires path is not easy

the right thing would be to make repository on the fly

I need to mesure how much memory this cost if the repository is "inmemory"

maybe, but fucking up the RAM usage in the meantime is not polite

agreed

if we do things well we can actually safe a lot of build time and memory

but my initial approach was not done well

so I need to think more about it

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?

it is actually quite fast

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

I'm noticing nontrivial times spent in the *_depends build phases, though I don't have any "before" times for comparison

RhodiumToad: right now it is too much, because my approach has been too dumb

if by the end of the week I could not find a better approach I will just entirely back out the feature

thanks

and bring it back (hopefully fixed) for 1.21 :D

the thing is doing it right will be done in 2 phases

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

aka having one dep will be slower, but every package with multiple deps will be way faster

byw the best place to complain^Wdiscuss pkg is #pkg on libera :D

s/byw/btw/

I haven't previously had reason to :-)

:D

I actually have an idea which would mean modify the package format

but long to implement

ok, I think I have an example of the shared lib issue

I have two packages that both say they provide a shared lib, but they do not include the path and they are not interchangeable

(in fact they install the lib to different dirs, neither of which should be on any ldconfig path)

(unfortunately they're not committed yet, since this is part of the guile flavors work which is STILL being ignored)

So if I want a lightweight 14"-class high-resolution laptop for FreeBSD use today, what do I get? :)

Do you want wifi to work?

er well I guess there's that wifibox thing now...

nm

I think the only thing standing in the way of FreeBSD on modern laptops the the performance cores?

Ltning: i've been eyeballing the 13" framework. in the end i'll probably pre-order the 16" -- community.frame.work/t/freebsd-on-the-framework-laptop/14823

Title: FreeBSD on the Framework Laptop - Framework Laptop 13 - Framework Community

I have a 13" frame.work, and it's been the biggest rollercoaster I've ever been on

same experience with my 13" framework. really bumpy ride 18 months ago, but mostly all just works now.

mine still gives me heartburn to this day, and I started actively using it... at the beginning of last year, I think

it locks ups if I try to use it on battery

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.

yikes, never had that issue. my struggle was mostly wifi driver support.

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

ah that's unfortunate to hear

that said, it's still been a pleasant experience as long as I keep it plugged in

to be clear, i have a first gen framework, so a newer model may be a different experience.

I have a hack to acpi_cmbat to limit notifications from being passed on past the kernel to mitigate the cycling problem

so upowerd only gets a snapshot every 5 minutes of what the laptop thinks it's doing

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)

kevans: are you still working on getting freebsd running on mac m1?

yuripv oh I would be interested in that!

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

yuripv: yeah, we're getting there slowly

yuripv i wonder if framework and FreeBSD are good together now.

antranigv: What was the FreeBSD on framework experience like before?

mexen when we got one it was brand new and there were some problems, specifically, as always, WiFi.

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.

Oh I see

the wifi driver issue with the original framework was simply lack of support for the wifi6E AX210 card. that's resolved for awhile now.

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.

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 ...

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

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

kevans: You didn't report anything related to the pkg timeout?

skered: ?

skered: bapt pointed out what he really wanted and I PR'd it. freebsd/pkg 546b43d

Title: libpkg: more accurately implement FETCH_TIMEOUT with libpkg · freebsd/pkg@546b43d · GitHub