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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63530 in the body.
You can then email your comments to 63530 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gabriel Wicki <gabriel <at> erlikon.ch>
To: bug-guix <at> gnu.org
Subject: Missing library in package procps
Date: Tue, 16 May 2023 00:13:07 +0200

Hi

Trying to upgrade a somewhat outdated system (from March 23) I noticed
igt-gpu-tools failed to build.  Investigating a bit the build fails due
to some "proc/readproc.h" include missing.  I think i managed to fix the
failure in procps's Makefile, but testing the patched build results in a
rather huge rebuild.  `guix refresh -l procps` results in 5328
packages.  Are there any other approaches one could take to a) fix the
broken package without b) triggering a world-rebuild?

I'm not sure if this is an upstream bug and whether other packages are
affected, neither do I know whether the other header files that aren't
being copied to the install dir should be.


Thanks for your input in advance!  I'll update this issue with a patch
as soon as I manage to verify that my attempt actually works.

gabber

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Csepp <raingloom <at> riseup.net>
To: Gabriel Wicki <gabriel <at> erlikon.ch>
Cc: bug-guix <at> gnu.org, 63530 <at> debbugs.gnu.org
Subject: Re: bug#63530: Missing library in package procps
Date: Tue, 16 May 2023 00:36:37 +0200

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

> Hi
>
> Trying to upgrade a somewhat outdated system (from March 23) I noticed
> igt-gpu-tools failed to build.  Investigating a bit the build fails due
> to some "proc/readproc.h" include missing.  I think i managed to fix the
> failure in procps's Makefile, but testing the patched build results in a
> rather huge rebuild.  `guix refresh -l procps` results in 5328
> packages.  Are there any other approaches one could take to a) fix the
> broken package without b) triggering a world-rebuild?
>
> I'm not sure if this is an upstream bug and whether other packages are
> affected, neither do I know whether the other header files that aren't
> being copied to the install dir should be.
>
>
> Thanks for your input in advance!  I'll update this issue with a patch
> as soon as I manage to verify that my attempt actually works.
>
> gabber

You could test it as a graft, then dependents won't get rebuilt.  If the
public ABI exported by the package doesn't change, it Should Be Fine TM.

Message #14 received at 63530 <at> debbugs.gnu.org (full text, mbox):

From: Gabriel Wicki <gabriel <at> erlikon.ch>
To: 63530 <at> debbugs.gnu.org
Subject: Re: bug#63530: Missing library in package procps
Date: Tue, 16 May 2023 10:05:54 +0200

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.

Message #19 received at 63530 <at> debbugs.gnu.org (full text, mbox):

From: Jelle Licht <jlicht <at> fsfe.org>
To: Gabriel Wicki <gabriel <at> erlikon.ch>, 63530 <at> debbugs.gnu.org
Subject: Re: 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

Message #22 received at 63530 <at> debbugs.gnu.org (full text, mbox):

From: Gabriel Wicki <gabriel <at> erlikon.ch>
To: 63530 <at> debbugs.gnu.org
Subject: Issue was fixed
Date: Tue, 28 Nov 2023 17:24:57 +0100

This issue seems to have been fixed by Tobias with commit
22642d460488896ec1ddb25d7eb262938db810eb
using a patch to work around the issue.  I created a patch that'd
upgrade to the next version where igt-gpu-tools is actually fixed (so
the patch is not needed anymore): https://issues.guix.gnu.org/67508

Previous Next

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