machinekit
Reviving QtQuickVcp functionality
I'm just wondering if anyone have any thoughts on how ? Or if there are other feasible remote gui's for the mksocfpga platform ?
I did some digging into this issue here: Besides generating a missing preview.so library it seems like mkwrapper.py and machinetalk-protobuf need to be updated to the new linuxcnc 2.8 , 2.9 axis --> joints changes ?
@the-snowwhite,
at least in my books, it was always the plan to make the remote access functionality work with EMCApplication. Problem was, I didn't like Python, so I wasn't exactly capable or willing to make that happen. However, recent changes caused that my ability to work with Python vastly improved, so now I can actually help.
I think the best course of action would be to decide where the code should be hosted/how it should be split. If it should be put into the QtQuickVcp repo, if a new repo should be created and in this case - if some code should be moved to that repos from QtQuickVcp repo or other connected (Cetus one, for example) repositories?
Getting to the bottom of this issue in other thread my findings are: (basic package will consist of 3 files that i needed to edit) the missing preview.so stems from a file I found in the machinekit-cnc/src/emc/rs274ngc folder The include files for this library are in the emcapplication-dev package and some library dependencies are in emcapplication-bin package. The last dependencies are in machinekit-hal / machinetalk-protobuf
The next file is machinekit-hal/src/machinetalk/proto/src/machinetalk/protobuf/status.proto this seems to be part of the machinetalk-protobuf sub repo Lastly there is the mkwrapper.py file itself that is useless without the preview.so lib so this file should be migrated to the new repo where preview.so is built.
The makefile for building preview.so is here and I'm having some trouble understanding the dependencies in this line:
Which is why I resulted to building the preview.so in the machinekit-hal repo
Since the qtquickvcp repo is naturally geared towards building the QT based MachinekitClient app I don't find it natural to add the preview.so and dependent mkwrapper into that repo. (On a side note some linuxcnc 2.9 changes are needed to be made to the qtquickvcp repo also).
More I would go for splitting Mkwrapper out into a separate repo together with the preview.so lib and then build against emcapp-dev/bin and also machinekit-hal (the Ihal/haltalk $(CZMQ_CFLAGS) $(PROTOBUF_CFLAGS))
And calling that repo: Mkwrapper
The last part of the puzzle is the support for python based hal configs: I came up with a 1 liner for patching the linuxcnc pythón script::
sed '/if ! haltcl -i \"$INIFILE\" \$CFGFILE \$CFGFILE_ARGS /!{ p; d }; n;n;n;n;n;n; i\ \ \ \ \ \ \ \ *.py)\n if ! python2 \$CFGFILE ; then\n Cleanup\n exit -1\n fi\n ;;' /usr/bin/linuxcnc
sudo sh -c 'sed -i '\''/if ! haltcl -i \"$INIFILE\" \$CFGFILE \$CFGFILE_ARGS /!{ p; d }; n;n;n;n;n;n; i\ \ \ \ \ \ \ \ *.py)\n if ! python2 \$CFGFILE ; then\n Cleanup\n exit -1\n fi\n ;;'\'' /usr/bin/linuxcnc'
Since I have no illusions about committing this to the right place: lcnc upstream This perhaps could be added to the emcapplication post install scripts ?
Also a crucial part of the python based hal config stuff is the fdm stuff here (that also works fine for a router) This I also think should be added to the MKWrapper repo/package
And calling that repo: Mkwrapper
Sounds sensible. Moreover, from historical point of view it is what it was called.
Lastly there is the mkwrapper.py file itself that is useless without the preview.so lib so this file should be migrated to the new repo where preview.so is built.
Yes, I agree. I think the dependencies and repo structure should be as tree-like as possible.
More I would go for splitting Mkwrapper out into a separate repo together with the preview.so lib and then build against emcapp-dev/bin and also machinekit-hal (the Ihal/haltalk $(CZMQ_CFLAGS) $(PROTOBUF_CFLAGS))
Agree.
Since I have no illusions about committing this to the right place: lcnc upstream This perhaps could be added to the emcapplication post install scripts ?
Probably not. However, I am not sure how good place for this is the post script. I think if it needs to be in EMCApplication package and not in the MKWrapper repository, then it should be in code proper. (One should still be able to do a hard diff on two branches and see the difference. The difference should be small, but I am worried that by adding functionality into install process - functionality, which should rightfully be somewhere else in the code-base - it will become untransparent.) I think that it is a situation in which the lesser evil has to be chosen.
Also a crucial part of the python based hal config stuff is the fdm stuff here (that also works fine for a router) This I also think should be added to the MKWrapper repo/package
Should that be in MKWrapper repository or in again another? Maybe having repository with common configurations should be considered?
Maybe having repository with common configurations should be considered?
Absolutely yes, a place for hal python configs and examples.
Should that be in MKWrapper repository or in again another?
Although the fdm stuff can be added locally to a config (and also customized that way), I see this more as a global function library (one size fits all) and would prefer to keep and maintain the fdm libs together as a whole same place as the mkwrapper script
@cerna Ah I see you have initiated the mkwrapper repo. Before going any further with the mkwrapper repo I thought it wise to rebase my fixes to MK-hal head and get up and running with a python3 version however I'm stuck in this mklauncher issue and need some python expert help before being able to move on. I would really like to start off with a clean python3 slate because rebasing to the older commits of the python2 stuff is so messy ... :-) BTW mklauncher seems like a candidate for the mkwrapper repo also ?
@the-snowwhite,
Ah I see you have initiated the mkwrapper repo.
Yes, I was planning to make at least a README page over the weekend (well, I am, I still have a few hours left), so it can be forked and the whole C4 system can be applied.
I would really like to start off with a clean python3 slate because rebasing to the older commits of the python2 stuff is so messy ... :-)
That is very good idea.
BTW mklauncher seems like a candidate for the mkwrapper repo also ?
On one side, it would make a sense, on the other I have a latency-test Python application I have been meaning to PR to Machinekit-HAL which uses the mklauncher. But down the line it is on par with having distributed installation and development. But then should it still be named MKWrapper given that mklauncher and mkwrapper have historically different functionality/meaning?
Fdm stuff has nothing to do with mkwrapper, this is hal code for 3d printers. Should either in machinekit-hal, in a separate machinekit-fdm project. It's just config files that are shared between different configs.
Ad mkwrapper: Not sure what the changes are in LinuxCNC 2.9, but it's based on the linuxcnc Python API. If there are any changes and additions in upstream Linuxcnc, they will need to go into status.proto and the mkwrapper.py file.
previewmodule.so is an alternative interpreter for LinuxCNC, so it should go there. QtQuickVcp doesn't need it, it's only required for 3d preview if needed by the particular applications. E.g. 3D printers may not need it at all.
However, it depends on protobuf and zmq. Building on top of LinuxCNC would be ideal. Also note that mkwrapper would work with native LinuxCNC and without machinetalk-hal if mklauncher and configserver are added to the mix.
I was beginning to wonder if it would be a good idea to move the whole Machinetalk entity out into a separate whole repository instead of having it split out different places ? @machinekoder ~Can you point out the source file(s) for the linuxcnc python api ?~ --> src/emc/usr_intf/axis/extensions/emcmodule.cc
they will need to go into status.proto and the mkwrapper.py
I guess that could be the source for me only being able to run Cetus in python2 but the Anddemo in Both (py2/py3)
It seems like the linuxcnc python api source file is: src/emc/usr_intf/axis/extensions/emcmodule.cc Comparing that to the one from machinekit-cnc shows a relative large amount of changes that need to be worked into status.proto @machinekoder Can I persuade you to work out this upgrade ? Else I need some guidelines for how to translate from emcmodule.cc --> status.proto As this work is a bit over my head :-)
@the-snowwhite I don't think they did break the API, so I suspect the changes are marginal, probably already in status.proto due to work on other projects. No intermedia changes might be needed, however, it would nice to have the additional properties of the linuxcnc module available in Machinetalk as well. To If you already have linuxcnc running, it would be great if you could do a
import linuxcnc
s = linuxcnc.stat
s.poll()
print(dir(s))
Machinetalk in a new entity: Yes, the Python part could be moved out of machinekit-hal, machinetalk-protobuf is already a pip package and could be a separate deb. The reason we kept it as git subtree is to make the build easier. Machinetalk could be used completely without HAL and Machinekit/Linuxcnc.
@machinekoder I have a new branch where emcapplication builds as python3 and I have also just added the preview module. I have built it against the latest mk-hal commit here are my results on my arm64 socfpga:
machinekit@mksocfpga-umyir-soc:~$ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import linuxcnc
>>> s = linuxcnc.stat
>>> s.poll()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: descriptor 'poll' of 'linuxcnc.stat' object needs an argument
>>> print(dir(s))
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'acceleration', 'active_queue', 'actual_position', 'adaptive_feed_enabled', 'ain', 'angular_units', 'aout', 'axes', 'axis', 'axis_mask', 'block_delete', 'call_level', 'command', 'current_line', 'current_vel', 'cycle_time', 'debug', 'delay_left', 'din', 'distance_to_go', 'dout', 'dtg', 'echo_serial_number', 'enabled', 'estop', 'exec_state', 'feed_hold_enabled', 'feed_override_enabled', 'feedrate', 'file', 'flood', 'g5x_index', 'g5x_offset', 'g92_offset', 'gcodes', 'homed', 'id', 'inpos', 'input_timeout', 'interp_state', 'interpreter_errcode', 'joint', 'joint_actual_position', 'joint_position', 'joints', 'kinematics_type', 'limit', 'linear_units', 'lube', 'lube_level', 'max_acceleration', 'max_velocity', 'mcodes', 'mist', 'motion_line', 'motion_mode', 'motion_type', 'num_extrajoints', 'optional_stop', 'paused', 'pocket_prepped', 'poll', 'position', 'probe_tripped', 'probe_val', 'probed_position', 'probing', 'program_units', 'queue', 'queue_full', 'queued_mdi_commands', 'rapidrate', 'read_line', 'rotation_xy', 'settings', 'spindle', 'spindles', 'state', 'task_mode', 'task_paused', 'task_state', 'tool_in_spindle', 'tool_offset', 'tool_table', 'velocity']
>>>
@machinekoder
I don't think they did break the API,
The main changes I found out is that Axis is mostly gone and now called joints instead, the spindle is upgraded from single to multi (up to 9). Here are the changes to mkwrapper.py and proto.status I came up with that got Machinekit client to work in python2 (but not python3)(I also didn't implement multi spindle)
I found out a different more friendly printout version:
machinekit@mksocfpga-umyir-soc:~$ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> #!/usr/bin/env python3
... import sys
>>> import linuxcnc
>>>
>>> s = linuxcnc.stat
>>> #s.poll()
... for x in dir(s):
... if not x.startswith("_"):
... print(x, getattr(s, x))
...
acceleration <member 'acceleration' of 'linuxcnc.stat' objects>
active_queue <member 'active_queue' of 'linuxcnc.stat' objects>
actual_position <attribute 'actual_position' of 'linuxcnc.stat' objects>
adaptive_feed_enabled <member 'adaptive_feed_enabled' of 'linuxcnc.stat' objects>
ain <attribute 'ain' of 'linuxcnc.stat' objects>
angular_units <member 'angular_units' of 'linuxcnc.stat' objects>
aout <attribute 'aout' of 'linuxcnc.stat' objects>
axes <attribute 'axes' of 'linuxcnc.stat' objects>
axis <attribute 'axis' of 'linuxcnc.stat' objects>
axis_mask <member 'axis_mask' of 'linuxcnc.stat' objects>
block_delete <member 'block_delete' of 'linuxcnc.stat' objects>
call_level <member 'call_level' of 'linuxcnc.stat' objects>
command <member 'command' of 'linuxcnc.stat' objects>
current_line <member 'current_line' of 'linuxcnc.stat' objects>
current_vel <member 'current_vel' of 'linuxcnc.stat' objects>
cycle_time <member 'cycle_time' of 'linuxcnc.stat' objects>
debug <member 'debug' of 'linuxcnc.stat' objects>
delay_left <member 'delay_left' of 'linuxcnc.stat' objects>
din <attribute 'din' of 'linuxcnc.stat' objects>
distance_to_go <member 'distance_to_go' of 'linuxcnc.stat' objects>
dout <attribute 'dout' of 'linuxcnc.stat' objects>
dtg <attribute 'dtg' of 'linuxcnc.stat' objects>
echo_serial_number <member 'echo_serial_number' of 'linuxcnc.stat' objects>
enabled <member 'enabled' of 'linuxcnc.stat' objects>
estop <member 'estop' of 'linuxcnc.stat' objects>
exec_state <member 'exec_state' of 'linuxcnc.stat' objects>
feed_hold_enabled <member 'feed_hold_enabled' of 'linuxcnc.stat' objects>
feed_override_enabled <member 'feed_override_enabled' of 'linuxcnc.stat' objects>
feedrate <member 'feedrate' of 'linuxcnc.stat' objects>
file <member 'file' of 'linuxcnc.stat' objects>
flood <member 'flood' of 'linuxcnc.stat' objects>
g5x_index <attribute 'g5x_index' of 'linuxcnc.stat' objects>
g5x_offset <attribute 'g5x_offset' of 'linuxcnc.stat' objects>
g92_offset <attribute 'g92_offset' of 'linuxcnc.stat' objects>
gcodes <attribute 'gcodes' of 'linuxcnc.stat' objects>
homed <attribute 'homed' of 'linuxcnc.stat' objects>
id <member 'id' of 'linuxcnc.stat' objects>
inpos <member 'inpos' of 'linuxcnc.stat' objects>
input_timeout <member 'input_timeout' of 'linuxcnc.stat' objects>
interp_state <member 'interp_state' of 'linuxcnc.stat' objects>
interpreter_errcode <member 'interpreter_errcode' of 'linuxcnc.stat' objects>
joint <attribute 'joint' of 'linuxcnc.stat' objects>
joint_actual_position <attribute 'joint_actual_position' of 'linuxcnc.stat' objects>
joint_position <attribute 'joint_position' of 'linuxcnc.stat' objects>
joints <member 'joints' of 'linuxcnc.stat' objects>
kinematics_type <member 'kinematics_type' of 'linuxcnc.stat' objects>
limit <attribute 'limit' of 'linuxcnc.stat' objects>
linear_units <member 'linear_units' of 'linuxcnc.stat' objects>
lube <member 'lube' of 'linuxcnc.stat' objects>
lube_level <member 'lube_level' of 'linuxcnc.stat' objects>
max_acceleration <member 'max_acceleration' of 'linuxcnc.stat' objects>
max_velocity <member 'max_velocity' of 'linuxcnc.stat' objects>
mcodes <attribute 'mcodes' of 'linuxcnc.stat' objects>
mist <member 'mist' of 'linuxcnc.stat' objects>
motion_line <member 'motion_line' of 'linuxcnc.stat' objects>
motion_mode <member 'motion_mode' of 'linuxcnc.stat' objects>
motion_type <member 'motion_type' of 'linuxcnc.stat' objects>
num_extrajoints <member 'num_extrajoints' of 'linuxcnc.stat' objects>
optional_stop <member 'optional_stop' of 'linuxcnc.stat' objects>
paused <member 'paused' of 'linuxcnc.stat' objects>
pocket_prepped <member 'pocket_prepped' of 'linuxcnc.stat' objects>
poll <method 'poll' of 'linuxcnc.stat' objects>
position <attribute 'position' of 'linuxcnc.stat' objects>
probe_tripped <member 'probe_tripped' of 'linuxcnc.stat' objects>
probe_val <member 'probe_val' of 'linuxcnc.stat' objects>
probed_position <attribute 'probed_position' of 'linuxcnc.stat' objects>
probing <member 'probing' of 'linuxcnc.stat' objects>
program_units <member 'program_units' of 'linuxcnc.stat' objects>
queue <member 'queue' of 'linuxcnc.stat' objects>
queue_full <member 'queue_full' of 'linuxcnc.stat' objects>
queued_mdi_commands <member 'queued_mdi_commands' of 'linuxcnc.stat' objects>
rapidrate <member 'rapidrate' of 'linuxcnc.stat' objects>
read_line <member 'read_line' of 'linuxcnc.stat' objects>
rotation_xy <member 'rotation_xy' of 'linuxcnc.stat' objects>
settings <attribute 'settings' of 'linuxcnc.stat' objects>
spindle <attribute 'spindle' of 'linuxcnc.stat' objects>
spindles <member 'spindles' of 'linuxcnc.stat' objects>
state <member 'state' of 'linuxcnc.stat' objects>
task_mode <member 'task_mode' of 'linuxcnc.stat' objects>
task_paused <member 'task_paused' of 'linuxcnc.stat' objects>
task_state <member 'task_state' of 'linuxcnc.stat' objects>
tool_in_spindle <member 'tool_in_spindle' of 'linuxcnc.stat' objects>
tool_offset <attribute 'tool_offset' of 'linuxcnc.stat' objects>
tool_table <attribute 'tool_table' of 'linuxcnc.stat' objects>
velocity <member 'velocity' of 'linuxcnc.stat' objects>
>>>
@the-snowwhite,
I was beginning to wonder if it would be a good idea to move the whole Machinetalk entity out into a separate whole repository
The whole Machinetalk architectural design is - speaking mildly - not very good. It was probably started before the idea to have multiple separate repositories to develop all the functionality and because of that it is all put on one heap with no clear distinction in functionality.
However, that doesn't mean that the idea on socketed access to rtapi with maybe smarter deamonization down the line should be abandoned. I think it just needs cutting into logical parts and integrating into connected projects (by that I don't mean into it's git repositories, you can have Machinekit-HAL and Machinekit-HAL-messages).
Now all messages for HAL, EMC, ROS and whatever else are in one place and pretty much chaotic.
(It would go against the Window/Container message which is in use today. But I am not a fan of that. I think the better solution is to have something like Flatbuffers provides: 4 bytes long unique ID in static place in each message, then you can filter and access known/unknown messages based on that.)
@cerna To learn more about the design of Machinetalk you can look here: https://machinekoder.com/machinetalk-explained-part-2-middleware-requirements/ in fact there is an ID for each message.
Why the container message? The idea was and still is that it's always extendable with custom new fields and types without the individual application parts knowing of the content. This was not possible with EMC design. In fact, you can still connect with an older Machinetalk client to a new version containing those new fields (but not the other way around).
You could also split up Machinetalk-Protobuf. The repository is just there for convenience. Having just one repository with all the message definitions should in theory make it easier to keep everything up to date. And back when we created it, that made perfectly sense, since everything was just one project.
Could you still split it up? Yes! I've done that several times for private projects. There is no need to use the "master" machinetalk-protobuf stuff. However, you might break backward compatibility by changing stuff in the message definitions. That's why there is a preferred way for deprecating stuff, the optional field. Protocol Buffers are very well thought through. But you can always include the "master" machinetalk-protobuf definition, meaning the Container message and extend it in the individual project. When not using the messagebus (actually we are not), we can pass messages directly as well. This would be appropriate for most parts of the project after all.
And yes, there is stuff in machinetalk-protobuf which shouldn't be there. I think there is no use of the ROS stuff for example.
If DDS/ROS2 had been more mature back then, we probably wouldn't even have designed Machinetalk. But at this time, the ROS project was still deciding on what they would want to use, without good OSS DDS implementations around. If ever a rework of the project is going to happen, it's worth considering throwing out Machinetalk and using ROS2 instead.
@cerna @machinekoder I must admit defeat on attempting to revive qtquickvcp.
I'm only able to get a "hole" thru to machinekit client in the python2 revsion (via changing the axis field to joint in status.proto) any other changes or additions result in silent failure of the mk client. Since machinekit-hal transitioned to python3 in august I have nowhere to place the working changes to mkwrapper. (The status-proto quick fix probably also breaks the api)
I'm unable to get Machinekit-Client to connect in any way with any modifications I have been able to come up with in python3 versions (I just get a silent failure in Machinekit Client with this image:
run log:
mib@kdeneon-ws3:~/Developer/the-snowwhite_git/QtQuickVcp$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 /home/mib/bin/MachinekitClient_Development-201910151052-master-3863795-x64.AppImage
qml: Starting to load the main application.
qrc:///main.qml:51:5: QML ConnectionWindow: Binding loop detected for property "state"
qml: Main application loaded.
qml: Finishing the splash screen progress bar.
qml: Hiding the splash screen.
qml: Deleting the splash screen.
qml: app source changed: file://tmp/MachinekitClient-5cxCvE/Cetus.qml active: false
qml: app source changed: file://tmp/MachinekitClient-5cxCvE/Cetus.qml active: true
qml: request 256 from '': Component not created since no_create flag set
If I click on enable preview or select anything from the view menu I get new messages like this:
file://tmp/MachinekitClient-5cxCvE/ToggleSettingAction.qml:14: TypeError: Cannot read property 'enable' of undefined
file://tmp/MachinekitClient-5cxCvE/ToggleSettingAction.qml:14: TypeError: Cannot read property 'showCoordinate' of undefined
file://tmp/MachinekitClient-5cxCvE/ToggleSettingAction.qml:14: TypeError: Cannot read property 'showVelocity' of undefined
file://tmp/MachinekitClient-5cxCvE/ToggleSettingAction.qml:14: TypeError: Cannot read property 'showSpindleSpeed' of undefined
I have been able to revive the mkwrapper-sim And run it in a (amd64) docker buster container based upon this docker file sketch and then successfully connect to machinekit client in my python 2 versions, but there my partial success ends(spindle buttons not working).
As I'm unable to connect to Machinekit Client via python 3 or commit my working python 2 fixes.....
@the-snowwhite, I will probably require a bit more hand holding.
I have tried to build Docker image of Machinekit-HAL (current version) and EMCApplication build for Python3 (by following this help) on Ubuntu 20.04 Focal and frankly had a pretty big problem. (I don't remember if I was able to do it in the past, I was living with presumption that I have been able to.)
The problem is:
Done reading realtime dependencies
Linking halui
/usr/bin/ld: objects/emc/usr_intf/halui.o: undefined reference to symbol 'rtapi_snprintf'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/libhalulapi.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [emc/usr_intf/Submakefile:42: ../bin/halui] Error 1
However, looking at the symbol I can clearly see it is there:
machinekit@09f2989915ad:~/emcapplication/src$ nm -D /usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/libhalulapi.so | grep rtapi_snprintf
000000000000c91a T rtapi_snprintf
(The T should mean that the library is exporting the symbol.)
So I am scratching my head about it. (And the halui is linked with -lhalulapi.)
So I went back to Debian Buster (where this problem is not shown) and was able to compile successfully. However, for some reason the sim_home_switch.comp is not build and installed. After installing it, I can run simulation Axis.
(There is an error about missing interpreter Python module, which is indeed unfindable, but it runs.)
Not sure if I am having a bad day or if you had similar problems?
@cerna I noticed there was no Cloud smith debs for Ubuntu Focal (20.04) So I wasn't surprised when I had similar results to yours when attempting that build. So I modified your dockerfile to this: and got Axis up and running with both my mk-hal python 2 and 3 branches.
For emcapp I have 2 (buster based)python 3 branches the first one just adds python3 compilation. The second one fully removes all python2 dependencies (and installation of python 2 debs), however requires buster backports to compile and install:(not stretch compatible either)
sudo sh -c 'echo "deb http://deb.debian.org/debian buster-backports main" > /etc/apt/sources.list.d/python3.list'
sudo apt -t buster-backports install libboost-python1.71-dev -y
Both these python 3 branches also have the preview module added in a single commit.
The python2 mk-hal branch combined with (current) emcapp (py2) yields a mostly functional mkwrapper-sim. The python3 stuff however ..... hmmmm ?
@the-snowwhite, I noticed there was no Cloud smith debs for Ubuntu Focal (20.04)
Yes, I thought that I tested version for Ubuntu Focal, but probably not. The default Python should be 3 and not 2 (but it can still be installed from packages), so waiting for LinuxCNC to have Python3 native Debian packaging seemed vital.
So I wasn't surprised when I had similar results to yours when attempting that build.
I was able to build and run basic tests on Ubuntu Focal (Python3 build RIP version) after few changes documented in cerna/EMCApplication@focal branch.
But I got on the same point as you. Note to self: I am uploading image quay.io/cerna/mk-hal-emca-p3:first to be on the same page...
To be run:
docker run -it --rm --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" -u 1000:1000 quay.io/cerna/mk-hal-emca-p3:first bash -i
TO BE EDITED HERE