search

containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.37k stars 2.38k forks source link

Package up podman for vanilla Debian #1742

Closed lsm5 closed 4 years ago

lsm5 commented 5 years ago

This is separate from the PPA work that's already being done. This issue will track efforts towards getting podman in vanilla Debian.

Update: Debian tickets

lsm5 commented 5 years ago

@qiancai let's track Debian work here

lsm5 commented 5 years ago

@qiancai I'm guessing we don't need to worry about SELinux for Debian and its downstreams. Do you see selinux-policy being a hard dependency somewhere?

rhatdan commented 5 years ago

SELinux should not be a hard dependency, but a Nice to Have.

ghost commented 5 years ago

Debian developer complained that libpod and its dependencies were unversioned. Is that something worth solving? https://lists.debian.org/debian-go/2018/11/msg00000.html

mheon commented 5 years ago

Libpod is versioned in lockstep with Podman - I consider version.go our definitive source of truth for versioning information on both.

We do have a number of unversioned dependencies, though - notably c/image and c/storage?

lsm5 commented 5 years ago

On Thu, Nov 01, 2018 at 07:07:08AM -0700, Qian Cai wrote:

Debian developer complained that libpod and its dependencies were unversioned. Is that something worth solving? https://lists.debian.org/debian-go/2018/11/msg00000.html

Is libpod still unversioned? I thought the versioned git tags implied otherwise, am I reading that wrong?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/containers/libpod/issues/1742#issuecomment-435041790

-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5

ghost commented 5 years ago

Filed a container-selinux bug,

https://github.com/containers/container-selinux/issues/57

ghost commented 5 years ago

Filed a oci-systemd-hook bug,

https://github.com/projectatomic/oci-systemd-hook/issues/107

In the meanwhile, skopeo works fine there. However, there are lots of vendors. Specifically, how about versioning containers/storage and containers/image if not done so yet? Then, I'll start to package skopeo first while waiting on fixing other blockers.

https://github.com/containers/skopeo/tree/master/vendor/github.com/containers

mheon commented 5 years ago

We no longer depend on oci-systemd-hook (for Podman at least) - it's not necessary if you aren't packaging CRI-O

ghost commented 5 years ago

It turned out that podman still depend on oci-systemd-hook. See https://github.com/containers/libpod/commit/57a8c2e5e844ee403c9a703c621780de7c7343f0

I can also help with running standalone runc systemd containers.

ghost commented 5 years ago

Never mind. I got podman working with systemd containers without oci-systemd-hook, so I don't need to package oci-systemd-hook to Debian now.

ghost commented 5 years ago

Filed bugs to tag repos.

https://github.com/containers/storage/issues/232

https://github.com/containers/image/issues/531

ghost commented 5 years ago

I suppose this is not needed anymore. The easiest path looks like just to get podman into snap store.

https://snapcraft.io/search?category=server

It looks like anyone could create that for CRI-O/podman etc as well.

https://docs.snapcraft.io/creating-a-snap/6799

Any objection?

rhatdan commented 5 years ago

Do people with debian use Snapstore. Or just Ubuntu and its descendent?

But I have no objection.

ghost commented 5 years ago

Looks like only Ubuntu and its descendant use snap store, but I suppose our goal is to reach the Ubuntu 's huge developer base.

rhatdan commented 5 years ago

Yup, That gets us to 95% of users, So much better then what we get now.

ghost commented 5 years ago

Sounds good. I'll let @lsm5 get those in the snap store then, since he have already packaged everything to PPA. I'll help around if needed.

lsm5 commented 5 years ago

I guess I'll defer this until I find out from kube maintainers if they're willing to include our tools on their apt repo.

Silvanoc commented 5 years ago

Snaps work on Debian, but it's like requiring the users of an Android App to install F-Droid to get it. It's feasible, but you will reach a smaller audience than if you use the Google Playstore.

I mean, there is already a package manager in Debian and it covers Debian, Ubuntu and much more. Snap is a Canonical kind of package manager that you will typically find only in Ubuntu and probably not so wide spread...

Would you offer libpod only as Flatpak for the RedHat-based distros?

I'm following the thread of CAI Qian trying to get a Debian package in the Go-Team and will try to support you on that effort. I already sent a message with the offer, but my e-mail client apparently missed-up with the thread-ID...

