feat(24.04): add SDF for iputils-ping

[eunufe]

Proposed changes

feat(24.04): add SDF for iputils-ping

Related issues/PRs

Forward porting

Checklist

• I have read the contributing guidelines
• I have tested my changes (see how)
• I have already submitted the CLA form

Additional Context

[github-actions]

Diff of dependencies:
None found.

---

[cjdcordeiro]

Thanks! Just a quick comment, similar to #447 (review)

[norrisjeremy]

Thanks! Just a quick comment, similar to #447 (review)

@cjdcordeiro, what sort of functional test do you believe would be appropriate for the ping utility that would be guaranteed to be functional when running the spread test suite?

I attempted to do something like this for redis, however the networking setup when Github ran the workflow for this seemed to make it difficult and caused it fail.

So I'm not sure what exactly would be appropriate for a network type utility such as ping, since it networking maybe flaky in whatever environment is used to execute the spread test suite?

[cjdcordeiro]

Thanks! Just a quick comment, similar to #447 (review)

@cjdcordeiro, what sort of functional test do you believe would be appropriate for the ping utility that would be guaranteed to be functional when running the spread test suite?

I attempted to do something like this for redis, however the networking setup when Github ran the workflow for this seemed to make it difficult and caused it fail.

So I'm not sure what exactly would be appropriate for a network type utility such as ping, since it networking maybe flaky in whatever environment is used to execute the spread test suite?

127.0.0.1 should always be available I think. localhost might not (as shown in https://github.com/canonical/chisel-releases/actions/runs/12654994997/job/35264222549) due to lacking name resolution inside the chroot environment.

Do you recall what kind of errors you were getting with Redis?

[norrisjeremy]

Thanks! Just a quick comment, similar to #447 (review)

@cjdcordeiro, what sort of functional test do you believe would be appropriate for the ping utility that would be guaranteed to be functional when running the spread test suite?
I attempted to do something like this for redis, however the networking setup when Github ran the workflow for this seemed to make it difficult and caused it fail.
So I'm not sure what exactly would be appropriate for a network type utility such as ping, since it networking maybe flaky in whatever environment is used to execute the spread test suite?

127.0.0.1 should always be available I think. localhost might not (as shown in https://github.com/canonical/chisel-releases/actions/runs/12654994997/job/35264222549) due to lacking name resolution inside the chroot environment.

Do you recall what kind of errors you were getting with Redis?

See https://github.com/canonical/chisel-releases/actions/runs/12213930844/job/34074096427

[cjdcordeiro]

it's hard to be sure that was a networking problem, as it could also have been a redis-server availability issue.

Since these last commits are passing with 127.0.0.1 , I suggest we stick to that, and if we see some problems later on, we try to rethink the testing infrastructure, but not the tests themselves.

[zhijie-yang]

It seems the spread test using 127.0.0.1 will not cause any failure in testing the standalone iputils-ping binaries. I agree with @cjdcordeiro that we can stick to using 127.0.0.1 in the tests for now.

This looks good to me. Thanks.

[clay-lake]

Looks good. Thanks for the contribution!

[cjdcordeiro]

Great, thanks for the changes