[From nobody Mon May 25 23:17:08 2026
Received: (at 1136557-done) by bugs.debian.org; 25 May 2026 22:15:22 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-107.5 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH,
 DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOURLA,
 FROMDEVELOPER,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST,VERSION
 autolearn=ham autolearn_force=no
 version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 11; hammy, 132; neutral, 46; spammy,
 0. spammytokens:
 hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
 0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <siretart@debian.org>
Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:40644)
 by buxtehude.debian.org with esmtps
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <siretart@debian.org>) id 1wRdZy-0060L1-06
 for 1136557-done@bugs.debian.org; Mon, 25 May 2026 22:15:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; 
 s=smtpauto.stravinsky;
 h=X-Debian-User:Message-Id:Date:To:From:Subject:
 Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:In-Reply-To:References;
 bh=lDkCz144gF4+8FHQjoPbb0oPGHNJPVWrDkvu5aMwfkw=; b=ViXt0UOtMlcv29LR+tjJaboRem
 XGV740qpdR/EDSCq6eAk69rN1M0m6UL3f8oK6BbLbdBNOfx+tzpJcRio//kg1BdaWwbmTSeqIzKqh
 VhQqjOh1DHKlPUE1dFH3TJR6+4iMfFXio8sR3V2ZA8l2U6lbIZiWthgCIi6+r4WZILhKUY4sTZaUn
 6Xd3LcAFbA9TNkf8+iYcS6nPTegCspGjPrxJLXntxWPcB03p0pTDUFNt7PQpKMcG4R3lMM/qtGr1v
 awuNPTmrWbDDAVK2bvRCSISOR/nFDJm+NsDKZ+oruui9XTaEU+6R0zYpyHdMjTDK1G4qHuhdvl8fG
 ElZGP7yA==;
Received: from authenticated-user by stravinsky.debian.org with esmtpsa
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <siretart@debian.org>) id 1wRdZx-001t9k-00
 for 1136557-done@bugs.debian.org; Mon, 25 May 2026 22:15:21 +0000
Received: from [192.168.88.76] (helo=x1.int.tauware.de)
 by hermes.tauware.de with esmtps (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <siretart@debian.org>) id 1wRdZu-007xxJ-2g
 for 1136557-done@bugs.debian.org; Tue, 26 May 2026 00:15:18 +0200
Received: by x1.int.tauware.de (Postfix, from userid 1000)
 id E1B0813F488; Mon, 25 May 2026 18:15:17 -0400 (EDT)
Subject: Findings regarding pidof usage in podman
From: Reinhard Tartler <siretart@debian.org>
To: <1136557-done@bugs.debian.org>
User-Agent: mail (GNU Mailutils 3.20)
Date: Mon, 25 May 2026 18:15:17 -0400
Message-Id: <20260525221517.E1B0813F488@x1.int.tauware.de>
X-Debian-User: siretart

Version: 5.8.2+ds1-1

Hello,

Thank you for the report regarding the upcoming pidof transition. I have 
investigated the usage of "pidof" in the podman source tree and found 
the following:

1. The only occurrences of "pidof" are in the Python-based API test 
   suite: test/apiv2/python/rest_api/test_v2_0_0_container.py

2. In these tests, a container is **dynamically created** via a POST 
   request to the Podman API using the alpine:latest image. The 
   "pidof" command is defined as part of a Healthcheck configuration 
   sent in the JSON payload of that request.

3. Consequently, "pidof" is intended to run *inside* the Alpine 
   container namespace. In that context, it is provided by the 
   container's own BusyBox/tools, not the host's procps package.

4. These Python tests are currently not executed during the Debian 
   build process (dh_auto_test only runs Go tests) nor are they part of 
   any autopkgtest defined in debian/tests/control.

5. I found no evidence of "pidof" being used by the podman binary 
   itself or any of the systemd units/scripts shipped in the package.

As such, this is a false positive for the host environment, and no 
additional dependency on procps is required. I am therefore closing 
this bug.

Regards,
-rt]