Bug 250381 - graphics/libosmesa: check-plist fails due to extra files in stage/
Summary: graphics/libosmesa: check-plist fails due to extra files in stage/
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords: buildisok
Depends on:
Blocks:
 
Reported: 2020-10-15 23:51 UTC by John Hein
Modified: 2021-11-22 05:31 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
[patch] don't build & install extra files to stage/ (330 bytes, patch)
2020-10-15 23:51 UTC, John Hein
jcfyecrayz: maintainer-approval? (manu)
jcfyecrayz: maintainer-approval? (x11)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Hein 2020-10-15 23:51:29 UTC
Created attachment 218777 [details]
[patch] don't build & install extra files to stage/

check-plist fails for graphics/libosmesa.  This may have started happening with the switch to meson.

================
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: include/GL/gl.h
Error: Orphaned: include/GL/glcorearb.h
Error: Orphaned: include/GL/glext.h
Error: Orphaned: include/KHR/khrplatform.h
Error: Orphaned: lib/libglapi.so
Error: Orphaned: lib/libglapi.so.0
Error: Orphaned: lib/libglapi.so.0.0.0
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1
================


The attached patch addresses this by not building / installing files that libosmesa does not need or use.
Comment 1 Niclas Zeising freebsd_committer freebsd_triage 2020-10-16 08:09:58 UTC
I can't reproduce this.
I've built libosmesa several times since the meson update, and the package cluster is also fine.  Do you have any special options of any kind?

In any case, I'd want input from manu as well before making changes.
Comment 2 John Hein 2020-10-16 20:22:54 UTC
(In reply to Niclas Zeising from comment #1)
As far as I can see, the package cluster doesn't run the check-plist target?  I think that poudriere bulk -t or testport will run that.  The following log shows that it is not running check-plist (nor stage-qa).


http://beefy9.nyi.freebsd.org/data/114amd64-default/552369/logs/libosmesa-20.2.0_1.log


I am not running with anything particularly special.  My poudriere etc/poudriere.d/<jail>/make.conf:

DEVELOPER=yes
DEFAULT_VERSIONS+=ssl=openssl
LANG=en_US.UTF-8

DEVELOPER=yes is ignored by poudriere, so that should be a no-op (see comment above about using bulk -t or testport).  The others shouldn't make a difference for this either, but I have not yet tried a test without them.
Comment 3 Automation User 2020-10-31 03:41:31 UTC
Build and package info is available at https://gitlab.com/swills/freebsd-ports/pipelines/209959803
Comment 4 John Hein 2020-11-05 13:14:35 UTC
Comment on attachment 218777 [details]
[patch] don't build & install extra files to stage/

(In reply to Niclas Zeising from comment #1)
Adding manu@ as Niclas Zeising suggested.
Comment 5 Antonio Huete Jimenez 2020-11-09 11:41:56 UTC
There are other ports that include some of those files, like for example:

$ git grep lib/libglapi.so
graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so
graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so.0
graphics/mesa-dri/pkg-plist:@comment lib/libglapi.so.0.0.0
graphics/mesa-libs/pkg-plist:lib/libglapi.so
graphics/mesa-libs/pkg-plist:lib/libglapi.so.0
graphics/mesa-libs/pkg-plist:lib/libglapi.so.0.0.0

So including them in plist would be problematic. On the other hand, libOSMesa library is linked against those files, so you can't remove, at least, some of them.

# ldd ../stage/usr/local/lib/libOSMesa.so
../stage/usr/local/lib/libOSMesa.so:
        libglapi.so.0 => /usr/local/lib/libglapi.so.0 (0x8012d0000)
        libz.so.3 => /lib/libz.so.3 (0x801507000)
        libstdc++.so.9 => /usr/lib/gcc80/libstdc++.so.9 (0x80151d000)
        libm.so.4 => /lib/libm.so.4 (0x8016a0000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x8016cc000)
        libc.so.8 => /lib/libc.so.8 (0x800462000)
Comment 6 Antonio Huete Jimenez 2020-11-09 11:49:31 UTC
I forgot to mention this is in DPorts but it's probably the same in freebsd-ports since (excerpt from meson.build):


  if with_opengl
    install_headers(
      'GL/gl.h',
      'GL/glcorearb.h',
      'GL/glext.h',
      subdir : 'GL',
    )
  endif
Comment 7 Steve Wills freebsd_committer freebsd_triage 2020-11-09 13:35:49 UTC
I'm able to reproduce this locally:

[00:02:06] Error: Orphaned: include/GL/gl.h
[00:02:06] Error: Orphaned: include/GL/glcorearb.h
[00:02:06] Error: Orphaned: include/GL/glext.h
[00:02:06] Error: Orphaned: include/KHR/khrplatform.h
[00:02:06] Error: Orphaned: lib/libglapi.so
[00:02:06] Error: Orphaned: lib/libglapi.so.0
[00:02:06] Error: Orphaned: lib/libglapi.so.0.0.0

and the patch does fix it.
Comment 8 Antonio Huete Jimenez 2020-11-09 14:17:35 UTC
Indeed it does, since it removes the opengl stuff from the build/install list. 

The point is, why was it enabled in the first place? Is it really needed for some port to work properly?
Comment 9 John Hein 2020-11-10 16:31:35 UTC
(In reply to Antonio Huete Jimenez from comment #5)
Yes, indeed libOSMesa.so links with libglapi.so.  And graphics/libosmesa correctly depends on graphics/mesa-libs.  In comment 5, you seem concerned that libglapi.so (or other files) could be removed, thus breaking graphics/libosmesa.  That won't happen because of the documented dependency.


(In reply to Antonio Huete Jimenez from comment #8)
You ask why was it (-Dopengl) enabled.  When it was committed (ports r552109), there was no explanation why it was enabled (nor in the review for that commit).  Maybe manu@ or zeising@ can weigh in.  But as far as I can tell (on reading the meson build files and actually building / installing), it does not need to be enabled for the libosmesa build.

As you pointed it, having 'opengl' enabled triggers an install of gl.h and some other header files.  Those are already installed by graphics/mesa-libs, so graphics/libosmesa does not need to enable the installation of those files itself.  

Additionally, it triggers the build and install of libglapi.so - as described, mesa-libs already makes libglapi.so available.

In my review, libglapi as built by the graphics/mesa-libs port is correct and sufficient for the needs of libosmesa.  It is not built any differently by mesa-libs than it is if -Dopengl=enabled is set for libosmesa build.  In fact, if it WERE built differently in a material way, then when libosmesa linked with mesa-lib's version of libglapi.so at run-time, that would be a problem.  So it is best that graphics/libosmesa links against the version of libglapi.so from graphics/mesa-libs rather than try to build one itself.
Comment 10 Emmanuel Vadot freebsd_committer freebsd_triage 2021-11-19 14:34:02 UTC
check-plist doesn't complain now, closing.
Comment 11 John Hein 2021-11-22 05:31:47 UTC
(In reply to Emmanuel Vadot from comment #10)
If you apply the patch (using -Dopengl=false), then you don't need the @comment hacks in pkg-plist, and it cuts build time (although not that much).