Porting X11Libre to FreeBSD.

nxjoseph said:
Maybe make makesum to generate new distinfo.
Click to expand...
Code: 
root@elfreebsdo1:~/xlibre/xlibre-ports/x11-servers/xlibre-server # make makesum
===>  License MIT accepted by the user
===>  License MIT accepted by the user
===>   xlibre-server- depends on file: /usr/local/sbin/pkg - found
=> X11Libre-xserver--01a66863_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/xlibre/server.
=> Attempting to fetch https://codeload.github.com/X11Libre/xserver/tar.gz/01a66863?dummy=/X11Libre-xserver--01a66863_GH0.tar.gz
fetch: https://codeload.github.com/X11Libre/xserver/tar.gz/01a66863?dummy=/X11Libre-xserver--01a66863_GH0.tar.gz: Not Found
=> Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/xlibre/server/X11Libre-xserver--01a66863_GH0.tar.gz
fetch: http://distcache.FreeBSD.org/ports-distfiles/xlibre/server/X11Libre-xserver--01a66863_GH0.tar.gz: Not Found
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/xlibre/server and try again.
*** Error code 1

Stop.
make[1]: stopped in /root/xlibre/xlibre-ports/x11-servers/xlibre-server
*** Error code 1

Stop.
make: stopped in /root/xlibre/xlibre-ports/x11-servers/xlibre-server
root@elfreebsdo1:~/xlibre/xlibre-ports/x11-servers/xlibre-server #
 
elgrande said:
I have the impression that GH_TAGNAME handles tags not commit.
To start & test bisect with the working commit, I added
Code: 
USE_GITHUB=    yes
GH_TAGNAME=    01a66863
to the Makefile and now receive
Code: 
root@elfreebsdo1:~/xlibre/xlibre-ports/x11-servers/xlibre-server # make
===>  License MIT accepted by the user
===>   xlibre-server- depends on file: /usr/local/sbin/pkg - found
=> xlibre/server/X11Libre-xserver--01a66863_GH0.tar.gz is not in /root/xlibre/xlibre-ports/x11-servers/xlibre-server/distinfo.
=> Either /root/xlibre/xlibre-ports/x11-servers/xlibre-server/distinfo is out of date, or
=> xlibre/server/X11Libre-xserver--01a66863_GH0.tar.gz is spelled incorrectly.
*** Error code 1

Stop.
make[1]: stopped in /root/xlibre/xlibre-ports/x11-servers/xlibre-server
*** Error code 1

Stop.
make: stopped in /root/xlibre/xlibre-ports/x11-servers/xlibre-server
root@elfreebsdo1:~/xlibre/xlibre-ports/x11-servers/xlibre-server #

Any idea?
Click to expand...

You are setting the commit hash for xlibre-server port to the ports trees commit hash.
You need to use ones from the XLibre/xserver repo: 25.0.0.5...25.0.0.7.
 
baaz said:
You are setting the commit hash for xlibre-server port to the ports trees commit hash.
You need to use ones from the XLibre/xserver repo: 25.0.0.5...25.0.0.7.
Click to expand...
Ok that was stupid me. O:‑)

Anyhow I continued today with fresh energy and the behavior is strange.
I went through the commits and ended up at the following still working smooth:
Code: 
GH_ACCOUNT=    X11Libre
GH_PROJECT=    xserver
USE_GITHUB=    yes
GH_TAGNAME=    90bfeca905a1530ccf8fb91006c9be028c56af74
From my understanding that is the commit which is identical to xlibre-xserver-25.0.0.7.
So building via the commit works (based on XLIBRE_MIN_VER=0.5), but XLIBRE_MIN_VER=0.7 without specifying a commit fails.
That's kinda strange.

Edit: So maybe the problem is within the xlibre ports repository commits? https://github.com/b-aaz/xlibre-por...e4...93ab0f2be3aef41b46b9b046561b1c349f588520
 
P.S.: I double checked - with latest version xlibre-server-25.0.0.8 from unmodified xlibre ports, the problem is there again.
 
