Package up podman for vanilla Debian #1742

lsm5 · 2018-11-01T00:17:53Z

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

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wnpp
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930440 :: libpod / podman
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928083 :: buildah
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880199 :: skopeo

lsm5 · 2018-11-01T00:18:23Z

@qiancai let's track Debian work here

lsm5 · 2018-11-01T00:20:10Z

@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 · 2018-11-01T13:01:15Z

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

ghost · 2018-11-01T13:31:57Z

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 · 2018-11-01T14:11:10Z

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 · 2018-11-01T14:14:57Z

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: #1742 (comment)

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

ghost · 2018-11-01T16:01:10Z

Filed a container-selinux bug,

containers/container-selinux#57

ghost · 2018-11-01T18:39:33Z

Filed a oci-systemd-hook bug,

projectatomic/oci-systemd-hook#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 · 2018-11-01T18:49:46Z

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

ghost · 2018-11-01T19:00:41Z

It turned out that podman still depend on oci-systemd-hook. See 57a8c2e

I can also help with running standalone runc systemd containers.

ghost · 2018-11-01T20:37:27Z

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 · 2018-11-07T15:35:55Z

Filed bugs to tag repos.

containers/storage#232

containers/image#531

ghost · 2018-12-07T18:40:31Z

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 · 2018-12-07T19:26:51Z

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

But I have no objection.

ghost · 2018-12-07T19:35:44Z

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 · 2018-12-07T19:47:04Z

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

ghost · 2018-12-07T20:51:50Z

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 · 2018-12-12T10:09:45Z

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 · 2019-02-19T11:33:00Z

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 · 2019-02-19T13:10:35Z

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 · 2019-02-19T13:23:44Z

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 😒

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! 👍

rhatdan · 2019-03-08T16:35:11Z

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 · 2019-03-10T15:52:11Z

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 containers/storage#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 · 2019-03-17T12:50:59Z

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 openshift/imagebuilder#125 (comment) - Valentin is working on a fix for that in openshift/imagebuilder#127

vrothberg · 2019-03-18T08:55:47Z

Thanks for the update, @siretart 🙏

rhatdan · 2019-04-13T09:36:21Z

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

siretart · 2019-04-13T12:20:30Z

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:

https://tracker.debian.org/pkg/golang-github-appc-cni (update to 0.7.2~rc2 in experimental)
https://tracker.debian.org/pkg/golang-github-vbauerster-mpb (new package)
https://tracker.debian.org/pkg/golang-github-spkg-bom (new package)
https://tracker.debian.org/pkg/slirp4netns (update to 0.3.0 in experimental)
https://tracker.debian.org/pkg/docker.io (update to 18.09.03 in experimental)

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 containers/buildah#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:

Wait for ftp-master to ACCEPT containers/storage, which would enable me to upload imagebuilder for review. The Debian 10 release is really around the corner, so I'm not surprised that ftp-master prioritizes the new stable release over NEW package
prepare the buildah package
investigate what needs to be packaged for skopeo

siretart · 2019-04-27T23:13:16Z

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/[email protected] - 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.

lsm5 · 2020-01-20T12:55:36Z

Quick update, the install doc has been updated to include OBS repo setup. The debian maintainers can update the relevant sections once the official packages are shipped. HTH.

travier-anssi · 2020-01-24T13:08:29Z

@lsm5 Thanks for the packaging work! This is very much appreciated!
The latest podman build from the Kubic project repository (podman_1.7.0~3) installs the "docker" man pages as well as the podman ones which makes this package conflict with Docker on a system with Docker already installed.

lsm5 · 2020-01-27T15:18:29Z

@travier-anssi whoops, thought I disabled docker manpages, but apparently not, fixing..

lsm5 · 2020-01-27T20:12:33Z

@lsm5 Thanks for the packaging work! This is very much appreciated!
The latest podman build from the Kubic project repository (podman_1.7.0~3) installs the "docker" man pages as well as the podman ones which makes this package conflict with Docker on a system with Docker already installed.

@travier-anssi #4747 (comment)