vrothberg commented 5 years ago

Would you offer libpod only as Flatpak for the RedHat-based distros?

I don't think the comparison is fair as packaging go-tools for Debian is exponentially more complex given all dependencies (see ./vendor) must, in theory, be packaged separately. There is a clear clash of how software is being distributed conceptually, and all go-tools suffer from that in Debian.

I'm following the thread of CAI Qian trying to get a Debian package in the Go-Team and will try to support you on that effort. I already sent a message with the offer, but my e-mail client apparently missed-up with the thread-ID...

The good news is that we are working with the Debian community together to get the tools into the main repositories. @siretart is actually doing all the heavy lifting of packaging the dependencies in preparation to eventually package the tools.

Silvanoc commented 5 years ago

I don't think the comparison is fair as packaging go-tools for Debian is exponentially more complex given all dependencies (see ./vendor) must, in theory, be packaged separately. There is a clear clash of how software is being distributed conceptually, and all go-tools suffer from that in Debian.

I wasn't comparing the effort, but the audience that you reach and in that sense I find it's a more than fair comparison. Flatpak appears to have a wider usage than snap/snappy/snapstore.

WRT to the effort, I fully agree with you :unamused:

The good news is that we are working with the Debian community together to get the tools into the main repositories. @siretart is actually doing all the heavy lifting of packaging the dependencies in preparation to eventually package the tools.

Those are great news! :+1:

rhatdan commented 5 years ago

Sad to say I think this is stalling again. Still huge hurdles to get over in order to get Go Programs packaged into Debian.

siretart commented 5 years ago

I probably should have updated this issue more frequently, my apologies.

I think it is fair to say that significant progress is being done. At this point, I've packaged all dependencies for golang-github-containers-storage 1.5, and that package itself. It is currently in the review queue by the Debian ftp-masters for inclusion into the Debian archive. This is standard procedure, and takes a couple of weeks right now (the team's priority at this point is the upcoming freeze for Debian 10, and not the inclusion of experimental and NEW packages). Also cf. https://ftp-master.debian.org/new/golang-github-containers-storage_1.5-1.html and http://bugs.debian.org/921949

I'm currently working on packaging golang-github-openshift-imagebuilder, which progress is tracked in http://bugs.debian.org/923300. Note that while working on this, I was running into https://github.com/containers/storage/issues/293, which luckily has been fixed much faster than I could have possibly wished for. Thank you so much for your assistance.

The next steps would be to wait for containers/storage to be ACCEPTED into the archive and update it to the most next version with the cleaned up docker dependencies. Then I can proceed to package containers/image, on which I've also started to work on. Progress for that is being tracked at http://bugs.debian.org/922842

Let me know if you have specific questions or concerns.

siretart commented 5 years ago

Given the cheers on my last week's update, it seems that there is interest in status updates.

In the last week, containers/storage remains in the NEW queue, but I've managed to update it locally to version 1.11 and got it to build.

I'm still working on openshift/imagebuilder in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923300 and ran into some missing imports in the debian docker.io package. NB: In Debian, the plan is to use the distro provided version of docker.io (which is version 18.09.1-CE at this point), and not the exact git revision that vendor.conf happens to point to. It turns out that the debian source package misses to install some golang sources that are required for compiling openshift/imagebuilder, and have thus created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924257 and added a patch to fix that. The package maintainer is responsive, has cleaned up the patch and asked me to upload it on his behalf to experimental together with an version upgrade to 18.09.03-CE. I was about to do so, but it turns out that there are additional sources missing, and https://github.com/openshift/imagebuilder/pull/125#issuecomment-473562682 - Valentin is working on a fix for that in https://github.com/openshift/imagebuilder/pull/127

vrothberg commented 5 years ago

Thanks for the update, @siretart :pray:

rhatdan commented 5 years ago

@siretart @vrothberg Is this still being worked on? Any progress?

siretart commented 5 years ago

There is. Sorry for the late update.

I've updated / uploaded a couple of dependencies in Debian, all of which are now present in the Debian archive:

The docker.io package required additional work to expose some libraries required by golang-github-openshift-imagebuilder, cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924257.

