tobhe changed the topic of #ubuntu-asahi to: Ubuntu-Asahi development | Github: https://github.com/UbuntuAsahi | Logs: https://oftc.irclog.whitequark.org/ubuntu-asahi
<eslerm[m]> for mesa, I `git reset --hard` ubuntu/mantic to the first commit in mesa, and then rebased on the main asahi/mesa branch
<eslerm[m]> just sent out a (hopefully final) lp build
<eslerm[m]> if the build tests well, mesa and 6.6.0-1004 should be ready to publish
<tobhe[m]> hm? why not just git reset --hard to the mesa release tag?
<eslerm[m]> I was planning to pr my branch to ubuntuasahi/mesa's ubunt/mesa branch
<eslerm[m]> and then pr ubuntu/mesa to main
<eslerm[m]> these exist in the upstream branch, but are comitted at a different time
<eslerm[m]> I reset to the intitial commit to make sure I wound the clock back far enough
<eslerm[m]> (I tried to do this more cautiously, and needed to go back and redo this)
<eslerm[m]> s/(I tried to do this more cautiously, and needed to go back and redo this)/(I tried to do this more cautiously at first, only restting as much as *needed*, but ended up needing to go back further)/
<tobhe[m]> if you plan to not merge you can just force push, so that shouldn't be a problem
<tobhe[m]> just take asahi-20240228, add some debian build magic and call it done
<eslerm[m]> most of it should be done, just waiting for builds to test well
<tobhe[m]> imo most important is to show that the commit history up to asahi-20240228 is intact and then there's some packaging on top
<tobhe[m]> since upstream rebases and force pushes regularly it might not even be possible to keep a linear commit history
<tobhe[m]> but by keeping our diff on top small and easy to review we can at least make sure we didn't break anything in merges
<tobhe[m]> but I would pick a different name for the Ubuntu tag
<tobhe[m]> because now you have two remotes with conflicting tags and that confuses git (and humans)
<tobhe[m]> normally I'd use something closer to the debain/changelog package version for the Ubuntu tag, see https://github.com/UbuntuAsahi/mesa/tags
<tobhe[m]> underscore because tags can't have ~
<eslerm[m]> ack, I can use `Ubuntu-24.0_pre20240228-0asahi3.23.10`
<eslerm[m]> I wish the `3` was a `1` :)
<tobhe_> why can't you use 1? because you already uploaded a few?
<tobhe_> it doesn't really matter but those are per ppa so you can just upload it to another one if it bothers you
<eslerm[m]> ok, can do since it won't impact github
<tobhe[m]> but it really doesn't matter. looks like I used both 0 and 1 in the past
<eslerm[m]> iiuc, if there is no changes the `0` would be dropped, and +`1` means downstream changes
<tobhe_> mesa has a bit of a special version number anyway. but I couldn't come up with a better one
<tobhe_> following that post it should probably be asahi1
<tobhe_> but who starts counting at 1
<eslerm[m]> the count starts at 0, but then text isn't added
<tobhe[m]> but then you can't add the text later because 23.10
<tobhe[m]> or maybe that should be at a different place
<tobhe[m]> but I think it's normally at the end because it marks a forwardport/backport
<tobhe[m]> too complicated for my simple mind 🙂
<eslerm[m]> github doesn't like the tag 24.0~pre20240228-0asahi1.23.10, even though that's they syntax of the current tags
<tobhe[m]> s/~/_/
<tobhe[m]> <tobhe[m]> "underscore because tags can't..." <- ^ this
<tobhe[m]> also you can git tag on the command line and then push the tag
<tobhe[m]> for better error messages
<eslerm[m]> well, on my fork done
<eslerm[m]> s/to/two/, s/0_pre20231121/0\_pre20231121/
<eslerm[m]> new build runs ryujinx :)
<tobhe_> nice! so the next step would be copying the kernel and mesa to asahi-testing
<tobhe[m]> oh and build 22.04 mesa because otherwise your snaps will break once we push out the new kernel
<john-cabaj[m]> Hopefully we have some people in the future buying these to test.
<john-cabaj[m]> I will be financially strapped
<tobhe[m]> finally two external displays supported by the hw
glem has joined #ubuntu-asahi
glem has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
glem has joined #ubuntu-asahi