Bug 204706 - x11-wm/openbox package build issue
Summary: x11-wm/openbox package build issue
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Roman Bogorodskiy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-21 00:33 UTC by Mason Loring Bliss
Modified: 2015-11-26 23:09 UTC (History)
1 user (show)

See Also:
novel: merge-quarterly+


Attachments
openbox xcursor dep (492 bytes, patch)
2015-11-21 11:08 UTC, Roman Bogorodskiy
no flags Details | Diff
locally built (from ports) openbox binary (350.09 KB, application/x-executable)
2015-11-24 19:59 UTC, Mason Loring Bliss
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss 2015-11-21 00:33:24 UTC
Openbox built from ports with default options honors monitor edges when maximizing a window. The pkg, which ought to be identical, does not.

ldd notes the following in the port but not the package:

libXcursor.so.1
libXfixes.so.3

Don't know if either of those is an issue, but my expectation was that a default port build would link the same libraries as the equivalent package.

Package from http://pkg.freebsd.org/freebsd:10:x86:64/quarterly/All/
Port built from https://svn.freebsd.org/ports/branches/2015Q4
Comment 1 Roman Bogorodskiy freebsd_committer 2015-11-21 11:08:18 UTC
Created attachment 163374 [details]
openbox xcursor dep

You are absolutely right, the builds should be deterministic in this context.

It looks like the issue is caused by the fact the openbox configure script checks xcursor presence and if it's there, it enabled support, otherwise continues without out.

http://beefy1.nyi.freebsd.org/data/93i386-default/402112/logs/openbox-3.6.log

Here, one could see:

 Compiling with these options:
               Startup Notification... yes
               X Cursor Library... no

It's not obvious how xcursor support is related to the described problem with windows though, but it should be fixed anyway.

Also, openbox pulls xfixes support through xcurses.

I've attached a patch to build with xcurses unconditionally.

I'll be on the road for the next couple of days, so most likely will be able to commit and MFH somewhere next week.

Thanks
Comment 2 Roman Bogorodskiy freebsd_committer 2015-11-24 13:14:05 UTC
I created an 10/amd64/2015Q4 updated package:

https://people.freebsd.org/~novel/misc/openbox-3.6_1.txz

SHA256 (openbox-3.6_1.txz) = 453d20db91ba93376c094dd76eec4ac85acad71d097483b9a58dcfbeaa87dc2b

Could you please check that it fixes the problem?
Comment 3 Mason Loring Bliss 2015-11-24 19:50:54 UTC
I'm sorry to say, the test package you supplied has the same misbehaviour as the official package - when I maximize a window, it covers both monitors rather than limiting itself to a single monitor. Rebuilding Openbox locally from the ports tree results in a binary which works.

If it's any help I tied xfwm as well, from pkg, and that honors monitor edges, so I don't think that the local build is strictly what's different. That said, the missing libraries were the only bits I noted as being different here. Your test package and my build of the port are linking identical libraries.

There's clearly something different, though. The files are different sizes - your package is a couple kilobytes smaller.

mason@acheron /home/mason$ ls -l foo/usr/local/bin/openbox
-r-xr-xr-x  1 mason  mason  355952 Nov 24 00:13 foo/usr/local/bin/openbox
mason@acheron /home/mason$ ls -l /usr/local/bin/openbox
-r-xr-xr-x  1 root  wheel  358488 Nov 24 14:38 /usr/local/bin/openbox

Both are stripped and link the same libraries, so either there's different code configured or mine's linking something statically or *something*.

I'm going to attach my actual binary for a more detailed grovelling.
Comment 4 Mason Loring Bliss 2015-11-24 19:59:19 UTC
Created attachment 163491 [details]
locally built (from ports) openbox binary

note that attachment is 2-3K bigger than Mr. Bogorodskiy's test package openbox binary, so something is happening differently here.

strings -a <binary> | tr /A-Z/ /a-z/ has a bunch of gibberish except at the very beginning, where see this in my locally-built binary but *not* in Mr. Bogorodskiy's test binary:

204d203
< obt_display_extension_xinerama
355,359d353
< libxinerama.so.1
< xineramaqueryscreens
< libxrender.so.1
< libxrandr.so.2
< xrrupdateconfiguration

I'm not quite clever enough to know how this happened. I'd have guessed that the library names were included as strings, but clearly they're not as the supplied test package links these without having the strings show up. At any rate, I suspect that the answer relates to this somehow.
Comment 5 Roman Bogorodskiy freebsd_committer 2015-11-24 20:30:26 UTC
Would appreciate if you try another package, the url is the same:

https://people.freebsd.org/~novel/misc/openbox-3.6_1.txz

SHA256 (openbox-3.6_1.txz) = ce04de649ab7a59a27b64d4ce8945691c38f12f2ca2fee74f2053ff87f98ef10
Comment 6 Mason Loring Bliss 2015-11-24 21:21:56 UTC
That one did the trick. What was the issue, out of curiosity?
Comment 7 Roman Bogorodskiy freebsd_committer 2015-11-24 22:05:36 UTC
The reason is that openbox tries to detect some other x11 extensions (xrandr, xinerama etc) during the build and silently continues if it cannot find something and doesn't print that info in the summary.

So adding these extensions to USE_XORG helped.

It's not obvious why it doesn't link directly though, need to take a look.

Thanks for testing, I'll commit it to HEAD soon and request MFH a little later.
Comment 8 commit-hook freebsd_committer 2015-11-24 22:21:33 UTC
A commit references this bug:

Author: novel
Date: Tue Nov 24 22:21:17 UTC 2015
New revision: 402380
URL: https://svnweb.freebsd.org/changeset/ports/402380

Log:
  x11-wm/openbox: fix dependencies and default package

  At build time openbox tries to detect presence of some
  X11 extentions libs and headers and silently disables
  support for them if they cannot be found.

  When building from port, these extensions are usually
  available already, so user gets a fully functional package,
  however, when installing from package user gets a package with
  a limited functionality.

  Fix this by adding all the required dependencies to USE_XORG.

  PR:	204706
  MFH:	2015Q4

Changes:
  head/x11-wm/openbox/Makefile
Comment 9 commit-hook freebsd_committer 2015-11-26 22:43:58 UTC
A commit references this bug:

Author: novel
Date: Thu Nov 26 22:43:21 UTC 2015
New revision: 402465
URL: https://svnweb.freebsd.org/changeset/ports/402465

Log:
  MFH: r402380

  x11-wm/openbox: fix dependencies and default package

  At build time openbox tries to detect presence of some
  X11 extentions libs and headers and silently disables
  support for them if they cannot be found.

  When building from port, these extensions are usually
  available already, so user gets a fully functional package,
  however, when installing from package user gets a package with
  a limited functionality.

  Fix this by adding all the required dependencies to USE_XORG.

  PR:		204706
  Approved by:	portmgr (erwin)

Changes:
_U  branches/2015Q4/
  branches/2015Q4/x11-wm/openbox/Makefile
Comment 10 Roman Bogorodskiy freebsd_committer 2015-11-26 22:46:14 UTC
I've merged the fix to the 2015Q4 branch, so package should get updated soon. Let me know if you will have issues with the new package.

Thanks