Adds the build of the arm64 windows installer as part of the release
GitHub workflow.
When a Windows installer is uploaded to the GitHub release, it is named
consistently with the macOS one:
`podman-installer-windows-${GOARCH}.exe`
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Includes the necessary changes so that the `Makefile` target
`release-artifacts` builds the `-windows_arm64.zip` too.
In particular the arm64 versions of gvproxy and win-sshproxy
are downloaded as part of the windows arm64 release zip file.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
This is a followup of https://github.com/containers/podman/pull/26048
It fixes `process-release.ps1` that was always looking for the amd64 release
zip file, even if `$env:PODMAN_ARCH` was set to arm64. With this fix it looks
for the right zip file.
It fixes `winmake.ps1` that, when the `-arch` param was not passed, set `$env:PODMAN_ARCH`
to the empty string instead of the local `$env:GOARCH`.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Winmake could only build amd64 artifacts (podman-remote, gvproxy,
win-sshproxy, podman.msi and podman-setup.exe).
This commit makes the necessary change to winmake so that it:
1) builds arm64 artifacts when executed on arm64
2) cross-compiles to arm64/amd64 with the `-architecture` parameter
It depends on https://github.com/containers/podman/pull/26023 that
removes the need to build `check.c` code (that is not used anyway).
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
This PR removes the file `check.c` and the instructions
to build it. The file was still built but the resulting
dll was not used by the installer anymore (see
https://github.com/containers/podman/pull/25237).
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
A new gvisor-tap-vsock has recently been released. This PR is a
backport to the podman 5.5 branch (i.e. release came out after 5.5
branched but before it released). This new version, among other things,
fixes a bug for gvproxy wheer if gvproxy is run with debug, it will try
to create a file in `cwd`. If the user does not have permissions to
create the file in `cwd`, gvproxy will quit (silently).
Signed-off-by: Brent Baude <bbaude@redhat.com>
Machines configured to mount local paths containing
spaces failed to start on Hyper-V and silently failed
to mount the folder on macOS/Linux.
On Windows/hyperv, where local paths are mounted
running a 9p client inside the VM, the local host
path needs to be surrounding with quotation marks
before using in a `podman machine ssh ...` command.
A similar behavior happened on Linux/QEMU where the
path was used in a SSH command to mount the folder
using virtiofs. Quoting the path when buidling the
command arguments fixed the problem.
On macOS/libkit,applehv the path was written as is
in a systemd unit name to instruct how to mount it.
Escaping space chars so that they are are parsed
successfully fixed this:
```diff
-- enable path with spaces.mount
++ enable path\x20with\x20spaces.mount
```
Fixes https://github.com/containers/podman/issues/25500
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Command `podman machine init` for Hyper-V machines invokes the command
`podman machine server9` and redirects it's output to a file. But the
file descriptor was closed before beeing used and the output file was
always empty.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Create GitHub action to automatically bump to a -dev version after a release is tagged.
On a branch:
- The bump will always be a z bump on branches
- If the bump is to an RC, then the bump will be back down to dev (ie, 9.9.0-rc1 to 9.9.0-dev)
- If the bump is not an RC, the bump wil be up to dev (ie, 9.9.0 to 9.9.1-dev)
On main:
- If the X.Y version on main is smaller than the X.Y on the release tag, this action will open a PR to bump the version on main to the release tag's X.Y+1
- Major version (X) dev bumps will still need to be manual
Signed-off-by: Ashley Cui <acui@redhat.com>
The tests for device I/O limits were using `/dev/zero`,
which is not a block device suitable for these cgroup
controls.
Update the tests to use `/dev/nullb0` if it exists.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
The tests were incorrectly using `/dev/zero`. These options are
intended to set I/O limits on specific block devices.
The test already sets up a loopback device, so reuse it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Cgroup block I/O limits cannot be applied to character devices.
Ignore character devices in the inspect output.
Update the API tests to use the null block device `/dev/nullb0` (if
available) instead of `/dev/zero` for testing I/O limits.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
In the instance where the user sends a signal, such as SIGINT (Ctl-c)
when a Podman Machine is in the middle of starting, make sure the state
doesn't get stuck in the "Currently Starting" status.
Resolves: #24416
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Otherwise we evaluate NATIVE_GOOS before it is set, which breaks the
FreeBSD build since various make variables are not set correctly.
Fixes: #26006
Signed-off-by: Mark Johnston <mark.johnston@klarasystems.com>
If this fails we should know exactly what failed. The underlying
connection error might just be unexpected EOF or somthing which is not
helpful.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the case of an Decoder error which is not EOF we loop forever, as the
Decoder stores some errors each next Decode() call will keep returning
the same error. Thus we loop forever until we run out of memory as each
error was stored in pullErrors array as described in [1].
Note this does not actually fix whatever causes the underlying
connection error in the issue, it just fixes the loop/memory leak.
[1] https://github.com/containers/podman/issues/25974
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
