| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the compilation demands of having libpod in main is a burden for the
remote client compilations. to combat this, we should move the use of
libpod structs, vars, constants, and functions into the adapter code
where it will only be compiled by the local client.
this should result in cleaner code organization and smaller binaries. it
should also help if we ever need to compile the remote client on
non-Linux operating systems natively (not cross-compiled).
Signed-off-by: baude <bbaude@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
to protect against regressions, we need to add a few gating tasks:
* build with varlink
* build podman-remote
* build podman-remote-darwin
we already have a gating task for building without varlink
Signed-off-by: baude <bbaude@redhat.com>
|
|
|
Add the ability to cross-compile podman remote for OSX.
Also, add image exists and tag to remote-client.
Signed-off-by: baude <bbaude@redhat.com>
|
