08:00 <jannau> chadmed: any idea what to do with rc based kernels? I suppose genpatches for them will only be released after the final release

08:01 <chadmed> yeah ive been meaning to ask sam_ about that

08:01 <chadmed> i tried adding the genpatches to an _rc5 ebuild but ofc it couldnt find any for 6.0

08:01 <chadmed> glad i got them working at all though, it was a bit of an ordeal

08:02 <jannau> did you dislike my idea to use "_pX" for the tag version?

08:02 <chadmed> nah thats fine, but unipatch() actually patches the source tree to the corresponding kernel version of the patch set

08:03 <chadmed> so now that we apply patches we actually get a full linux-5.19.3-asahi

08:03 <chadmed> i just removed the _pX because i got rid of all the ebuilds with previous tags since they are outdated and shouldnt be installed by anyone at this stage

08:05 <jannau> yes, I saw that. I would like to change that to asahi-sources-5.19.3_p5 to represent asahi-5.19-5

08:06 <jannau> it might be even possible to extract the tag from ebuild version

08:08 <chadmed> well when you set ${PV} it will include the _p5 iirc so you can just slice that variable

08:08 <chadmed> (when portage sets ${PV}*)

08:27 <jannau> yes, the only minor problem is to reliably extract it from $PV. vers_ functions are not helpful if you can't rely on a static X.Y.Z_pA version scheme

08:31 <chadmed> so do you wanna just add _pX to every release and track tags? im happy to do that if you think itll be useful

08:39 <jannau> yes, I think it's useful to do version bumps just by renaming/copying the ebuild

09:59 <chadmed> jannau: _pX has returned

10:00 <chadmed> im testing something for povik's sanity right now so im not gonna investigate parsing ${PV} at the moment

11:30 <chadmed> hm ok so something to note for the future

11:30 <chadmed> turning off -mcpu=apple-m1 fixes everything...

11:31 <chadmed> i have a hard time believing that these things speculate fast enough or that 8-way is wide enough to cause enough races to completely explode userspace to the degree that it does

11:32 <chadmed> considering the same llvm optimisations with rust dont cause anywhere near as many issues

11:39 <chadmed> (and by anywhere near i mean literally zero there is no issues with any rust code)

11:40 <j`ey> what software breaks with that flag?

11:40 <chadmed> i dont know but its got to be something important because it takes out (inter alia) dracut, module loading and probing, pipewire, alsa-utils

11:41 <j`ey> nice

11:42 <chadmed> just rebuilt the entire root with gcc and now there are no issues. modules load properly, dracut works as its meant to, reinstallingplasma now so we'll see what the desktop is like

15:12 <sam_> I think mpagano starts rebasing them in the late RCs

15:12 <sam_> we can probably ask if he'd e willing to do earlier ones

15:17 <chadmed[m]> eh not crucial at this stage imo, it's still in testing

15:17 <chadmed[m]> id like to make 6.0 or 6.1 the first asahi-sources we upstream though now that ive figured out how to apply genpatches cleanly

16:01 <jannau> sam_: I've seen he already created a branch for 6.0. I was more wondering if there is a halfway sane way to not apply genpatches for the -rc releases

17:17 <sam_> jannau: ask in #gentoo-kernel on libera if needed, but I'd compare vanilla-sources with gentoo-sources (or vanilla-kernel with gentoo-kernel)