Bug 1198266

I'm not sure when the actual 4.x release will be but if it's going to be soon can we package the library+devel in parallel with the 3.x version, instead of as a replacement? It has some big API changes.

(In reply to Tejas Guruswamy from comment #1)
> I'm not sure when the actual 4.x release will be but if it's going to be
> soon can we package the library+devel in parallel with the 3.x version,
> instead of as a replacement? It has some big API changes.

Hmm I do not fully understand ... yes there are some API changes and yes some translations are missed but this is Tumbleweed.  What is wrong with bleeding edge here?  And IMHO it was worth as otherwise I would never had detected the not working AIX sorting problems

Yes, given the API changes it is »bleeding edge«, but given the non-synced translations and the experimental nature of this release, it is a big step back. I know, most developers don't consider translations as very important, but said with my translator's hat on, it is very annoying to see such a tarball get packaged, even for Tumbleweed. To mention, I've initiated the man page translations in procps some years ago (and moved existing translations from the manpages-l10n project and some other sources toprocps), and it was a lot of work to convince Craig Small to do so. Fortunately, I don't have to complain anything about psmisc (his other project), which also comes with translated man pages.

I don't know when the real 4.0.0 (or 4.0.1, whatever) gets released; at least the GNU TP robot hasn't rolled out a pre-release tarball yet. OK, if you make sure that v4.0.0 never reaches Leap …

(In reply to Dr. Werner Fink from comment #2) 
> Hmm I do not fully understand ... yes there are some API changes and yes
> some translations are missed but this is Tumbleweed.  What is wrong with
> bleeding edge here?  And IMHO it was worth as otherwise I would never had
> detected the not working AIX sorting problems

I am not asking for 4.x to never be packaged -- I am asking for the current versions of the library libprocps8 and associated devel files to remain in the distro for some time, ideally until dependent applications have been ported or removed. Because 4.x is not a simple replacement for the current version, even once the release is actually ready. It is effectively an entirely new library.

Here I am of course only talking about having parallel installs of the shared library libproc*, not the binaries in procps.

After all this is the motivation of the shared library packaging policy, to enable parallel installation of library versions. Conveniently there isn't even much overlap in filenames since the base soname is changed.

Which package(s) beside procps-devel do/does require libprocps8?

 rpm -q --whatrequires libprocps8
 procps-devel-3.3.17-5.3.x86_64

otherwise I never had replaced 3.3.17

(In reply to Tejas Guruswamy from comment #4)
> (In reply to Dr. Werner Fink from comment #2) 

> After all this is the motivation of the shared library packaging policy, to
> enable parallel installation of library versions. Conveniently there isn't
> even much overlap in filenames since the base soname is changed.

The API of the new library is complete different to the old libprocps.so.8(.0.3) .... it is more designed as growed piecemeal over the time

(In reply to Dr. Werner Fink from comment #5)
> Which package(s) beside procps-devel do/does require libprocps8?
> 
>  rpm -q --whatrequires libprocps8
>  procps-devel-3.3.17-5.3.x86_64
> 
> otherwise I never had replaced 3.3.17

$ zypper se --requires-pkg libprocps8
S | Name                                       | Summary                                                                 | Type
--+--------------------------------------------+-------------------------------------------------------------------------+--------
  | apitrace                                   | Tools for tracing OpenGL                                                | package
i | intel-gpu-tools                            | Collection of tools for development and testing of the Intel DRM driver | package
  | lxqt-session                               | LXQt Session Manager                                                    | package
i | procps                                     | The ps utilities for /proc                                              | package
  | procps-devel                               | Development files for procps                                            | package
  | veyon                                      | Computer monitoring and classroom management                            | package

Not a long list certainly but it isn't zero. My interest comes from currently being the packager/bugowner for intel-gpu-tools.

Adding the maintainers and bugowners of intel-gpu-tools ...  please consider to report this upstream and/or port this package to new libproc-2

Hmm. I don't know how often I already tried to drop intel-gpu-tools from our products. Trying again ...

https://build.opensuse.org/request/show/971199

Looks like the tools of this package use

                 U closeproc
                 U freeproc
                 U openproc
                 U readproc

(In reply to Stefan Dirsch from comment #8)
> Hmm. I don't know how often I already tried to drop intel-gpu-tools from our
> products. Trying again ...
> 
> https://build.opensuse.org/request/show/971199

Stefan, you gave me ownership of the package. I am maintaining it. Please remove this request.

Werner, I don't understand your last message. As I said I am the bugowner and maintainer for intel-gpu-tools. The OBS and all tools reflect that as far as I know.

I really don't understand how this is getting so confusing for everyone else.

Indeed this is no longer my package. Sorry @Tejas, that I already forgot, that I handed it over to you. :-( Saying goodbye to this ticket ... Joan wasn't involved here either ...

(In reply to Tejas Guruswamy from comment #10)
> (In reply to Stefan Dirsch from comment #8)
> > Hmm. I don't know how often I already tried to drop intel-gpu-tools from our
> > products. Trying again ...
> > 
> > https://build.opensuse.org/request/show/971199
> 
> Stefan, you gave me ownership of the package. I am maintaining it. Please
> remove this request.

done. revoked.

(In reply to Tejas Guruswamy from comment #10)

> 
> Werner, I don't understand your last message. As I said I am the bugowner
> and maintainer for intel-gpu-tools. The OBS and all tools reflect that as
> far as I know.
> 

It would be nice to have intel-gpu-tools ported to procps with newlib support (which in fact is 4.0.0 and above)

From upstream mailing list https://www.freelists.org/post/procps/looking-ahead-to-401,8 

On 4/20/22 9:42 AM, Dr. Werner Fink wrote:
> Also some manual pages are missed for those who use the API of the old libprocps
> like the intel-gpu-tools:
>
>                   U closeproc
>                   U freeproc
>                   U openproc
>                   U readproc
>

Hi Werner,

Those manual pages weren't missed.  Rather, such functions are no longer
exported.

For the single module impacted in intel-gpu-tools, these should be used
instead:

    procps_pids_new
    procps_pids_get
    procps_unref

Regards,

Jim

(In reply to Dr. Werner Fink from comment #13)
> (In reply to Tejas Guruswamy from comment #10)
> 
> > 
> > Werner, I don't understand your last message. As I said I am the bugowner
> > and maintainer for intel-gpu-tools. The OBS and all tools reflect that as
> > far as I know.
> > 
> 
> It would be nice to have intel-gpu-tools ported to procps with newlib
> support (which in fact is 4.0.0 and above)

Sorry, I meant the message about adding the maintainers of i-g-t. I think that's resolved now (if there's somewhere that the maintainer list is out of date, please let me know.)

> From upstream mailing list
> https://www.freelists.org/post/procps/looking-ahead-to-401,8 
> 
> On 4/20/22 9:42 AM, Dr. Werner Fink wrote:
> > Also some manual pages are missed for those who use the API of the old libprocps
> > like the intel-gpu-tools:
> >
> >                   U closeproc
> >                   U freeproc
> >                   U openproc
> >                   U readproc
> >
> 
> Hi Werner,
> 
> Those manual pages weren't missed.  Rather, such functions are no longer
> exported.
> 
> For the single module impacted in intel-gpu-tools, these should be used
> instead:
> 
>     procps_pids_new
>     procps_pids_get
>     procps_unref
> 
> Regards,
> 
> Jim

Thank you for asking the procps devs, I'll work with intel-gpu upstream on the port. In the meantime, if you do want to package procps 4.x that's fine obviously, but is it ok if we keep the old version in parallel or not? If you don't want the extra package in your name, I'll take it on -- it would just be a copy of the current version "procps3" with only the library, no binaries.

As we have now two packages procps and procps4 with their own library packages libprocps8 and libproc2 the problem is gone I hope

Maybe upstream of intel-gpu-tools would move forward to libproc2

Yes, with parallel packages the immediate problem was solved, thank you Werner.

For reference, there is an upstream bug tracking projects migration to the new API: https://gitlab.com/procps-ng/procps/-/issues/239

I am working on borrowing a Debian patch for intel-gpu-tools to move it to the new API.