💾 Archived View for perso.pw › blog › articles › pipeline-ports.gmi captured on 2023-01-29 at 04:01:14. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-17)

➡️ Next capture (2023-05-24)

🚧 View Differences

-=-=-=-=-=-=-

About pipelining OpenBSD ports contributions

NIL=> https://bsd.network/@solenepercent/104938458099517905 Comment on Mastodon

After modest contributions to the NixOS operating system which made

me learn about the contribution process, I found enjoyable to have

an automatic report and feedback about the quality of the submitted

work. While on NixOS this requires GitHub, I think this could be

applied as well on OpenBSD and the mailing list contributing system.

I made a prototype before starting the real work and actually I'm

happy with the result.

This is what I get after feeding the script with a mail containing

a patch:

Determining package path ✓

Verifying patch isn't committed ✓

Applying the patch ✓

Fetching distfiles ✓

Distfile checksum ✓

Applying ports patches ✓

Extracting sources ✓

Building result ✓

It requires a lot of checks to find a patch in the file, because

we have have patches generated from cvs or git which have a slightly

different output. And then, we need to find from where to apply

this patch.

The idea would be to retrieve mails sent to ports@openbsd.org by

subscribing, then store metadata about that submission into a

database:

Sender

Date

Diff (raw text)

Status (already committed, doesn't apply, apply, compile)

Then, another program will pick a diff from the database, prepare a VM using a

derivated qcow2 disk from a base image so it always start fresh and

clean and ready, and do the checks within the VM.

Once it is finished, a mail could be sent as a reply to the original

mail to give the status of each step until error or last check. The

database could be reused to make a web page to track what compiles

but is not yet committed. As it's possible to verify if a patch is

committed in the tree, this can automatically prune committed patches

over time.

I really think this can improve tracking patches sent to ports@ and

ease the contribution process.

- This would not be an official part of the project, I do it on my own

- This may be cancelled

- This may be a bad idea

- This could be used "as a service" instead of pulling automatically

from ports, meaning people could send mails to it to receive an

automatic review. Ideally this should be done in portcheck(1) but

I'm not sure how to verify a diff apply on the ports tree without

enforcing requirements

- **Human work will still be required to check the content and verify

the port works correctly!**