I've worked on the golang-github-openshift-imagebuilder package, the most recent version can be seen here: https://salsa.debian.org/docker-team/docker/tree/experimental, progress on getting it into debian is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923300 - in short, we are (still) waiting for golang-github-containers-storage to arrive into the archive.

On that front, we had a setback (cf. http://bugs.debian.org/921949#17): ftp-master REJECTED version 1.5 of the package with concerns about unclear copyright holder declarations. The response was not exactly constructive. I've asked for clarification, did an update to debian/copyright, updated the package to version 1.12.2, and reuploaded for review. This could have been avoided if the upstream package were more clear about who is holding the copyright. This recommendation applies to any upstream package.

Looking forward, I've filed https://github.com/containers/buildah/issues/1437 and noticed only today that this seems to have been addressed (I didn't notice earlier because there was no status update on the issue). This allows me to proceed with preparing a package for buildah in salsa, and clarifies this as a dependency for podman/libpod.

Next steps:

siretart commented 5 years ago

Not much progress, the NEW queue remains to be super slow.

I was able to build a somewhat "proper" skopeo package:

siretart@kaby:~$ which skopeo
/usr/bin/skopeo
siretart@kaby:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux buster/sid
Release:        testing
Codename:       buster
siretart@kaby:~$ which skopeo
/usr/bin/skopeo
siretart@kaby:~$ skopeo --version
skopeo version 0.1.35
siretart@kaby:~$ skopeo --help
NAME:
   skopeo - Various operations with container images and container image registries

USAGE:
   skopeo [global options] command [command options] [arguments...]

VERSION:
   0.1.35

COMMANDS:
     copy               Copy an IMAGE-NAME from one location to another
     inspect            Inspect image IMAGE-NAME
     delete             Delete image IMAGE-NAME
     manifest-digest    Compute a manifest digest of a file
     standalone-sign    Create a signature using local files
     standalone-verify  Verify a signature using local files
     help, h            Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug                  enable debug output
   --policy value           Path to a trust policy file
   --insecure-policy        run the tool without any policy check
   --registries.d DIR       use registry configuration files in DIR (e.g. for container signature storage)
   --override-arch ARCH     use ARCH instead of the architecture of the machine for choosing images
   --override-os OS         use OS instead of the running OS for choosing images
   --command-timeout value  timeout for the command execution (default: 0s)
   --help, -h               show help
   --version, -v            print the version

and buildah:

siretart@kaby:/srv/scratch/packages/containers$ which buildah
/usr/bin/buildah
siretart@kaby:/srv/scratch/packages/containers$ buildah --help
A tool that facilitates building OCI images

Usage:
  buildah [flags]
  buildah [command]

Available Commands:
  add                    Add content to the container
  build-using-dockerfile Build an image using instructions in a Dockerfile
  commit                 Create an image from a working container
  config                 Update image configuration settings
  containers             List working containers and their base images
  copy                   Copy content into the container
  from                   Create a working container based on an image
  help                   Help about any command
  images                 List images in local storage
  info                   Display Buildah system information
  inspect                Inspect the configuration of a container or image
  mount                  Mount a working container's root filesystem
  pull                   Pull an image from the specified location
  push                   Push an image to a specified destination
  rename                 Rename a container
  rm                     Remove one or more working containers
  rmi                    Remove one or more images from local storage
  run                    Run a command inside of the container
  tag                    Add an additional name to a local image
  umount                 Unmount the root file system of the specified working containers
  unshare                Run a command in a modified user namespace
  version                Display the Buildah version information

Flags:
      --debug                                print debugging information
  -h, --help                                 help for buildah
      --registries-conf string               path to registries.conf file (not usually used)
      --registries-conf-dir string           path to registries.conf.d directory (not usually used)
      --root string                          storage root dir (default "/var/lib/containers/storage")
      --runroot string                       storage state dir (default "/var/run/containers/storage")
      --storage-driver string                storage-driver
      --storage-opt strings                  storage driver option
      --userns-gid-map ctrID:hostID:length   default ctrID:hostID:length GID mapping to use
      --userns-uid-map ctrID:hostID:length   default ctrID:hostID:length UID mapping to use
      --version                              version for buildah

