Please add maintainers to this repo

[mkurz]

@marcan Would it be OK to give me write access to this repo so I can close/merge pull requests and issues? See: https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#permissions-for-each-role
Write permission would be enough, no need for maintainer rights.

The thing is @joske and me are updating the PKGBUILD files and we have ALARM running very nicely right now.
These are the pull requests we always push to: https://github.com/AsahiLinux/PKGBUILDs/pulls/joske.
(We usually PR against joskes repo (https://github.com/joske/PKGBUILDs/pulls?q=is%3Apr+is%3Aclosed) so the commits end up in above's pull requests)
It would be nice if we eventually can just merge them instead of having this endless commits in the PRs.

If you need some track record, please take a look please see my comment activity in the AsahiLinux GitHub org: https://github.com/search?q=org%3AAsahiLinux+commenter%3Amkurz&type=issues&s=created&o=desc
I was having a discussion with @asahilina a couple of days ago regarding the kwin bug: AsahiLinux/linux#72 (comment)
Also I am asking questions every now and then in the Asahi IRC since 2 years+.

• https://oftc.irclog.whitequark.org/asahi/search?q=mkurz
• https://oftc.irclog.whitequark.org/asahi-dev/search?q=mkurz
• https://oftc.irclog.whitequark.org/asahi-gpu/search?q=mkurz

Also I am an open source project maintainer myself since 10+ years: https://github.com/playframework/playframework/pulls?q=author%3Amkurz

Let me know what you think, thanks!

[mkurz]

/cc @jannau

[mkurz]

Again, not asking for any admin rights, just write permissions to keep the repo clean.

[marcan]

Since we are no longer maintaining the PKGBUILDs under the Asahi Linux umbrella, I think it makes more sense for the folks actually keeping things up to date to fork the repo and maintain it under a different organization. I can archive this repo to make it clear it's deprecated and point to the new one if you want.

[mkurz]

I can archive this repo to make it clear it's deprecated and point to the new one if you want.

@marcan OK, let's do that. I forked it under https://github.com/mkurz/PKGBUILDs-asahi - if you can point to that repo so others can follow that would be great. Update: We created a own GitHub org. Maybe we should transfer the repo? see below

Thanks!

[mkurz]

@marcan Before you archive this repo, maybe its good to clean it up before. I commented on all open issues and pull requests.
Can you please close all before you archive?

• https://github.com/AsahiLinux/PKGBUILDs/issues
• https://github.com/AsahiLinux/PKGBUILDs/pulls

Thanks!

[joske]

@mkurz maybe better to create an org (maybe called asahi-alarm or similar) for this and not use your personal github? This makes it easier to add collaborators, and to transfer ownership if you ever need to stop.

[joske]

Another thought I have is that having a repo is nice and all but ideally we would need to build packages and publish them in a pacman repo.

[mkurz]

@joske Yeah that would be great, but I don't have time to set up that up. If you want to do that please go ahead.
Maybe this can be automated with GitHub actions?

[joske]

Are you talking about packages or creating an org? 😉

[mkurz]

sorry, packages

[joske]

That is not urgent. What do you say about having this under an org?

[mkurz]

I just invited you to https://github.com/orgs/asahi-alarm/ I will make you owner as well.

[mkurz]

You are owner now.

[mkurz]

Forked the repo: https://github.com/asahi-alarm/PKGBUILDs

Or maybe.. should we transfer it?

[joske]

what's the difference?

[mkurz]

By transfering all issues + pull requests will be transfered as well, its like moving the repo to a different url.
Forking is a fork - its a new repo with commit history of the original one.

[joske]

Do we care about those? I suspect not much is lost by just forking. Transfer is probably not something we can do ourselves.

[mkurz]

Transfering has to be done by @marcan.
It's just like two clicks + enter new destination.
After a transfer GitHub will automatically redirect the url https://github.com/AsahiLinux/PKGBUILDs to https://github.com/asahi-alarm/PKGBUILDs

Depends what @marcan says.

[mkurz]

Also are we happy about the name asahi-alarm? If we want to change it we should do that now and not later:
Like:
https://github.com/organizations/asahi-alarm
https://github.com/organizations/asahialarm
https://github.com/organizations/AsahiALARM
https://github.com/organizations/AsahiArchLinuxARM
etc.

[joske]

I think that asahi-alarm is fine. It clearly says what it is 😁

[mkurz]

I will ping @marcan in IRC regarding transfer vs fork.

[kwankiu]

I can archive this repo to make it clear it's deprecated and point to the new one if you want.

Thanks for the response and the new organization to maintain asahi for alarm,

but ideally we would need to build packages and publish them in a pacman repo.

I think that's the biggest problem here, if asahi linux is deprecated for arch linux arm, built packages became outdated and might stop functioning, without a build system and a binary repo, the user would be expected to build all the packages using another machine or creating an Arch Linux ARM VM / Container.

Maybe this can be automated with GitHub actions?

I have been thinking of doing this for a while, but github runners currently supports only x86_64, building with github action inside an alarm docker image using qemu would probably be too slow. (ARM64 runners are still in beta, that might be an option in the future, but we might need to wait til at least the end of this year)

FYI, there are https://github.com/7Ji-PKGBUILDs for PKGBUILDs and https://github.com/7Ji/archrepo as a pacman binary repo, currently maintaining lots of rockchip packages, but it is also maintaining other packages and platforms. Packages are currently built on a Huawei Kunpeng-920 server.

[mkurz]

ARM64 runners are still in beta, that might be an option in the future, but we might need to wait til at least the end of this year

They are not in beta anymore, however currently only availabe to GitHub enterprise customers.
According to the latest updates "will be released broadly in early 2025" (meaning for public repos).

• GitHub Actions: arm64 Linux and Windows runners are now generally available
• Arm64 on GitHub Actions: Powering faster, more efficient build systems
• https://github.com/orgs/community/discussions/19197#discussioncomment-10550689
• https://github.blog/news-insights/product-news/universe-2024-previews-releases/#more-compute-resources-and-better-insights-for-your-workflows

Personally, I would just wait for this runners to be avaible and then set up everything with GitHub actions. "early 2025" sounds no longer then March?

[mkurz]

FYI, there are https://github.com/7Ji-PKGBUILDs for PKGBUILDs and https://github.com/7Ji/archrepo as a pacman binary repo, currently maintaining lots of rockchip packages, but it is also maintaining other packages and platforms. Packages are currently built on a Huawei Kunpeng-920 server.

It's interesting how this is set up, basically no infrastructure needed... The packages provided via GitHub releases.

[joske]

Also have a look at this: https://github.com/anonymix007/x1e-alarm/blob/master/release.sh

He also uses github releases to store packages.

In the meantime I've ordered an M4 max MBP 😁

[mkurz]

This is how the page to transfer a GitHub repo looks like (because I am transfering a repo right now).

It's linking to https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

[mkurz]

Regardingt he GitHub ARM hosted runners you can also follow this issue:

• ARM hosted runners for OSS/free plans [Public Preview] github/roadmap#970

[marcan]

I'm okay with transferring the repo. You need to give me repo create access on asahi-alarm (temporarily) for me to transfer it, though.

[marcan]

Done. Feel free to remove me from the org.

[mkurz]

@marcan I see you just transfered (after I made you member of the repo).
Thanks!

[mkurz]

Now as the repo is transferred we can start to clean up PRs and issues.
@joske you are welcome to help.

If someone else wants to help ping us!
Thanks everyone!

[marcan]

I've gone ahead and moved asahi-alarm-builder too, since I presume you also want to take care of that.

[marcan]

Do you want asahi-calamares-configs too, or should I archive it? That's the old X11 one, the modern configs for Wayland are at https://pagure.io/fedora-asahi/calamares-firstboot-config .

[marcan]

Also mkinitcpio (not sure if that is even relevant any more on Arch)

[marcan]

I've also archived AsahiLinux/asahilinux-keyring since that is fundamentally the deprecated keyring for our package repo. However, feel free to fork it as a basis for your own keyring if you wish.

[mkurz]

Do you want asahi-calamares-configs too, or should I archive it? That's the old X11 one, the modern configs for Wayland are at https://pagure.io/fedora-asahi/calamares-firstboot-config .

I think you can archive the legacy one.

Also mkinitcpio (not sure if that is even relevant any more on Arch)

Looking at your fork, there are just 3 commits in the asahi branch:

• AsahiLinux/mkinitcpio@0e54169 this one landed upstream.
• The other two:
  • AsahiLinux/mkinitcpio@eec9562
  • AsahiLinux/mkinitcpio@275d02e

I think they are also not relevant anymore, since I think upstream can now handle this things correctly? However maybe you can comment on that?