[macports/macports-ports] abcde: switch to Perl 5.34 (PR #13720)

[Gabriel Rosenkoetter]

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:

> https://github.com/macports/macports-ports/pull/13720

> ...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 
terminal output.

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...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220121/1de26ae0/attachment.sig>