Your message dated Tue, 9 Mar 2021 06:02:01 +0100
with message-id <[email protected]>
and subject line Re: Bug#981813: API regression: Could not get either 
XDG_CONFIG_HOME or HOME
has caused the Debian Bug report #981813,
regarding API regression: Could not get either XDG_CONFIG_HOME or HOME
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
981813: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981813
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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

--- End Message ---
--- Begin Message ---
Version: 3.0.1+dfsg1-1

3.0.1 is in testing now, so this is fixed in all current versions. Closing.

Martin

--- End Message ---

Reply via email to