rhatdan · 2020-02-17T22:20:19Z

Can we close this one now? Is podman available from Debian?

TomSweeneyRedHat · 2020-02-17T22:47:25Z

@lsm5 WDYT?

anarcat · 2020-02-17T23:01:51Z

as far as the "from debian" side of things, podman is still waiting for approval in "NEW":

https://ftp-master.debian.org/new/libpod_1.6.4+dfsg-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930440

lsm5 · 2020-02-18T13:29:05Z

@lsm5 WDYT?

I'm not opposed to closing this, but maybe community prefers this bug for tracking instead of the debian bugs listed above...

rhatdan · 2020-02-18T14:11:45Z

Since this is not an upstream issue, I will close it.

Silvanoc · 2020-05-18T10:07:35Z

Even when this issue is closed, just to share the information with the people following this issue: Podman has been accepted to "unstable"! 🎉

Currently it's still on version 1.6.4, but I assume that an update will follow.

If some criteria are fulfilled, then the package moves automatically to testing. That will be the point where the masses will be able to start enjoying the effort of @onlyjob (thanks for it!).

anarcat · 2020-05-19T15:19:23Z

for those wanting details of the debian package, i find that https://tracker.debian.org/pkg/libpod is a better URL to follow. packages.debian.org is more "user-facing" and tracker.debian.org is better for "developers" (including upstreams), and will show stuff like "has the package entered testing? why not? which versions are in which release? (including ubuntu if it diverges? yes!) is it behind upstream?" etc.

in this case, podman is blocked on https://tracker.debian.org/pkg/golang-github-openshift-imagebuilder which was failing to build on arm: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959538 (openshift/imagebuilder#160) for which a fix was uploaded today. :)

siretart · 2020-05-19T22:08:37Z

Thanks anarcat for keeping this issue posted.

The packages in debian are currently lagging a few upstream releases behind, but the good news is that I already prepared updated packages and they work great for me on my laptop. The new packages needed a couple of dependencies updated and as soon as they make it to Debian, I can proceed with uploading the updates.

ghost · 2020-07-09T09:50:09Z

Wish debian Sid support podman v2.0

anarcat · 2020-07-09T13:25:23Z

Wish debian Sid support podman v2.0

I believe the right place to report that is not here but on the Debian bugtracker, which already knows about it. :)

It seems there's about a dozen dependencies missing...

siretart · 2020-07-17T01:01:21Z

I just uploaded it to experimental. Turns out not all dependency updates were needed and I could patch podman to avoid some of the more problematic ones caughdockercaugh.

