vendor: update go.podman.io/... and buildah to latest

[Luap99]

Mainly so we get a commit after [1] which makes the renovate auto update work again. And also buildah to get a fix for a flake [2].

[1] containers/container-libs#635
[2] containers/buildah#6688

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

[Luap99]

new build flags that need to be implemented again (--mount,--source-policy-file), I don't have time to wire them up

--source-policy-file seems to need a file path in the backend so more or less not really possible to be used with podman-remote
It seems that podman-remote is often forgotten when adding new features over there? And as always nobody proactivly vendors and implements these in podman so someone unreleated who just wants to vendor buildah gets stuck. Do we need to rethink our process around that?

@containers/podman-maintainers @containers/buildah-maintainers

[mheon]

I mean, wasn't this the ultimate goal of the monorepo? Ensuring that we don't need chains of pull requests implement these features, and the person who originally wrote the code needs to do everything? Maybe time to discuss what it would mean to keep going?

[nalind]

Feel free to cherry-pick the tip of https://github.com/nalind/podman/tree/podman-28106.

Broadly, this is all a choice that we made: to expose every build CLI flag and option as quickly as possible, to settle for only automating some of the work involved, to have CI flag when the rest hasn't been done. We could revisit that.
Podman could parse its own flags, own its own API types, and expose features at its own pace.
The CI could let some of its checks slide under any circumstances, if we changed them to.

[Luap99]

I mean, wasn't this the ultimate goal of the monorepo? Ensuring that we don't need chains of pull requests implement these features, and the person who originally wrote the code needs to do everything? Maybe time to discuss what it would mean to keep going?

That would be one solution yes, the way I view the monorepo today it has some outstanding problems that need to be fixed first before we should move ahead with adding more things. And even then we need to look at the pros and cons again.

Feel free to cherry-pick the tip of https://github.com/nalind/podman/tree/podman-28106.

Thanks

Broadly, this is all a choice that we made: to expose every build CLI flag and option as quickly as possible, to settle for only automating some of the work involved, to have CI flag when the rest hasn't been done. We could revisit that.
Podman could parse its own flags, own its own API types, and expose features at its own pace.
The CI could let some of its checks slide under any circumstances, if we changed them to.

Sure it is a choice, I mean the way we code things up today is far from optimal anbd I am sure we could improve the APIs to help a bit but for remote we also will need extra manual changes here. I just wanted to trigger a discussion about this somewhat painful process we run into all the time. Especially who is responsible for adding the new flags?
Should we make the buildah patch author do this? Should we have a dedicated person monitoring this and implementing the flags ASAP?

I think the main issue is if we would not have CI flag these things right away most devs would ignore podman flags until users complain which is bad, i.e. for each release we should have all features properly wired up in advance and not have to rush this at the last moment.

Also somewhat the real concern has to start much earlier, already on the buildah PR we must consider how to expose these things. Do we really want a filepath argument in the builder code? I see your patch fixes that by creating a tempfile, that is an easy work around but IMO is far from optimal as it is unnecessary complexity.

[nalind]

Broadly, this is all a choice that we made: to expose every build CLI flag and option as quickly as possible, to settle for only automating some of the work involved, to have CI flag when the rest hasn't been done. We could revisit that.
Podman could parse its own flags, own its own API types, and expose features at its own pace.
The CI could let some of its checks slide under any circumstances, if we changed them to.

Sure it is a choice, I mean the way we code things up today is far from optimal anbd I am sure we could improve the APIs to help a bit but for remote we also will need extra manual changes here. I just wanted to trigger a discussion about this somewhat painful process we run into all the time. Especially who is responsible for adding the new flags? Should we make the buildah patch author do this? Should we have a dedicated person monitoring this and implementing the flags ASAP?

In general, I think that expecting someone who's making a contribution in a repository that podman depends on, to also make changes in the podman repository, as a requirement for getting their contribution to that dependency accepted, is unrealistic.

I think the main issue is if we would not have CI flag these things right away most devs would ignore podman flags until users complain which is bad, i.e. for each release we should have all features properly wired up in advance and not have to rush this at the last moment.

I agree. Historically I think we tend to ignore that as much and as long as possible, and then, well, grumble that new features have been added.

Also somewhat the real concern has to start much earlier, already on the buildah PR we must consider how to expose these things. Do we really want a filepath argument in the builder code? I see your patch fixes that by creating a tempfile, that is an easy work around but IMO is far from optimal as it is unnecessary complexity.

It's either that, or pass the file's contents as a string to buildah APIs as well, because I wouldn't want to have to deal with serializing the file's contents after it's parsed into a structure. I wouldn't object to a patch that deprecated the filename field in favor of a field that carried its contents, unless perhaps we expect such files to be excessive in size. But this is one of many such API fields.

[Luap99]

@nalind pushed your commit but I also removed the client side validation of the file as I think that will cause problems when using different client/server versions, we may end up blocking something than a newer server understands.

I can squash the commit into yours if reviewers prefer that as it just reverts that one part of the previous commit.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Luap99]

tests are green

[mheon]

LGTM