Your message dated Thu, 14 May 2026 09:01:40 +0200
with message-id <[email protected]>
and subject line Re: Bug#1136474: bpftrace uses pidof but does not depend on 
procps
has caused the Debian Bug report #1136474,
regarding bpftrace uses pidof but does not depend on procps
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.)


-- 
1136474: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136474
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: bpftrace
Version: 0.25.1-1
Usertags: pidof-without-procps

Dear maintainer(s) of bpftrace,

it appears that bpftrace uses `pidof` in its testsuite, or that
at least one of its binary packages uses `pidof` at runtime.
Historically, `pidof` was provided by the Essential package
`sysvinit-tools`, making an explicit dependency unnecessary. However
`pidof` will soon be moved to `procps` and will no longer be part of
the Essential set.

Please add an explicit dependency on `procps`:

* via the `Depends:` field of all binary packages of bpftrace
  that use `pidof` at runtime;
* via the `Build-Depends:` field of bpftrace, if `pidof` is
  used in tests run at build-time;
* via the `Depends:` field of `debian/control/tests`, if `pidof` is
  used in autopkgtests.

To prevent any disruption for users of bpftrace, please add
this dependency now, before `pidof` is moved from `sysvinit-utils` to
`procps`. Alternatively, you could remove all uses of `pidof`.

It is believed that bpftrace uses `pidof` due to the following
code snippets:

```
path: bpftrace_0.24.1-1.1/tests/runtime/watchpoint
NAME function_arg_addr_process_flag
RUN {{BPFTRACE}} -e 'watchpoint:increment+arg1:4:w { printf("hit!\n"); exit() 
}' -p $(pidof watchpoint_func)
BEFORE ./testprogs/watchpoint_func
EXPECT hit!


path: bpftrace_0.24.1-1.1/tests/runtime/usdt
NAME usdt probes - lists linked library probes by pid
RUN {{BPFTRACE}} -l 'usdt:*' -p $(pidof usdt_lib)
EXPECT_REGEX usdt:.*/libusdt_tp.so:tracetestlib:lib_probe_1$
BEFORE ./testprogs/usdt_lib


path: bpftrace_0.24.1-1.1/tests/runtime/usdt
NAME usdt probes - attach to fully specified library probe by pid
RUN {{BPFTRACE}} -e 'usdt:./testlibs/libusdt_tp.so:tracetestlib:lib_probe_1 { 
printf("here\n" ); exit(); }' -p $(pidof usdt_lib)
BEFORE ./testprogs/usdt_lib
EXPECT here


path: bpftrace_0.24.1-1.1/tests/runtime/engine/runner.py
                child_name = os.path.basename(child_name)
                childpid = subprocess.Popen(["pidof", child_name], 
stdout=subprocess.PIPE, universal_newlines=True).communicate()[0].split()[0]
                bpf_call = re.sub("{{BEFORE_PID}}", str(childpid), bpf_call)
            env = {


path: bpftrace_0.24.1-1.1/tests/runtime/probe
NAME signal_order
RUN {{BPFTRACE}} -e 'self:signal:SIGUSR1 { printf("first"); } 
self:signal:SIGUSR1 { printf(" second\n"); exit(); }'
AFTER kill -s USR1 $(pidof bpftrace)
EXPECT_REGEX (first)+ second


path: bpftrace_0.24.1-1.1/tests/runtime/signals
NAME custom signal handling probe
RUN {{BPFTRACE}} -e 'self:signal:SIGUSR1 { print("signal handler"); exit(); }'
AFTER kill -s USR1 $(pidof bpftrace)
EXPECT signal handler
```

Feel free to close this issue if this is a false positive (for example
if this code is in an unreachable code path).

Regards,

-- 
Gioele Barabucci

--- End Message ---
--- Begin Message ---
On 2026-05-14 01:25, Gioele Barabucci wrote:

it appears that bpftrace uses `pidof` in its testsuite, or that
at least one of its binary packages uses `pidof` at runtime.
Historically, `pidof` was provided by the Essential package
`sysvinit-tools`, making an explicit dependency unnecessary. However
`pidof` will soon be moved to `procps` and will no longer be part of
the Essential set.

The testsuite is not run, so we are OK.

Thanks.

--- End Message ---

Reply via email to