undetected armhf setuid issues in at least versions 0.4.20894 and 0.4.20868 (for emcapp python2 gui stuff)

[the-snowwhite]

Following the new guide for how to build EMCApplacation for armhf
I then built a fresh new mksocfpga armhf buster sd-image for testing on a DE0-Nano-SoC Kit/Atlas-SoC Kit

Installing the debs I also had to include:

python3-avahi_0.8-3_armhf.deb

libavahi-common-data_0.8-3_armhf.deb

from "Bullseye"

For some reason emcapplication_2.9.0-pre0.23507.git1dcbe183f-buster_armhf.deb asked for machinekit-hal_0.4.20996

so I wgot that and ended up with:

machinekit@mksocfpga-ob-ox:~/current_emc$ ls
emcapplication_2.9.0~pre0.23507.git1dcbe183f~buster_armhf.deb  machinekit-hal_0.4.20894-1.gitebe1344a0~buster_armhf.deb             python3-avahi_0.8-3_armhf.deb
libavahi-common-data_0.8-3_armhf.deb                           machinekit-hal-rt-preempt_0.4.20894-1.gitebe1344a0~buster_armhf.deb

That I installed with:

sudo apt install ./*.deb

testing then turned into an immediate terrible experience:

running linuxcnc gave some error messages (about BACKGROUND color) that could be remedied with:

xrdb -load /dev/null
xrdb -query

Then linuxcnc gui ran (in a ssh -X terminal) however selecting the axis sim configuration lead to a foul error loop:

Investigating further I found out running halrun gave error messages: (with both version 0.4.20894 and 0.4.20868)
However not with the latest version:0.4.20996

machinekit@mksocfpga-ob-ox:~/recomended_emc$ ls
machinekit-hal_0.4.20996-1.git2524ccd02~buster_armhf.deb  machinekit-hal-rt-preempt_0.4.20996-1.git2524ccd02~buster_armhf.deb

machinekit@mksocfpga-ob-ox:~/recomended_emc$ halrun
msgd:0 stopped
rtapi:0 stopped
rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
warning: removing unused HAL shm segment /hal-0-00414c32
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::4345:rt INFO:  Picked default flavor 'rt-preempt' automatically
1:rtapi_app:4345:user cannot gain I/O privileges - forgot 'sudo make setuid'?
1:rtapi_app:4345:user rtapi_app:0 failed to setup realtime environment - 'sudo make setuid' missing?
halcmd: cant connect to rtapi_app: -1 (uri= uuid=18cabec7-96ae-4413-85e0-7f75eed5aa92): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/hal.log
halcmd: the msgd:0 logger demon is not running - please investigate /var/log/hal.log
E: 20-10-14 14:50:37 [4346]dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:284

machinekit@mksocfpga-ob-ox:~/recomended_emc$ cat /var/log/hal.log

Oct 14 14:50:31 localhost rtapi:0: 1:rtapi_app:4345:user cannot gain I/O privileges - forgot 'sudo make setuid'?
Oct 14 14:50:31 localhost rtapi:0: 1:rtapi_app:4345:user rtapi_app:0 failed to setup realtime environment - 'sudo make setuid' missing?
Oct 14 14:50:31 localhost msgd:0: rtapi_app exit detected - scheduled shutdown
Oct 14 14:50:33 localhost msgd:0: msgd shutting down

same reuult for:

machinekit@mksocfpga-ob-ox:~/recomended_emc$ ls
machinekit-hal_0.4.20868-1.gitca75c54aa~buster_armhf.deb  machinekit-hal-rt-preempt_0.4.20868-1.gitca75c54aa~buster_armhf.deb

Since the guide specifies max or = 0.4.20868 the setuid problem in these packages is a big showstopper.

---

On the other side I prefer the Machineface gui qtquickvcp gui setup instead of any builtin linuxcnc gui's so I wonder if its possible to
build against 0.4.20996 and ignore the builtin lcnc gui's and get the Machineface gui to work instead ?

[the-snowwhite]

I can confirm that this issue is not relevant for the arm64 packages.
I just sucessfully ran the emcapplication on an Ultra96v1 after recompiling for machinekit-hal_0.4.20868-1.gitca75c54aa

[cerna]

@the-snowwhite (@Holotronic, sorry I have just now noted that you opened the machinekit/machinekit-docs#321 with different account, and I am not sure which one are you using),

Installing the debs I also had to include:
python3-avahi_0.8-3_armhf.deb
libavahi-common-data_0.8-3_armhf.deb
from "Bullseye"

These packages should be available from the Machinekit/Machinekit repository: Python3-avahi and Libavahi-common-data and actually should be installed automatically as dependencies of the machinekit-hal* packages. But I actually have never tested them with real armhf hardware. Does it mean that they are not working?

For some reason emcapplication_2.9.0-pre0.23507.git1dcbe183f-buster_armhf.deb asked for machinekit-hal_0.4.20996

The reason is that I haven't yet regenerated the emcapplication packages yet and so far there is no CI service. More info can be had in machinekit/EMCApplication#2 and machinekit/EMCApplication#6.

Investigating further I found out running halrun gave error messages: (with both version 0.4.20894 and 0.4.20868) However not with the latest version:0.4.20996

This is interesting. So can I understand it that the whole machinekit-hal package at version 0.4.20894 does not run on armhf architecture? @jallwine reported some time back the same thing, I recommended commenting out code in rtapi_app.cc, which now I can see was included in his latest patch, so that is the reason why it is now working. (That code - well, at least in my opinion - has no place in that place, it should complain lot lower in the module where I/O access is actually requested.)

Can you try to comment it out and rebuild the package at the 20894 (ebe1344a0) state?

On the other side I prefer the Machineface gui qtquickvcp gui setup instead of any builtin linuxcnc gui's so I wonder if its possible to
build against 0.4.20996 and ignore the builtin lcnc gui's and get the Machineface gui to work instead ?

It should be possible, but so far I haven't looked into it. (I have been procrastinating on the EMCApplication's issue, so...). But still it will need first the Python3 packaging in upstream LinuxCNC@master (they are doing it at the same time).

The best way how to attack this is probably to create a new package for the whole qtquickvcp against Machinekit-HAL. (If I remember correctly, it was never tested with Machinekit-HAL, only the monorepo Machinekit.)

[the-snowwhite]

@cerna sorry about the @Holotronic mishap I created that account for some research help work that unfortunately has to be in a private repo.

Can you try to comment it out and rebuild the package at the 20894 (ebe1344a0) state?

Sure: I can test out the armhf commenting out tomorrow, however I have been testing out the mklauncher, qtquickvcp, Cetus, MachinekitClient stuff out on my arm64 based Ultra96 so far without any success:

1. Does'nt seem to accept python based hal config. --> attempted to mold a traditional hal file.
2. latest debug info I'm stuck at is: ./ox.hal:430: haltalk exited without becoming ready. (the very last line don't know what to do about that)

I suspect any armhf based approach will strand the same place.

BTW: The qtquickvcp, python-hal and MachinekitClient stuff did make it past the monorepo Machinekit:

Just before you stepped in armhf qtquickvcp was already working in the machinekit-hal machinekit-cnc repo combo and .deb packaged and in distribution.

The arm64 mk-hal / mk-cnc combo was just made to work correctly and actually committed when unfortunately exactly then the plug was simultaneously pulled on the old build system's, so the arm64 packages were never built and distributed officially, likewise with any work in progress with arm64 mksocfpga building and packaging.

[the-snowwhite]

about:
2.
I see following messages in hal.log:

...
Oct 14 23:48:20 localhost haltalk: FATAL - 'MACHINEKIT_INI' missing in environment
Oct 14 23:48:22 localhost msgd:0: hal_lib:3794:rt hm2/hm2_ultr.0: unregistered
Oct 14 23:48:22 localhost msgd:0: hal_lib:3794:rt hm2: unloading
...

Edit:
Its possible to get the configuration to take hold by doing:

export MACHINEKIT_INI=/etc/machinekit/machinekit.ini

before running mklauncher.

However MachinekitClient is only able to find the file service and the rest of needed services are missing.

[the-snowwhite]

I did the commenting out and rebuilt the mk-hal armhf packages and then the emcapplication and then ran it on
my DE0_Nano_Soc / Atlas.

linuxcnc ran the default axis sim after doing:

xrdb -load /dev/null

However stepconf and pncconf are no-go.

Edit:
I wonder if it would be possible to rebuild the armhf 0.4.20868, etc cloudsmith packages and get them online instead ?

[cerna]

@the-snowwhite,

However stepconf and pncconf are no-go.

Actually, that's a feature, not a bug. 😛

Both these programs are manipulating the HAL and as such both come under the LinuxCNC HAL implementation, not Machinekit-HAL.

Sure: I can test out the armhf commenting out tomorrow, however I have been testing out the mklauncher, qtquickvcp, Cetus, MachinekitClient stuff out on my arm64 based Ultra96 so far without any success:

Hmm, I understood it that the arm64 architecture (Machinekit-HAL stack) is working flawlessly and only the armhf is causing problems.

Both Travis and Drone Cloud are testing the arm* build code natively, but both are using actually arm64 hardware with only Drone testing the armhf under faked environment. So it might happen that for some reason tests are green but actually the application is not.

The arm64 mk-hal / mk-cnc combo was just made to work correctly and actually committed when unfortunately exactly then the plug was simultaneously pulled on the old build system's, so the arm64 packages were never built and distributed officially, likewise with any work in progress with arm64 mksocfpga building and packaging.

Hopefully we will be able to get it all working now too! 👍

I wonder if it would be possible to rebuild the armhf 0.4.20868, etc cloudsmith packages and get them online instead ?

You mean the EMCApplication requiring the 0.4.20868 Machinekit-HAL or Machinekit-HAL at 0.4.20868 state with that code commented out?

BTW, can you merge pull requests?

[the-snowwhite]

I meant

Machinekit-HAL at 0.4.20868 state with that code commented out

BTW, can you merge pull requests?

I think I can ... I just havn't been brave enough to try..

[the-snowwhite]

Hmm, I understood it that the arm64 architecture (Machinekit-HAL stack) is working flawlessly and only the armhf is causing problems.

What does flawlessly mean ?

1. are python based hal configs supposed to work ?
2. are mklauncher based configs with f.ex Cetus/Machineface and MachinekitClient supposed to work ?

[the-snowwhite]

I got a step closer:
It's possible to patch the linuxcnc script to get it to parse python based hal config files:

mib@kdeneon-ws3:~/Developer/ext-repos_git/emcapplication$ git diff scripts/linuxcnc.in
diff --git a/scripts/linuxcnc.in b/scripts/linuxcnc.in
index 7cc32928e..2c013bcaf 100644
--- a/scripts/linuxcnc.in
+++ b/scripts/linuxcnc.in
@@ -847,6 +847,12 @@ else
                exit -1
            fi
        ;;
+        *.py)
+            if ! python2 $CFGFILE ; then
+                Cleanup
+                exit -1
+            fi
+        ;;
        *)
            if ! $HALCMD -i "$INIFILE" -f $CFGFILE && [ "$DASHK" = "" ]; then
                Cleanup

And then run a mklauncer run.py config
This however leads to a new problem loading the hm2_soc_ol driver workes fine from a hal fil but running mklauncher gives this:

starting mklauncher... done
starting configserver... done
starting linuxcnc... LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX'
Machine configuration file is 'ox.ini'
Starting LinuxCNC...
done
rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::4686:rt INFO:  Picked default flavor 'rt-preempt' automatically
Found file(REL): ./ox.py
1:rtapi_app:4686:user hal_call_usrfunct(newinst,--  "num_pwmgens=1 num_stepgens=4") failed: -1 - Operation not permitted
Traceback (most recent call last):
File "./ox.py", line 18, in <module>
    motion.setup_motion()
File "/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX/fdm_local/config/motion.py", line 18, in setup_motion
    c.find('HOSTMOT2', 'CONFIG'))
File "hal/cython/machinekit/rtapi.pyx", line 272, in machinekit.rtapi.RTAPIcommand.newinst
RuntimeError: rtapi_newinst '('hm2_soc_ol', '"hm2-socfpga0 already_programmed=1"', '-- ', '"num_pwmgens=1 num_stepgens=4"')' failed: Operation not permitted
Shutting down and cleaning up LinuxCNC...
LinuxCNC terminated with an error.  You can find more information in the log:
    /home/machinekit/linuxcnc_debug.txt
and
    /home/machinekit/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
stopping mklauncher... done
stopping configserver... done

[cerna]

@the-snowwhite,

are python based hal configs supposed to work ?

I am trying to get the Python based Machinekit-HAL application working and so far having a problem:

./run.py
stopping realtime... done
cleaning up leftover session... done
starting realtime...rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::20528:rt INFO:  Picked default flavor 'posix' automatically
done
loading main.py... done
starting mklauncher... INFO:mklauncher:Remote communication is deactivated, configserver will use the loopback interfaces
INFO:mklauncher:set REMOTE in /etc/machinekit/machinekit.ini to 1 to enable remote communication
ERROR:dbus.connection:Unable to set arguments (0, 0, dbus.UInt32(0), 'Machinekit Launcher on mars.local', '_machinekit._tcp', '', '', dbus.UInt16(46869), ['dsn=tcp://127.0.0.1:46869', 'uuid=39b7d24d-a7a3-486e-947e-be1db9a3b8a7', 'instance=12456472-10b1-11eb-83a3-0c5415b56747', 'service=launcher']) according to signature 'iiussssqaay': <class 'TypeError'>: an integer is required (got type str)
ERROR:mklauncher:cannot register DNS servicean integer is required (got type str)
stopping realtime... stopping realtime... halcmd: cant connect to rtapi_app: -1 (uri= uuid=39b7d24d-a7a3-486e-947e-be1db9a3b8a7): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate /var/log/hal.log
halcmd: the msgd:0 logger demon is not running - please investigate /var/log/hal.log
E: 20-10-17 21:43:52 [20583]dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:284
done

Based on the python-hal-seed (BTW, why these useful tutorials are not in the main Machinekit repository is beyond me, I discovered it just yesterday).

Can you confirm that you are seeing the same problem? Or is your problem different?

Looking back, you have probably different problem...

[the-snowwhite]

Oh this is a normal problem you just have to:

set REMOTE in /etc/machinekit/machinekit.ini to 1

with nano or some other text editor.

[cerna]

@the-snowwhite,

Oh this is a normal problem you just have to:

Yes, but the real problem is actually hidden in:

starting mklauncher... ERROR:dbus.connection:Unable to set arguments (-1, 0, dbus.UInt32(0), 'Machinekit Launcher on mars.local', '_machinekit._tcp', '', '', dbus.UInt16(34681), ['dsn=tcp://mars.local:34681', 'uuid=39b7d24d-a7a3-486e-947e-be1db9a3b8a7', 'instance=e5e6f16a-1133-11eb-83ac-0c5415b56747', 'service=launcher']) according to signature 'iiussssqaay': <class 'TypeError'>: an integer is required (got type str)
ERROR:mklauncher:cannot register DNS servicean integer is required (got type str)

Which comes from file lib/python/machinekit/service.py. I have tried this file outside Machinekit and yes, there is some (type) problem stemming from the Python 2 -> Python 3 port and how the action is requested from Avahi by DBus. I have been able to create the announcement by mucking the code little bit, but unfortunately I will have to study the DBus and Avahi more.

Have no idea if @zultron or @rene-dev looked at this portion of code in their Python3 marathon.

[rene-dev]

I only ported hal, and mentioned serveral times that the UIs will be broken after this.
I will happily look into the issue, but could not figure out how to run the repo in place, with non-packaged MK HAL

[cerna]

I only ported hal, and mentioned serveral times that the UIs will be broken after this.

Sorry for pinging you then. This issue is on the line between HAL, RTAPI and UI, so I wasn't sure.

This problem is caused by the string encoding changes in Python3 and can be rectified by few .encode('utf-8') - of course the question is if the current implementation is still good or it should be redone some other way. If Python code was the only part using zeroconf, it would be best to use the python3-zeroconf project and ditch the dependency on DBus but alas that is not true.

(BTW, I don't want to make you feel obliged in any way.)

[the-snowwhite]

@cerna
Funny I get some different error messages just to be sure I set remote back to 0 in machinekit.ini and then ran run.py
from this configuration
on my freshly started de0_nano_soc running:
The above mentioned recompiled commented out machinekit-hal debs and python patched linuxcnc script.

machinekit@mksocfpga-ob-ox:~/Hm2-soc_FDM/Cramps/PY/OX$ ./run.py
starting mklauncher... done
starting configserver... INFO:mklauncher:Remote communication is deactivated, configserver will use the loopback interfaces
INFO:mklauncher:set REMOTE in /etc/machinekit/machinekit.ini to 1 to enable remote communication
done
starting linuxcnc... LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX'
Machine configuration file is 'ox.ini'
Remote communication is deactivated, configserver will use the loopback interfaces
set REMOTE in /etc/machinekit/machinekit.ini to 1 to enable remote communication
Starting LinuxCNC...
done
rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::2779:rt INFO:  Picked default flavor 'rt-preempt' automatically
Found file(REL): ./ox.py
1:rtapi_app:2779:user hal_call_usrfunct(newinst,--  "num_pwmgens=1 num_stepgens=4") failed: -1 - Operation not permitted
Traceback (most recent call last):
File "./ox.py", line 18, in <module>
    motion.setup_motion()
File "/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX/fdm_local/config/motion.py", line 18, in setup_motion
    c.find('HOSTMOT2', 'CONFIG'))
File "hal/cython/machinekit/rtapi.pyx", line 272, in machinekit.rtapi.RTAPIcommand.newinst
RuntimeError: rtapi_newinst '('hm2_soc_ol', '"hm2-socfpga0 already_programmed=1"', '-- ', '"num_pwmgens=1 num_stepgens=4"')' failed: Operation not permitted
Shutting down and cleaning up LinuxCNC...
Traceback (most recent call last):
File "/usr/bin/axis-remote", line 84, in <module>
    t = tkinter.Tk(); t.wm_withdraw()
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1828, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"
application-specific initialization failed: unknown color name "BACKGROUND"
LinuxCNC terminated with an error.  You can find more information in the log:
    /home/machinekit/linuxcnc_debug.txt
and
    /home/machinekit/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
stopping mklauncher... done
stopping configserver... done

same run with remote=1:

machinekit@mksocfpga-ob-ox:~/Hm2-soc_FDM/Cramps/PY/OX$ ./run.py
starting mklauncher... done
starting configserver... done
starting linuxcnc... LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX'
Machine configuration file is 'ox.ini'
Starting LinuxCNC...
done
rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::3050:rt INFO:  Picked default flavor 'rt-preempt' automatically
Found file(REL): ./ox.py
1:rtapi_app:3050:user hal_call_usrfunct(newinst,--  "num_pwmgens=1 num_stepgens=4") failed: -1 - Operation not permitted
Traceback (most recent call last):
File "./ox.py", line 18, in <module>
    motion.setup_motion()
File "/home/machinekit/Hm2-soc_FDM/Cramps/PY/OX/fdm_local/config/motion.py", line 18, in setup_motion
    c.find('HOSTMOT2', 'CONFIG'))
File "hal/cython/machinekit/rtapi.pyx", line 272, in machinekit.rtapi.RTAPIcommand.newinst
RuntimeError: rtapi_newinst '('hm2_soc_ol', '"hm2-socfpga0 already_programmed=1"', '-- ', '"num_pwmgens=1 num_stepgens=4"')' failed: Operation not permitted
Shutting down and cleaning up LinuxCNC...
Traceback (most recent call last):
File "/usr/bin/axis-remote", line 84, in <module>
    t = tkinter.Tk(); t.wm_withdraw()
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1828, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: unknown color name "BACKGROUND"
application-specific initialization failed: unknown color name "BACKGROUND"
LinuxCNC terminated with an error.  You can find more information in the log:
    /home/machinekit/linuxcnc_debug.txt
and
    /home/machinekit/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal
stopping mklauncher... done
stopping configserver... done

[the-snowwhite]

@cerna
can you confirm that you can run the anddemo from here: ?

machinekit@mksocfpga-ob-ox:~$ git clone https://github.com/qtquickvcp/anddemo.git
machinekit@mksocfpga-ob-ox:~$ cd anddemo
machinekit@mksocfpga-ob-ox:~/anddemo$ ./run.py
starting realtime...rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 -- 
debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::2023:rt INFO:  Picked default flavor 'rt-preempt' automatically
done
loading anddemo.py... done
starting mklauncher... done
starting configserver... done
^Cstopping mklauncher... done
stopping configserver... done
stopping realtime... done

I can get it to run just fine with machinekitclient

[the-snowwhite]

A test run with a similar hal based mklauncher config

machinekit@mksocfpga-ob-ox:~$ xrdb -load /dev/null
machinekit@mksocfpga-ob-ox:~$ cd ~/Hm2-soc_FDM/Cramps/HAL/OX
machinekit@mksocfpga-ob-ox:~/Hm2-soc_FDM/Cramps/HAL/OX$ ./run.py
starting mklauncher... done
starting configserver... done
starting linuxcnc... LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/machinekit/Hm2-soc_FDM/Cramps/HAL/OX'
Machine configuration file is 'ox.ini'
done
Starting LinuxCNC...
rtapi_msgd command:  /usr/libexec/machinekit/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --debug=1 --halsize=524288
rtapi_app command:  /usr/libexec/machinekit/rtapi_app --instance=0 --debug=1
3::1828:rt INFO:  Picked default flavor 'rt-preempt' automatically
Found file(REL): ./ob-ox_py.hal
emcTrajSetJoints(3) returned 0
emcTrajSetSpindles(1) returned 0
emcTrajSetAxes(3, 7)
emcTrajSetUnits(1.0000, 1.0000)
emcTrajSetVelocity(0.0000, 20.0000) returned 0
emcTrajSetMaxVelocity(200.0000) returned 0
emcTrajSetAcceleration(999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.0000) returned 0
emcTrajSetMaxAcceleration(999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.0000)
emcTrajSetHome(0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000) returned 0
emcJointSetType(0, 1)
emcJointSetUnits(0, 1.0000)
emcJointSetBacklash(0, 0.0600) returned 0
emcJointSetMinPositionLimit(0, -0.5000) returned 0
emcJointSetMaxPositionLimit(0, 320.0000) returned 0
emcJointSetFerror(0, 800.0000) returned 0
emcJointSetMinFerror(0, 200.0000) returned 0
emcJointSetHomingParams(0, 0.0000, 0.0000, -1.0000, -10.0000, 1.0000, 0, 1, 0, 1, 0) returned 0
emcJointSetMaxVelocity(0, 50.0000) returned 0
emcJointSetMaxAcceleration(0, 80.0000) returned 0
emcJointActivate(0) returned 0
emcJointSetType(1, 1)
emcJointSetUnits(1, 1.0000)
emcJointSetBacklash(1, 0.0800) returned 0
emcJointSetMinPositionLimit(1, -1.0000) returned 0
emcJointSetMaxPositionLimit(1, 500.1000) returned 0
emcJointSetFerror(1, 800.0000) returned 0
emcJointSetMinFerror(1, 200.0000) returned 0
emcJointSetHomingParams(1, 0.0000, 0.0000, -1.0000, -20.0000, 1.0000, 0, 1, 0, 1, 0) returned 0
emcJointSetMaxVelocity(1, 50.0000) returned 0
emcJointSetMaxAcceleration(1, 80.0000) returned 0
emcJointActivate(1) returned 0
emcJointSetType(2, 1)
emcJointSetUnits(2, 1.0000)
emcJointSetBacklash(2, 0.0200) returned 0
emcJointSetMinPositionLimit(2, -40.2000) returned 0
emcJointSetMaxPositionLimit(2, 0.2000) returned 0
emcJointSetFerror(2, 800.0000) returned 0
emcJointSetMinFerror(2, 200.0000) returned 0
emcJointSetHomingParams(2, 0.0000, 0.2000, -1.0000, 8.0000, -1.0000, 0, 1, 0, 0, 0) returned 0
emcJointSetMaxVelocity(2, 10.0000) returned 0
emcJointSetMaxAcceleration(2, 20.0000) returned 0
emcJointActivate(2) returned 0
emcAxisSetMinPositionLimit(0, -0.5000) returned 0
emcAxisSetMaxPositionLimit(0, 320.0000) returned 0
emcAxisSetMaxVelocity(0, 50.0000) returned 0
emcAxisSetMaxAcceleration(0, 80.0000) returned 0
emcAxisSetLockingJoint(0, -1) returned 0
emcAxisSetMinPositionLimit(1, -1.0000) returned 0
emcAxisSetMaxPositionLimit(1, 500.1000) returned 0
emcAxisSetMaxVelocity(1, 50.0000) returned 0
emcAxisSetMaxAcceleration(1, 90.0000) returned 0
emcAxisSetLockingJoint(1, -1) returned 0
emcAxisSetMinPositionLimit(2, -40.0000) returned 0
emcAxisSetMaxPositionLimit(2, 0.2000) returned 0
emcAxisSetMaxVelocity(2, 10.0000) returned 0
emcAxisSetMaxAcceleration(2, 20.0000) returned 0
emcAxisSetLockingJoint(2, -1) returned 0
hm2: loading Mesa HostMot2 driver version 0.15

hm2_soc_ol: loading Mesa AnyIO HostMot2 socfpga overlay driver version 0.9

hm2/hm2_5i25.0: 72 I/O Pins used:

hm2/hm2_5i25.0:     IO Pin 000 (GPIO0.P0-01): StepGen #0, pin Step (Output)

hm2/hm2_5i25.0:     IO Pin 001 (GPIO0.P0-02): StepGen #0, pin Direction (Output)

hm2/hm2_5i25.0:     IO Pin 002 (GPIO0.P0-03): StepGen #1, pin Step (Output)

hm2/hm2_5i25.0:     IO Pin 003 (GPIO0.P0-04): StepGen #1, pin Direction (Output)

hm2/hm2_5i25.0:     IO Pin 004 (GPIO0.P0-05): StepGen #2, pin Step (Output)

hm2/hm2_5i25.0:     IO Pin 005 (GPIO0.P0-06): StepGen #2, pin Direction (Output)

hm2/hm2_5i25.0:     IO Pin 006 (GPIO0.P0-07): StepGen #3, pin Step (Output)

hm2/hm2_5i25.0:     IO Pin 007 (GPIO0.P0-08): StepGen #3, pin Direction (Output)

hm2/hm2_5i25.0:     IO Pin 008 (GPIO0.P0-09): IOPort

hm2/hm2_5i25.0:     IO Pin 009 (GPIO0.P0-10): IOPort

hm2/hm2_5i25.0:     IO Pin 010 (GPIO0.P0-11): IOPort

hm2/hm2_5i25.0:     IO Pin 011 (GPIO0.P0-12): IOPort

hm2/hm2_5i25.0:     IO Pin 012 (GPIO0.P0-13): IOPort

hm2/hm2_5i25.0:     IO Pin 013 (GPIO0.P0-14): IOPort

hm2/hm2_5i25.0:     IO Pin 014 (GPIO0.P0-15): IOPort

hm2/hm2_5i25.0:     IO Pin 015 (GPIO0.P0-16): IOPort

hm2/hm2_5i25.0:     IO Pin 016 (GPIO0.P0-17): IOPort

hm2/hm2_5i25.0:     IO Pin 017 (GPIO0.P0-18): IOPort

hm2/hm2_5i25.0:     IO Pin 018 (GPIO0.P0-19): PWMGen #0, pin Out0 (PWM or Up) (Output)

hm2/hm2_5i25.0:     IO Pin 019 (GPIO0.P0-20): IOPort

hm2/hm2_5i25.0:     IO Pin 020 (GPIO0.P0-21): IOPort

hm2/hm2_5i25.0:     IO Pin 021 (GPIO0.P0-22): IOPort

hm2/hm2_5i25.0:     IO Pin 022 (GPIO0.P0-23): IOPort

hm2/hm2_5i25.0:     IO Pin 023 (GPIO0.P0-24): IOPort

/usr/lib/python2.7/dist-packages/pyftpdlib/authorizers.py:244: RuntimeWarning: write permissions assigned to anonymous user.
RuntimeWarning)
Process Process-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/process.py", line 267, in _bootstrap
    self.run()
File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
File "/usr/bin/mkwrapper", line 322, in run
    import preview  # must be imported in new process to work properly
ImportError: No module named preview
task: main loop took 5.009068 seconds
task: main loop took 5.015048 seconds
task: main loop took 5.010377 seconds
task: main loop took 5.008468 seconds
task: main loop took 5.009266 seconds

I don't know how to interpret the:

import preview # must be imported in new process to work properly message
However this config has no qtquick gui elements configured as of yet.

[cerna]

@the-snowwhite,

can you confirm that you can run the anddemo from here: ?

With applied patch from #325 on Debian Buster on amd64 with python3 --version Python 3.7.3 and started with python3 run.py I can get it running. Without this patch I cannot.

[the-snowwhite]

I tested your patch via hand editing:

sudo nano -c /usr/lib/python2.7/dist-packages/machinekit/service.py

anddemo works fine here both with and without the patch... that is python2

machinekit@mksocfpga-ob-ox:~/anddemo$ python --version
Python 2.7.16

Python3 result both with and without patch is:

machinekit@mksocfpga-ob-ox:~/anddemo$ python3 run.py
Traceback (most recent call last):
  File "run.py", line 8, in <module>
    from machinekit import launcher
ModuleNotFoundError: No module named 'machinekit'

However the platform difference may be more than amd64 vs armhf/arm64
To get something quickly up and running I'm got stuck on the 0.4.20868 (Python2) combo required for the emc app.
I guess it's time to update to mainline arm mk-hal and continue from there ... ?

[the-snowwhite]

@cerna
With applied patch from #325 on Debian Buster on amd64 with python3 --version Python 3.7.3 and started with python3 run.py I can get it running. Without this patch I cannot.

Ditto (I installed the newest cloudsmith packages on my soc).
I'll merge your patch ... ok ?

[the-snowwhite]

Well on second inspection I'll wait as there seems to be a test error:
Test RIP version on Debian 9 amd64

[cerna]

@the-snowwhite,

Well on second inspection I'll wait as there seems to be a test error:

That error is unfortunately old news, I am tracking it here. (Usually all it needs is to restart the test, it is error in monotonic scheduling on systems, where elevated priorities are not possible. More in that thread.) Before I force pushed the branch again (Travis created two jobs in Github environment and only ran one, so the PR would keep hanging as all Github Actions/Travis-CI/Drone Cloud testings need to be green), it ran all OK.

So, it should be fine. Merge on green.

I would not put my head on the block for this, bur my theory is such:

With the Python3 marathon, the cython bindings were changed and I would say that it become incompatible with Python2. So the newer version of Machinekit-HAL cannot be used with Python2, respective it starts failing as some files (modules) are Python2 compatible and some not.

Then @machinekoder authored commits which @zultron included in PR #315 adding f-Strings into the code-base in the bindings. Problem is - f-Strings are Python constructs added in version 3.6 as noted in PEP 498 and Debian Stretch is using Python version 3.5. If you are using Stretch, then you are probably boned. (It flew through the tests, given that there are probably no tests for bindings and Python is interpreted language and not compiled one.) Not sure what to do about it, to be frank.

[the-snowwhite]

What shall I say:
Well then reality kicked in while testing my hal config:

machinekit@mksocfpga-ob-ox:~/Hm2-soc_FDM/Cramps/HAL/OX$ python3 run.py
starting mklauncher... done
starting configserver... done
starting linuxcnc... /bin/sh: 1: linuxcnc: not found
stopping mklauncher... done
stopping configserver... done

I noticed there are online arm packages for the emc application however they are about 2 month old now so I guess they are tied to the latest(old) python2 based mk-hal commit (0.4.20868 ).

Is there yet any python3 linuxcnc version that can be emc app (deb) packaged for mklauncer use ?

[cerna]

Is there yet any python3 linuxcnc version that can be emc app (deb) packaged for mklauncer use ?

No, there is the LinuxCNC/linuxcnc#943 draft pull request which can be made to work under Python3 (but I have no idea about mklauncher - it probably can all be made to work, it will just require effort).

I noticed there are online arm packages for the emc application however they are about 2 month old now so I guess they are tied to the latest(old) python2 based mk-hal commit (0.4.20868 ).

These packages will take any machinekit-hal with higher version than 0.4 and will not work on the current Python3 Machinekit-HAL. Back when I built them I didn't realize that you need to limit the versions of Machinekit-HAL.

(I can try to create draft merge of this in special pull request.)

I will try to rebuild EMCApplication packages later today with limit to the Python2 version of Machinekit-HAL. (Plus build the special version of Machinekit-HAL for Python2 armhf architecture.)

[the-snowwhite]

Problem with the python2 version is that it also requires work to get mklauncher functionality I cannot see how to get this to fly without setting up a separate mk-hal python2 branch/fork.
Also python2 Axis Gui is really annoying'ls small on my main development screen and the only way I'm able to scale it is to use plama's built in magnifier/zoom function ...!

---

So either which way (or both) there is work to do to restore full MachinekitClient Cnc and linuxcnc python2/3 based hal functionality.

[rene-dev]

the scaling problem has been fixed a long time ago in linuxcnc, I cant remember how or when.
there is no way any binaries can work with python2 and 3.
yes, Stretch is using Python version 3.5, which causes all sorts of problems.
Im guessing in linuxcnc we just drop support for it.

[the-snowwhite]

the scaling problem has been fixed a long time ago in linuxcnc, I cant remember how or when.

I wonder why this "fix" doesn't reflect in the current emcapplication on my kdeneon 20.04 workstation with a 4k 52" monitor ?

I's not that its tiny I just want to make it a little bit larger and found no way to do that on a ssh -XY setup.

[the-snowwhite]

@cerna machinekit/EMCApplication#7 (comment)

I can confirm that the new packages work on the DE0_Nano_Soc (armhf) with:

sudo apt install machinekit-hal=0.4.20868-1.gitc2e248500~buster machinekit-hal-rt-preempt=0.4.20868-1.gitc2e248500~buster emcapplication

This issue can be closed

[cerna]

Thank you for testing it, @the-snowwhite!