The package should work just fine on a debian 'testing' system as well (that's what I have on my laptop). Just install the .deb package from experimental.

Coming up next: Getting this in shape for the upcoming Debian's "bullseye" release...

I guess the instructions on https://podman.io/getting-started/installation for Debian could be updated?

Silvanoc · 2020-07-17T07:21:48Z

@siretart why is it only available for i386? Specially when the provided GitLab CI pipeline specification is only running architecture amd64 for experimental...
I hope it's an error, because I'd be glad to test the package, but I'm not activating multiarch in my system only for this package 🙂

yrro · 2020-07-17T07:28:16Z

It failed to build on the other architectures: https://buildd.debian.org/status/package.php?p=libpod&suite=experimental

siretart · 2020-07-17T10:41:58Z

It seems there is an issue with /run/user/... on some (but not all) buildd nodes (and not on my machine). ~~I'm on it~~ I've just uploaded a workaround for that -- apparently some buildds have XDG_RUNTIME_DIR pointing to a non-writable location, go figure!

siretart · 2020-07-20T15:51:50Z

FYI, I've just uploaded podman 2.0 to unstable: https://tracker.debian.org/pkg/libpod

rhatdan · 2020-07-20T19:15:39Z

Awesome @siretart Great work.

Silvanoc · 2020-07-21T13:21:24Z

I've just installed it (on Debian Testing/Bullseye) and a simple rootless "image pull" and "run" worked directly 👏

Silvanoc · 2020-09-17T13:24:50Z

2020-07-27 Podman 2 reached the last stage needed to get into Debian stable: https://tracker.debian.org/news/1163256/libpod-202dfsg1-3-migrated-to-testing/

We will see, if it makes its way to the next stable release. But by having reached "Testing" release it has become usable for most developers using containers (we tend to use "testing" on our development machines) and it will probably get its way into next Ubuntu release (derived from Debian Testing).

Current version on testing is 2.0.4. This is the page to follow it: https://tracker.debian.org/pkg/libpod

Great job @siretart ! I'm happy to see it happening.

rosaliagomez referenced this issue in containers/containers.github.io Mar 22, 2019

Initial commit

78f0408

siretart mentioned this issue Apr 14, 2019

Buildah 1.7.2 fails to build against containers/image 1.5 containers/buildah#1512

Closed

lsm5 removed their assignment Jan 20, 2020

siretart mentioned this issue Jan 28, 2020

Copyright missing holders containers/skopeo#804

Closed

tchaikov mentioned this issue Feb 12, 2020

ceph.spec: Recommend (but do not require) podman ceph/ceph#33221

Merged

rhatdan closed this as completed Feb 18, 2020

castedo mentioned this issue Aug 20, 2020

Add development/testing Dockerfiles/Makefiles used with "cnest" tskit-dev/containers#1

Closed

FranklinYu mentioned this issue Sep 24, 2020

Update installation information on Debian containers/podman.io_old#288

Merged

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023

Package up podman for vanilla Debian #1742

Package up podman for vanilla Debian #1742

Comments

lsm5 commented Nov 1, 2018 • edited Loading

Update: Debian tickets

lsm5 commented Nov 1, 2018

lsm5 commented Nov 1, 2018

rhatdan commented Nov 1, 2018

ghost commented Nov 1, 2018

mheon commented Nov 1, 2018

lsm5 commented Nov 1, 2018 via email

ghost commented Nov 1, 2018

ghost commented Nov 1, 2018

mheon commented Nov 1, 2018

ghost commented Nov 1, 2018

ghost commented Nov 1, 2018

ghost commented Nov 7, 2018

ghost commented Dec 7, 2018

rhatdan commented Dec 7, 2018

ghost commented Dec 7, 2018

rhatdan commented Dec 7, 2018

ghost commented Dec 7, 2018

lsm5 commented Dec 12, 2018

Silvanoc commented Feb 19, 2019

vrothberg commented Feb 19, 2019

Silvanoc commented Feb 19, 2019 • edited Loading

rhatdan commented Mar 8, 2019

siretart commented Mar 10, 2019

siretart commented Mar 17, 2019

vrothberg commented Mar 18, 2019

rhatdan commented Apr 13, 2019

siretart commented Apr 13, 2019

siretart commented Apr 27, 2019

lsm5 commented Jan 20, 2020

travier-anssi commented Jan 24, 2020

lsm5 commented Jan 27, 2020

lsm5 commented Jan 27, 2020

rhatdan commented Feb 17, 2020

TomSweeneyRedHat commented Feb 17, 2020

anarcat commented Feb 17, 2020

lsm5 commented Feb 18, 2020

rhatdan commented Feb 18, 2020

Silvanoc commented May 18, 2020

anarcat commented May 19, 2020

siretart commented May 19, 2020

ghost commented Jul 9, 2020

anarcat commented Jul 9, 2020

siretart commented Jul 17, 2020 • edited Loading

Silvanoc commented Jul 17, 2020

yrro commented Jul 17, 2020

siretart commented Jul 17, 2020 • edited Loading

siretart commented Jul 20, 2020

rhatdan commented Jul 20, 2020

Silvanoc commented Jul 21, 2020

Silvanoc commented Sep 17, 2020

lsm5 commented Nov 1, 2018 •

edited

Loading

Silvanoc commented Feb 19, 2019 •

edited

Loading

siretart commented Jul 17, 2020 •

edited

Loading

siretart commented Jul 17, 2020 •

edited

Loading