I debugged some more and used git bisect on the ports repository.
The following is the result:
Code: 
root@elfreebsdo1 ~/x/x/x/xlibre-server ((93ab0f2b)|BISECTING)# git bisect bad
93ab0f2be3aef41b46b9b046561b1c349f588520 is the first bad commit
commit 93ab0f2be3aef41b46b9b046561b1c349f588520 (HEAD)
Author: b-aaz <85005689+b-aaz@users.noreply.github.com>
Date:   Thu Jul 31 13:32:10 2025 +0000

    Moved the servers to new minor release 25.0.0.7.
    
    The epoll dependency was not properly recognized due to its include
    search path not being added to the compiler flags and its has_function
    check being broken, both are now fixed by the two patches:
    patch-include_meson.build
    patch-meson.build
    Now the server gets properly linked to libepoll-shim.
    
    The old patch-meson.build patch is no longer needed since the change is
    merged into the upstream.

 x11-servers/xlibre-server/Makefile                        |  1 -
 x11-servers/xlibre-server/Makefile.version                |  2 +-
 x11-servers/xlibre-server/distinfo                        |  6 +++---
 x11-servers/xlibre-server/files/patch-include_meson.build | 11 +++++++++++
 x11-servers/xlibre-server/files/patch-meson.build         | 26 ++++++++++++++++++--------
 5 files changed, 33 insertions(+), 13 deletions(-)
 create mode 100644 x11-servers/xlibre-server/files/patch-include_meson.build
root@elfreebsdo1 ~/x/x/x/xlibre-server ((93ab0f2b)|BISECTING)#
So to me it seems the issue is potentially in the files/patch-* changes.
I keep on searching.
 
Note that epoll on FreeBSD is NOT in base, but in devel/libepoll-shim port, which states itself "implements epoll on top of kqueue".
And its "actual" update was an year (+) ago. (Commits after that is for flavorizing i386 not to install 64bit libraries, thus, should be NOP for 64bit archs.)

And more, the mentioned patch forx11-servers/xorg-server is like this. Not sure it relates with epoll or not. At least nothing to do with x86_64 (amd64), but aarch64 and arm.

If epoll matters here and the time the issue (not sure what it is, though) is confirmed to exist was after the above-mentioned commit (or quarterly 2024Q3 or later), what affects could be in base kquere implementations, which could be different between branches (main, stable/14, releng/14.3, ...).
 
T-Aoki said:
Note that epoll on FreeBSD is NOT in base, but in devel/libepoll-shim port, which states itself "implements epoll on top of kqueue".
And its "actual" update was an year (+) ago. (Commits after that is for flavorizing i386 not to install 64bit libraries, thus, should be NOP for 64bit archs.)

And more, the mentioned patch forx11-servers/xorg-server is like this. Not sure it relates with epoll or not. At least nothing to do with x86_64 (amd64), but aarch64 and arm.

If epoll matters here and the time the issue (not sure what it is, though) is confirmed to exist was after the above-mentioned commit (or quarterly 2024Q3 or later), what affects could be in base kquere implementations, which could be different between branches (main, stable/14, releng/14.3, ...).
Click to expand...
That indeed sounds challenging...
 
How bad is it to rewrite epoll code into kqueue/event in this code base? I'd rather see that done than rely on the shim. I've done it before for other items, but it was a simple/small code base. This is coming from someone who's not exactly a well experienced C developer.
 
fmc000 said:
baaz - I suggest you speak with the KDE maintainers because pkg install kde brings in xorg-server and thus it's impossible to use your packages with KDE.
Click to expand...
I would like to experiment again with Xlibre on my KDE machine but life got the better of my time lately and I somewhat lost track of the progresses made (and honestly some of those discussions are above my FreeBSD knowledge).

Anyways, has anything changed in the past couple of months with regards to this? What's the favorite way to run plasma 6.4.4 with Xlibre, if such a way actually exists?

My system uses pkgbase, in case it's relevant.
 
fmc000 said:
I would like to experiment again with Xlibre on my KDE machine but life got the better of my time lately and I somewhat lost track of the progresses made (and honestly some of those discussions are above my FreeBSD knowledge).

Anyways, has anything changed in the past couple of months with regards to this? What's the favorite way to run plasma 6.4.4 with Xlibre, if such a way actually exists?

My system uses pkgbase, in case it's relevant.
Click to expand...
Sorry to quote myself but I'm still in my hospital bed with no progress on my side. I appreciate some help with this regards, hoping to get back to my machine soon, thank you.
 
elgrande said:
I guess plasma will be difficult since it pulls in xorg afaik.
So it may require adjusting the port to remove the dependency and then manual compilation.
Click to expand...
I guess it shouldn't be too hard to mod port, KDE 6.4.5 works okay with XLibre on Gentoo (OpenRC), OpenMandriva and Fedora (only 3 that I'm personally testing in VM just for that combo)
 
You must log in or register to reply here.
Back
Top