Use "buildah [command] --help" for more information about a command.
siretart@kaby:/srv/scratch/packages/containers$ buildah --version
buildah version 1.7.2 (image-spec 1.0.1, runtime-spec 1.0.1)

This required me to identify some API patches and backport them as distro patches: https://salsa.debian.org/go-team/packages/golang-github-containers-image/tree/master/debian/patches

Interest in those packages has been raised on the debian-go mailinglist: http://lists.debian.org/1556175727.17363.6.camel@siemens.com - with the many package we have here, it is admittedly not easy to keep track of all dependencies. As next steps, I'll play with https://aptly.info to create a repository that backports all packages and dependencies required to build and run skopeo and buildah. I think I should be able to publish that on my https://people.debian.org/~siretart/ homepage.

I also briefly looked at packaging podman, and noticed that there are a number of additional dependencies that need to be packaged.

vrothberg commented 5 years ago

@siretart, thank you so much! Wonderful news and certainly a herculean task given the jungle of dependencies.

rhatdan commented 5 years ago

Does that mean I can install a debian machine and just install skopeo, or is there some other configureation that needs to be setup. basically can I do

buildah from debian
buildah run apt-get skopeo
ramcq commented 5 years ago

@siretart This is really great progress, thanks for your work. We're integrating podman/buildah/toolbox into Endless OS which is a Debian derivative. We started with building the Ubuntu PPAs but I understand they will go away soon in favour of snaps. @andrunko has been working on it recently - is there anything we could do to help you get the debs completed and into Debian?

siretart commented 5 years ago

Does that mean I can install a debian machine and just install skopeo, or is there some other configureation that needs to be setup.

There is additional configuration necessary. Specifically, you'll be able to do that after you've added the additional repository that I plan to work on to your system:

As next steps, I'll play with https://aptly.info to create a repository that backports all packages and dependencies required to build and run skopeo and buildah. I think I should be able to publish that on my https://people.debian.org/~siretart/ homepage.

