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

Ryan Schmidt ryandesign at macports.org
Fri Jan 21 10:36:18 UTC 2022

On Jan 20, 2022, at 23:04, Gabriel Rosenkoetter wrote:
> Probably belaboring the git history with this conversation further is unnecessary.
> After some local frustrations (see also macports-user), I just ripped a CD successfully with abcde reinstalled per Christopher's (minimal, of course) patch, with perl5.34 on the system (and pointed to by /opt/local/bin/perl).
> I'm hazy on current MacPorts git etiquette. Any reason I shouldn't just push "merge"?
> Was my response to this overkill?
> Do you (anybody) also think the CI/CD chain ought to include a "actually functions" step?
> (Granted: that's a Big Drag for ports that depend on the presence of external media to test, as abcde does, and writing the test for the output here is complicated, since even if one were to load the build boxes with a CD with a single track a second long of a square wave, and run with the same abcde.conf every time, the output file probably wouldn't diff(1) against a prior sample, even with no software changes, so maybe just "ran without complaining" is enough. But even *that* kinda sucks.)
> Aside: although I'm included as a maintainer for the abcde port (because, I think, years ago I submitted code to the upstream source to get it working on macOS, and then either refreshed or created the port), I… honestly don't remember where it ends up calling Perl (the main thing's just a Bash script, but it uses various software to read from devs and encode and then write out files). Blah blah blah https://www.ntia.gov/SBOM

I feel like I'm being asked to jump into the middle of a conversation... I went back to the pull request to see what it was about...


...but I'm still not exactly sure what you're asking now.

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.

We do already build on macOS 12 and for all macOS versions down to 10.6 after changes are pushed to master.

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.

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.

Only MacPorts team members have the ability to merge PRs.

More information about the macports-dev mailing list