[pkg-go] Bug#981813: API regression: Could not get either XDG_CONFIG_HOME or HOME

Martin Pitt mpitt at debian.org
Thu Feb 4 07:31:42 GMT 2021


Package: podman
Version: 2.1.1+dfsg1-5

A few days ago, our cockpit-podman tests started to fail on Debian testing [1]
(screenshot [2]) for committing images. This coincides with the testing update
of 2.1.1+dfsg1-4 (last known good version) to 2.1.1+dfsg1-6.

CLI reproducer (as root):

# start from a clean slate, especially after package down/upgrades
podman rm -f --all; podman rmi testimg; systemctl stop io.podman.service podman.service
# create container
podman run --name test -d quay.io/libpod/busybox sleep infinity
# commit it through the API
curl -XPOST --unix-socket /run/podman/podman.sock -v 'http://d/v1.0.0/libpod/commit?container=test&repo=testimg'

This started to fail like this:

< HTTP/1.1 500 Internal Server Error
< Api-Version: 1.40
< Content-Type: application/json
< Libpod-Api-Version: 2.0.0
< Server: Libpod/2.0.0 (linux)
< Date: Thu, 04 Feb 2021 06:48:56 GMT
< Content-Length: 185
<
{"cause":"could not get either XDG_CONFIG_HOME or HOME","message":"CommitFailure: error resolving name \"testimg:latest\": could not get either XDG_CONFIG_HOME or HOME","response":500}

The `podman commit` CLI API works fine, this just affects the REST API.

After a successful operation, there should be a committed image:

# podman images
REPOSITORY                TAG     IMAGE ID      CREATED        SIZE
localhost/testimg         latest  b30349f6d1ea  3 seconds ago  1.46 MB


I tested various podman package versions from snapshot.d.o. (no other binary
package changes):

2.1.1+dfsg1-4: works
2.1.1+dfsg1-5: fails
2.1.1+dfsg1-6: fails
2.1.1+dfsg1-7: fails
2.2.1+dfsg1-1: fails
3.0.0~rc2+dfsg1-2: works

(I'm going to mark the affected/unaffected versions in a follow-up email once
BTS imports this new bug)

The changes between -4 and -5 seem rather unrelated:
https://salsa.debian.org/debian/libpod/-/commit/e6685dfe282cf9049db2980d91bc85e57e1bb8d7
So I can only imagine this is due to some changed go dependencies?

Fedora 33 has podman 2.2.1, and that works fine. This corroborates that this is
not in the podman code itself, but some dependency.

Since this works again in current Debian unstable, I'm mostly filing this to
(1) track the fix in testing, and (2) satisfy our automatic upstream regression
tracker.

Thanks,

Martin


[1] https://github.com/cockpit-project/cockpit-podman/pull/663
[2] https://logs.cockpit-project.org/logs/pull-663-20210201-073807-b9dbbbd7-debian-testing/TestApplication-testBasicSystem-debian-testing-127.0.0.2-2301-FAIL.png



More information about the Pkg-go-maintainers mailing list