GNU bug report logs - #63530
procps 4.0 upstream API change breaks packages

Previous Next

Full log

View this message in rfc822 format

From: Jelle Licht <jlicht <at> fsfe.org>
To: Gabriel Wicki <gabriel <at> erlikon.ch>, 63530 <at> debbugs.gnu.org
Subject: bug#63530: Missing library in package procps
Date: Sun, 28 May 2023 13:54:24 +0200

Hello,

Gabriel Wicki <gabriel <at> erlikon.ch> writes:

> A little more hacking leads me to the conclusion that (probably with
> version 4 but it's not exactly clear from the changelog) procps has made
> some significant changes to it's API.  So, unless igt-gpu-tools (and
> probably others) are fixed upstream they remain broken.  Fixes through
> simple regex-magic in our build-phases might be possible, but I am not
> confident enough in the matter to guarantee that the package would not
> just build but be broken in a more specific manner.
>
> Is there an easy way to check which dependents of procps are actually
> broken currently?  Or is it really just igt-gpu-tools?
>
> There's two ways to go (I'd be happy for some input and volunteer to do
> the actual leg-work):
>  1. Add an additional procps-3 package with the older API to fix the
>  broken packages.
>  2. Leave it as-is and wait for an upstream change of the currently
>  broken packages.

I have found the upstream issue:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/116

We can wait it out until the release, which will be out Soon (tm), or we
make use of the patch that debian applies to igt-gpu-tools so it can
work with the new libproc2 API:

https://salsa.debian.org/xorg-team/app/intel-gpu-tools/-/blob/067ddd789fd80c12972fb92db8f93fadbdc4530e/debian/patches/libproc2_library

AFAICS, this would not lead to a world-rebuild.

Thoughts?
- Jelle

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.