[macports/macports-ports] abcde: switch to Perl 5.34 (PR #13720)
gr at eclipsed.net
Sat Jan 22 02:17:43 UTC 2022
On 2022-01-21 05:36 EST, Ryan Schmidt wrote:
> I feel like I'm being asked to jump into the middle of a conversation...
I'm sorry, that's certainly my fault: I should have responded to (and
included the content from) an earlier git email notification. Thanks for
providing the context! That is:
> ...but I'm still not exactly sure what you're asking now.
I'll try to explain.
> Yes, we should try builds of PRs on macOS 12 but AFAIK GitHub Actions does not yet give us that ability. When it does, we'll add it.
Yep, totally clear on that now (as I thought I indicated in the comments
on that PR). That's not the lingering question for me.
> Ports are encouraged to offer a test phase but it is not required to do so and neither the GitHub Actions CI setup that runs for PRs nor the Buildbot setup that runs after changes go to master runs the tests.
Gotcha. I've been largely absent as a "maintainer" of the abcde port
(and Christopher's done all of the recent work: thank you!), and I
obviously can't promise I won't flake out over work/life/whatever in the
future, but I've actually got some free time at the moment, and I'd like
to follow that suggestion. :^>
> I'm not aware of any ports whose test phases require the use of external media or devices. If that's the only way to test that the software works, nothing prevents you from writing a test phase that works this way, however it will naturally restrict who is able to run the tests. Neither GitHub Actions nor our Buildbot could accommodate that, nor could users who, for example, don't have an optical media reader.
Yep, I *definitely* get that! :^>
I was fishing for advice on what a "good enough" test here would be.
Right now, I'm thinking dd(1) a few blocks constructed to look like a
very short audio CD into a file under [/var]/tmp, mount(8) that as a
pseudo-device, tell abcde to "rip" it (pointing the output to /dev/null:
with compression algorithms, rather than hashing algorithms, there's no
reasonable expectation of identical output from sequential runs with the
same input data anyway), and then parse for errors reported in the
Does that seem like a reasonable approach?
> Only MacPorts team members have the ability to merge PRs.
Yup, figured that out, smacked my forehead, concluded sending yet
*another* email just to acknowledge my ignorance probably wasn't
productive for anybody involved. :^>
Gabriel Rosenkoetter (he/him)
gr at eclipsed.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 236 bytes
Desc: OpenPGP digital signature
More information about the macports-dev