Podman: Package up podman for vanilla Debian
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
All 142 comments
@qiancai let's track Debian work here
lsm5
on 1 Nov 2018
@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?
lsm5
on 1 Nov 2018
SELinux should not be a hard dependency, but a Nice to Have.
rhatdan
on 1 Nov 2018
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
ghost
on 1 Nov 2018
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?
mheon
on 1 Nov 2018
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
lsm5
on 1 Nov 2018
Filed a container-selinux bug,
ghost
on 1 Nov 2018
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
ghost
on 1 Nov 2018
We no longer depend on oci-systemd-hook (for Podman at least) - it's not necessary if you aren't packaging CRI-O
mheon
on 1 Nov 2018
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
on 1 Nov 2018
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
on 1 Nov 2018
Filed bugs to tag repos.
ghost
on 7 Nov 2018
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?
ghost
on 7 Dec 2018
Do people with debian use Snapstore. Or just Ubuntu and its descendent?
But I have no objection.
rhatdan
on 7 Dec 2018
Looks like only Ubuntu and its descendant use snap store, but I suppose our goal is to reach the Ubuntu 's huge developer base.
ghost
on 7 Dec 2018
Yup, That gets us to 95% of users, So much better then what we get now.
rhatdan
on 7 Dec 2018
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.
ghost
on 7 Dec 2018
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.
lsm5
on 12 Dec 2018
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...
Silvanoc
on 19 Feb 2019
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.
vrothberg
on 19 Feb 2019
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:
Silvanoc
on 19 Feb 2019
Sad to say I think this is stalling again. Still huge hurdles to get over in order to get Go Programs packaged into Debian.
rhatdan
on 8 Mar 2019
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
on 10 Mar 2019
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
siretart
on 17 Mar 2019
Thanks for the update, @siretart :pray:
vrothberg
on 18 Mar 2019
@siretart @vrothberg Is this still being worked on? Any progress?
rhatdan
on 13 Apr 2019
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 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:
- 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
on 13 Apr 2019
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.
siretart
on 28 Apr 2019
@siretart, thank you so much! Wonderful news and certainly a herculean task given the jungle of dependencies.
vrothberg
on 28 Apr 2019
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
@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?
ramcq
on 28 Apr 2019
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
on 28 Apr 2019
@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:
- Identify / draw a map of dependencies and source package git repositories on http://salsa.debian.org . I currently have it in my head, but having a visual representation would, I believe be helpful - keep in mind, there still churn caused by upstream development on this, see the linked issues from this thread. This map is (still) evolving.
- Review the packaging of the packages that I did:
- Are the files
debian/copyrightin the individual packages accurate? I experienced setbacks because of this. It may involve asking for clarification from Upstream - Figure out a way how to re-enable the test suites in the packages. I had to disable them in some packages to make progress faster, but that is risky -- having the tests run would give us more confidence with going to newer upstream releases.
- Are the files
- Testing of my packages
- this will get much easier with the repository I'm working on, see above. Until this is done, try using the map of dependencies from above to build the stack yourself.
- Give feedback on integration and functionality. This may involve communication with upstream.
- Package
podman(there is still a lot of work to be done here):
- Identify / map out dependencies that need to be packaged
- File an ITP bug and mention all of those missing dependencies there
- package the missing dependencies.
siretart
on 28 Apr 2019
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.
MarcoFalke
on 28 Apr 2019
@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.
ramcq
on 28 Apr 2019
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.
siretart
on 28 Apr 2019
I'll play with https://aptly.info to create a repository that backports all packages and dependencies required to build and run
skopeoandbuildah. I think I should be able to publish that on my https://people.debian.org/~siretart/ homepage.
That would be helpful!
Silvanoc
on 29 Apr 2019
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 <
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.
siretart
on 30 Apr 2019
@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
gertvdijk
on 30 Apr 2019
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.
siretart
on 30 Apr 2019
@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.
gertvdijk
on 6 May 2019
@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 !
varac
on 12 Jun 2019
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
Zjemm
on 2 Jul 2019
Thanks for all the hard work. I can't wait to see these packages in vanilla debian.
xinau
on 13 Jul 2019
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
Ciantic
on 18 Jul 2019
@lsm5 Any progress? @Ciantic @Zjemm @varac @gertvdijk @siretart Could anyone help this issue?
rhatdan
on 5 Aug 2019
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
lsm5
on 5 Aug 2019
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.
vrothberg
on 6 Aug 2019
@lsm5 nice, keep us posted
Zjemm
on 18 Aug 2019
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 :)
lsm5
on 19 Aug 2019
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 :)
I have no experience in cross-distro packaging in OBS. At the moment, the packages are not offered for other distros. @sysrich, @marcov, how much work would it be to use the packages in devel:kubic to offer them for Debian, Ubuntu etc.?
vrothberg
on 19 Aug 2019
Hi @vrothberg, from my experience with Kata, adding a new set of {dsc,control,rules} files to build deb packages is something that would not take more than 1 day or 2.
Assuming those packages are made available on devel:kubic, who will provide the required support for Debian/Ubuntu issues? Maybe a good solution would be to have a dedicated subproject for to deb builds, linked to the parent project.
marcov
on 19 Aug 2019
Hi @vrothberg, from my experience with Kata, adding a new set of
{dsc,control,rules}files to build deb packages is something that would not take more than 1 day or 2.
This sounds very promising!
Assuming those packages are made available on devel:kubic, who will provide the required support for Debian/Ubuntu issues?
@lsm5, would that be you? I can certainly help getting started with the packages as I've spent quite some time packaging them for openSUSE.
Maybe a good solution would be to have a dedicated subproject for to deb builds, linked to the parent project.
I trust your cross-distro experience :) Sounds good to me.
vrothberg
on 19 Aug 2019
Nice, I'd like to hear what @sysrich thinks about this.
marcov
on 19 Aug 2019
On Mon, Aug 19, 2019 at 01:29:01AM -0700, Valentin Rothberg wrote:
Assuming those packages are made available on devel:kubic, who will provide the required support for Debian/Ubuntu issues?
@lsm5, would that be you? In can certainly help getting started with the packages as I've spent quite some time packaging them for openSUSE.
Sure, I can own that. My OBS account is 'lsm5'.
--
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
lsm5
on 19 Aug 2019
Does vanilla debian mean also Raspberry Pi variant?
I am also curious about this. I would love to be able to install and run this on Pi.
kevinelliott
on 13 Sep 2019
@kevinelliott want to run podman on RPI3?
[This is an Ad] :laughing: Check out openSUSE Tumbleweed then, the latest podman is packaged and ready to install.
marcov
on 13 Sep 2019
@marcov I did end up using Fedora Minimal 10 to get it early this morning.
kevinelliott
on 13 Sep 2019
Friendly bump on the progress of the debian packages for podman, buildah and skopeo?
johanbrandhorst
on 26 Sep 2019
@johanbrandhorst just follow respective Debian WNPP tickets for status.
In short, not even close. Docker is already a dependency hell and _libpod_ adds a bunch of dependencies on top. Resulting dependency tree is insane/fragile and very hard to maintain due to its size.
This is how it feels to maintain the docker and libpod dependency trees: https://media.wired.com/photos/5c50f2c878c63d4dfaaf9b5a/master/pass/jenga-488252207.jpg ;)
onlyjob
on 26 Sep 2019
Thanks, sorry for being a noob, have you got a link to the tickets?
johanbrandhorst
on 26 Sep 2019
Hi @vrothberg, from my experience with Kata, adding a new set of
{dsc,control,rules}files to build deb packages is something that would not take more than 1 day or 2.Assuming those packages are made available on devel:kubic, who will provide the required support for Debian/Ubuntu issues? Maybe a good solution would be to have a dedicated subproject for to deb builds, linked to the parent project.
@marcov @sysrich would you still like to go ahead with this? Let me know how I can help.
lsm5
on 26 Sep 2019
onlyjob
on 26 Sep 2019
Thanks, @onlyjob. I added the links to the top comment to highlight them.
vrothberg
on 2 Oct 2019
For those interested in status of libpod, the most recent updates seem to be in blocking bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923300 (last week) which seems to be nearing upload.
The other blockers for libpod are https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930900 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928083
The latter is formally blocked on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922842 but, reading the bug thread, may not actually be a prerequisite for libpod.
khimaros
on 15 Oct 2019
This should be fixed now since the vendor has been removed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923300
rhatdan
on 17 Oct 2019
so it comes closer and closer
Zjemm
on 25 Oct 2019
so it comes closer and closer
Yeah... But it is a desperate move in the absence of anything better (perhaps except Singularity).
I wish they'd give some attention to rkt instead.
The problem is that libpod/podman depends on Docker and through Docker on the "world" of Goland libraries. Combined dependency tree is enormous...
_rkt_ have advantage of being lightweight and better designed, without depending on Docker.
I wish it hasn't been abandoned...
onlyjob
on 26 Oct 2019
( @onlyjob Looking at the Rkt activity, it seems abandoned to me: https://github.com/rkt/rkt/graphs/contributors :- ( ... Anyway, looking forward to Podman on Debian. Then I can use Systemd + Podman for my software on all of RHEL / Debian / Ubuntu :- ) )
kajmagnus
on 26 Oct 2019
You are arguing about Betamax versus VHS. The UI and the quantity of image is what one. The Podman/Docker CLI and the OCI Images.
rhatdan
on 26 Oct 2019
For those who build (or convert) their own images, the quantity of available (untrusted) images is pointless. Reproducing Docker's CLI interface is of questionable convenience value. The whole idea is about getting off inferior Docker that just refuses to improve due to bad governance -- to avoid using Docker indirectly and therefore avoid Docker's code bloat and other insanities. IMHO _libpod_ is a missed opportunity to _really_ improve things because _libpod_ builds upon Docker when _rkt_ is not. IMHO _rkt_ is still a superior technology, regretfully abandoned not for technical but for political reasons. I think it is silly to make a new application container engine due to dissatisfaction with Docker yet depend on Docker code base. Just let the Docker die already and clear the path for superior container runtimes...
onlyjob
on 26 Oct 2019
I don't think this conversation is constructive, so please don't let this issue derail into something else than the Debian packaging efforts.
We have invested a considerable amount of time to make the tools easier to package for Debian; especially earlier this year with @siretart who found quite some obstacles that we collaboratively improved. Those efforts were based on real issues that needed to be resolved to unblock the ongoing packaging work.
By _actually looking at the code_, you will notice that the dependencies on Docker (and other large code bases) have _zero_ impact on the architecture of Podman. If using go packages from Docker is a _real_ problem for some, please raise your voice _constructively_, outlining the exact issues, and we're willing to help. We're certainly always welcoming contributions.
vrothberg
on 28 Oct 2019
... dependencies on Docker (and other large code bases) have zero impact on the architecture of Podman.
Zero impact, really? You have no idea... Bugs in Docker, especially security bugs, affect Podman as well. Maybe not such a big problem for you, @vrothberg, but downstream maintainer have to own the whole (fragile) dependency tree effectively maintaining Docker as well (like if that is not hard enough), with all its dependencies. You see, it only takes one security bug in Docker (or any of its dependencies) for all packages depending on Docker to be thrown away from "testing". It only takes one serious bug (e.g. causing "FTBFS") _anywhere_ in the dependency tree to have all depending packages thrown away from "testing"... Too much code and too many dependencies is a challenge to maintain and a practical problem let's not forget that one needs to take care of obsolete libraries, forks, etc. It is not only the Podman needs to be packaged (and maintained) but _all_ its dependencies as well and that's a lot of work large portion of which lays in Docker.
onlyjob
on 28 Oct 2019
I was talking about the _architecture_ of Podman. You are now referring to the impact of a Docker bug on the _Debian maintenance_, which are two separate things. My comment referred to your statement about Podman inheriting some not further specified problems you see with Docker (see https://github.com/containers/libpod/issues/1742#issuecomment-546591336). I understand it's a herculean task to package those gigantic code bases for Debian and we're continuing to support those efforts as we did before.
Most Linux distros don't bother trying to package each project into separate source packages as it's too much work and things are moving very quickly with frequent big changes. Debian goes down this rabbit hole, so I can only imagine the pain. However, we can't change the Debian packaging policies and we also don't have a fast path to prune the dependencies on Docker since they provide essential functionality for Podman (e.g., docker client code, ability to copy images to/from the Docker daemon).
Long story short, let's not hate the player but the game: we're in this together.
vrothberg
on 28 Oct 2019
Please keep this discussion on-topic. A bunch of people have subscribed here that want to follow the status of "Package up podman for vanilla Debian" and only that. Thanks :pray:
MarcoFalke
on 28 Oct 2019
IMHO it would be better to have an optional CLI utility to fetch/import Docker images (e.g. something similar to docker2aci). This way Podman could have no dependencies on Docker and only those who needs Docker interoperability would install/use such utility.
As for packaging Podman, the progress is good as a lot of work has been done during last several months (I estimate that there were 40+ uploads of direct and indirect dependency packages). Podman 1.6 builds and appears to work; only few dependencies are pending review...
onlyjob
on 29 Oct 2019
Not ideal, but it may be good to know: ubuntu bionic packages have been working with debian stretch.
yangm97
on 8 Nov 2019
Quick update: debian(10, testing and unstable) and ubuntu(18.04, 19.04 and 19.10) builds on OBS are WIP at https://build.opensuse.org/project/show/home:rhcontainerbot:stable since yesterday, (got some dependencies packaged but not podman, buildah or cri-o yet), seems to be progressing quick and I hope to get done this week. If it works well for people, I hope to obsolete the current PPAs in favour of OBS.
Future TODOs:
- enable testing and unstable branches in there for RC and hourly master branch builds.
- keep a few older builds in repo for anyone wishing to revert.
- add more arches and distros
/cc @vrothberg @baude @mheon @TomSweeneyRedHat @rhatdan
lsm5
on 18 Nov 2019
While I appreciate the work on OBS, it looks like the builds are only for x86_64. For e.g. aarch64 or similar we'd have to keep using the ppa or hope for vanilla packages?
MarcoFalke
on 18 Nov 2019
While I appreciate the work on OBS, it looks like the builds are only for x86_64. For e.g. aarch64 or similar we'd have to keep using the ppa or hope for vanilla packages?
TODO updated in above comment. More arches and distros will be added.
lsm5
on 18 Nov 2019
So how would you switch to using OBS from existing ppa for ubuntu bionic? I assume that is where current efforts are directing us.
alitvak69
on 21 Nov 2019
Whos efforts? I have submitted Podman for review and currently it is pending in NEW.
Once accepted, the official packages will become available from Debian mirrors and hopefully nobody would need _vendor_ packages any more.
Using _vendor_ packages is usually a bad idea - you know, Don't break Debian.
As for Ubuntu, I recommend to use Debian instead.
onlyjob
on 21 Nov 2019
So how would you switch to using OBS from existing ppa for ubuntu bionic? I assume that is where current efforts are directing us.
AFAICT, the packages in the OBS repos will be ahead of the PPA, so you should just be able to add the OBS repo and apt update to the latest.
lsm5
on 21 Nov 2019
Whos efforts? I have submitted Podman for review and currently it is pending in NEW.
Once accepted, the official packages will become available from Debian mirrors and hopefully nobody would need _vendor_ packages any more.
Great news, thanks for your hard work, @onlyjob!
vrothberg
on 21 Nov 2019
@onlyjob Of course, the world needs Debian to solve all its problems :-)
@lsm5 I am a bit confused here. For Ubuntu xxx, will you maintain both ppa and OBS? Also, forgive me my ignorance but in sources.list, does it look like
deb https://download.opensuse.org/repositories/home:/rhcontainerbot:/ xUbuntu_18.04 stable
Or you need to do it some other way? I prefer not to use snap if possible.
alitvak69
on 21 Nov 2019
Actually found this document here:
https://en.opensuse.org/openSUSE:Build_Service_Debian_builds
alitvak69
on 21 Nov 2019
@lsm5 I wonder if the new packages from OBS get to Atomic Host PPA or the PPA becomes obsolete? At this point I have both on my box, what are your plans there?
I guess my problem is, we are relying on LTS releases of ubuntu and 19.10 packages are not very useful to my developers. It doesn't mean that other people don't need them but OBS missing 16.04 packages completely and also some 18.04 packages (skopeo just one of the examples).
It would be great to have all the packages in one distro IMHO.
alitvak69
on 26 Nov 2019
@lsm5 I wonder if the new packages from OBS get to Atomic Host PPA or the PPA becomes obsolete? At this point I have both on my box, what are your plans there?
I plan to include all supported (including LTS) Ubuntu releases as well on OBS, so that nobody would need to use PPA once OBS is setup.
Currently, I notice dependency issues on some basic packages (debhelper and such) which I'm working on with the OBS people.
There would also be the issue of getting a newer golang (probably from gophers PPA) for 16.04 and maybe 18.04 to get packages to build, and that'd need some more customization of OBS infra and maybe the packaging files too.
lsm5
on 27 Nov 2019
As far as I can see, the Debian packaging configuration being used for OBS is not available in this repository right? Is it somewhere available?
I've found an issue on https://download.opensuse.org/repositories/home:/rhcontainerbot:/stable/Debian_Testing/amd64/podman_1.6.3~14_amd64.deb and I'd like to report it including the fix.
Just in case you are interested on the issue: the package is trying to create /usr/lib/tmpfiles.d as a file, what luckily fails because it's an already existing directory.
Silvanoc
on 5 Dec 2019
On Thu, Dec 05, 2019 at 05:34:04AM -0800, Silvano Cirujano Cuesta wrote:
As far as I can see, the Debian packaging configuration being used for OBS is not available in this repository right? Is it somewhere available?
I've found an issue on https://download.opensuse.org/repositories/home:/rhcontainerbot:/stable/Debian_Testing/amd64/podman_1.6.3~14_amd64.deb and I'd like to report it including the fix.
Just in case you are interested on the issue: the package is trying to create
/usr/lib/tmpfiles.das a file, what luckily fails because it's an already existing directory.
Thanks, this issue should be fixed in 1.6.3\~15.
The deb packaging stuff is currently on my personal fork.
See: https://github.com/lsm5/podman/blob/debian-stable/debian/rules#L67
--
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
lsm5
on 5 Dec 2019
As far as I'm concerned this is such a bad Debian packaging that nobody should use it.
onlyjob
on 5 Dec 2019
On Thu, Dec 05, 2019 at 06:20:07AM -0800, Dmitry Smirnov wrote:
As far as I'm concerned this is such a bad Debian packaging that nobody should use it.
Patches welcome. Can't wait to get this off my back :)
--
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
lsm5
on 5 Dec 2019
As far as I'm concerned this is such a bad Debian packaging that nobody should use it.
@onlyjob, if you want to improve the package in question, please make sure to give constructive feedback with concrete points for improvements and remain polite.
vrothberg
on 5 Dec 2019
As far as I'm concerned this is such a bad Debian packaging that nobody should use it.
As a temporary solution for non-productive bleeding edge experimentation is fine for me.
For productive/stable I agree that the WIP proper debianization is the only way to go.
Silvanoc
on 5 Dec 2019
As far as I'm concerned this is such a bad Debian packaging that nobody should use it.
Something that is a clear reason for me playing around with the OBS packages is that I get something to install easily.
Through the official Debian channels I only get a Debian packaging configuration that requests me to install something between 40 and 70 packages just to build the package. Some of them are not ready yet as packages, so they have to be built too. Sorry, that's too much just for playing around or experimenting the tool and not the packaging...
Silvanoc
on 5 Dec 2019
For productive/stable I agree that the WIP proper debianization is the only way to go.
Yes, so the work by @onlyjob is highly appreciated. Packaging things "the Debian way" would increase the stability of the overall system during system upgrade. I have had issues with several non-standard deb packages before.
FranklinYu
on 5 Dec 2019
if you want to improve the package in question, please make sure to give constructive feedback with concrete points for improvements and remain polite.
@vrothberg, I do not want to improve package in question. it is beyond constructive feedback and the whole point is that such redundant, improper, sloppy packaging should not exist, let alone be provided to the general public.
This poor packaging is an example of how not to do the job because it has been done without experience, without regards to good packaging practices, without respect to current policy; based on many-years-old template; without lintian, etc. Too many problems to list and why bother anyway when with @siretart we were working on proper Debianization for a _year_, really caring to do the job properly.
You say I should be providing constructive criticism? Why person who did such a terrible job with packaging did not follow our progress? Did not reach out with questions? Did not care to sync, cooperate or contribute?
To me helping to improve that packaging would require to do redundant job _again_, in the different place.
Proper Debianization should be done in one place - in Debian.
And the job is (nearly) done thanks to my nearly full time effort for the last four months or so, funded entirely on my own.
@Silvanoc, I'm not sure what you tried exactly but installing 40...70 dependency packages wouldn't be a problem if you were to build using chrooted _pbuilder_ or _sbuild_ tools.
Yes, proper packaging is not easy - it requires expertise and that's why it should be done by those who know how to do the work.
Thanks, @FranklinYu.
onlyjob
on 5 Dec 2019
@onlyjob -- I appreciate all of the work you've put into packaging podman (and surely many other packages), and I can see that you are passionate about upholding high standards of quality. As a Debian user of over 20 years and a former package maintainer myself, I'm in awe of the tremendous work and attention to detail that goes into providing such a solid foundation for the broader Linux distribution ecosystem. The work you do reaches far beyond Debian.
It seems that there were and are opportunities for closer collaboration on podman packaging, and I am sure the intention behind your reply is to challenge others to higher levels of technical excellence. That's honorable! However, I personally find the truth in your message is diluted by the way you've chosen to express it. As a Debian developer, it is not only your duty to be an effective package maintainer, but also to encourage and support others who flirt with joining the community. The damage done by "sloppy" communication can far outweigh the damage done by a "sloppy" package implementation. That damage can also reach far beyond Debian.
To be more specific with my critique; your suggestion that packaging should be done by skilled Debian developers is discouraging for those who are still learning. Everyone starts out as a novice, and it would be wise to heed the words of Plato: "Never discourage anyone [...] who continually makes progress, no matter how slow.” -- I'm sure you will continue to uphold standards of excellence on a technical level and I am certain that you can uphold similar standards of mentorship.
@lsm5 -- thank you for the work you've done to prototype these podman packages. You filled a gap in the ~year that elapsed between this issue's creation and supportable packages entering Debian Unstable. I hope that you won't be discouraged and will continue to engage with the Debian community and learn from the valid critiques of your work (run lintian, use modern templates, communicate/collaborate with other maintainers). The Debian community needs a stream of new volunteers like you to evolve and grow.
khimaros
on 6 Dec 2019
The package in question exists to provide something for Debian users _now_ and is an _intentional_ decision by the Podman maintainers where @lsm5 is tirelessly making sure that as many users on as many distributions can run Podman, Buildah, Skopeo, CRI-O and all direct dependencies. It pre-dates the effort to get Podman into the main Debian repositories and is not meant to compete but to offer Podman to Debian and Ubuntu users now.
We are more than happy when others step up to get Podman packaged into their main repositories, following the individual policies of each distribution. Certainly, we compromise quality with speed. Yet, technical differences do not justify personal attacks.
@onlyjob I would like to remind you that we are an inclusive community and would encourage you to remain polite and show respect to others here, I understand your point of view and frustrations, but let's use this space to collaborate with each other to make the experience better for all. Let this be the last time that I have to remind you to stay on topic before proceeding to take action.
vrothberg
on 6 Dec 2019
Ok let's keep this positive in nature. Everyone's goal here is to get Podman and friends in front of as many people users as possible and on to their distribution of choice.
rhatdan
on 6 Dec 2019
@khimaros thanks for the supportive comment, really appreciate it. We certainly want to see podman and related tools shipped in all the (atleast major) distros. RE: valid critiques on quality, sure I'll update packaging sources soon as I can find the time to focus on those, but at the moment, my goal is to deliver functional packages to Debian and downstream users and accommodate as many user requests as I can (bleeding-edge updates and the like), hopefully in an automated way.
As long as I'm not breaking users' envs, I would like to prioritize shipping builds and work on Debianizing once the delivery system is in place. Right now, I'm only reusing the packaging files I used for delivering builds to our Ubuntu PPA.
If you see any obvious problems that are going to affect users severely, please do point those out, this work is still WIP btw :) . Might be better to track those in a separate issue, and keep this issue for status updates only.
Thanks again!
lsm5
on 6 Dec 2019
Let this be the last time that I have to remind you to stay on topic before proceeding to take action.
@vrothberg, I find the threat and the tone of your message to be inappropriate. The very topic of this issue is being discussed and the discussion is relevant. Whatever "action" you have in mind, please don't hesitate as I'll walk away easily if you want me to. I have little patience with hostility.
@khimaros, thank you for your eloquence. Of course Debian is a welcoming community and we always do our best with good mentoring. It does not matter how much experience contributors have as long as they strive for excellence. However on this instance there were no attempt to do a good job from the very beginning let alone to improve it for policy compliance, best practice, etc.
In the interim until Podman is available from Debian repositories it might be "OK" to provide improper packages but the damage is not only from fragmentation and duplication of effort but also from the very availability of vendor packages as they will remain to be a source of confusion and an example of how not to package software for Debian.
IMHO discouraging bad job is just as important as encouraging an honest effort.
onlyjob
on 7 Dec 2019
Yet, technical differences do not justify personal attacks.
@vrothberg I have to point out that I have made no personal attacks but you did. I was only ever criticising technical work and the existence of vendor packages. You are reading between the lines.
onlyjob
on 7 Dec 2019
Dmitry,
It is not what you said, it's how you said it. And may be you feel like
you were just making a point, however other people on this thread
interpreted message as hostile.
BTW, the libpod group is very welcoming in general and comparing to other
FOS organizations is very responsive to developers and users needs. At
least I have been able to accomplish here much more than when we needed
help with docker.
On Fri, Dec 6, 2019, 6:28 PM Dmitry Smirnov notifications@github.com
wrote:
Yet, technical differences do not justify personal attacks.
@vrothberg https://github.com/vrothberg I have to point out that I have
made no personal attacks but you did. I was only ever criticising technical
work and the existence of vendor packages. You are reading between the
lines.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/1742?email_source=notifications&email_token=ABWJN3E4K6RSUN3Z3URTZRLQXLU2NA5CNFSM4GAWJJR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGFYMXI#issuecomment-562792029,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABWJN3G4A2E6Z6YXT2YJWBLQXLU2NANCNFSM4GAWJJRQ
.
alitvak69
on 7 Dec 2019
Let's try to bring to the surface all the positive happening around the topic of this discussion to recover the collaboration...
Thanks to the efforts of @lsm5 I've been able to easily test Podman on a Debian system specifically prepared for experimentation. It has been very useful for me to confirm that there are no blocker on Debian for running Podman. Thank you @lsm5 :heart:
Now I'm starting to test the packaging of @onlyjob with the hope to be able to use Podman on my development machine for productive usage. Thank you @onlyjob :heart:
I can almost see the goal thanks to your efforts!
Silvanoc
on 7 Dec 2019
In the current OBS package for Debian 10 has a bug:
dpkg: error processing archive /var/cache/apt/archives/podman_1.6.3~14_amd64.deb (--install):
trying to overwrite directory '/usr/lib/tmpfiles.d' in package dbus 1.12.16-1 with nondirectory
It contain usr/lib/tmpfiles.d as empty file
after removing the file, the package works:
sudo dpkg -i fixed.deb
(Reading database ... 53362 files and directories currently installed.)
Preparing to unpack fixed.deb ...
Unpacking podman (1.6.3~14) over (1.6.3~14) ...
Setting up podman (1.6.3~14) ...
Processing triggers for man-db (2.8.5-2) ...
How to remove the file?
dpkg-deb -R /var/cache/apt/archives/podman_1.6.3~14_amd64.deb /tmp/ex
rm usr/lib/tmpfiles.d
dpkg-deb -b /tmp/ex/ fixed.deb
sudo dpkg -i fixed.deb
apt-get install -f
stephankoelle
on 16 Dec 2019
While it's unfortunate there was some conflict around the packaging work in Debian, I am happy to announce that it seems there's some progress on the Debian side at least...
It seems podman has entered NEW:
https://ftp-master.debian.org/new/libpod_1.6.4+dfsg-1.html
The last dependency that was missing (bug 948113) is also waiting there:
https://ftp-master.debian.org/new/golang-github-checkpoint-restore-go-criu_3.11-1.html
This is great news! Can't wait to see this awesome project available in Debian... Just keep in mind packages can wait a while in NEW, however, as those packages are manually reviewed and vetted before admission.
Congratulations to everyone on all their hard work. Let's hope this can converge on a good, standard set of packages that will satisfy everyone involved! I, for one, will look at replacing Docker with podman in the near future on my infrastructure. :)
anarcat
on 5 Jan 2020
I've tried to create a backport for debian/buster. I think in the debian package are some files missing:
gitlab
packagecloud
I've tried to install it on debian/buster:
Add debian repository
root@debian-2gb-nbg1-1:~# curl -s https://packagecloud.io/install/repositories/chickeaterbanana/libpod/script.deb.sh | sudo bash
Detected operating system as debian/buster.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Running apt-get update... done.
Installing debian-archive-keyring which is needed for installing
apt-transport-https on many Debian systems.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/chickeaterbanana_libpod.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.
The repository is setup! You can now install packages.
Install Package:
root@debian-2gb-nbg1-1:~# apt-get install podman
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
conmon containernetworking-plugins crun libgpgme11 libseccomp2 libyajl2
Suggested packages:
containers-storage
Recommended packages:
buildah fuse-overlayfs slirp4netns tini | dumb-init uidmap
The following NEW packages will be installed:
conmon containernetworking-plugins crun libgpgme11 libyajl2 podman
The following packages will be upgraded:
libseccomp2
1 upgraded, 6 newly installed, 0 to remove and 93 not upgraded.
Need to get 19,2 MB of archives.
After this operation, 99,3 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian buster/main amd64 libyajl2 amd64 2.1.0-3 [23,8 kB]
Get:2 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 libseccomp2 amd64 2.4.2-2 [43,8 kB]
Get:3 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 conmon amd64 2.0.2-1 [26,2 kB]
Get:4 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 containernetworking-plugins amd64 0.8.3-2 [8.457 kB]
Get:5 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 crun amd64 0.11+dfsg-1 [148 kB]
Get:6 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 libgpgme11 amd64 1.13.1-1 [274 kB]
Get:7 https://packagecloud.io/chickeaterbanana/libpod/debian buster/main amd64 podman amd64 1.6.4+dfsg-1 [10,2 MB]
Fetched 19,2 MB in 4s (4.308 kB/s)
Try to run podman:
root@debian-2gb-nbg1-1:~# podman --version
podman version 1.6.4
WARN[0000] unable to find /etc/containers/registries.conf. some podman (image shortnames) commands may be limited
So the registries.conf isn't available. I get the registries.conf from github:
root@debian-2gb-nbg1-1:~# echo "# This is a system-wide configuration file used to
> # keep track of registries for various container backends.
> # It adheres to TOML format and does not support recursive
> # lists of registries.
>
> # The default location for this configuration file is /etc/containers/registries.conf.
>
> # The only valid categories are: 'registries.search', 'registries.insecure',
> # and 'registries.block'.
>
> [registries.search]
> registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']
>
> # If you need to access insecure registries, add the registry's fully-qualified name.
> # An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
> [registries.insecure]
> registries = []
>
>
> # If you need to block pull access from a registry, uncomment the section below
> # and add the registries fully-qualified name.
> #
> [registries.block]
> registries = []" > /etc/containers/registries.conf
Now everything seems fine:
root@debian-2gb-nbg1-1:~# podman --version
podman version 1.6.4
So we try to run alpine for a test:
root@debian-2gb-nbg1-1:~# podman run alpine echo test
Error: unable to pull alpine: open /etc/containers/policy.json: no such file or directory
The next file, i would expect it to be in the debian package.
root@debian-2gb-nbg1-1:~# echo '{
"default": [
{
"type": "insecureAcceptAnything"
}
],
"transports":
{
"docker-daemon":
{
"": [{"type":"insecureAcceptAnything"}]
}
}
}' > /etc/containers/policy.json
Another try with alpine:
root@debian-2gb-nbg1-1:~# podman run alpine echo test
Trying to pull docker.io/library/alpine...
Getting image source signatures
Copying blob e6b0cf9c0882 done
Copying config cc0abc535e done
Writing manifest to image destination
Storing signatures
test
Seems great. So next check if we can use podman rootless. Lets look at man-page and run the necessary steps:
root@debian-2gb-nbg1-1:~# adduser testuser
Adding user `testuser' ...
Adding new group `testuser' (1000) ...
Adding new user `testuser' (1000) with group `testuser' ...
Creating home directory `/home/testuser' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for testuser
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n]
root@debian-2gb-nbg1-1:~# usermod --add-subuids 10000-75535 testuser
root@debian-2gb-nbg1-1:~# usermod --add-subgids 10000-75535 testuser
root@debian-2gb-nbg1-1:~# cat /etc/sub
subgid subgid- subuid subuid-
root@debian-2gb-nbg1-1:~# cat /etc/subgid
testuser:100000:65536
testuser:10000:65536
root@debian-2gb-nbg1-1:~# cat /etc/subuid
testuser:100000:65536
testuser:10000:65536
Now run container as testuser:
root@debian-2gb-nbg1-1:~# su - testuser
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
Error: could not get runtime: default OCI runtime "runc" not found: invalid argument
I've expected it would work, but something have to be done:
testuser@debian-2gb-nbg1-1:~$ ln -s /etc/containers/libpod.conf $HOME/.config/containers/libpod.conf
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
Error: could not get runtime: database libpod temporary files directory (tmpdir) "/tmp/run-1000/libpod/tmp" does not match our libpod temporary files directory (tmpdir) "/var/run/libpod": database configuration mismatch
Again something not working as expected...
root@debian-2gb-nbg1-1:~# cp /etc/containers/libpod.conf /etc/containers/libpod.conf.bak
root@debian-2gb-nbg1-1:~# diff /etc/containers/libpod.conf /etc/containers/libpod.conf.bak
42c42
< # tmp_dir = "/var/run/libpod"
---
> tmp_dir = "/var/run/libpod"
root@debian-2gb-nbg1-1:~# podman run alpine echo test
test
root@debian-2gb-nbg1-1:~# su - testuser
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
cannot clone: Operation not permitted
user namespaces are not enabled in /proc/sys/kernel/unprivileged_userns_clone
Error: could not get runtime: cannot re-exec process
I didn't find following command in the man-page, maybe it will be added:
root@debian-2gb-nbg1-1:~# sysctl kernel.unprivileged_userns_clone=1
kernel.unprivileged_userns_clone = 1
root@debian-2gb-nbg1-1:~# su - testuser
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
Trying to pull docker.io/library/alpine...
Getting image source signatures
Copying blob e6b0cf9c0882 done
Copying config cc0abc535e done
Writing manifest to image destination
Storing signatures
ERRO[0003] Error while applying layer: ApplyLayer exit status 1 stdout: stderr: there might not be enough IDs available in the namespace (requested 0:42 for /etc/shadow): lchown /etc/shadow: invalid argument
ApplyLayer exit status 1 stdout: stderr: there might not be enough IDs available in the namespace (requested 0:42 for /etc/shadow): lchown /etc/shadow: invalid argument
Trying to pull registry.fedoraproject.org/alpine...
manifest unknown: manifest unknown
Trying to pull quay.io/alpine...
error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>404 Not Found</title>\n<h1>Not Found</h1>\n<p>The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.</p>\n"
Trying to pull registry.access.redhat.com/alpine...
name unknown: Repo not found
Trying to pull registry.centos.org/alpine...
manifest unknown: manifest unknown
Error: unable to pull alpine: 5 errors occurred:
* Error committing the finished image: error adding layer with blob "sha256:e6b0cf9c0882fb079c9d35361d12ff4691f916b6d825061247d1bd0b26d7cf3f": ApplyLayer exit status 1 stdout: stderr: there might not be enough IDs available in the namespace (requested 0:42 for /etc/shadow): lchown /etc/shadow: invalid argument
* Error initializing source docker://registry.fedoraproject.org/alpine:latest: Error reading manifest latest in registry.fedoraproject.org/alpine: manifest unknown: manifest unknown
* Error initializing source docker://quay.io/alpine:latest: Error reading manifest latest in quay.io/alpine: error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>404 Not Found</title>\n<h1>Not Found</h1>\n<p>The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.</p>\n"
* Error initializing source docker://registry.access.redhat.com/alpine:latest: Error reading manifest latest in registry.access.redhat.com/alpine: name unknown: Repo not found
* Error initializing source docker://registry.centos.org/alpine:latest: Error reading manifest latest in registry.centos.org/alpine: manifest unknown: manifest unknown
But now I don't know what to do next. Can somebody give me a hint in the correct direction?
chickeaterbanana
on 5 Jan 2020
I have found an earlier Bug report: https://github.com/containers/libpod/issues/3421
so I've done:
root@debian-2gb-nbg1-1:~# apt install uidmap
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
uidmap
0 upgraded, 1 newly installed, 0 to remove and 93 not upgraded.
Need to get 258 kB of archives.
After this operation, 341 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian buster/main amd64 uidmap amd64 1:4.5-1.1 [258 kB]
Fetched 258 kB in 0s (9.487 kB/s)
Selecting previously unselected package uidmap.
(Reading database ... 35208 files and directories currently installed.)
Preparing to unpack .../uidmap_1%3a4.5-1.1_amd64.deb ...
Unpacking uidmap (1:4.5-1.1) ...
Setting up uidmap (1:4.5-1.1) ...
Processing triggers for man-db (2.8.5-2) ...
root@debian-2gb-nbg1-1:~# su - testuser
testuser@debian-2gb-nbg1-1:~$ podman system migrate
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
Trying to pull docker.io/library/alpine...
Getting image source signatures
Copying blob e6b0cf9c0882 done
Copying config cc0abc535e done
Writing manifest to image destination
Storing signatures
ERRO[0003] could not find slirp4netns, the network namespace won't be configured: exec: "slirp4netns": executable file not found in $PATH
test
After installing slirp4netns the ERRO is also corrected:
testuser@debian-2gb-nbg1-1:~$ podman run alpine echo test
test
testuser@debian-2gb-nbg1-1:~$ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cf9ed680f052 docker.io/library/alpine:latest echo test 2 minutes ago Exited (0) 2 minutes ago magical_bell
b402e07b5a38 docker.io/library/alpine:latest echo test 21 minutes ago Exited (0) 21 minutes ago mystifying_franklin
testuser@debian-2gb-nbg1-1:~$ podman generate kube cf9ed680f052 > kube.yml
testuser@debian-2gb-nbg1-1:~$ podman play kube kube.yml
a container exists with the same name (magicalbell) as the pod in your YAML file; changing pod name to magicalbell_pod
Pod:
898fbebb42ed75131f6758e226f344023718b1846ec22aca88a5e51dc8a92aa1
Container:
281bcc8a01f19ec72718976c8f33728e0b34482c0166ecb7a16cafef1e8b968e
testuser@debian-2gb-nbg1-1:~$ podman pod ps
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
898fbebb42ed magicalbell_pod Running 22 seconds ago 2 3166beba58c1
testuser@debian-2gb-nbg1-1:~$ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
281bcc8a01f1 docker.io/library/alpine:latest echo test 31 seconds ago Exited (0) 30 seconds ago magicalbell
3166beba58c1 k8s.gcr.io/pause:3.1 31 seconds ago Up 31 seconds ago 898fbebb42ed-infra
cf9ed680f052 docker.io/library/alpine:latest echo test 8 minutes ago Exited (0) 8 minutes ago magical_bell
b402e07b5a38 docker.io/library/alpine:latest echo test 27 minutes ago Exited (0) 27 minutes ago mystifying_franklin
testuser@debian-2gb-nbg1-1:~$ podman pod inspect 898fbebb42ed
{
"Config": {
"id": "898fbebb42ed75131f6758e226f344023718b1846ec22aca88a5e51dc8a92aa1",
"name": "magicalbell_pod",
"hostname": "magicalbell_pod",
"labels": {
},
"cgroupParent": "/libpod_parent",
"sharesCgroup": true,
"sharesIpc": true,
"sharesNet": true,
"sharesUts": true,
"infraConfig": {
"makeInfraContainer": true,
"infraPortBindings": null
},
"created": "2020-01-06T00:06:34.486570399+01:00",
"lockID": 2
},
"State": {
"cgroupPath": "/libpod_parent/898fbebb42ed75131f6758e226f344023718b1846ec22aca88a5e51dc8a92aa1",
"infraContainerID": "3166beba58c1b73909e71bf84dd1998d1c4b4d06f17ff8542ccde90981d2a65a"
},
"Containers": [
{
"id": "281bcc8a01f19ec72718976c8f33728e0b34482c0166ecb7a16cafef1e8b968e",
"state": "exited"
},
{
"id": "3166beba58c1b73909e71bf84dd1998d1c4b4d06f17ff8542ccde90981d2a65a",
"state": "running"
}
]
}
```
chickeaterbanana
on 6 Jan 2020
Starting a container somtimes really slow:
testuser@debian-2gb-nbg1-1:~$ time podman run --rm -it ruby echo test
test
real 0m5.959s
user 0m1.278s
sys 0m3.775s
And sometimes i can't stable reproduce it:
root@b859e5e7461d:/# exit
exit
ERRO[0271] unable to close namespace: "close /proc/4212/ns/user: bad file descriptor"
I have created a dependency graph with debtree.
chickeaterbanana
on 6 Jan 2020
Crazy cool graphs, thanks. Note that the biggest node on build-deps graphs is _docker.io_...
I wish we could retire Docker in favour of Podman but huge maintenance burden associated with Docker (their terrible release practices and Docker's dependency graph) will remain on maintainer's shoulders as long as _libpod_ (and its dependencies) continue to depend on Docker...
onlyjob
on 6 Jan 2020
wait what, libpod depends on Docker? I thought the entire point of this project was to not require Docker in the first place...
anarcat
on 6 Jan 2020
Our core container-launching logic is entirely distinct, but given our goal of Docker compatibility, there are a number of frontend bits we've reused - parsing for various options, for example. I have a goal of reducing this dependency by reimplementing where it makes sense, but it's hard to justify in a lot of cases - why rewrite the logic for, say, parsing ports when the existing code works and perfectly matches Docker behavior.
mheon
on 6 Jan 2020
In terms of actual build size (for the podman binary), it's not that bad:
https://gist.github.com/afbjorklund/911a8c231ba8e5965db3b19f42bb47fe
i.e. less than 5% for github.com/docker
afbjorklund
on 6 Jan 2020
@mheon isn't it possible to create a third library to share the reused parts between docker and podman?
chickeaterbanana
on 6 Jan 2020
wait what, libpod depends on Docker? I thought the entire point of this project was to not require Docker in the first place...
My understanding is that docker.io is only a _build-time_ dependency. When end users install that libpod package it will only depend on:
libc6 (>=2.28),
libdevmapper1.02.1 (>=2:1.02.97),
libglib2.0-0 (>=2.33.14),
libgpgme11 (>=1.4.1),
libostree-1-1 (>=2016.8),
libseccomp2 (>=2.4.1),
libselinux1 (>=2.0.65),
conmon (>=2.0.0~),
containernetworking-plugins,
crun | runc (>=1.0.0~rc9~)
hrj
on 7 Jan 2020
_Only_ build-time (not run-time) dependency (Podma is a statically linked executable after all) but on build-time Docker represent more than half of all dependencies needed to compile Podman and also the most fragile ones...
onlyjob
on 7 Jan 2020
It is source code from docker git that we are using. There is little incentive in Docker breaking out this code so it would be separate form Docker. We might be able to just grab the same/similar code from moby. If we were to fork and use our own copy then we would not get fixes/changes that went into Docker. Bottom line we use Code from Docker, but we do not depend on the docker package running anywhere during build or running.
rhatdan
on 7 Jan 2020
I assume the versions of dependencies are locked ingo.sum. If so then I guess the dependency being fragile won’t make packaging more expensive? (Maintaining podman itself would be more expensive, though.)
FranklinYu
on 10 Jan 2020
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.
lsm5
on 20 Jan 2020
@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
on 24 Jan 2020
@travier-anssi whoops, thought I disabled docker manpages, but apparently not, fixing..
lsm5
on 27 Jan 2020
@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 https://github.com/containers/libpod/issues/4747#issuecomment-578930208
lsm5
on 27 Jan 2020
Can we close this one now? Is podman available from Debian?
rhatdan
on 17 Feb 2020
@lsm5 WDYT?
TomSweeneyRedHat
on 17 Feb 2020
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
anarcat
on 18 Feb 2020
@lsm5 WDYT?
I'm not opposed to closing this, but maybe community prefers this bug for tracking instead of the debian bugs listed above...
lsm5
on 18 Feb 2020
Since this is not an upstream issue, I will close it.
rhatdan
on 18 Feb 2020
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!).
Silvanoc
on 18 May 2020
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 (https://github.com/openshift/imagebuilder/issues/160) for which a fix was uploaded today. :)
anarcat
on 19 May 2020
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.
siretart
on 20 May 2020
Wish debian Sid support podman v2.0
netroby
on 9 Jul 2020
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...
anarcat
on 9 Jul 2020
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?
siretart
on 17 Jul 2020
@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 :slightly_smiling_face:
Silvanoc
on 17 Jul 2020
It failed to build on the other architectures: https://buildd.debian.org/status/package.php?p=libpod&suite=experimental
yrro
on 17 Jul 2020
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
on 17 Jul 2020
FYI, I've just uploaded podman 2.0 to unstable: https://tracker.debian.org/pkg/libpod
siretart
on 20 Jul 2020
Awesome @siretart Great work.
rhatdan
on 20 Jul 2020
I've just installed it (on Debian Testing/Bullseye) and a simple rootless "image pull" and "run" worked directly 👏
Silvanoc
on 21 Jul 2020
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.
Silvanoc
on 17 Sep 2020
Related issues
jtligon
·
4Comments
evelineraine
·
3Comments
NooneXe
·
3Comments
runlevel5
·
4Comments
pkubatrh
·
4Comments
Most helpful comment
@onlyjob -- I appreciate all of the work you've put into packaging podman (and surely many other packages), and I can see that you are passionate about upholding high standards of quality. As a Debian user of over 20 years and a former package maintainer myself, I'm in awe of the tremendous work and attention to detail that goes into providing such a solid foundation for the broader Linux distribution ecosystem. The work you do reaches far beyond Debian.
It seems that there were and are opportunities for closer collaboration on podman packaging, and I am sure the intention behind your reply is to challenge others to higher levels of technical excellence. That's honorable! However, I personally find the truth in your message is diluted by the way you've chosen to express it. As a Debian developer, it is not only your duty to be an effective package maintainer, but also to encourage and support others who flirt with joining the community. The damage done by "sloppy" communication can far outweigh the damage done by a "sloppy" package implementation. That damage can also reach far beyond Debian.
To be more specific with my critique; your suggestion that packaging should be done by skilled Debian developers is discouraging for those who are still learning. Everyone starts out as a novice, and it would be wise to heed the words of Plato: "Never discourage anyone [...] who continually makes progress, no matter how slow.” -- I'm sure you will continue to uphold standards of excellence on a technical level and I am certain that you can uphold similar standards of mentorship.
@lsm5 -- thank you for the work you've done to prototype these podman packages. You filled a gap in the ~year that elapsed between this issue's creation and supportable packages entering Debian Unstable. I hope that you won't be discouraged and will continue to engage with the Debian community and learn from the valid critiques of your work (run lintian, use modern templates, communicate/collaborate with other maintainers). The Debian community needs a stream of new volunteers like you to evolve and grow.