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
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
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?
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.
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.
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
That one did the trick. What was the issue, out of curiosity?
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.
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
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
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