That step will go away after ftp-master has finished reviewing the NEW packages and ACCEPTed them into the Debian archive proper (cf. https://ftp-master.debian.org/new.html, and https://ftp-master.debian.org/REJECT-FAQ.html). Right now, they are super busy with the upcoming Debian buster release.

siretart commented 5 years ago

@siretart This is really great progress, thanks for your work. We're integrating podman/buildah/toolbox into Endless OS which is a Debian derivative. We started with building the Ubuntu PPAs but I understand they will go away soon in favour of snaps. @andrunko has been working on it recently - is there anything we could do to help you get the debs completed and into Debian?

Can you please give me a reference to PPAs going away? I'm confused about this comment.

Thank you for your interest in helping out. There are, in fact, a couple of things you guys could help me with:

maflcko commented 5 years ago

I do like the effort to get the podman package into vanilla Debian, but I fail to understand how the podman release process plays with the Debian guideline on backports and bug fixes. IIUC podman is on a rolling release and bug fixes only come with the next release, which inevitably includes new features. Old releases of podman are superseded with a new release of podman and there are no fixup releases of previous major versions? Given that Debian avoids to pull in new versions that add features or break workflows, this could lead to delays in backporting security fixes, especially if the bug fix interacts with features that were added later and thus no longer applies cleanly to a previous release.

ramcq commented 5 years ago

@marcofalke What you describe is the entire problem with Linux distributions in general and isn't specific to podman at all. Debian generally adopts a policy of backporting security patches if the upstream releases contain unrelated changes, but some upstreams where fixes are numerous time-critical, complex to backport, and expose the user to significant risk have an exception where newer upstream versions are used - I believe Firefox is an example of this. In any case, each stable Debian release has a corresponding backports repository where the maintainer can keep the latest upstream version running on the stable Debian release. I think podman would be a good candidate for this.

siretart commented 5 years ago

I do like the effort to get the podman package into vanilla Debian, but I fail to understand how the podman release process plays with the Debian guideline on backports and bug fixes. IIUC podman is on a rolling release and bug fixes only come with the next release, which inevitably includes new features. Old releases of podman are superseded with a new release of podman and there are no fixup releases of previous major versions? Given that Debian avoids to pull in new versions that add features or break workflows, this could lead to delays in backporting security fixes, especially if the bug fix interacts with features that were added later and thus no longer applies cleanly to a previous release.

I think your question is confused and mixes a number of different concerns and goals here.

One of them is producing a stable "release" that gives users reliable and working software. This is what Debian "stable" releases provide. Software in stable are called stable not because they are bugfree or provide most recent features, but are predictable and surprise-free in operations. This usually means no new upstream releases and features, but confidence that a security update will not interfere with your operations. For software packages such as podman and buildah this provides significant value for its users, since, as you point out, upstream is developing at fast pace and those packages are evolving swiftly. In a way, software in stable insulates this upstream development churn from users that require a predictable working environment.

The Firefox example (and this applies to chromium, and a few number of other packages as well) is not a great one, because it constitutes an exception to this rule. In such cases, the Debian security team has basically "given up" on the goals outlined above and essentially backport the whole stack. For browsers, this has lead to frustrations about plugins no longer working, and similar. This is not what I'd wish for podman and buildah.

The Debian testing distribution on the other hand is more of a rolling distribution. It is an excellent choice for developers because it provides access to modern software package versions with a relatively low turnaround (usually measured in days, sometimes weeks). Getting podman and friends here should be the primary goal for this particular github issue. To get there, we need to package all components in a way that complies with the various Debian policies, including the Debian Policy Manual (cf. https://www.debian.org/doc/debian-policy/), the Debian Free Software Guidelines (cf. https://www.debian.org/social_contract#guidelines) and Licensing Review (cf. https://wiki.debian.org/Teams/FTPMaster and https://ftp-master.debian.org/REJECT-FAQ.html). I see significant value to software packages in general, and the RedHat Container projects in particular, to actively seek conformance here: Because of its relatively high bar, it generally makes your software package more portable, applicable and relevant to customers and the Free Software community in general.

Once we have the package in testing, we may choose to backport them following the guidelines at https://backports.debian.org/. This enables users of stable versions of Debian to use newer versions of the software in earlier releases of Debian. Here, users choose to compromise on the promise of stable releases, but admittedly, it is a rather popular compromise. As you can see from the backports web page, having the software package in testing is a strict requirement (and the maintainers of the backports archive tend to not compromise on this).

At this point, I'm focusing on getting the software packages, and their dependencies, into the unstable and experimental distributions of Debian, because Debian is currently in freeze mode, cf. https://lists.debian.org/debian-devel-announce/2019/03/msg00003.html. This means that right now is a really bad time to get new software packages into testing. Once Debian buster is released, we ideally have all packages in place and have a smooth transition to testing. The most recent update on the freeze process and the upcoming release can be read at https://lists.debian.org/debian-devel-announce/2018/04/msg00007.html

Hope this clarifies things.

Silvanoc commented 5 years ago

I'll play with https://aptly.info to create a repository that backports all packages and dependencies required to build and run skopeo and buildah. I think I should be able to publish that on my https://people.debian.org/~siretart/ homepage.

That would be helpful!

siretart commented 5 years ago

I've rebuild and backported the full stack in clean Debian/buster chroots, so I'd expect the packages to work on the upcoming Debian 10 release, and existing Debian "testing" and "unstable" laptops. To enable the repository, do these steps as root:

$ curl https://people.debian.org/~siretart/rtbp/siretart-archive-key.asc | apt-key add -

$ cat > /etc/apt/sources.list.d/rtbp.list <<EOF deb https://people.debian.org/~siretart/rtbp buster-backports main deb-src https://people.debian.org/~siretart/rtbp buster-backports main EOF

$ apt update && apt install buildah skopeo

Before using skopeo, please mind the note in https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/blob/d47ce7267b370614095d4a5a621d5eba473eb23d/debian/README.Debian

User Namespaces

Buildah requires a Linux Kernel with userspaces enabled. Debian Kernels have that functionaly, but the local system administrator needs to enable it manually, with a command like this:

sudo sysctl -w kernel.unprivileged_userns_clone=1

Feedback, and assistance, preferably in form of PRs against the salsa packaging branches would be most appreciated.

gertvdijk commented 5 years ago

@siretart Lovely, thanks for your work! Can't wait for the podman package available too. :smiley:

Sidenote: I see you've published docker.io in the repository too, presumably purely to allow other people building the packages too (as it seems to be a build dependency). It would now also update the docker.io package on your system, unless one will use APT pinning to prevent that. Would it be possible to publish docker.io in either 1) a separate repository, 2) with a lower priority in your repo (so that only packages not in regular repositories will be considered in apt-upgrade)?

$ apt policy docker.io
docker.io:
  Installed: (none)
  Candidate: 18.09.3+dfsg1-1~rtbp1
  Version table:
     18.09.3+dfsg1-1~rtbp1 500
        500 https://people.debian.org/~siretart/rtbp buster-backports/main amd64 Packages
     18.09.1+dfsg1-5+b10 500
        500 http://ftp.nl.debian.org/debian buster/main amd64 Packages
siretart commented 5 years ago

Thanks for your interest in that repository.

That would be a major inconvenience, because that would prevent me from using that repository as a staging ground for package builds - I'd have to juggle between two repositories which to be frank I don't find very valuable. Please note that my repository doesn't come with any warranty or support, its sole purpose is to solicit feedback and help with testing. Please don't install any packages from that repository on any machines where you use the docker.io package for your day-to-day activities, please use a VM or similar instead.

Also note that I might be asked to remove those packages at any time by the team operating http://people.debian.org, so please don't rely on it for any purpose other than testing and providing feedback.

gertvdijk commented 5 years ago

@siretart

that would prevent me from using that repository as a staging ground for package builds - I'd have to juggle between two repositories which to be frank I don't find very valuable.

Understand that and that's why I suggested pinning. To elaborate a bit more: e.g. pin your repository with e.g. prio 600 in APT preferences if you need to build from it, but publish with the option -butautomaticupgrades causes it to lower the priority (more info) would prevent updating the unrelated packages on the systems of (non-developer) users, just like how the regular buster-backports repository is published:

ButAutomaticUpgrades: yes

in http://ftp.nl.debian.org/debian/dists/buster-backports/Release

Anyway, it's just a suggestion and improving the experience for users who might otherwise not receive (important) security updates of the Docker package if your repository isn't maintained in the future.

varac commented 5 years ago

@siretart Are you aware of any progress of a official Debian package ?

The old debian-go thread about packaging podman (next to other container tools) stalled. I crreated a request for packaging. It would be awesome to have it in plain Debian !

Zjemm commented 5 years ago

i hope it will get picked up as debian is my go to for bare metal servers. So it would me great to use podman on vanilla debian

xinau commented 5 years ago

Thanks for all the hard work. I can't wait to see these packages in vanilla debian.

Ciantic commented 5 years ago

Does vanilla debian mean also Raspberry Pi variant?

My Pi is very unhappy camper as you can see:

pi@raspberrypi:~ $ sudo apt install podman
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package podman

pi@raspberrypi:~ $ sudo apt install libpod
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libpod
rhatdan commented 5 years ago

@lsm5 Any progress? @Ciantic @Zjemm @varac @gertvdijk @siretart Could anyone help this issue?

lsm5 commented 5 years ago

On Mon, Aug 05, 2019 at 02:06:48PM -0700, Daniel J Walsh wrote:

@lsm5 Any progress? @Ciantic @Zjemm @varac @gertvdijk @siretart Could anyone help this issue?

Nothing yet, but I'm planning to use opensuse's open build service to build for debian, soon as I get the chance. That might be the most convenient for debian, unless others can suggest/contribute better approaches.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/containers/libpod/issues/1742#issuecomment-518400295

-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5

vrothberg commented 5 years ago

Pulling in @sysrich who will surely be happy to support us in using OBS. The packages for Podman and Buildah (and CRI-O) are already in the Kubic project, so maybe we can collaborate on that? @marcov did an awesome job in helping Kata packaging on OBS.

Zjemm commented 5 years ago

@lsm5 nice, keep us posted

lsm5 commented 5 years ago

Pulling in @sysrich who will surely be happy to support us in using OBS. The packages for Podman and Buildah (and CRI-O) are already in the Kubic project, so maybe we can collaborate on that? @marcov did an awesome job in helping Kata packaging on OBS.

@sysrich @vrothberg are those podman and buildah packages apt install-able? We could just post those install steps on our docs and be done with it. So, hopefully, nothing for me to do then :)