- Status Closed
- Percent Complete
- Task Type Improvement
- Category ports
-
Assigned To
jue - Operating System CRUX
- Severity Low
- Priority Very Low
- Reported Version 3.7
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#1924 - QEMU on headless machine
I run qemu on a headless host that doesn't have the xorg repo. With some minor package tweaks qemu builds and runs well. Some of these might be worth considering:
1) xorg-libpixman doesn't need any xorg deps. I suggest moving it to opt, unless there's a reason it needs to be in the xorg repo. Right now I just fetch a copy of the port to avoid syncing the whole xorg repo.
2) Building libxkbcommon requires: -D enable-x11=false. There's actually already a check for wayland, I suggest adding a similar one for xorg-server, which would be helpful anyway for people migrating to a pure wayland setup in the future.
This is what I add: prt-get isinst xorg-server || PKGMK_XKBCOMMON+=' -D enable-x11=false'
3) The qemu package requires a dependency on libxml2. It was probably omited since it gets pulled in from it's current dependency on something from xorg.
4) In order to make it headless I also add: --disable-sdl --disable-opengl. I'm not sure how to make that flexible. Maybe have a qemu-headless package?
None of these issues are a big deal, but I think 1 2 and 3 have no downsides and are easy changes.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
> I think 1 2 and 3 have no downsides and are easy changes.
One downside of 2 (at least the way jue first tried to implement it) is that some of the ports depending on libxkbcommon will now have to be adjusted, since they previously could assume the presence of all the ports that xkeyboard-config pulled in. beerman discovered footprint mismatches for qt5 and qt6-base, as a result of this change.
Maybe Alexander has tested a less disruptive change. The proposal as written does not provide enough detail to avoid the breakage. libxkbcommon appearing under opt (not xorg) makes it tempting to try disabling the xorg repo for headless hosts, but these repos are too entangled at the moment, for proposal 2 to be implemented as in commit 53af22068196e7e7b88574ec79bd68d1e89a528f.
Just to make sure we're on the same page, libxkbcommon was already in opt before I suggested the check for xorg-server: https://crux.nu/portdb/?a=search&q=libxkbcommon
xorg-libpixman on the other hand is in the xorg repo. My point regarding that was that it could be moved to opt without affecting anything in the xorg repo while allowing things outside xorg access to libpixman
I think this ticket has uncovered some interesting relationships among our ports, as illustrated by today's commits mentioning xkeyboard-config. Thanks for prompting the investigation into making our libxkbcommon port more flexible.
The unstated assumption behind this ticket appears to be: "opt is a collection that extends core, and xorg is a collection that extends further. Hence a user should be allowed to disable the xorg collection without any ill effects." In the early years of CRUX, this reasoning would have made more sense: https://lists.crux.nu/pipermail/crux-devel/2005-May/000918.html
Even at the time of Tilman's retirement, the xorg collection had a narrower scope: https://lists.crux.nu/pipermail/crux-devel/2012-June/004031.html If Alexander's involvement with CRUX dates back to that era, then he might naturally anticipate no major problems after disabling the xorg collection.
But the opt and xorg repositories have been interdependent for the majority of CRUX history. As early as 2008 sepen wrote a tool (repoverify) that explicitly recognized this interdependence: https://lists.crux.nu/pipermail/crux-devel/2008-July/003697.html Looking at the code fragment sepen quoted, you can see that opt ports are allowed to depend on xorg ports, and vice-versa. Disabling any of the three official repos is therefore non-standard practice, with no guarantee that your `prt-get depinst` commands will succeed. The fact that it's possible to get qemu working, with the xorg collection disabled, should not offer any confidence that other opt ports can be tweaked in a similar manner. But today's commits citing xkeyboard-config demonstrate the ingenuity of CRUX maintainers to accommodate non-standard configurations.
@Alexander Matviychuk: with the recent changes to qemu, can this ticket be closed? Moving a port out of xorg might be done for 3.8, personally I feel very indifferent about it.
Thanks for the improvements! I'm ok with closing this ticket