To be talking about support on Bullseye when it's at the end of its useful life before Linuxcnc has any public method to install on that platform other than from compiling the source belies belief. Yes I know there is now a buildbot for it, but existence seems to be a closely guarded secret no user could hope to find it. The issues with Gmoccappy have been known for several months and the fact it's not worked on Bullseye as well as Bookworm has been reported on the forum. Yet only now is there some interest in resolving problems and the matter becomes urgent. Come on guys, this has been coming for a long time and We've been in Bookworm for over a year.
Some breakages in GUI 's has only been a recent development. I'm not sure what has changed but for the last few months Linuxcnc will not run on the default Bookworm Gnome/Wayland environment. Installing or selecting a Xorg based distro like XFCE does fix most issues, but it does not solve Gmoccappy's problems. The other issue which is going to raise its head is that the Debian patches to linux-image-rt (the preempt_rt kernel) from Kernel 5.10 through to 6.1 (eg Bullseye and above) are introducing network latency that is not evident with compiled PREEMPT_RT kernels from the upstream kernel.org. Whilst Intel based NIC's can generally handle this additional latency, the Realtek NIC's (used in most small industrial PC's) Can't They generate an error finishing read on Mesa Ethernet devices which disables the connection to the Mesa card. So if you think GUI support is going to be a problem moving forward, that's likely to be the least of Linuxcnc's support worries. The Debian RT patches are here https://salsa.debian.org/kernel-team/linux/-/tree/master/debian/patches-rt The file called series contains the order patches are installed and some notes. Sadly, I don't know enough to do anything useful. The prime suspect to me is support for Lazy preemption which seems to have been added in Bullseye when comparing branches. If anyone knows their way around the Debian codebase, it would be interesting to see if removing these patches solved the issue. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 5 Jan 2023 at 03:39, Hans Unzner <hansunz...@gmail.com> wrote: > > > Am 04.01.23 um 17:19 schrieb Sebastian Kuzminsky: > > On 1/4/23 05:09, Hans Unzner wrote: > >> However, I have some annotations: > >> - You could mention that the tests need to be run as sudo (at least > >> for it only worked so) and need Python >= 3.8 > > > > Hmm, I run them as a regular user. Maybe you just installed > > docker.io, and you have to log out and log back in again for your > > user's membership in the `docker` group to register? > Yeah maybe that's the point. > > > > As for the python version, I run the tests on a bullseye host (python > > 3.9), I haven't tried running it anywhere else. > I tried on my Ubuntu 18 system which has Python 3.6 and 3.8. And it > worked only for 3.8. > > > > > >> - The stderr file only shows something like "+ su --pty -c 'linuxcnc > >> > /usr/share/doc/linuxcnc/examples/sample-configs/sim/gmoccapy/lathe_configs/lathe_C.ini' > > >> testrunner" > > > > Yeah, not much useful stuff there :-) > > > > But that makes me think, maybe the tests should copy out > > linuxcnc_{print,debug}.log at the end, just before tearing down the > > container... > > > > > >> - For the configs which show an error message as window (like the > >> gmoccapy config you attached) - is there another way to check if all > >> tests have passed except looking at all screenshots or stdout logs? > > > > If the `linuxcnc` launcher program doesn't exit, I don't know of any > > easy way to tell if it worked or not. > > > > You could imagine trying to OCR the screenshot image and see if it > > looks like an error popup... > > > > Or maybe you see if some GUI-specific HAL pins showed up, though I > > just checked the gmoccapy config and on that one the GUI's HAL pins > > showed up even though the screen just shows that error popup... > > > > I think it's going to be hard to detect the kind of stalling failures > > that don't cause linuxcnc to exit. I'm open to suggestions here. > > > > > >> And I wonder why you chose Bookworm over Bullseye. I think all the > >> Gmoccapy configs would pass on Bullseye. > > > > I don't have a great reason for doing this test on bookworm instead of > > bullseye, it was just the first one that came to mind. Rod and Steffen > > are right that bookworm will be the first Debian release to include > > linuxcnc packages from debian.org, so it's an important one to get > right. > > > > It's easy to switch this test to bullseye (or any other debian-based > > distro), by editing the FROM line in the Dockerfile and rebuilding the > > image. > > > > Ideally we'd run this test all the time, on every supported platform, > > just like we do our other tests. > We could compare the screenshot image with a screenshot we provide that > shows a proper window without error messages. Once all configs are > passing, we could use those screenshots as reference. > > > > I just tried one of the gmoccapy configs by hand on bullseye and it > > failed in the same way. > Hmm as far as I have been told the problem only appears on Bookworm. I > have never tested it on Bullseye by myself. But it seems that I have to. > > > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
