How to help? #39

New Issue

2022-05-21T08:14:13Z

mrvdb commented

2022-05-21 08:14:13 +00:00

(Migrated from github.com)

I've recently gotten a Talos II workstation and using the arch powerpc64le port and I would like to help.

In using I've build quite a few packages. How can I help getting these into the repository? Many of the packages just work, others need very minor tuning.

Perhaps a CONTRIBUTING.md file might be a good first step? Or is there and upstream archlinux document we could use?

Specific details I'd want to see documented:

guidelines for the PKGBUILD adjustments
which packages to include ? (just base from arch upstream? or also AUR?)
one PR per package, multiple packages? logical sets?
when to ask upstream for changes? (like outdated config.guess/config.sub files)

I've recently gotten a Talos II workstation and using the arch powerpc64le port and I would like to help. In using I've build quite a few packages. How can I help getting these into the repository? Many of the packages just work, others need very minor tuning. Perhaps a `CONTRIBUTING.md` file might be a good first step? Or is there and upstream archlinux document we could use? Specific details I'd want to see documented: - guidelines for the PKGBUILD adjustments - which packages to include ? (just base from arch upstream? or also AUR?) - one PR per package, multiple packages? logical sets? - when to ask upstream for changes? (like outdated config.guess/config.sub files)

👍 1

kth5 commented

2022-05-23 07:51:34 +00:00

(Migrated from github.com)

At the time I'm working to automate stuff more which will work with PRs and a few scripts and I might even go with the regular asp and devtools from Archlinux if they aren't going to be too high maintenance (which they do look like at this time). Once that's settled there is also the issue of signing the package DBs, which currently is done using my personal key.

Once these issues are tackled, this project will be more open to contributions and easier for everyone to dive into with documentation.

Until then, a PR would be nice and if you can provide reproducable builds we can already incorporate them. Just make sure no rebuilds are required that aren't included in the PR (so-bumps etc).

Help is very welcome at any stage, as time is limited on my end and I focus on keeping my daily drivers stable and up to date.

At the time I'm working to automate stuff more which will work with PRs and a few scripts and I might even go with the regular asp and devtools from Archlinux if they aren't going to be too high maintenance (which they do look like at this time). Once that's settled there is also the issue of signing the package DBs, which currently is done using my personal key. Once these issues are tackled, this project will be more open to contributions and easier for everyone to dive into with documentation. Until then, a PR would be nice and if you can provide reproducable builds we can already incorporate them. Just make sure no rebuilds are required that aren't included in the PR (so-bumps etc). Help is very welcome at any stage, as time is limited on my end and I focus on keeping my daily drivers stable and up to date.

bobpaul commented

2024-12-20 16:03:18 +00:00

(Migrated from github.com)

Do you have a TODO list of automation tasks?

I have some (not a lot) of experience with Gitlab's CI system and I do see that the gitlab-ci-runner is available for ppc64le. I've previously set up projects such that a commit to github caused a push to gitlab which triggered ci on runner installed on a local computer. That was using webhooks from github to a custom python script running locally, but I think with Github Actions that could be simplified.

Things I was thinking of:

attempt upgrade/build of a package when upstream (arch for amd64) bumps the version
- might require scheduled (nightly?) check for upstream changes
deploy successful builds to a testing repository

Do you have a TODO list of automation tasks? I have some (not a lot) of experience with Gitlab's CI system and I do see that the gitlab-ci-runner is available for ppc64le. I've previously set up projects such that a commit to github caused a push to gitlab which triggered ci on runner installed on a local computer. That was using webhooks from github to a custom python script running locally, but I think with Github Actions that could be simplified. Things I was thinking of: - [ ] attempt upgrade/build of a package when upstream (arch for amd64) bumps the version - [ ] might require scheduled (nightly?) check for upstream changes - [ ] deploy successful builds to a testing repository

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ArchPOWER/packages#39