jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
<marcan>
jannau: apparently the reason those PRs were ignored is because there was something wrong with them
<marcan>
and the maintainer's approach to that is to just... ignore them?
<marcan>
"I fixed and committed the 16k PRs, but this will be the last time that I do so." (direct quote)
<marcan>
this... does not give me confidence about this upstream :(
<marcan>
I hope he reconsiders and tries to work with us, or I might be seriously tempted to move to Fedora or something... we can't work with "if your PR is wrong it gets ignored" :(
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
gff has joined #asahi-dev
gff_ has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
PyroPeter_ has joined #asahi-dev
PyroPeter has quit [Ping timeout: 480 seconds]
a_plastic_bag has joined #asahi-dev
jialixu[m] has joined #asahi-dev
a_plastic_bag has quit [Quit: WeeChat 3.6]
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
nehsou^ has quit [Remote host closed the connection]
nehsou^ has joined #asahi-dev
kettenis has joined #asahi-dev
benpoulson has joined #asahi-dev
<chadmed>
suddenly glad i took the time to get gentoo working properly(tm) then...
<chadmed>
what an awful attitude
benpoulson has quit [Ping timeout: 480 seconds]
paulywog has joined #asahi-dev
<jannau>
I fear it's short-sighted strategy to deal with too much work. it might also work long-term by driving users away
<jannau>
I'm still confused why everyone seems to be happy with support for a different architecture is another distribution
<chadmed>
the arch community is just like that
<chadmed>
its user base exists in spite of its hostile and insular community, not because of it
the_lanetly_052 has joined #asahi-dev
<chadmed>
the arch heavyweights who make these decisions probably just think arm is "soy" or whatever these types are saying about anything-that-isnt-a-pc-with-dwm systems these days
<paulywog>
^^ people who haven't yet left a twitch stream running on battery overnight and come back to their laptop still solidly charged
<chadmed>
no dude a thinkpad with an 800mhz centrino in it is more chad and based ok dont ask questions it just is
<paulywog>
anyone know what's been "started" with the hwmon driver in the yak shaving section? It's likely something I could poke at but I don't know if someone has mostly completed it and just has it stashed on some branch
<chadmed>
havent heard anything on that front since the person edited the page initially
<chadmed>
it should be simple enough to do even as an exercise if you want to, we already have SMC support you just need to grab the keys out of it and tell hwmon what each of the keys are in terms of sensor readings
<paulywog>
yeah I've already looked at macsmc_power, looks pretty straightforward
<mps>
chadmed: on alpine we are trying to work equally on all 7 arches, and now also riscv
<chadmed>
check the python stuff in m1n1 for the most up to date list of keys
<mps>
chadmed: it doesn't always work well, and some arches have some problems but we don't ignore these problems
<mps>
yes, I know that gentoo people also does same
<paulywog>
thanks for the lead chadmed, that'll be helpful
fp has joined #asahi-dev
<paulywog>
figured there was likely to be something more
<chadmed>
you can make m1n1 dump out the keys with their current values so that will probably be the best place to start for finding which is which for stuff not listed on the wiki
veloek has joined #asahi-dev
<paulywog>
interesting, I thought m1n1 was a bootloader, but it's clear there's more to it
fp1 has joined #asahi-dev
fp has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-dev
paulywog has quit [Quit: leaving]
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<Dementor[m]>
marcan: did he say what was wrong with it? Or give you chance to fix it?
<marcan>
nope, he just fixed them himself so I guess now we get to diff the original PR and what was committed and learn from the diff...
<marcan>
my email was about helping out because I thought he was overworked and that's why the PRs hadn't been looked at in 5 months, and he fired back with that. I'm concerned.
<marcan>
I'd go with Gentoo but "compile everything yourself" just isn't practical for the average user, and I'm not going to sign up to maintain a golden /etc/portage and binhost
<jannau>
the rust and jemalloc changes were indeed wrong since we forgot that alarm supports armv7-a as well
<marcan>
doesn't really matter *why* they were wrong if he doesn't tell us... and we can't work with a "submit a PR, and guess it might be wrong if it doesn't get merged in 2 weeks" dynamic
<marcan>
I really, *really* hope he changes his approach, because if not I'd much rather pull the rug out under our users now and switch distros than do it years down the line
<marcan>
Glanzmann: I occassionally have to deal with Debian packaging for a side gig and I have no interest in making it part of my main job, sorry ;)
<Glanzmann>
Worth a try.
<mps>
:)
<marcan>
plus Fedora have been the first and so far only distro to offer to support these platforms officially, and that is *very* important
<marcan>
since our goal is to cease to exist
<marcan>
(that said, I've never used Fedora, so I'd have to try it)
<marcan>
(OTOH I *did* have to mess with Fedora packaging once for a Ceph PR, and that was not too painful)
<dottedmag>
Glanzmann: That process took me 2 years
<dottedmag>
Granted, it was a long time ago
<marcan>
my project lead spidey-sense points towards Fedora too right now, for whatever that's worth (but I think it's served me well so far ;)
<mps>
iirc I was few times on debian new maintainer process but didn't finished any, too burauecratic
<marcan>
yeah, bureaucracy is the last thing we need
<mps>
I would say that alpine because it is similar to arch, but alpine uses musl so I think most people will feel not comfortable with it
<Glanzmann>
mps: I considered once to become a Debian maintainer, but than dropped it. But I have a good friend who would sponser me, if I want to go ahead with it.
<marcan>
too niche for desktop use and we don't need even more exotic choices that can cause software to break (sorry Ariadne)
<mps>
marcan: yes, I agree
<marcan>
Asahi isn't supposed to be opinionated about anything. Heck I went with Arch because it basically isn't, it's largely just unmodified upstream packages.
<mps>
and also I wouldn't be pleased to work on help to newcomers who want ready-made big DEs
<marcan>
Gentoo is not practical, so that leaves Debian and Fedora really, unless I forget about some other major distro
<mps>
well, imo arch is quite fine
<marcan>
arch is quite fine if we can get things upstreamed and work with the maintainers. apparently, that might be a problem..
<mps>
well, I fear you will meet same or similar with other distros, sooner or later
<marcan>
so far every Fedora person who has talked with me has been nice, and they've shown *active* interest in supporting these platforms, which is a far cry from ignoring PRs
<marcan>
ALARM is basically just one guy running the show, and if that one guy doesn't want to work with us, we have a problem :(
<mps>
ime debian is too slow for accepting new things and changes
<marcan>
agreed
<marcan>
but I bet at least they'd fix bugs faster than 5 months
<mps>
yes
<mps>
Glanzmann: yes, debian people are good ones. but process and rules, uhm
<mps>
oh I forgot, postmarketOS people works on using apple silicon also, didn't looked much how far they are now
<marcan>
that's an alpine derivative
<marcan>
and apparently focused on phones
<mps>
yes, but they added these different DEs
<marcan>
we're not going to chain off of a second-level distro, that makes even less sense
<mps>
and not only on phones, but also on arm notebooks
<mps>
alarm is also some kind of second level distro
<mps>
but yes, I agree that for anything based on musl will make a hassle
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #asahi-dev
<dottedmag>
marcan: the only another large first-level distro (that is, coming with its own package repository - you mean that by first-level, right?) is openSUSE, everything else seems very niche. So yeah, looks like Fedora is the only viable candidate.
<marcan>
yeah, I forgot about SUSE :)
<marcan>
but then again, one of the people pushing for Fedora support for us is... on the OpenSUSE board... so I'll take that as a sign that we should go with Fedora
<as400[m]>
Guys, is decision of changing a distro already taken ? Or it's just discussion ?
<kazukih[m]>
What about Manjaro?
<kazukih[m]>
Then you can just use the pkgbuilds you made for alarm without changing much
<AdryzzOLEDEdition[m]11>
manjaro relies on ALARM
<kazukih[m]>
Huh, I thought they had different maintainers
<as400[m]>
The only thing that would be lost going with Fedora would be ALARM rolling characteristics
<kazukih[m]>
Ah looks like a big chunk of Manjaro-arm stuff is based on alarm, my bad
<marcan>
Fedora does have Rawhide and apparently updates mid-cycle for the most part, even in the regular releases
<marcan>
as400[m]: Discussion
<as400[m]>
marcan: ok, asking out of curiosity. I do know the pain though.
<marcan>
but it really does come down to Kevin's handling of this situation, because if we're going to switch base distros, I'd much rather do it now than a year down the line when we have an even bigger userbase
<marcan>
so let's hope he reconsiders his PR strategy, and otherwise, I'm going to start looking into Fedora
<as400[m]>
Everything you wrote above in this discussion is perfectly understandable. And if you're forced to do a switch, doing it early as possible would be beneficial for sure.
Chainfire has quit [Remote host closed the connection]
conradev8 has quit [Quit: -]
conradev8 has joined #asahi-dev
leitao has joined #asahi-dev
benpoulson has joined #asahi-dev
<dottedmag>
Hopefully year down the line the switch will be "remove the distro bits, all upstreamed" :)
<marcan>
yup, that's the hope
<marcan>
and Fedora already has a PR for adding the upstreamed Asahi bits to their kernel, so that's a start!
<marcan>
though we'll probably forever be a bleeding edge repo anyway, so the switch will be more like "you can now drop the asahi repo if you want a stable distro"
<marcan>
and we'd probably only offer the non-asahi image in the installer, and users can add the extra asahi bleeding edge repo if they want
<marcan>
much like asahi and asahi-dev today
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
<Dcow[m]>
I personally like Fedora and been using it for long time. Gentoo is one love, but it too time consuming.
<Dcow[m]>
But what about fedora on ARM? it is binary distro, so we have to consider richness of the repo?
<chadmed>
its as mature as alarm is and better maintained
<as400[m]>
chadmed: does fedora have something similar to aur ? Or any user maintained repos ? I haven't used it for years now.
<Dcow[m]>
Fedora Workstation is default to Gnome, how about that?)
<chadmed>
besides the more important thing right now is willingness to cooperate on repo maintenance. if the maintainers are more proactive and hospitable with their merge policy, then growing the repo wont be too much of an issue
<chadmed>
you can use rpm fusion on fedora which is basically the proto-aur anyway
<chadmed>
and there are also spins of fedora with all the major DEs so its not like you _have_ to use gnome
<chadmed>
itd be the first thing i yeet off my system if i ever migrated
<chadmed>
but i spent all that time on gentoo enablement for a reason
<marcan>
chadmed: I honestly wonder whether I'll end up on Gentoo or not, it depends on what's available. e.g. ALARM actually had more proaudio stuff than Gentoo sans overlays.
<marcan>
sometimes it gets tiring fixing the weekly build problems on my buildhost
<chadmed>
true actually, theres still no ebuild for carla in the main gentoo tree
<chadmed>
might have to fix that on the holidays...
<marcan>
so there's a chance I'll get used to Fedora or what have you... though I probably will keep Gentoo on the servers because I'm comfortable with that (and my server binhost chroot is the least troublesome one, since it's not ~amd64 and has much fewer packages/USE flags)
<marcan>
ALARM's carla crashes opening zynaddsubfx, I found that out yesterday, but a source build works fine. OTOH, it's not saving the zyn/drumkv1 preset data... I feel like somehow Carla is always broken for me in some way
<marcan>
(not saving plugin data, not saving the patchbay layout, *something*)
<marcan>
I'm supposed to be a maintainer for the gentoo audio-overlay, but these days I have ~zero time for that...
<marcan>
already dropped proxymaint for the couple packages I had because I just can't attend to bugs
<marcan>
the main benefit of gentoo for me right now on desktop is ease of patching, but if I can figure out Fedora package builds, that doesn't really matter for fixing things broken today. that leaves "long-term" patches
<DmitrySharshakov[m]>
Why did you drop openSUSE from the discussion?
<marcan>
looking around my /etc/portage... it's all build fixes or things I don't care about, except for one specific patch: a hack for kwin to disable Night Color on external outputs, so it doesn't affect my stream (a problem I had early on)
<marcan>
I can probably figure out how to make that a properly developed setting/patch and upstream it in less time than I spend babysitting my desktop binhost, tbh
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
(or maybe once I move to M1 there will be enough free CPU to just do the stream capture/forwarding in software rather than hardware)
<marcan>
(ooh, cute idea: thunderbolt support for efficient computer-to-computer screen capture)
<marcan>
(dma-buf over thunderbolt anyone?)
<DmitrySharshakov[m]>
I have sometimes looked at it and it's great for custom builds (OBS), also pretty beginner-friendly. I use Fedora on my computers, but am looking at openSUSE MicroOS as a great distro for some future systems. Overall openSUSE Tumbleweed should be a decent alternative to Arch, as Fedora Rawhide is not a rolling distro but a testing platform
<marcan>
mostly because no openSUSE people have showed up to propose Asahi support, while Fedora people have :)
<DmitrySharshakov[m]>
`(dma-buf over thunderbolt anyone?)` I've seen network over TB in default Linux. I guess it used some sort of shared memory thing
<DmitrySharshakov[m]>
If memory is unified then passing a GPU memory BO shouldn't be a problem
<marcan>
there's no such thing as GPU memory, it's unified
<marcan>
so yes
<DmitrySharshakov[m]>
Yes, I meant memory object related to GPU work
<DmitrySharshakov[m]>
Can it be possible for at least compute workloads running on eGPU? I heard that the issue is like lack of GTT support in M1/M2 PCIe controller?
<DmitrySharshakov[m]>
Or what is lacking for it to work really?
<marcan>
the issue is there is no mapping GPU memory as normal memory
<marcan>
which is going to affect compute workloads even worse most likely
<marcan>
e.g. you can't use unaligned loads/stores on VRAM, no cache, etc.
<mps>
heh, interesting discusion about distro. didn't knew so much problems exit. could be because I use alpine which works out of the box from the beginning and don't have these problems ;p
<DmitrySharshakov[m]>
So textures/other buffers have to be copied since they cannot be placed into a memory area usable for both SoC and GPU?
<chadmed>
the only real distro-related issue ive had in the past like 6 years is having to sed -i s/unwind/llvm-libunwind/ the samba ebuild every system update
<chadmed>
but thats my fault for not reporting upstream that it works and they can stop hard depending on libunwind
leitao has joined #asahi-dev
<dottedmag>
marcan: Any ideas already what to look at for local patching on Fedora? I was looking for setting up a way for Gentoo- or NixOS-like local customizations, but with a more mainstream distro.
<dottedmag>
marcan: Or rather, please share if you find anything usable or make one.
<marcan>
silverblue is also a point for fedora, since several people have asked about a macOS-like secureboot setup for Linux, and that's never going to happen with ALARM
<marcan>
being able to just drop that in and build a neat little secureboot setup when we get there would be *really* cool, even if not that many people actually use it
<marcan>
(macOS-like as in immutable system volume)
<marcan>
(obviously we will support more traditional secureboot setups for everything, relying on FDE for security)
<mps>
chadmed: oh, I have issues ofc, but I try to find bugs, fix, report upstream etc
<marcan>
so far I've only had problems getting things upstreamed with ALARM, and funny enough, Arch itself, though my sample size there is 1
<marcan>
Gentoo depends on who the package maintainer is, but they will usually take PRs pretty quickly
<mps>
btw, for pkgs I maintain in alpine I often look in alarm and Arch to find some ideas or solutions
<DmitrySharshakov[m]>
`macOS-like secureboot` - like setting up an immutable volume with dm-verity etc? Yes, that's quite a great concept
<marcan>
yup
<DmitrySharshakov[m]>
marcan: I also wanted to chat a bit about some ideas about secure boot
<mps>
if that issue with Kevin could be solved in fine manner I don't see strong reason to change
<marcan>
let's see what his reply is
<chadmed>
yeah but... can it?
<marcan>
either way, my intent was always to have several official supported distros, and regardless of whether #1 on the list is ALARM or not, I am interested in seeing Fedora get more official support
<DmitrySharshakov[m]>
Secure boot trust chain can have various implementation and that also makes a factor for distro choice: how breaking would out secure boot policy changes be
<marcan>
the secureboot chain hands off to m1n1 and after that we can do/trust whatever we want
<DmitrySharshakov[m]>
Probably with some U-Boot patches it can be made to support sort of true UEFI-standard secure boot
<DmitrySharshakov[m]>
The root of truct is m1n1-1 baked into boot policy
<DmitrySharshakov[m]>
s/truct/trust/
<chadmed>
ideally and eventually it will be the SEP
<marcan>
the SEP is involved in FDE but not really secureboot
<chadmed>
we couldnt use it to store keys/hashes of payloads?
<DmitrySharshakov[m]>
Well, but I guess reversing the SEP is less trivial and might take a long to be really secure and more important - reliable
<marcan>
I'm not sure UEFI-standard secure boot is necessarily the best idea here... at the point where you have a fully integrated secureboot distro, it might make sense to just start bundling up m1n1-stage2+u-boot+kernel+initramfs into one image, signing that to be loaded by stage1, and calling it a day
<DmitrySharshakov[m]>
But quite a great security can be accomplished even without any SEP driver
<DmitrySharshakov[m]>
marcan: Yes, it can be like that
<marcan>
chadmed: not really, it requires the xARTS stuff for storage and I don't see us putting an APFS driver in u-boot
<chadmed>
oh yeah of course
<marcan>
SEP is primarily useful for protecting mutable user data
<marcan>
it is not really involved in secure boot beyond the bootpolicy stuff
the_lanetly_052__ has quit []
<DmitrySharshakov[m]>
Since emulating all the MOK dances can be quite demanding and it's easy to do something wrong implementing that spec
<marcan>
yup
<marcan>
UEFI secure boot is a shitshow, and the nice thing about this platform is we can bypass that
<marcan>
you'd want a locked down u-boot that just boots an embedded kernel and that's it
<marcan>
no USB or NVMe drivers
<DmitrySharshakov[m]>
But we want to retain the GRUB/sd-boot I guess, so not welding m1n1-2+u-boot+kernel+initrd, as if kernel update breaks something I'd like to be able to choose previous one
<marcan>
then the only secureboot-relevant component before the kernel is m1n1, and that's why that part of the code is written in Rust
<marcan>
that's a fair point, but a bit tricky... and at that point, it might actually make sense to make m1n1-stage1 able to boot multiple stage2s. That also, conveniently, solves the device tree incompatibility problem, by allowing separate DTs for each kernel.
<marcan>
adding a little menu that just looks for files in /m1n1/ would be pretty trivial, and can be done securely in the Rust code
<DmitrySharshakov[m]>
Also I've once opened a question issue on GH whether booting m1n1 test builds on emulators would be easy enough. That'd help interested people without hardware (like me huh) to do hw-independent stuff and maybe autotests and fuzzing
<marcan>
it isn't, because m1n1 relies heavily on Apple-specific features
<marcan>
its entire purpose is to deal with all the Apple-isms
<DmitrySharshakov[m]>
marcan: And then conventional bootloader is gone completely? So m1n1-1 -> choice -> m1n1-2 -> u-boot + kernel + initramfs bundle is the boot sequence?
<marcan>
yes
<DmitrySharshakov[m]>
marcan: Well, like I expected. feel free to close or I can do that
<chadmed>
its easy enough to build a new stage2 from userspace that this really isnt the hinderance that it used to be with all the kmutil nonsense
<chadmed>
update-m1n1-secureboot or some such
<marcan>
yeah, though for a "distro-managed" secureboot distro, the distro would do that in a single package anyway, and ship it pre-signed
<marcan>
for a "user-managed" mode they'd keep their own private key, but then we need some way for the installer to securely pass that into the installed OS, which is at least a little bit tricky
<marcan>
(unless SEP is involved, but I don't see pulling that off from macOS being easy...)
<DmitrySharshakov[m]>
So probably for now we need that bootpicker in m1n1 and a more generic package for handling all the userspace stuff. Well, an utility like sbsign or update-grub which will weld m1n1-2 and all the subsequent parts together, then go to ESP, ask user's password to decrypt the private key, sign and store things
<marcan>
something like that, yes, for a user-managed version
<DmitrySharshakov[m]>
marcan: Was going to write my ideas
benpoulson has quit [Remote host closed the connection]
<marcan>
if using distro-managed public keys it'd be done by the distro
<marcan>
(like apple does)
benpoulson has joined #asahi-dev
<DmitrySharshakov[m]>
We can use AES + password-derived key I guess. recoveryOS part of the installer generates the keypair, burns pubkey into m1n1-1, and encrypts private one to be stored in the ESP
<DmitrySharshakov[m]>
Or gpg can be bundled into the part 2 of the installer to accomplish the job
<DmitrySharshakov[m]>
This way we get a machine-owner-password-encrypted private key for signing. On updates machine owner has to confirm the action by entering their password
<DmitrySharshakov[m]>
Or some keyslot madness can be implemented, so in case multiple users are present they all can unlock the keyfile
benpoulson has quit [Remote host closed the connection]
<marcan>
that's a bad idea, it lowers the security guarantees of the platform
<DmitrySharshakov[m]>
Can we run a custom Rust binary in recoveryOS for the sake of simplicity?
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<DmitrySharshakov[m]>
marcan: What of those exactly?
<marcan>
it's not possible to guarantee secure erasure of such a key file (this is why apple have effaceable storage), and therefore you potentially forever tie the security of secureboot to the user password, even if they change it
<marcan>
LUKS at least *tries* to be a bit better than doing it the naive way by hashing a bunch of random data IIRC
<marcan>
but if we can do SEP-backed FDE that's much better and solves this problem
<marcan>
ideally we figure out some SEP voodoo to allow wrapping the key file with that in macOS in a way that is then accessible again from Linux, but I'm not entirely sure that's possible, though it ought to be, since FileVault works like that?
<marcan>
this needs more research
leitao has joined #asahi-dev
<marcan>
and it doesn't help that we can't hit raw SEP APIs from macOS as far as I know, only the public ones
<DmitrySharshakov[m]>
Hmm, so we can have separate profiles (like full and reduced security)
<marcan>
it's possible that the ticket ends up being creating a tiny FileVault-enabled volume in the stub partition, sticking the key material in there, and then reading it from linux
<DmitrySharshakov[m]>
full security just enforces use of distro-provided kernel+initrd, will require support from distro
<marcan>
that should definitely work, doesn't require any funny primitives from macOS, etc
<marcan>
it just means we need to support APFS and SEP enough to mount FV-enabled volumes
<DmitrySharshakov[m]>
and reduced security is for those who want custom builds, they have a password-protected key story
<marcan>
either way, this is relatively far in the future :)
<marcan>
we'll see once SEP support starts taking shape
<DmitrySharshakov[m]>
`it just means we need to support APFS and SEP enough to mount FV-enabled volumes` are you sure SEP container stuff doesn't restrict that? Or it'll be like encryption of an external drive?
<marcan>
it does not, pretty sure you can log in and mount a separate OS's Data volume as long as you can log in as a valid user
chengsun_ has joined #asahi-dev
<marcan>
I think they are stricter on iOS though
<DmitrySharshakov[m]>
marcan: Couldn't we do some sort of secure boot (with a password-protected key) to improve quality now and then replace it by SEP-backed hardware security?
<marcan>
ah, but wait, FV requires full security, doesn't it? :/
<marcan>
well, maybe it doesn't for non-OS volumes
<DmitrySharshakov[m]>
idk
<marcan>
I guess this needs testing
chengsun has quit [Ping timeout: 480 seconds]
isoriano has joined #asahi-dev
<DmitrySharshakov[m]>
At least that 'first approach' I suggested gives the same degree of security as custom sb keys on PC platforms. Btw you could also store the key on external media or do a secure erasure of the key material when changing the password
fp2 has joined #asahi-dev
<marcan>
"secure erasure" isn't a thing on SSDs
<DmitrySharshakov[m]>
and when a better approach is ready (SEP-backed wrapping), then you free up some space in the container, do a trip through recoveryOS and enroll the new m1n1 then wrap its key in a new fashion
<marcan>
hence apple's effaceable storage stuff
<DmitrySharshakov[m]>
Well yes. But the risk is still low enough for casual users and attacker will have to desolder NAND to take a look at lost fragments of a broken cryptocontainer (which first has to have a compromised password or cryptography)
fp1 has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
And for high-value cases a config option can be set to store the key on external media which can be wiped better
chengsun_ has quit [Quit: Quit]
chengsun has joined #asahi-dev
joske has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #asahi-dev
yrlf has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
isoriano has quit [Remote host closed the connection]
<sven>
so i've wondered for a while why DP mode seems to have less tunables in the ADT than all the other modes
<sven>
turns out it's because for some reason Apple decided to just put the "missing" DP tunables directly into the kext
<povik>
can't we just shove these <150 lines in kernel and be done with it?
<Ariadne>
marcan: i mean, i don't disagree?
<Ariadne>
(though i think on an architecture like aarch64, the need to care about compatibility with GNU/Linux is largely irrelevant)
<marcan>
povik: :/
<marcan>
Ariadne: :)
<povik>
yeah it's not going in
<povik>
so i guess that goes in my _archive/
<Ariadne>
marcan: my only problem is when for-profit companies decide to slag alpine to get customers for their image lobotomization product ;)
<Ariadne>
(or when the same people did this years ago to sell ubuntu advantage)
<marcan>
I know, I know :)
<Ariadne>
alpine is designed from the position that people are already quite familiar with unix-like systems, so using something that is more straightforward means less work is needed to polish it
* Ariadne
shrugs
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
leitao has quit [Remote host closed the connection]
<mps>
Ariadne: also I wouldn't like idea that alpine evolve to next ubuntu
<Ariadne>
i do not think you have to worry about that happening
<mps>
I hope so ;)
<qcyrdqcpzg[m]>
is the apple cli tool "powermetrics" reliable? specifically the ANE metric?
<Glanzmann>
marcan: +1 for putting a boot picker in m1n1.
<povik>
that's in consideration?
<AdryzzOLEDEdition[m]11>
there are no manuals
<AdryzzOLEDEdition[m]11>
nor parts
<AdryzzOLEDEdition[m]11>
oh it says tomorrow
<Glanzmann>
povik: It wasn't and we were never going to do that until I read todays backlog. But I often thought about doing it myself but than said it is wasted time because marcan would never merge it.
<Glanzmann>
But that would solve our choose the right dt for the kernel issue and would allow us to have multiple kernels installed with different dts.
<marcan>
in *principle* that shouldn't be required once the DT stabilizes, but it can help in the early days. but I'm more interested in it for secureboot.
fp3 has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit []
<povik>
marcan: did you catch that i sent you the rebased/updated audio branch?
<povik>
not pushing, just making sure you saw it
fp2 has quit [Ping timeout: 480 seconds]
<_jannau_>
and there's a libglvnd release with the BTI fix in the case someone likes their branches protected on M2
<Glanzmann>
jannau: Nice.
<_jannau_>
povik: marcan was considering using github pull requests as reminders without intention to merge them
<povik>
:D
<povik>
(to branches protected)
<_jannau_>
i.e. a PR against the bits/audio branch with the conflicting new state. if devicetree are required, just mention that and branch/commit in the PR description
<_jannau_>
povik: gcc switch to enable it is '-mbranch-protection=...`
___nick___ has joined #asahi-dev
<povik>
let me try the fake PR workflow then
<povik>
possibly diffs will still work
___nick___ has quit []
___nick___ has joined #asahi-dev
nehsou^ has quit [Remote host closed the connection]
<povik>
didn't like how slow github's UI was, i guess because it's struggling with the size of the repo/its network
<Dcow[m]>
povik: looks like you have already implemented amp limit and normalizing on the probe. What other danger endpoints there yet to be fixed?
<povik>
also silly me put the cs42l84 schema in sound/soc/codecs/
<povik>
Dcow[m]: also the codec highpass is set on tweeters
<povik>
possibly none
<povik>
marcan may test it now
<DmitrySharshakov[m]>
I guess MacBook Air's also need some sort of capping functions, but as those are not present now (at least weren't there yesterday) driver will refuse to probe. Quite a smart solution to protect everything :)
<Dcow[m]>
povik: Thanks for update!
<DmitrySharshakov[m]>
I guess when somebody sets those for MBA then audio is ready to be shipped by default and for MBP will have to either ship asahi-audio PipeWire configs or wait for WirePlumber patches
<DmitrySharshakov[m]>
Will probably ping somebody of WirePlumber maintainers to review parts necessary
Race has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
___nick___ has quit []
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
benpoulson has quit [Remote host closed the connection]
leitao has joined #asahi-dev
mia_ has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
chengsun has quit [Ping timeout: 480 seconds]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
<jannau>
povik: mac studio m1 ultra (j375d), m1 max should be identical trace_codecs.log
<jannau>
would it be useful to do something with the headphone jack on unkown cs42l84 devices?
<jeffmiw>
paulywog: about hwmon, I have been looking into it, ramping very slowly due to limited time. I do not have anything useful to share yet as started from zero knowledge on hwmon and smc.
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
Race has joined #asahi-dev
jnn has joined #asahi-dev
jn has quit [Ping timeout: 480 seconds]
<chadmed>
DmitrySharshakov[m]: no way are we packaging a beta branch of wireplumber just to jump the gun by a couple of months. as julian points out in that note, it will be released in a couple of months, so we can just wait.
<chadmed>
for one, i dont want to write an ebuild for it, and for another i dont want to deal with "why does wireplumber work on all my other machines but is janky on asahi" type support questions that come with forcing unstable testing branches on users who are not prepared to deal with them
<chadmed>
the time is better used testing the proposed features ourselves and smoothing out the experience
<chadmed>
something something ethical hacking et cetera and so on and so forth