Re: [Emc-developers] Status of LinuxCNC in Debian

[Sebastian Kuzminsky]

On 3/22/24 04:12, andy pugh wrote:
> Is LinuxCNC currently in Debian? I know that we were due for removal from
> Testing, and since then I have heard no further updates from Debian about
> anything at all.

Looks like we're currently in bookworm (stable) and sid (unstable) but
not in testing:

<https://packages.debian.org/linuxcnc-uspace>


-- 
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Status of LinuxCNC in Debian

[Sebastian Kuzminsky]

On 3/22/24 07:04, andy pugh wrote:
> On Fri, 22 Mar 2024 at 12:56, Stuart Stevenson  wrote:
> 
>> I want to download the source from git. Is there a script of instructions
>> to get me there?
> 
> If you only want the code, and don't want to make pull requests etc, then
> just download this zip file:
> https://github.com/LinuxCNC/linuxcnc/archive/refs/heads/master.zip
> 
> Otherwise, see:
> https://linuxcnc.org/docs/stable/html/code/contributing-to-linuxcnc.html

This document is intended to describe how to download the source,
satisfy build dependencies, and configure and build it:

<http://linuxcnc.org/docs/2.9/html/code/building-linuxcnc.html>


-- 
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot is down

[Sebastian Kuzminsky]

On 1/6/24 17:27, Chris Morley wrote:

help please :)
Thanks.


Thanks for the bug report, the VM host crashed, fixed now.

--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first impressions

[Sebastian Kuzminsky]

On 12/27/23 13:38, Steffen Möller via Emc-developers wrote:



Gesendet: Mittwoch, 27. Dezember 2023 um 17:13 Uhr
Von: "andy pugh" 
An: "EMC developers" 
Cc: "Steffen Möller" 
Betreff: Re: [Emc-developers] RPi5 + Raspbian + LinuxCNC latency tests - first 
impressions

On Wed, 27 Dec 2023 at 15:20, Steffen Möller via Emc-developers
 wrote:


My RPi5 arrived over Xmas and I just fired it up, was offered to install 
LinuxCNC directly from what we offer in Debian, and then ran latency tests.  
Graphics (as in video but also the extra art from your X interface when 
ALT-tabbing through your applications) have the most effect on the latency. I/O 
from the SD does not seem to affect it too much.


The numbers you show are _awful_ though?

It doesn't look like the LinuxCNC installation has installed the
correct kernel. (I seem to recall that I had to do a fair bit of
fiddling to make it happen, it's a Pi thing)


Rebooted with
Linux version 6.1.0-rpi7-rpi-2712 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24)
but do not see any relevant change.


That's the wrong kernel: "PREEMPT" is not enough, you need "PREEMPT_RT" 
in the uname string.


This is usually the difficult part of getting systems with out-of-tree 
vendor-specific kernels to work well with LinuxCNC.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Buildbot Failing

[Sebastian Kuzminsky]

On 12/6/23 18:06, Phill Carter via Emc-developers wrote:

Buildbot is failing with the following:
fatal: Unable to create 
'/home/buildslave/emc2-buildbot/wheezy-rtai-i386-clang/wheezy-rtai-i386-clang/source/.git/packed-refs.lock':
 Read-only file system


Thanks for the bug report, this should be fixed now.

--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Buildbot Error

[Sebastian Kuzminsky]

On 11/5/23 18:02, Phill Carter via Emc-developers wrote:

It seems that Builder 4041.deb-buster-rtpreempt-amd64 has run out of disk space.


Thanks for the bug report.  Should be fixed now.

--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-users] LinuxCNC 2.9 is Released

[Sebastian Kuzminsky]

On 11/4/23 18:39, andy pugh wrote:

LinuxCNC 2.9.1 has been released


Wooo!!!

That's awesome, thanks :-)


--
Sebastian Kuzminsky



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-developers] Task/Motion startup race

[Sebastian Kuzminsky]

When the `linuxcnc` script launches linuxcnc it starts Task, then loads 
motmod (as one of the commands in the [HAL]HALFILE list).


I believe this is racey, leading to at least some of the intermittent 
failures on the buildbot.


Task does this at startup:

1. Runs `usrmotInit()` which connects to the emcmotStruct shm, including 
emcmotCommand and emcmotStatus.


2. Runs `usrmotWriteEmcmotCommand()` to copy the first initialization 
command into emcmotCommand, then polls emcmotStatus waiting for motmod 
to echo the first command's commandNum.


3. If the commandNum does not echo in emcmotStatus within a timeout, 
Task gives up on the command.


Motion/motmod does this at startup:

1. Runs `init_comm_buffers()` to connect to the emcmotStruct shm, 
including emcmotCommand and emcmotStatus.  Calls `memset()` on 
emcmotStruct to initialize it to all-bytes-zero.


2. Start polling emcmotCommand for new commands (this happens in a hal 
thread via the `motion-command-handler` function).


The race happens when Task does its 1 and 2, then Motion does *its* 1, 
discarding Task's first command.



I think the recent move of iocontrol into Task changed system timing and 
made this race more likely to bite.


Any thoughts?


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Linking problem?

[Sebastian Kuzminsky]

On 8/30/23 10:45, andy pugh wrote:

On Wed, 30 Aug 2023 at 15:06, andy pugh  wrote:


rtapi_app is compiled/linked via src/rtapi/Submakefile.


I am no less confused now. The compilation command is

c++ -std=gnu++17 -rdynamic -L/home/andypugh/linuxcnc-dev/lib
-Wl,-rpath,/home/andypugh/linuxcnc-dev/lib -ltirpc  -lgpiod -o
../bin/rtapi_app objects/rtapi/uspace_rtapi_app.o
objects/rtapi/uspace_rtapi_parport.o
objects/rtapi/uspace_rtapi_string.o objects/rtapi/rtapi_pci.o
-pthread -lrt -ludev  -ldl


I'm confused by this command line.

The "-o ../bin/rtapi_app" indicates that we're building rtapi_app from a 
bunch of object files and libraries.  Is it really rtapi_app that needs 
to be linked against libgpiod, isn't it the hal_gpiod driver?


If i'm misremembering how that stuff's supposed to work (which is very 
possible), the other possibility that comes to mind is the order of 
arguments on the linker command line.  Some linkers (but I think not 
all?) require that the "-lwhatever" libraries come *later* in the 
command line than the object files that require them.  When the linker 
comes to to a -l argument, it tries to satisfy any *currently unknown* 
symbols from the named library.




And there is a clear "-lgpiod" as a flag.  But once compiled:

andypugh@pi400:~/linuxcnc-dev/src$ ldd ../bin/rtapi_app
linux-vdso.so.1 (0x7f95)
libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x7f85)
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x7f63)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x7f5f)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x7f44)
/lib/ld-linux-aarch64.so.1 (0x7f913000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x7f3a)

Which doesn't really seem to match?



If none of rtapi_app's input files needed symbols from libgpiod, then 
the linker will not link rtapi_app against libgpiod.  See for example 
how the -ltirpc in the linker command line did not cause rtapi_app to be 
linked to libtirpc.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] spi on Bookworm

[Sebastian Kuzminsky]

On 8/29/23 14:11, Peter Wallace wrote:

On Tue, 29 Aug 2023, Sebastian Kuzminsky wrote:


On 8/29/23 13:02, Alan Condit wrote:


Have you had any luck getting spi devices to run on Debian 12 Bookworm?
I got spi-bcm2835 to load on boot but so far I havent been able to 
create 

any spi devices.
I did load spi-tools and api-config runs but wont create any spi devices 

for me.

Yes, SPI is working for me on RPi4 running Debian Bookworm and 
LinuxCNC (from debian.org).


I just `loadrt hm2_rpspi` (note, not the generic `hm2_spi`).


I think the issue Alan has is that the dev/spi0 device is not created 
and perhaps raspi-config is missing or does not work.


Yes, /dev/spi* is missing from Debian's Raspberry Pi image, and 
unfortunately the raspi-config tool won't help.


The /dev/spi device file is created by the Linux kernel SPI driver, 
based on the Device Tree Blob (dtb) loaded at boot time.  Debian's dtb 
does not enable the RPi SPI hardware, and I haven't been able to figure 
out how to make the correct change to it to enable the SPI.  Therefore 
on Debian there are no /dev/spi* devices, so hm2_spi and mesaflash won't 
work.


I believe the raspi-config tool relies on a non-standard kernel feature 
in the Raspberry Pi OS kernel which was never upstreamed to the mainline 
Linux kernel.  This feature is called "dynamic dtb overlays", and it 
lets the user modify the active dtb at runtime, to do things like enable 
SPI.  Because the debian kernel does not have the dynamic device tree 
overlay feature, the raspi-config tool cannot be used to enable SPI on 
debian.


The hm2_rpspi HAL driver does not use /dev/spi, instead it enables and 
talks to the SPI hardware directly, so it works even if the Linux kernel 
doesn't know about the SPI hardware.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] spi on Bookworm

[Sebastian Kuzminsky]

On 8/29/23 13:02, Alan Condit wrote:

Seb,

Have you had any luck getting spi devices to run on Debian 12 Bookworm?
I got spi-bcm2835 to load on boot but so far I haven’t been able to create any 
spi devices.
I did load spi-tools and api-config runs but won’t create any spi devices for 
me.


Yes, SPI is working for me on RPi4 running Debian Bookworm and LinuxCNC 
(from debian.org).


I just `loadrt hm2_rpspi` (note, not the generic `hm2_spi`).


--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Buildbot

[Sebastian Kuzminsky]

On 8/10/23 09:38, Marius wrote:
Just so I understand please. Did the RPi 4 code crash or are you using a 
RPi 4 to do some of the compilation?


The Pi is one of the workers in the buildbot, it checks out the linuxcnc 
source code, builds and tests it, and builds & uploads its Raspberry Pi 
OS Buster/armhf debs to our debian package archive.


The Pi crashes maybe once per month - the whole computer locks up so it 
has to be powercycled.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Buildbot

[Sebastian Kuzminsky]

On 8/10/23 02:31, Phill Carter via Emc-developers wrote:

Buildbot seems to be asleep.


Thanks for the bug report.  The Raspberry Pi 4 had crashed again and the 
buildbot was waiting for it, holding things up.  I rebooted it and now 
it's moving forward again.


--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-users] LinuxCNC build on BeagleBoneBlack

[Sebastian Kuzminsky]

On 8/4/23 14:09, gene heskett wrote:

On 8/4/23 14:14, marcus.bow...@visible.eclipse.co.uk wrote:


I have just managed to buy an 8Gb Pi 4 and had hoped to run LinuxCNC 
into my 7i96S for my small CNC lathe.
I would be disappointed if LinuxCNC on the Pi is not currently being 
supported.


Apparently not ATM, my rpi4 running buster has not received a uspace 
update, just the docs for about 90 days now. And my comments about it 
have been ignored.


The most recent buildbot build of LinuxCNC 2.9 for Raspberry Pi OS 
Buster armhf was about a week ago, both docs & binaries:


<http://buildbot.linuxcnc.org/dists/buster/2.9-rtpreempt/binary-armhf/?C=M;O=D>

I'm running LinuxCNC on a Raspberry Pi 4B (2 GB) using the normal 
debian.org Bookworm arm64 distro, including the Preempt-RT kernel and 
the linuxcnc-uspace deb from the debian.org package archive.  It works fine.



--
Sebastian Kuzminsky



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-developers] website HTML docs are behind

[Sebastian Kuzminsky]

On 7/15/23 21:03, Chris Morley wrote:

Anybody notice why? I saw some reported failures with arch?
Something about not being able to pull in updates? Is that the problem?


The Raspberry Pi 4 builder in the buildbot has been flaky lately and 
that's been holding up the build.  I keep resetting it when it crashes 
and the buildbot moves forward again.


Here's the current build queue:

<http://buildbot.linuxcnc.org/buildbot/builders/.checkin>


--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: POE Hat and dtoverlays in Debian 12

[Sebastian Kuzminsky]

On 7/13/23 13:53, Markus Falb wrote:

Because I could not find the overlays (maybe they are not shipped?) I compiled 
it myself
https://github.com/raspberrypi/linux/blob/1.20230405/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts


Most of the Raspberry Pi overlays are not in the mainline Linux kernel, 
they're only in the Raspberry Pi fork of the Linux kernel which you 
pointed to above.


Furthermore, I believe that the overlays in the Raspberry Pi kernel 
apply cleanly to the base device tree that ships with the Raspberry Pi 
kernel, but not to the base device tree in the mainline Linux kernel (or 
to the one in the Debian kernel).


Ubuntu is shipping the Raspberry Pi fork of the kernel (or something 
very close to it), including all their overlays.  Debian on the other 
hand ships a closer-to-mainline kernel which does not include the 
Raspberry Pi overlays (or a bunch of their kernel patches that make it 
easier to work with overlays at runtime).


This really limits the functionality of the Raspberry Pi running Debian.

I ran in to this problem when trying to enable SPI on the Raspberry Pi, 
which (on Raspberry Pi OS and Ubuntu) is done with a device tree overlay.



--
Sebastian Kuzminsky

Bug#1037221: [Emc-developers] Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Sebastian Kuzminsky]

On 6/8/23 02:01, Petter Reinholdtsen wrote:


Package: linuxcnc
Version: 2.9.0~pre1+git20230208.f1270d6ed7-1

Is the linuxcnc community prepared to support the linuxcnc edition
currently in Debian Bullseye for 3-4 years?  In other words, willing and
able to fix any security issues or other fatal problems with the package
in a timely maner?


I willing to put some effort into this.

The current version of LinuxCNC in Debian is a pre-release 
("2.9.0~pre1...").  Many new fixes have gone in to our 2.9 branch since 
that upstream tarball was made, and undoubtedly more patches will come 
over the 3-4 years that Bookworm will be active.


What is Debian's policy for how we are to fix problems with our package 
in the Debian stable release, specifically: when is it ok to update the 
upstream tarball to a newer 2.9 snapshot vs when must we backport 
specific bugfix commits and place them in debian/patches?



--
Sebastian Kuzminsky

Re: [Emc-developers] Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Sebastian Kuzminsky]

On 6/8/23 02:01, Petter Reinholdtsen wrote:


Package: linuxcnc
Version: 2.9.0~pre1+git20230208.f1270d6ed7-1

Is the linuxcnc community prepared to support the linuxcnc edition
currently in Debian Bullseye for 3-4 years?  In other words, willing and
able to fix any security issues or other fatal problems with the package
in a timely maner?


I willing to put some effort into this.

The current version of LinuxCNC in Debian is a pre-release 
("2.9.0~pre1...").  Many new fixes have gone in to our 2.9 branch since 
that upstream tarball was made, and undoubtedly more patches will come 
over the 3-4 years that Bookworm will be active.


What is Debian's policy for how we are to fix problems with our package 
in the Debian stable release, specifically: when is it ok to update the 
upstream tarball to a newer 2.9 snapshot vs when must we backport 
specific bugfix commits and place them in debian/patches?



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bookworm

[Sebastian Kuzminsky]

On 6/7/23 14:29, Alec Ari via Emc-developers wrote:

2.9 branch is still missing any recent Clang fixes, just throwing that out 
there as a reminder.

https://github.com/LinuxCNC/linuxcnc/pull/2214/commits


Too bad that was merged into master - our published policy is to merge 
fixes into the oldest active stable branch.


<http://linuxcnc.org/docs/2.9/html/code/contributing-to-linuxcnc.html#_use_of_git_in_the_linuxcnc_project>

I'll backport it to 2.9.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bookworm

[Sebastian Kuzminsky]

On 6/7/23 06:48, andy pugh wrote:

Is it a problem that we haven't actually released 2.9 and that it is
due to be in Bookworm, which is due to be released very soon indeed?


IMO it would have been better if we released 2.9.0 and got it into 
Bookworm, just because the version number 
(`2.9.0~pre1+git20230208.f1270d6ed7`) looks a bit goofy and 
unprofessional.  Even just `2.9.0~pre2` would have been preferable.


Based on my reading of 
<https://release.debian.org/testing/freeze_policy.html>, now that 
Bookworm is in "Full Freeze" we should not upload a new upstream 
release, so i think we're stuck with the big goofy version.


Any bugs we want to fix in the debian.org package will need to be fixed 
in that version of our source code - i assume we'll fix it in the "real" 
2.9 and cherrypick/backport the fix to a "bookworm" branch in our gbp 
repo (<https://github.com/LinuxCNC/linuxcnc-gbp).


I think that's ok.  ¯\_(ツ)_/¯


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 release discussion

[Sebastian Kuzminsky]

On 5/1/23 17:22, gene heskett wrote:

On 5/1/23 18:43, andy pugh wrote:

On Mon, 1 May 2023 at 16:55, gene heskett  wrote:


I have hoped that the stuck in homing problem would make the list, but
it did not.



We tried to reproduce it for about 20 minutes, on various configurations,
but nothing unexpected happened.

It does sound fairly serious, but if we can't make it happen, we can't
prove that we have fixed it.

I just put the whole config dir at the Go704 link in my sig. Let me know 
if you can't pull the tarball.


I downloaded the tarball and glanced at it.  Did not see anything 
obviously wrong.


Uploaded it to the github issue here: 
<https://github.com/LinuxCNC/linuxcnc/issues/2388>



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 release discussion

[Sebastian Kuzminsky]

On 5/1/23 09:52, gene heskett wrote:
I have hoped that the stuck in homing problem would make the list, but 
it did not. Its very disconcerting to have an axis fail, tripping off 
F2, which on my machines kills all machine power, so home are all marked 
volatile, but re-enable F2 and have the next axis in the homing sequence 
take off uncommanded and cannot be stopped Tripping of F2 should kill 
ALL homing motions until commanded again.


I tried to reproduce this in sim and could not see any failure - it all 
worked exactly how I expected it to.  Can you attach your complete 
config (INI and HAL files, plus anything else relevant) to the Github 
ticket?



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Sunday plans

[Sebastian Kuzminsky]

It worked well on Saturday, so let's do it again on Sunday: Meet in the Double 
Tree lobby at 8:30 for breakfast, then Tormach at 10 for hacking.

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Zoom!

[Sebastian Kuzminsky]

Spectate on the hackfest here: 
https://us02web.zoom.us/j/8498381080?pwd=REEzTW4xMngvQWk3SlhqQUdmWFNUdz09

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Tormach meeting Saturday

[Sebastian Kuzminsky]

A bunch of us are meeting in the lobby of the Doubletree tomorrow (Saturday) at 
8:30 to find breakfast somewhere.  We're planning to be at Tormach around 10.  
Join us or be talked about!

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters

[Sebastian Kuzminsky]

On 4/7/23 09:21, Jon Elson wrote:

Does anyone have agenda items for the meeting?


The responsible thing would probably be to talk a bit about how to get 
2.9 released and out the door...


But the fun thing would probably be to geek out over neat hardware...


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters

[Sebastian Kuzminsky]

On 4/12/23 08:20, andy pugh wrote:

On Fri, 7 Apr 2023 at 16:24, Jon Elson  wrote:


Does anyone have agenda items for the meeting?



There is an offer of a Remora presentation:

https://forum.linuxcnc.org/29-forum-announcements/48753-april-2023-linuxcnc-meeting-at-tormach-headquarters#267650


I'd love to see Remora in action and get a tour of how it's implemented.

--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Documentation question

[Sebastian Kuzminsky]

On 4/7/23 16:49, andy pugh wrote:

I have made some changes to hm2_pktuart and I feel the urge to document
them.

Currently this feature is (barely) documented in groff/troff in the files:
docs/man/man3/hm2_pktuart_read.3hm2
docs/man/man3/hm2_pktuart_send.3hm2
docs/man/man3/hm2_pktuart_setup.3hm2

However there are now severa more functions, and they really would be
better documented in a single file that explained how to use them (as this
is still fairly fresh in my mind)

Preferably a file in asciidoc.

Is there anywhere that I can put an adoc file that will automatically get
processed and added to the man3 section?


docs/src/man/ should do it.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] messed-up merge of master into 2.9, branches locked

[Sebastian Kuzminsky]

Recently master was merged into 2.9.  The merge commit was later 
reverted, so the *contents* of 2.9 are correct (I think), though the 
history remains.


I have opened https://github.com/LinuxCNC/linuxcnc/issues/2420 to 
discuss and track the issue, or we can talk about it here on the mailing 
list.


I've locked master and 2.* while we address the problem.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] HAL shared memory and the mis-use of hal_malloc

[Sebastian Kuzminsky]

On March 26, 2023 5:26:29 PM MDT, andy pugh  wrote:
>It's a tempting thing to do, it keeps the data structures neat, and means
>that you don't have to free on exit, as the whole HAL memory is freed on
>exit.

Non-hal memory (eg from malloc) is also freed when the process exits (it's more 
complicated for kernel mode realtime components, maybe that's what you meant).


>Is using hal_malloc for all your component data bad? Or should we accept it
>for the convenience?

I'd prefer if we used hal memory for things that need to be in hal, and used 
non-hal memory for everything else.

But I don't intend to clean up all the violations of this preference, so my 
opinion doesn't count for much.


-- 
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: Is an ARM computer a good choice? Which one?

[Sebastian Kuzminsky]

On 3/21/23 12:11, Andrew M.A. Cater wrote:

On Tue, Mar 21, 2023 at 11:59:08AM +0100, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 08:33:26AM +, Andrew M.A. Cater wrote:


If you can get a Raspberry Pi 4 - it woill work as a small desktop,
more or less silently. To fit extra disks you'll need an add on case
- something like the Argon which will take NVME. There are
bottlenecks. It's still essentially a phone SOC. It's not *free*
because blobs and if you want peripherals, you more or less are tied
to running Raspberry Pi OS.


What ties me into Raspberry Pi OS for peripherals? Non-free drivers
and/or firmware that cannot get into Debian, or just "it is not
packaged for Debian because nobody did the work but could be"?



The Raspberry Pi packaged kernel and dtb and the Pi "hat" ecosystem.

The peripheral drivers thing is particularly annoying because the dtb's
are not that much - I have a GPS hat for which there is no obvious
driver except in Raspberry Pi forked kernel, for example.


I'm in a similar situation: I'm using SPI to talk to a peripheral, and 
the Raspberry Pi's SPI master is not available in Debian because of 
missing DTB support (the kernel driver is there but the hardware is 
disabled by the stock kernel.org DTB).


Both Raspberry Pi OS and Ubuntu ship updated (optional) DTBs that enable 
the SPI port.



--
Sebastian Kuzminsky

Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters

[Sebastian Kuzminsky]

On 3/20/23 11:21, Jon Elson wrote:

Will people who plan to attend (weekend of April 22-23) please confirm?


I'm going to attend.

Looking forward to seeing you all!  :-)


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] still stuck from the pid switch. And bug report

[Sebastian Kuzminsky]

On 3/10/23 10:33, gene heskett wrote:

On 3/10/23 08:04, andy pugh wrote:

On Tue, 7 Mar 2023 at 05:45, gene heskett  wrote:

That to me needs fixed, if F2 has been cycled by the error, all homing

operations should be canceled until restarting from scratch by another
click on the home_all button.



Can you create an issue on the bug tracker for that one?


address? I don't have it book-marked.


https://github.com/linuxcnc/linuxcnc/issues

Click "New issue", big green button in the upper right.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] failing sample configs in 2.9: remap, gmoccapy, qtvcp, and more!

[Sebastian Kuzminsky]

On 3/8/23 13:23, Hans Unzner wrote:


PS: In the README.md, I guess there is a linebreak intended between 
`docker pull debian:bookworm` and ` docker build ...`. It's displayed on 
GitHub in one line...


Thanks, fixed.

--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] failing sample configs in 2.9: remap, gmoccapy, qtvcp, and more!

[Sebastian Kuzminsky]

On 3/8/23 12:21, Hans Unzner 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?


As for the python version, I run the tests on a bullseye host (python 
3.9), I haven't tried running it anywhere else.



Hmm still need to run it as sudo...

Another question: is there a way to update only the linuxcnc-part 
without a complete rebuild of the docker image? And also it would be 
nice to be able to run the tests for a local version of linuxcnc (one 
that isn't already in bookworm).


There's not a great way to update linuxcnc.deb in an existing image 
unfortunately.  Because the config-test program starts a new container 
for each config it tests you'd have to install the deb once for each 
config you're testing...


You could potentially try to strip off the top layer of the docker image 
(where it installs linuxcnc.deb), and reuse the lower layers (where it 
installs xvfb and x11vnc, and creates the testrunner user), but i'm not 
sure it would be worth the hassle, since almost all the build time is in 
installing the linuxcnc deb and all its dependencies.


There's an awkward manual way to build an image with a local deb.  In 
the Dockerfile, comment out the RUN statement where it installs 
linuxcnc.deb from the buildbot, and uncomment the COPY and RUN 
statements after that where it grabs and installs a local linuxcnc deb 
(it looks for the local deb in the directory you run `docker build` from).



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] spindle speed output not working?

[Sebastian Kuzminsky]

I can imagine halcmd emitting a warning if you call loadrt with an argument 
that's just "=", but that feels a bit over-specific for this particular user's 
syntax error.

-- 
Sebastian Kuzminsky


On March 5, 2023 4:54:15 PM MST, andy pugh  wrote:
>On Sun, 5 Mar 2023 at 23:45, Jon Elson  wrote:
>
>> loadrt hal_ppmc extradac = 0x00
>>
>> this caused a parameter extradac not found error from hal.
>>
>> The correct syntax that works is :
>>
>> loadrt hal_ppmc extradac=0x00  (note - no spaces between
>> extradac and the 0x00).  Is this a known issue in loadrt
>> parameters, and would it be easy to fix?
>
>I don't think that it is an easy fix, as my understanding is that this
>is built-in Linux behaviour as to how command-line parameters are sent
>to modules.
>
>(Note, I am not actually an expert in this area)
>
>Basically, any whitespace is treated as a delimiter, which is why you
>can say myprogram --option1 --option2 and then get the two options as
>separate arguments to the called code.
>
>-- 
>atp
>"A motorcycle is a bicycle with a pandemonium attachment and is
>designed for the especial use of mechanical geniuses, daredevils and
>lunatics."
>— George Fitch, Atlanta Constitution Newspaper, 1912
>
>
>___
>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

Re: [Emc-users] Linux CNC on Pi3

[Sebastian Kuzminsky]

The 7i90 in SPI mode works well with the Raspberry Pi 4, and probably 
the Pi 3 too.  (There's an issue with SPI on Pi on Debian Bookworm, but 
it works fine on Raspberry Pi OS Buster.)


http://store.mesanet.com/index.php?route=product/product_id=291

6 available, for $60.

You have to flash one of the SPI firmwares on it, using mesaflash.


--
Sebastian Kuzminsky


On 2/27/23 12:01, John Dammeyer wrote:

Two problems.
One: $249US and two: out of stock at the moment.

Mind you, so is the 7i92H but it was around $89 and with two Chinese BoBs at $5 
each comes in much cheaper.

So then the question is both require waiting.  A Pi4 isn't cheap either nor in 
stock.

And an ACORN CNC kit is $329.  Looks like in stock.
https://www.centroidcnc.com/centroid_diy/acorn_cnc_controller.html

It's hard to convince someone to go the CNC route with LinuxCNC when all they 
want is simple 3 or 4 axis with none of the other amazing features that 
LinuxCNC offers.

John


-Original Message-
From: andy pugh [mailto:bodge...@gmail.com]
Sent: February-27-23 10:32 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Linux CNC on Pi3

On Mon, 27 Feb 2023 at 18:15, John Dammeyer  wrote:


Ah.  I forgot about that little tidbit.


SPI (Such as 7C80) ought to work though.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
� George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: raspi image-specs root partition size limitation

[Sebastian Kuzminsky]

On 2/22/23 16:25, Sebastian Kuzminsky wrote:

On 2/22/23 13:04, Sebastian Kuzminsky wrote:
As you can see I'm mostly adding a bunch of standard debian packages 
and a little bit of system configuration to make things easier for 
LinuxCNC users.  Because I'm adding packages, I had to increase the 
size of the root partition.


I found that if I increase it to 8192M or larger, it fails to resize 
itself to fill the micro-SD card on the first boot.  8000M works fine. 
I'm fine for now staying below 8 gigs, just thought I'd report the 
issue here.


Hmm, I spoke too soon.  It's not the larger root partition size that 
breaks the partition resizer, it's installing task-xfce-desktop.


The debugging continues...


Ok, false alarm, sort of: the problem was operator error on my part.

I had added a second "apt: install" step to install some packages in 
addition to the "base system" (outside of the cached root fs tarball). 
That caused the initramfs to be regenerated, but the rpi-resizerootfs 
scripts had already been deleted by then.


Sorry for the noise, folks.


--
Sebastian Kuzminsky

Re: raspi image-specs root partition size limitation

[Sebastian Kuzminsky]

On 2/22/23 13:04, Sebastian Kuzminsky wrote:
As you can see I'm mostly adding a bunch of standard debian packages and 
a little bit of system configuration to make things easier for LinuxCNC 
users.  Because I'm adding packages, I had to increase the size of the 
root partition.


I found that if I increase it to 8192M or larger, it fails to resize 
itself to fill the micro-SD card on the first boot.  8000M works fine. 
I'm fine for now staying below 8 gigs, just thought I'd report the issue 
here.


Hmm, I spoke too soon.  It's not the larger root partition size that 
breaks the partition resizer, it's installing task-xfce-desktop.


The debugging continues...


--
Sebastian Kuzminsky

raspi image-specs root partition size limitation

[Sebastian Kuzminsky]

Hi there, I'm using image-specs to make a custom Raspberry Pi image for 
LinuxCNC (https://www.linuxcnc.org).  My fork is here: 
https://github.com/SebKuzminsky/image-specs/


As you can see I'm mostly adding a bunch of standard debian packages and 
a little bit of system configuration to make things easier for LinuxCNC 
users.  Because I'm adding packages, I had to increase the size of the 
root partition.


I found that if I increase it to 8192M or larger, it fails to resize 
itself to fill the micro-SD card on the first boot.  8000M works fine. 
I'm fine for now staying below 8 gigs, just thought I'd report the issue 
here.


Thanks for a great tool :-)


--
Sebastian Kuzminsky

Re: [Emc-developers] Debian deadline.

[Sebastian Kuzminsky]

On 2/9/23 11:32, Chris Morley wrote:


I read something about a deadline in 3 days.
Any info on that?

What is the plan for 2.9 updates/bug fixes after Debian release etc?


Here's what's going on with the freeze: 
<https://release.debian.org/testing/freeze_policy.html>


I'm preparing an upload of 2.9~pre1 (f1270d6ed7) right now.

I think we'll keep uploading "small, targeted fixes" after the freeze.

Let's get 2.9 into as good a shape as we can.


--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bug#983719: please upgrade to 4.4

[Sebastian Kuzminsky]

This is the version in Bullseye (and Bookworm and Sid):

$ esptool version
esptool.py v2.8
2.8

It does not correctly identify e.g. the ESP32-PICO-V3-02, as found on
the Adafruit ESP32 Feather V2, and it can not write the flash:
 
$ esptool --port /dev/ttyACM2 chip_id

esptool.py v2.8
Serial port /dev/ttyACM2
Connecting
Detecting chip type... ESP32
Chip is unknown ESP32 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme 
None
Crystal is 40MHz
MAC: e8:9f:6d:20:37:44
Enabling default SPI flash mode...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: e8:9f:6d:20:37:44
Hard resetting via RTS pin...

The latest version (installed with pip) is 4.4:

$ ~/.local/bin/esptool.py version
esptool.py v4.4
4.4

It works fine with this newer module, and it can write the flash:

$ ~/.local/bin/esptool.py --port /dev/ttyACM2 chip_id
esptool.py v4.4
Serial port /dev/ttyACM2
Connecting
Detecting chip type... Unsupported detection protocol, switching and trying 
again...
Connecting
Detecting chip type... ESP32
Chip is ESP32-PICO-V3-02 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, Embedded PSRAM, VRef 
calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:20:37:44
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: e8:9f:6d:20:37:44
Hard resetting via RTS pin...


An updated package would be appreciated.  Thanks!


--
Sebastian Kuzminsky

Re: [Emc-users] LinuxCNC on RaspberryPi4

[Sebastian Kuzminsky]

On 1/31/23 11:09, Alan Condit wrote:

I installed 2.9pre on two of my Raspberry Pi4s from debs that I had
compiled earlier. However, I can’t find my write up on how to cross-compile
LinuxCNC for the RPi4 on my X86-64. Also, I found that the compile on the
RaspberryPi4 with a 240gb SSD runs almost as fast, or maybe a little
faster, as on the Intel with a hard-drive.
The problem that I am currently having is that the installation of the
required packages reports a problem with locale setup.  LC_CTYPE, LANG, etc.

Has anybody else seen this? Have a fix?

I have got a pretty good script(manual) for creating a new SSD for a RPi4.
It involves using a Debian install image (minimal) and installing the
packages that I need. Maybe I will post it on the forum.


Cool!

How does your setup compare to the images from 
<https://raspi.debian.net>, built with the script at 
<https://salsa.debian.org/raspi-team/image-specs>?  I've been using 
those to build and run LinuxCNC on my Raspberry Pi 4.


And yeah, because of how fast the RPi4 is, I just build everything 
there, natively.  I don't feel any urge to cross-compile.



--
Sebastian Kuzminsky


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] I: Linuxcnc debs for RPi4

[Sebastian Kuzminsky]

On 1/23/23 08:23, ERNESTO LO VALVO wrote:


For armhf
http://linuxcnc.org/dists/bullseye/2.9-rtpreempt/binary-armhf/

For arm64
http://linuxcnc.org/dists/bullseye/2.9-rtpreempt/binary-arm64/


Something's wrong there - those debs have suspicious-looking version 
numbers, and the directories are lacking all debian package metadata.



--
Sebastian Kuzminsky


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Linuxcnc debs for RPi4

[Sebastian Kuzminsky]

On 1/22/23 12:30, Alan Condit wrote:

Does any one have debs for installing linuxcnc for Raspberry Pi4 on Debian
Bullseye?


We don't currently build that platform.

Adding it would require new hardware in the buildbot: at least one 
additional Raspberry Pi 4B, which is hard to find these days.



--
Sebastian Kuzminsky



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Bug#1029011: python3-opengl: GLUT import error on Wayland

[Sebastian Kuzminsky]

Package: python3-opengl
Version: 3.1.6+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: s...@highlab.com


GLUT fails to import on Wayland (using EGL), but it works if you force
it to GLX:

  $ echo $XDG_SESSION_TYPE
  wayland

  $ python3 -c 'from OpenGL.GLUT import *'
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/OpenGL/GLUT/__init__.py", line 5, in 

  from OpenGL.GLUT.fonts import *
File "/usr/lib/python3/dist-packages/OpenGL/GLUT/fonts.py", line 20, in 

  p = platform.getGLUTFontPointer( name )
File "/usr/lib/python3/dist-packages/OpenGL/platform/baseplatform.py", line 
350, in getGLUTFontPointer
  raise NotImplementedError(
  NotImplementedError: Platform does not define a GLUT font retrieval function

  $ PYOPENGL_PLATFORM=x11 python3 -c 'from OpenGL.GLUT import *; print("no 
problem")'
  no problem


Looking at OpenGL.platform.egl[0] there is indeed no
`getGLUTFontPointer()` function, unlike in OpenGL.platform.glx[1] where
the function *does* exist.

0: ,
1: 

The problem is not present in 3.1.5 (e.g. in Bullseye), because the
older platform detection code there does not try to detect Wayland and
so chooses GLX (which works) instead of EGL (which fails):

3.1.5:
* 

* 


3.1.6:
* 

* 


Reported to upstream here: 


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-opengl depends on:
ii  libgl1  1.5.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  python3 3.10.6-3+b1

python3-opengl recommends no packages.

Versions of packages python3-opengl suggests:
pn  libgle3
ii  python3-numpy  1:1.23.5-2
ii  python3-tk 3.10.8-1

-- no debconf information

Bug#1029011: python3-opengl: GLUT import error on Wayland

[Sebastian Kuzminsky]

Package: python3-opengl
Version: 3.1.6+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: s...@highlab.com


GLUT fails to import on Wayland (using EGL), but it works if you force
it to GLX:

  $ echo $XDG_SESSION_TYPE
  wayland

  $ python3 -c 'from OpenGL.GLUT import *'
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/OpenGL/GLUT/__init__.py", line 5, in 

  from OpenGL.GLUT.fonts import *
File "/usr/lib/python3/dist-packages/OpenGL/GLUT/fonts.py", line 20, in 

  p = platform.getGLUTFontPointer( name )
File "/usr/lib/python3/dist-packages/OpenGL/platform/baseplatform.py", line 
350, in getGLUTFontPointer
  raise NotImplementedError(
  NotImplementedError: Platform does not define a GLUT font retrieval function

  $ PYOPENGL_PLATFORM=x11 python3 -c 'from OpenGL.GLUT import *; print("no 
problem")'
  no problem


Looking at OpenGL.platform.egl[0] there is indeed no
`getGLUTFontPointer()` function, unlike in OpenGL.platform.glx[1] where
the function *does* exist.

0: ,
1: 

The problem is not present in 3.1.5 (e.g. in Bullseye), because the
older platform detection code there does not try to detect Wayland and
so chooses GLX (which works) instead of EGL (which fails):

3.1.5:
* 

* 


3.1.6:
* 

* 


Reported to upstream here: 


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-opengl depends on:
ii  libgl1  1.5.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  python3 3.10.6-3+b1

python3-opengl recommends no packages.

Versions of packages python3-opengl suggests:
pn  libgle3
ii  python3-numpy  1:1.23.5-2
ii  python3-tk 3.10.8-1

-- no debconf information

Re: [Emc-developers] Unable to start LinuxCNC: TypeError: 'NoneType' object is not callable

[Sebastian Kuzminsky]

Does this work around the problem?

https://github.com/LinuxCNC/linuxcnc/issues/2264#issuecomment-1380954324



On January 12, 2023 11:15:51 PM MST, Alec Ari via Emc-developers 
 wrote:
>Running Gentoo, just trying to get the sim axis window working again (not a 
>real-time kernel, just quick test)
>
>ntu@ntu ~ $ linuxcnc
>LINUXCNC - 2.10.0~pre0
>Machine configuration directory is '/home/ntu/linuxcnc/configs/sim.axis'
>Machine configuration file is 'axis.ini'
>Starting LinuxCNC...
>linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
>Note: Using POSIX non-realtime
>Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
>Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal
>Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal
>Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
>Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal
>link (updating variable file): No such file or directory
>note: MAXV max: 5.000 units/sec 300.000 units/min
>note: LJOG max: 5.000 units/sec 300.000 units/min
>note: LJOG default: 0.250 units/sec 15.000 units/min
>note: jog_order='XYZ'
>note: jog_invert=set()
>Traceback (most recent call last):
>  File "/usr/lib/python3.10/site-packages/OpenGL/latebind.py", line 43, in 
>__call__
>    return self._finalCall( *args, **named )
>TypeError: 'NoneType' object is not callable
>
>During handling of the above exception, another exception occurred:
>
>Traceback (most recent call last):
>  File "/usr/bin/axis", line 3964, in 
>    get_coordinate_font(vars.dro_large_font.get())
>  File "/usr/bin/axis", line 3842, in get_coordinate_font
>    glnav.use_pango_font(coordinate_font, 0, 128)
>  File "/usr/lib/python3.10/site-packages/glnav.py", line 65, in use_pango_font
>    glBitmap(0, 0, 0, 0, 0, h-d, ''.encode())
>  File "/usr/lib/python3.10/site-packages/OpenGL/latebind.py", line 47, in 
>__call__
>    return self._finalCall( *args, **named )
>  File "/usr/lib/python3.10/site-packages/OpenGL/wrapper.py", line 700, in 
>wrapperCall
>    raise err
>  File "/usr/lib/python3.10/site-packages/OpenGL/wrapper.py", line 693, in 
>wrapperCall
>    result = wrappedOperation( *cArguments )
>  File "/usr/lib/python3.10/site-packages/OpenGL/platform/baseplatform.py", 
>line 415, in __call__
>    return self( *args, **named )
>  File "/usr/lib/python3.10/site-packages/OpenGL/error.py", line 230, in 
>glCheckError
>    raise self._errorClass(
>OpenGL.error.GLError: GLError(
>    err = 1285,
>    description = b'out of memory',
>    baseOperation = glBitmap,
>    pyArgs = (0, 0, 0, 0, 0, 13.0, b''),
>    cArgs = (0, 0, 0, 0, 0, 13.0, b''),
>    cArguments = (0, 0, 0, 0, 0, 13.0, b'')
>)
>Shutting down and cleaning up LinuxCNC...
>task: 473 cycles, min=0.04, max=0.001062, avg=0.001019, 0 latency 
>excursions (> 10x expected cycle time of 0.001000s)
>Note: Using POSIX non-realtime
>LinuxCNC terminated with an error.  You can find more information in the log:
>    /home/ntu/linuxcnc_debug.txt
>and
>    /home/ntu/linuxcnc_print.txt
>as well as in the output of the shell command 'dmesg' and in the terminal
>
>ntu@ntu ~ $ cat linuxcnc*.txt
>23766
>23816
>Stopping realtime threads
>Unloading hal components
>RUN_IN_PLACE=no
>LINUXCNC_DIR=
>LINUXCNC_BIN_DIR=/usr/bin
>LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
>LINUXCNC_SCRIPT_DIR=
>LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
>LINUXCNC_CONFIG_DIR=
>LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
>INIVAR=inivar
>HALCMD=halcmd
>LINUXCNC_EMCSH=/usr/bin/wish8.6
>INIFILE=/home/ntu/linuxcnc/configs/sim.axis/axis.ini
>VERSION=1.1
>PARAMETER_FILE=sim.var
>TPMOD=
>HOMEMOD=
>TASK=milltask
>HALUI=halui
>DISPLAY=axis
>COORDINATES=X Y Z
>KINEMATICS=trivkins
>Starting LinuxCNC server program: linuxcncsvr
>Loading Real Time OS, RTAPI, and HAL_LIB modules
>Starting LinuxCNC IO program: io
>Starting HAL User Interface program: halui
>Starting TASK program: milltask
>Starting DISPLAY program: axis
>Removing HAL_LIB, RTAPI, and Real Time OS modules
>Removing NML shared memory segmentsTypeError: 'NoneType' object is not callable
>
>On this test system, it is fully hardened (lots of security features 
>throughout) not sure if related.. Any ideas on what's wrong?
>
>Alec
>
>
>___
>Emc-developers mailing list
>Emc-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-developers

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Broken master 06jan23

[Sebastian Kuzminsky]

I believe a root cause of this breakage was the difficulty of merging 
the docs from 2.9 to master.


The merge resulted in a bunch of awkward conflicts.  As always, the 
conflicts were caused by files being changed in the same place in both 
branches.  In this case, the conflicts came from a couple of misplaced 
commits back in November:


8d07575ef31c0d99cd9601aabb90e5d59cea9ac5
c1668e209290693a086f99c039271a22bc5e9061

Those were big translation-motivated changes that mistakenly went into 
master, when they should have gone into 2.9.  (You can see that those 
went into master instead of 2.9 using `git branch -a --contains $SHA` to 
list all branches that have those commits in their history.)


Later, similar but slightly different translaton-motivated changes went 
into 2.9, and the following merge stopped on the conflicts.


I think we now have a consensus in place that, generally, changes to 
.adoc files go in 2.9 (unless they're describing new behavior in master, 
of course), and all changes to .po/.pot files without exceptions go in 
master.


Had we had this consensus in place back in November, the present merge 
problem would have been much smaller.


Perhaps we should have a Github Action that warns on .adoc changes in 
master or .po/.pot changes in 2.9?



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Broken master 06jan23

[Sebastian Kuzminsky]

On 1/8/23 11:38, Jeff Epler wrote:


On Sun, Jan 08, 2023 at 04:06:07AM +, Chris Morley wrote:


I disagree with having to use pull requests for devs. (if I understood that 
right)
We already have problems getting pull request reviewed and aproved.


I will not change this without consensus.

In the long run, though, successful projects are able to review and
merge (or, when necessary, reject) pull requests in a timely fashion. In
this respect, our project's health is poor.

I think that the way that "core developers" can simply ignore the pull
request process if they choose to do so contributes to this. These core
developers can both bypass this speed bump if they choose, and ignore
pull requests from others even where their expertise can accelerate the
PR's inclusion.

In other projects where I participate (incuding my work, which is all
public on github) working via pull request is the default.  It works
well, and by numbers I believe that most PRs come from external
contributors but admittedly "the it works" depends on having ~4.5 paid
FTEs on the project.  A small number of reviewers are able to make short
work of most PRs, especially when there's a culture of doing it. I spend
maybe 5% of my time reviewing PRs, while some of my colleagues probably
spend substantially more.


My work experience is varied.  I've worked on larger teams where 
everything went through the PR process (and folks treated new PRs as 
high-priority interrupts), and on smaller teams where we all pushed 
directly to the long-lived branches without review.


The ubiquitous use of PRs is beneficial for code quality and for team 
communication, but it does introduce extra work, sometimes a significant 
amount.


Some of the extra work falls on the folks reviewing PRs, but it's 
important that the person *opening* the PR shoulder some of this burden 
too: by writing small, clean commits with good descriptive commit 
messages, and a good message in the PR explaining the high-level purpose 
of the whole branch.


This is good practice anyway, and is part of our project guidelines, 
though I sometimes get lazy and don't follow it:


<http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_effective_use_of_git>

I think beyond a certain project size the PR process becomes worth it. 
I think we're well beyond that project size, and I would like to see us 
at least try this.


If we can't make ourselves review each others' PRs in a timely fashion 
the experiment will have failed and we can go back to the current "push 
at will" workflow.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] failing sample configs in 2.9: remap, gmoccapy, qtvcp, and more!

[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?


As for the python version, I run the tests on a bullseye host (python 
3.9), I haven't tried running it anywhere else.



- 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.


I just tried one of the gmoccapy configs by hand on bullseye and it 
failed in the same way.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: Clean-room build of deb package?

[Sebastian Kuzminsky]

On 12/29/22 06:02, Barry Scott wrote:
On Fedora/RHEL I would use mock to build a RPM from source to ensure 
that I have the RPM spec file correctly written.


Mock ensures that no packages in my dev machine are used to build the RPM.

What is the debian version of that tool?


I use `pbuilder` for this purpose:
<https://pbuilder-team.pages.debian.net/pbuilder/>


--
Sebastian Kuzminsky

Re: [Emc-developers] Fwd: Bug#1025433: Copyright issue

[Sebastian Kuzminsky]

On 12/10/22 08:14, Andy Pugh wrote:




On 10 Dec 2022, at 14:49, Dewey Garrett  wrote:

nada -- this file is intree but not used


Interesting. Perhaps we can just delete it.


As Dewey reported later, procfs_macros.h is used in the RTAI backend of 
RTAPI, and deleting it breaks the RTAI build unless we turn off our 
/proc code at the same time.


I'm testing 2.8 on Wheezy with the 3.4-9-rtai-686-pae kernel from our 
package archive.


There are a bunch of things in /proc/rtapi that seem useful, that use 
procfs_macros.h.  Unfortunately reading from any of them produces 
garbage.  Writing to /proc/rtapi/debug works fine and does the expected 
thing (rtapi messages start showing up in the kernel log).


This is representative:

~~~
$ cat /proc/rtapi/status

ssage level = 5
975 nSec
  
 

~~~

It seems like `seq_file` may be a better way for us to supply the 
contents of our files in /proc?  It's part of the mainline kernel.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Fwd: Bug#1025433: Copyright issue

[Sebastian Kuzminsky]

Great!  Thanks for figuring this out Dewey :-)

On December 10, 2022 10:43:06 AM MST, Dewey Garrett  wrote:
>In <863c8874-ef3b-4f5d-a1fb-6135dc438...@highlab.com> Sebastian Kuzminsky 
> writes:
>
>>Does it build on both uspace and RTAI?
>
>$ git status -uno
>On branch master
>Your branch is up to date with 'origin/master'.
>
>Changes to be committed:
>  (use "git restore --staged ..." to unstage)
>   modified:   src/rtapi/README
>   deleted:src/rtapi/procfs_macros.h
>   deleted:src/rtapi/rtapi_proc.h
>
>$ git diff -b --cached src/rtapi/README
>diff --git a/src/rtapi/README b/src/rtapi/README
>index 3ae1f121ac..43a894 100644
>--- a/src/rtapi/README
>+++ b/src/rtapi/README
>@@ -10,7 +10,6 @@ README  : this file
> rtapi.h : decls for the generic RTAPI functions.
> rtapi_app.h : decls for the kernel modules
> rtapi_common.h  : Collection of typedefs, etc,  used internally by RTAPI.
>-procfs_macros.h : Macros used to implement the /proc interface
> rtapi_proc.h: more stuff implementing the /proc interface
> rtai_rtapi.c: implementation of real-time API, for RTAI
> rtai_ulapi.c: implementation of user-level API, for RTAI
>
>#===
>Tested: $ make clean && make && sudo make setuid
>
>builds ok on both uspace and rtai (rtai in a virtualbox)
>
>Ref:
>1) uspace
>$ uname -a
>Linux beye 5.10.78-rt55 #4 SMP PREEMPT_RT Fri Dec 2 16:47:27 MST 2022 x86_64 
>GNU/Linux
>$ lsb_release -a
>No LSB modules are available.
>Distributor ID:Debian
>Description:   Debian GNU/Linux 11 (bullseye)
>Release:   11
>Codename:  bullseye
>
>2) rtai (virtualbox):
>$ uname -a
>Linux dvm 4.19.195-rtai-amd64 #5 SMP PREEMPT Sun Jul 11 19:13:27 BST 2021 
>x86_64 GNU/Linux
>$ lsb_release -a
>No LSB modules are available.
>Distributor ID:Debian
>Description:   Debian GNU/Linux 10 (buster)
>Release:   10
>Codename:  buster
>
>#===
>runtests passed on both systems above
>
>Note: also tested uspace on non-std kernel for bullseye (6.0.5-rt14)
>$ uname -a
>Linux beye 6.0.5-rt14 #1 SMP PREEMPT_RT Sat Dec 3 07:07:29 MST 2022 x86_64 
>GNU/Linux
>
>-- 
>Dewey Garrett
>
>
>
>___
>Emc-developers mailing list
>Emc-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-developers

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Fwd: Bug#1025433: Copyright issue

[Sebastian Kuzminsky]

Does it build on both uspace and RTAI?

On December 10, 2022 8:04:19 AM MST, Dewey Garrett  wrote:
>In  Dewey Garrett  writes:
>
>
>
>>nada -- this file is intree but not used
>not used in any .c,.cc files but:
>
>$ find . -type f  -exec grep -H procfs_macros {} \; 
>./src/rtapi/rtapi_proc.h:#include "procfs_macros.h"/* macros for read 
>functions */
>./src/rtapi/README:procfs_macros.h : Macros used to implement the /proc 
>interface
>
>However, when commenting out those lines, build still works
>-- 
>Dewey Garrett
>
>
>
>___
>Emc-developers mailing list
>Emc-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-developers

-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Arc Bug, help needed.

[Sebastian Kuzminsky]

On 12/7/22 13:31, John Thornton wrote:
I can confirm the bug is in the 2.9 branch that is currently in Debian, 
I'm unable to build a RIP on 2.9 to see if it's still there as I get 
configure errors I don't understand how to fix.


configure error could not link test program to Python... Maybe the main 
Python library has been installed in some non-standard library path.


Python 3 came installed with Debian 12...


Do you have all the 2.9 build dependencies installed?  Check with:

$ debian/configure
$ dpkg-checkbuilddeps

(Per the instructions here: 
<http://linuxcnc.org/docs/2.9/html/code/building-linuxcnc.html#Satisfying-Build-Dependencies> 
.)



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Sebastian Kuzminsky]

On 12/5/22 15:18, Steffen Möller wrote:


It would make some good sense to me not to use DDS that currently runs in the 
base thread.


The base thread and servo thread both currently do not communicates via 
NML, and I don't think anyone(?) is suggesting changing that.


NML communication is currently used between Task (which is a sort of 
central coordinator of the LinuxCNC processes & components) and the 
GUIs.  NML is used for non-realtime communications only.


Latency in this communication channel is still important, for example 
when a user lets go of the jog button on the keyboard the GUI should 
communicate that promptly to Task so Task can tell the motion controller 
to stop jogging.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Sebastian Kuzminsky]

On 12/4/22 08:16, Dewey Garrett wrote:


A correction:


NML is used between the GUI(s) and Task, and between Task and IO.


The commit 2dbb2f640f changed the interface between
EMCIO and TASK to use a memory mapped interface.

This facility has been in use in the master branch
since its incorporation in January 2021 and is
currently included in the 2.9 branch.


Thanks for correcting my outdated information!


--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Sebastian Kuzminsky]

On 12/3/22 19:20, Jon Elson wrote:
Underneath HAL there is NML that links major sections of LinuxCNC 
together and makes the state of major components available.  NML exports 
the ENTIRE state of everything to all clients.  This is doable on a 
single computer system, but causes issues on multiple networked nodes.  


Note, HAL does not use NML.  This diagram shows the places where NML is 
used:


http://linuxcnc.org/docs/devel/html/code/code-notes.html#_architecture_overview

NML is used between the GUI(s) and Task, and between Task and IO.  The 
connection between Task and Motion uses an NML-like message-passing 
system, but not the actual NML code.


That diagram predates HAL.  HAL is a fine-grained shared-memory system 
acting as a kind of backplane connecting IO, Motion, and the "Realtime 
Hardware Devices" and "Non-Realtime Hardware Devices" in that diagram. 
HAL does not use message-passing.


One challenge with making LinuxCNC distributed across multiple physical 
computers is that HAL is shm-based, not message-based.  So we'd need a 
tool to periodically inspect the state of (some?) HAL objects, serialize 
the information into a message, and send that message to recipient(s) on 
the network.  I believe Machinekit made some progress in this area, but 
I don't know how far they got and I never saw a PR that I could understand.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Sebastian Kuzminsky]

On Dec 3, 2022, at 10:58 AM, Chris Morley
 wrote:

Have you looked at machinekit code? Is that similar to what you
want?


On 12/3/22 17:06, Johannes Fassotte wrote:
> I think that this will get done individuals like me that get together
> and see the advantages that this offers. I usually get  referred to
> machinekit liked you did which is really like saying go away, we
> don’t want to hear this because it is not compatible with existing
> plans and therefore rejected.

I have two comments to make here.

1:

Last time i looked at machinekit's "machinetalk" feature, it was 
basically a special UI that got its "user input" from 0mq instead of 
from mouse clicks and keyboard presses, and reported its info into 0mq 
instead of into a GUI window.  Machinetalk still interfaced to LinuxCNC 
using the same old NML system we've been using since the beginning.


Machinekit may have evolved since then, or I may me misremembering (as 
it's been years since I looked at it), so please fact-check me and 
correct me if i'm wrong.


I would welcome a new network-transparent interface for UIs to talk to 
the LinuxCNC machine control core, but I am not at all interested in 
adding a new layer of pretty networking on top of the existing 
interfaces.  If you're going to do this, do it right, by replacing the 
old cruft with new, more useful stuff.


2:

There is no cabal of evil villains preventing innovation and improvement 
in LinuxCNC.  There's not even a "board of directors" that makes their 
own plans and rejects everyone else's good ideas.


There is only a loose association of well-meaning, interested 
individuals, all contributing what we can, when we can, as it fits 
around the other things going on in our lives.


If you have a good idea, please, bring it up and discuss it on the 
mailing list as you did.  If anyone is moved to add anything to the 
discussion, they will.  Don't take silence as rejection, it's often just 
folks being distracted by other things and not paying attention to the 
mailing list.  Ideas that are presented clearly (and politely) will get 
the most interaction.  Your idea may get criticism and/or encouragement, 
but remember that in the end, no one is obligated to act on your ideas. 
If you want something, you generally have to do it yourself, with the 
guidance and whatever collaboration individuals in the community choose 
to offer you.


Code talks, especially well implemented, well documented, well tested 
code grounded in community discussion and rough consensus.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] pncconf discrepancy between 2.8 and 2.9

[Sebastian Kuzminsky]

I'm merging 2.8 into 2.9, and I came across a spot where it looks like a 
feature was added independently to both 2.8 and 2.9 (7i96s support in 
pncconf), and a bunch of bugfixes were applied in 2.9 but not 2.8.


Please remember folks: apply patches to the oldest branch where it 
belongs, then merge up.  When you apply a patch to multiple branches 
independently, and then apply different bugfixes in different branches, 
the result is chaos and regressions.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCnc growing with to much none essential code

[Sebastian Kuzminsky]

On 11/30/22 22:24, Johannes P Fassotte wrote:
It was not to may years ago that LinuxCnc was just over 120Mb in 
extracted size.  Now V 2.9 master is takes up 252Mb so its getting 
bloaded with a lot of none essential things. I think it needs a good 
cleaning to get it back on track. I feel that there are to many 
personnal projects being added that are better suited to be developer 
supported addtions and not part of LinuxCnc itself.


I think the best way to address this concern would be to provide 
finer-grained packaging, so that users can choose what GUIs to install.


There is a strong incentive to keep the GUIs in our repo, so that GUI 
developers don't have to reproduce our test & packaging infrastructure.


We could move (for example) the Qt stuff into a new `linuxcnc-gui-qt` 
package, which would be installed by default but easy for an end user to 
remove.


I have no intention of working on this myself, but I would be happy to 
review a PR that has successfully made it past our automated package & 
test systems.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Merge Strategy

[Sebastian Kuzminsky]

I still think merging upwards is the best way to do this.

The main advantage is that git keeps track of what commits need to be 
propagated to the newer branch, so we'll never leave behind any bugfix 
commits in older stable branches.  This avoids the terrible situation 
where we fix a bug in the stable branch, but the bug is "reintroduced" 
in the development branch because the bugfix commit never made it in to 
the newer branch.


That said, I *am* sympathetic to the concern that if part of the 
software has evolved significantly between the stable branch and the 
development branch, and that part of the software got a bugfix, then the 
merge may have significant conflicts...


So let me be specific, and compare the two situations, so we have a 
common place to discuss from.



# Scenario 1

In this scenario the old stable branch (2.8) has several new commits: 
some that add a new driver, then a bugfix in old code, then some that 
add another new driver.


The new branch (2.9) has lots of changes, but nothing that conflicts 
with the new stuff in 2.8.


"Merging up" looks like this:

$ git checkout 2.9
$ git merge origin/2.8

There are no conflicts so the merge is automatic.

"Cherry-pick" looks like this:

$ git checkout 2.9
# identify the list of commits needed, and cherry-pick each one

Identifying the list of commits needed is a manual, error-prone process. 
 Git doesn't provide much help here - you have to walk backwards 
through history in 2.8, and for each commit you have to guess if it has 
been already cherry-picked into 2.9 by searching for it in the 2.9 
commit history.  The only thing you have to go on is the commit message 
- if they're the same, then the 2.9 commit was probably cherry-picked 
from 2.8 (unless it was cherry-picked the other way, or reimplemented 
independently).  Once you find a commit in 2.8 that's already in 2.9, 
then you may assume that every 2.8 commit *after* that one is new and 
should be cherry-picked into 2.9.


You cherry-pick all the commits starting at that first new one and 
ending at the tip of 2.8, in order, into 2.9.  In the current scenario 
there are no conflicts, so this process goes smoothly.


But even in this easy scenario, this is a lot of error-prone manual labor.


# Scenario 2

This is just like Scenario 1, except the bugfix in the old code *does* 
conflict with changes in 2.9.


"Merging up" looks like this:

$ git checkout 2.9
$ git merge origin/2.8

The merge detects the conflict and stops halfway through.

You have a choice here: if it's a simple conflict you can resolve it 
yourself and finish the merge, or if it's too complicated you can `git 
merge --abort` and punt it to someone else.


If you choose to punt, you have the option to do just the easy first 
part of the merge (remember, in this scenario 2.8 has a new driver, then 
a conflicting bugfix, then another new driver).


So you would run `git log origin/2.8 ^origin/2.9` to see the log of just 
the not-yet-propagated new commits that are in 2.8.  You'd identify the 
commit that finishes the first driver add, and `git merge` that commit 
into 2.9.  (There will be no conflicts, according to this scenario.)


Then email the folks who know more about the conflict and ask them to 
merge their bugfix into 2.9.


"Cherry-pick" looks like this:

Actually it looks just like Scenario 1 (including all the manual 
searching and guessing), except the cherry-pick of the bugfix will 
conflict, and at that point you fix it or punt just like in the "merging 
up" case.



So that's my thinking.  I hope this shows why i think merging up is 
better than cherry-picking.



--
Sebastian Kuzminsky


On 11/27/22 11:11, Chris Morley wrote:

Well we will never agree on anything different if we never discuss it.
How about throwing out an opinion here?

Chris

From: Hans Unzner 
Sent: November 27, 2022 10:54 AM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Merge Strategy

I agree that we should stick to "merge up" until we reach an agreement
to change this.

Hans

Am 23.11.22 um 22:42 schrieb Chris Morley:

Ya it's always been hard to consistently get answers in our project.
It just seems the nature of our group.
Thanks for continuing to try.

Currently strategy is to merge up, though you can cherry-pick up too, as a 
merge later should understand this.
But we rarely do anything with an older-then-current-release (I realize that 
2.8 is still sorta current)

On the absence of an agreement, I am merging up 2.9 to master to keep in sync.

Chris

From: andy pugh 
Sent: November 23, 2022 4:59 PM
To: EMC developers 
Subject: [Emc-developers] Merge Strategy

On Tue, 8 Nov 2022 at 21:38, Chris Morley  wrote:

I wonder if we might discuss a different merging strategy for 2 9/master.
This would be relative to work being done in 2.9 for release.

I suggest we don'

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/24/22 08:29, Jérémie Tarot wrote:

Le jeu. 24 nov. 2022 à 15:08, Alec Ari via Emc-developers <
emc-developers@lists.sourceforge.net> a écrit :


Ah, let me rephrase. There has been talk of automatic testing of RTAI not
being feasible unless done manually but this is not true according to Seb.


Testing it _requires_ a machine, metal or virtual, with a kernel and
privileges allowing to load and unload kernel modules. As a consequence:
* Our buildbot, as it uses full virtual machines, is capable of testing RTAI
* Container (vs machine) based CI/CD pipelines are NOT able to test RTAI
* Among all the CI/CD pipelines options mentioned before, only those
allowing to launch hypervisor based virtual machines with a freely chosen
or custom kernel would allow testing RTAI


This is exactly correct.  Thanks for the concise explanation of the 
situation.



--
Sebastian Kuzminsky



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/23/22 12:19, Alec Ari via Emc-developers wrote:

OK, so that should work with the Github CI/CD too then, right?


Yes.  Here's a recent run of our CI in Github Actions:

https://github.com/LinuxCNC/linuxcnc/actions/runs/3500716822

This is the script that controls it:

https://github.com/LinuxCNC/linuxcnc/blob/master/.github/workflows/ci.yml

As you can see we currently build run-in-place and run the test suite, 
we build the html docs, and we build & test debs on multiple debian 
distros (Buster, Bullseye, Bookworm, and Sid).


All this is done on Github's runners, which are all amd64 with vanilla 
kernels.  So it exercises amd64 uspace pretty well but doesn't exercise 
any other CPU architecture, and doesn't exercise RTAI.



Our mesaflash build uses a different (3rd-party) action to test building 
debs on multiple CPU architectures, using docker:


https://github.com/LinuxCNC/mesaflash/actions/runs/3422479631

https://github.com/LinuxCNC/mesaflash/blob/master/.github/workflows/ci.yml#L43-L47


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/23/22 09:02, Alec Ari via Emc-developers wrote:

With CI/CD, can't you have it do a `runtests` in a run-in-place
environment? I could also write a simple RTAI test program (even more
simple than the testsuite/built-in latency test) that'll just load
and exit.


Yes, the full test suite can run (using `runtests`) in a run-in-place 
build (for both RTAI and uspace), as documented here:


<http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html#Quick-Start>


This is how the buildbot currently runs the tests on RTAI:

<http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/7201>

Of course this only works on a CI/CD machine running an RTAI kernel, and 
with sufficient capabilities/permissions to load and unload kernel modules.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/14/22 18:43, m...@mattshaver.com wrote:

On 2022-11-14 15:54, Sebastian Kuzminsky wrote:


In order to support testing LinuxCNC on RTAI the buildbot uses custom
VMs which i created a long time ago and maintain poorly.  It all runs
on hardware in my house, on my local network, so I am reluctant to
open it up to a more collaborative mode of development/maintenance.


Is there some way of replicating your home based setup (or obtaining a 
compatible hardware/software environment) by contracting with a 
commercial hosting company, or co-location facility, or something like 
that? If this could be done for a reasonable amount of money, I'd be 
happy to pay for it, or at least chip in. I can't do much to help, but I 
can spend money!


Hosting the hardware is relatively little effort.

Most of the effort is in the initial creation of new builder VMs (i.e. 
to build on new platforms), and ongoing updates to the buildmaster.


These tasks would still fall on us of the LinuxCNC project, rather than 
on whatever hosting provider we use.


The lack of builders newer than Buster in the buildbot is due to a 
version-skew issue within the buildbot project: to support newer 
builders I need to upgrade the buildmaster from the current (ancient) 
0.8 version to the new 2.x version.  Again, this is work that a hosting 
provider can't help with.  I have been working on it on and off, and 
I've made some progress, but it's not ready to deploy yet.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/14/22 16:58, Rod Webster wrote:

Perhaps the Github actions could be extended to build the 2.9 branch?


Our current Github Actions already builds & tests all branches (but does 
not publish any packages).



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.9 Release Manager Required.

[Sebastian Kuzminsky]

On 11/14/22 13:37, Jérémie Tarot wrote:


Could someone explain me how relocating the buildbot on someone's
machine can be better for the project than migrating it to GitHub
Actions, build farm and package hoster ?
Don't get me wrong John and Rod, I very much appreciate your proposal
and investment but I believe your time and resources would be better
employed. I'm looking at you MesaCT, EtherCAT...

 From what I've found and understood, it could be enough to upgrade our
current ci.yml to use docker containers to build all our packages for
the desired architectures and selected distributions/releases, and
then use one of the PackageCloud actions available to push artifacts
to a specialised host.


The difficulty with building and testing LinuxCNC in docker containers 
or in off-the-shelf VMs (as in Github Actions) is that our 'RTAI' 
configuration needs a special kernel, and needs to load and unload 
kernel modules to run & test LinuxCNC.


(Unlike RTAI, the 'uspace' config *can* be built and tested in docker 
containers, though we don't currently do that in our Github Actions. 
The LinuxCNC/mesaflash project builds in docker in Github Actions, and I 
agree, it's great and super convenient.)


In order to support testing LinuxCNC on RTAI the buildbot uses custom 
VMs which i created a long time ago and maintain poorly.  It all runs on 
hardware in my house, on my local network, so I am reluctant to open it 
up to a more collaborative mode of development/maintenance.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: how to enable spi on Raspberry Pi 4 (bookworm)?

[Sebastian Kuzminsky]

On 10/25/22 12:03, Sebastian Kuzminsky wrote:
I'm using the 2022-08-08 bookworm rpi4 image from 
<https://raspi.debian.net/tested-images/>, it's got linux-image-arm64 
5.18.14-1 and raspi-firmware 1.20220331+ds-2.


It's working great, except I can't use the SPI devices.

SPI works on same hardware when running Raspbian's Buster image, after 
running "dtparam spi=on" (or adding "dtparam=spi=on" to the firmware 
config.txt file).


Raspbian Buster's dtparam program is not available on Debian Bookworm.

On Raspbian it comes from the libraspberrypi-bin deb, which is made from 
the raspberrypi/firwmware git repo on github (the same repo that 
supplies all the dtb files in /boot).  dtparam and the other programs 
there are provided in binary form (for armhf), not source :-(


I don't have this working yet but I've made a little bit of progress.

The Raspbian Buster armhf binaries can be made to run on Debian Bookworm 
arm64 with a little bit of coaxing, but they rely on kernel features 
that are not in Bookworm's arm64 kernel, so that's a bit of a dead end.


I then tried editing the dtb directly:

I "decompiled" the dtb `/boot/firmware/bcm2711-rpi-4-b.dtb` into an 
editable dts with `dtc -I dtb -O dts $DTB > $DTS`.


I edited the dts to change the spi0 "status" field from "disabled" to "ok".

I "compiled" the edited dts with `dtc -I dts -O dtb $DTS > $DTB`.

I then replaced the old dtb with the new one and rebooted.

The spi port seems to be present/enabled now: dmesg includes 
"spi-bcm2835 fe204000.spi: no tx-dma configuration found - not using dma 
mode", and /sys/bus/platform/drivers/spi-bcm2835/fe204000.spi shows up.


But something is still wrong, there are still no /dev/spi* device files 
like i get with Raspbian Buster.


So I'm closer, but I'm still missing something.  The quest goes on!


--
Sebastian Kuzminsky

how to enable spi?

[Sebastian Kuzminsky]

I'm using the 2022-08-08 bookworm rpi4 image from 
<https://raspi.debian.net/tested-images/>, it's got linux-image-arm64 
5.18.14-1 and raspi-firmware 1.20220331+ds-2.


It's working great, except I can't use the SPI devices.

SPI works on same hardware when running Raspbian's Buster image, after 
running "dtparam spi=on" (or adding "dtparam=spi=on" to the firmware 
config.txt file).


Raspbian Buster's dtparam program is not available on Debian Bookworm.

On Raspbian it comes from the libraspberrypi-bin deb, which is made from 
the raspberrypi/firwmware git repo on github (the same repo that 
supplies all the dtb files in /boot).  dtparam and the other programs 
there are provided in binary form (for armhf), not source :-(


Does anyone have any advise for me on how to enable SPI on Debian?

(In case it's not obvious, I'm a noob at dealing with device tree stuff.)


--
Sebastian Kuzminsky

Re: [Emc-developers] linuxcnc on raspberry pi bullseye?

[Sebastian Kuzminsky]

On 9/14/22 15:35, Rod Webster wrote:


https://raspi.debian.net/tested-images/


This is awesome!

I tried the "2022-08-08" Bookworm image for Raspberry Pi 4.  The image 
is for the arm64 architecture.  Everything seems to work fine on a 
Raspberry Pi 4B, including wifi, GUI, and the serial console.


After `apt-get install linuxcnc-uspace linux-image-rt-arm64` and a 
little bit of tweaking, I'm now getting latencies around 150 µs, which 
is not as good as the Raspbian Buster armhf image at linuxcnc.org (~70 
µs latency) but probably acceptable.


It's neat that there are several easy(-ish), usable options for LinuxCNC 
on Raspberry Pi now.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc on raspberry pi bullseye?

[Sebastian Kuzminsky]

On 9/14/22 17:27, Phill Carter wrote:



On 15 Sep 2022, at 4:53 am, Sebastian Kuzminsky  wrote:

Does anyone know if there's a well-liked pre-built official or
community-supported Rpi4 realtime kernel somewhere?


Not sure how modern you want but the kernel on the image here is 
5.15.27-rt35-v8+

<https://forum.linuxcnc.org/9-installing-linuxcnc/39779-rpi4-raspbian-64-bit-linuxcnc?start=130#238020
 
<https://forum.linuxcnc.org/9-installing-linuxcnc/39779-rpi4-raspbian-64-bit-linuxcnc?start=130#238020>>


That's great, thanks Phill!  It linked to just what I was looking for:

<https://github.com/kdoren/linux/>

That's a fork of the official RPi kernel, reconfigured for Preempt-RT, 
with prebuilt debs for armhf & arm64.


The debs installed on top of a clean up-to-date pi-gen Bullseye armhf 
image (so Raspberry Pi OS aka Raspbian, not the real Debian).


The latest "release", 5.15.65-rt49, did not boot on my Rpi4, but the 
previous one, 5.15.40-rt43, did.  Latency is a bit worse than Raspbian 
Buster with the 4.19.71-rt2 kernel but probably usable.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] linuxcnc on raspberry pi bullseye?

[Sebastian Kuzminsky]

Hi folks, with all the attention that newer distros have been getting
lately, I'm looking in to running LinuxCNC On the Bullseye version of 
Raspberry Pi OS (aka Raspbian) on a Raspberry Pi 4B.


It looks super straight-forward, except for the realtime kernel (as
usual).  I don't see a modern kernel built with Preempt-RT enabled in
the raspbian bullseye package archive...

Does anyone know if there's a well-liked pre-built official or
community-supported Rpi4 realtime kernel somewhere?

Or do I have to reconfigure & rebuild the "official" kernel?


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Debian package - what is the future?

[Sebastian Kuzminsky]

On 9/5/22 11:33, gene heskett wrote:

On 9/5/22 12:46, Sebastian Kuzminsky wrote:
Note that because of dependencies, 2.8 can't go into any distro newer 
than Buster, and 2.9 (aka master) can't go into any distro older than 
Bullseye.


uhh, Seb, 2.9 is running quite well on raspios buster. I just updated it 
this morning. Along with the other 3

intel powered buster installs, all are running master from the buildbot.

What isn't supposed to work on buster?


Oops, you're right, I'm wrong.  2.9/master runs on *Buster* and newer.

Thanks for fact-checking me on that one :-)


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Debian package - what is the future?

[Sebastian Kuzminsky]

On 9/5/22 04:56, Steffen Moeller wrote:

I do not see the LinuxCNC buildbot in conflict with the Debian-upload
of LinuxCNC. Ideally one would add the buildbot repository to the
Debian repository and then decides what version to install - and one
could go back to the earlier version with no hassle.


Agreed.  For this to work, we need to synchronize the package version 
numbers (including the epoch) between the debs at debian.org and the 
ones at linuxcnc.org.


Petter suggested starting a discussion on debian-devel about the best 
way to go about this, i'll try to write that email today.



All the releases and point-releases should be uploaded to the 
distribution. Backports as we see fit.


Agreed 100%.

Note that because of dependencies, 2.8 can't go into any distro newer 
than Buster, and 2.9 (aka master) can't go into any distro older than 
Bullseye.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Debian package - what is the future?

[Sebastian Kuzminsky]

On 9/4/22 10:36, Sebastian Kuzminsky wrote:

There are currently four ways to get pre-built debs of linuxcnc:

1. debian.org

2. buildbot

3. www.linuxcnc.org

4. github "artifacts"


I forgot to mention another important difference between the debian.org 
debs and the buildbot debs:


The buildbot builds debs from every commit that passes our tests, so the 
buildbot debs are very up to date.  The debian.org debs are prepared by 
a human, so they get updated much less often.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Debian package - what is the future?

[Sebastian Kuzminsky]

org, and the epoch was deleted from 
the version numbers of the official debian.org packages.


I'm not sure how to deal with this.  We should probably follow suit, 
delete the epoch number from "our" debs, remove all debs-with-epochs 
from our package archive, and somehow teach our users the recipe for 
downgrading from debs-with-epochs to debs-without-epochs.


But this is a slightly tangential issue & discussion, and I don't want 
to derail Chris's thread too much.




Will having Debian force us on a time schedule?
What happens if we are not on time?


No, debian does not force a release schedule on us.  Debian releases and 
LinuxCNC releases are fundamentally decoupled.


There is some advantage to having a relatively up-to-date stable release 
of LinuxCNC ready "shortly" (a few months?) before a Debian release, so 
that we can all feel excited to maintain the version that made it into 
the debian release.  But this is an optimization, it's not a hard 
requirement.


If we don't have a LinuxCNC release ready when Debian freezes for its 
release, we have two options:


1. Package whatever is in the master branch at that time (like we 
currently do with our 2.9~pre debs), and update the packages when we 
make the final release (at any point in the life cycle of that debian 
release).


2. Package the current stable branch, whatever that is at the time. 
This does strongly encourage us to maintain that stable branch until the 
debian release reaches its end-of-life.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Next Linuxcnc Online meeting

[Sebastian Kuzminsky]

On 8/10/22 12:36, Hans Unzner wrote:
I agree that the meeting was not really effective. In my opinion we have 
to think about the topics we want to discuss in advance and put them on 
the agenda. And also limit the time.
The audio and video is often a problem at those meetings. Maybe we 
should spend some time to check that before we actually start the 
discussion.


We can collect ideas for the agenda in the Google document, linked 
below. But I'm not sure if everyone with the link has write access to 
that. Can you try that?


Am 10.08.22 um 19:10 schrieb Chris Morley:
I unfortunately found the meeting frustrating. The audio was unusable 
about 50% of the time.

For mw,It got to the point it was useless to continue trying.
Not sure if it was on my end or if there were any other options.
Seb did mention he had some trouble too.

Next meeting:
Is there a way to post small writeups of subjects keen to be discussed?
I had opinions on 2.9 release but could not be heard?

Thanks for organising the meeting. Nice to see a try on an organised 
direction again :)


Last time we decided we wanted a more formal meeting structure, we did 
it this way:  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC


IRC in 2013 was way more reliable that video chats in 2022, but perhaps 
less accessible to folks who are not used to it.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Next Linuxcnc Online meeting

[Sebastian Kuzminsky]

On 8/5/22 05:41, Rene Hopf via Emc-developers wrote:

Meeting will be Monday 8.8. 20:00 CEST.


What's the link to join?  I'll try to be there.

Thanks for organizing!


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc is marked for autoremoval from testing

[Sebastian Kuzminsky]

Note that Jeff already "fixed" this by making LinuxCNC not use the buggy 
libtk-img library (turns out the functionality we used from that library had 
become available in core Tk).

I intend to upload a new LinuxCNC deb to unstable that closes this bug, which 
will prevent us from getting removed from testing.

-- 
Sebastian Kuzminsky


On June 29, 2022 10:56:46 AM MDT, "Steffen Möller"  
wrote:
>On 29.06.22 17:14, Stuart Stevenson wrote:
>> What does 'autoremoval from testing' mean? Is it good or bad?
>
>Harmless. Mostly :)
>
>When there is a bug to a package that is not fixed then the package is
>removed from the testing distribution of Debian that is the next stable
>release. And with it all packages that depend on that package need to
>go. Such removals are mighty annoying when the dependency just affects
>some borderline use of some software. On the plus side, this gets things
>fixed more quickly.
>
>A removal from testing does not mean that it is removed from unstable,
>i.e. the Debian distribution in which all uploaded packages appear
>before 5 days later transitioning to testing. This (very ironic) renders
>unstable sometimes more stable than testing.
>
>The background to this bug is that there was this abi change to the tiff
>library that affected the Img Tk library. This was first spotted from
>within LinuxCNC. I personally take this as an indication that LinuxCNC
>is one of the most-used Tk applications these days :) It is not our bug,
>though. And someone has already or is about to fix this.
>
>Such incompatibilities happen all the time. It is the main purpose of a
>Linux distribution to spot these and fix them. With LinuxCNC now being
>part of the very latest of Debian in Debian unstable (and unstable+5
>bugfree days = testing) LinuxCNC is more exposed to this
>distribution-development. A year from now the current testing
>distribution will be frozen, i.e. no more uploads and thus no more
>sudden incompatibilities, and after loads of bug fixes released as the
>new stable.
>
>Best,
>Steffen
>
>> 
>> On Thu, Jun 23, 2022 at 11:34 AM gene heskett  wrote:
>> 
>>> On 6/23/22 10:31, Debian testing autoremoval watch wrote:
>>>> linuxcnc 2.9.0~pre0+git20220402.2500863908-4 is marked for autoremoval
>>> from testing on 2022-07-13
>>>> It is affected by these RC bugs:
>>>> 1012789: linuxcnc-uspace: Linux CNC will not start
>>>>https://bugs.debian.org/1012789
>>> I beg to differ, this mornings install from the buildbot for both wintel
>>> and armhf machines
>>> is working fine. And has done so for every install here. sometimes at
>>> less than daily intervals
>>> for an updated install since the last time the buildbot was restarted.
>>> Pix of two machines running it are at:
>>> 
>>> 
>>> 
>>> This is all on uptodate buster.  The last time I tried to build on
>>> bullseye was on the rpi4 (armhf)
>>> and it failed on both a wintel and on an armhf because the python was
>>> too new.
>>> 
>>> 
>>>> 
>>>> This mail is generated by:
>>>> 
>>> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
>>>> Autoremoval data is generated by:
>>>> 
>>> https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
>>>> 
>>>> ___
>>>> Emc-developers mailing list
>>>> Emc-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>> .
>>> 
>>> Cheers, Gene Heskett.
>>> --
>>> "There are four boxes to be used in defense of liberty:
>>>soap, ballot, jury, and ammo. Please use in that order."
>>> -Ed Howdershelt (Author, 1940)
>>> If we desire respect for the law, we must first make the law respectable.
>>>- Louis D. Brandeis
>>> 
>>> 
>>> 
>>> ___
>>> 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

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-users] R2E3 retrofit

[Sebastian Kuzminsky]

On 6/26/22 01:30, Jon Elson wrote:
I just got an R2E3 Bridgeport mill in my basement, and will be doing a 
LinuxCNC retrofit.


Awesome!


When I bought my Bridgeport R2E3 it came with a bunch of manuals, which 
Stuart Stevenson kindly scanned into PDFs.  I contacted Bridgeport and 
got permission to redistribute them:


http://highlab.com/~seb/bridgeport-r2e3/


The LinuxCNC config for my machine is here:

https://github.com/SebKuzminsky/linuxcnc-config-bridgeport-r2e3


--
Sebastian Kuzminsky


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-developers] Is it still possible to build RTAI debs?

[Sebastian Kuzminsky]

On 6/28/22 02:04, andy pugh wrote:

Trying to address a recent request to add latency-histogram to the
menu, I have attempted to build a .deb

But my previous recipe (./debian/configure -r ) no longer works.

All my test machines (at the moment) are running an RTAI kernel.

Have we actually abandoned support for this whilst I was not looking?


Sort of, yes :-(

Since 2.9/master dropped support for all platforms that have packaged 
RTAI kernel debs on wlo, support for configuring debs for RTAI was 
removed in commit 6f285604ac1a1b58b2d65d5904ffec3998a833ef.


Does anyone know if the RTAI bug where it would crash ~1% of the time 
when you unloaded the RTAI kernel modules has been fixed yet?


I think it would be good to have (working) packaged RTAI kernels for 
newer distros and re-enable the option in debian/configure.


Anyone want to make RTAI debs for bullseye and bookworm?


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-users] Meldas TRS-50 servo amps, Mazak VQC 15/40

[Sebastian Kuzminsky]

I'm working with Petter Reinholdtsen trying to convert his Mazak VQC 15/40 to 
LinuxCNC, with Mesa interface hardware.  We have all the 24V stuff working, 
including the hydraulics and pneumatics, and we're getting data from the 
secondary resolvers on the ballscrews.  But we're having trouble getting the 
servo amps to respond.

Has anyone interfaced Meldas TRS-50 servo amps to LinuxCNC?  The maintenance 
manual we found was not much help in terms of the interface...

-- 
Sebastian Kuzminsky
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-developers] Interfacing to Magnescale scales

[Sebastian Kuzminsky]

On 6/14/22 08:21, Sebastian Kuzminsky wrote:

The machine has servos with resolvers, but the resolvers only connect
to the servo amps, not to the controller. The are connectors on the
amps for passing the resolvers on to the controller, but those cables
are not present.

Instead this machine has the fairly rare optional Magnescale option,
so each axis has magnetic linear scales (Sony SR-721RM scale with
MSD-9037 detector). These are connected directly to the controller,
and the old controller used them for position feedback. These are
circa 1987 or so.

Does anyone know how to interface these position sensors to
LinuxCNC?


Thanks for the help everyone, but this was a false alarm due to a 
misunderstanding on my part.  I blame the midsummer midnight sun.  This 
machine does not have Magnescales.


Each servo has a resolver that is connected only to the servo amp, and 
each ballscrew has a second, totally independent resolver that goes only 
to the controller.  We plugged the ballscrew resolvers into the Mesa 
7i49 and are getting good rotation information.  Whew, crisis averted!


Most of the low-speed stuff on the machine is working (relays & SSRs, 
hydraylic & pneumatic solenoids, the tool magazine, etc), and the axes 
and the spindle are very close to moving, I'll post all the details when 
we have success.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Interfacing to Magnescale scales

[Sebastian Kuzminsky]

I'm working with Pere/Petter Reinholdtsen on converting his Mazak 15/40.  It 
looks like a great machine, capable and compact, but we've run in to a bit of 
an issue.

The machine has servos with resolvers, but the resolvers only connect to the 
servo amps, not to the controller. The are connectors on the amps for passing 
the resolvers on to the controller, but those cables are not present.

Instead this machine has the fairly rare optional Magnescale option, so each 
axis has magnetic linear scales (Sony SR-721RM scale with MSD-9037 detector). 
These are connected directly to the controller, and the old controller used 
them for position feedback. These are circa 1987 or so.

Does anyone know how to interface these position sensors to LinuxCNC?

Another option might be to ignore the scales and access the resolvers by 
connecting to the currently unused resolver outputs on the servo amps.  I'm 
guessing in this case the servo amps provide the resolver excitation signal and 
we'd try to passively read the resolver response.

Thanks for any help...
-- 
Sebastian Kuzminsky
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot? no updates in about a week now.

[Sebastian Kuzminsky]

On 6/10/22 11:30, Jérémie Tarot wrote:


What about splitting out the docs in dedicated packages like many other
projects?

We could have linuxcnc-doc for english and then linuxcnc-doc-$lang for
translations. This in turn would allow us to build docs translation
packages at will.

In the future, this will also avoid installing 1Gb of 27 translations docs!


The English docs & each of the translated docs is already each in a 
separate package.  Users can choose which, if any, to install.


Or do you mean to split the repo, so the docs and the code are in 
different git repositories?  I'm opposed to that idea for a couple of 
reasons:


1. Having the code & the docs live together in one repo makes it easier 
to update both when either changes (ie, in the same PR), and simplifies 
release management.


2. Our "halcompile" infrastructure puts the code and the manpage for 
that code in the same file, so that infrastructure would have to be 
changed or discontinued.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot? no updates in about a week now.

[Sebastian Kuzminsky]

On 6/9/22 14:08, Hans Unzner wrote:

I only wonder why Petters fix (
https://github.com/LinuxCNC/linuxcnc/pull/1754) which should use po4a only
when the correct version is available, didn't resolve that.


Petter's fix made the linuxcnc build system detect that the po4a on 
Buster is too old, and disables building of translated docs (pdf & html 
files).


But the debian packages don't know that those docs did not get built, 
and still tries to build the debs for the translated docs.  The files 
that should go in those debs (the translated docs) are missing, so 
building the debs fails.


We could teach our debian packaging to know about build profiles 
(https://wiki.debian.org/BuildProfileSpec) and then switch the CI to use 
the `nodoc` build profile, but that would leave our poor old Buster 
users without local docs.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot? no updates in about a week now.

[Sebastian Kuzminsky]

On 6/9/22 10:42, andy pugh wrote:

.deb builds are currently failing:

http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/1818


debs are failing because the wonderful new translation infrastructure 
that just went into master requires a newer po4a than what's available 
on Buster.  (The version in Bullseye and newer works.)


So I think the best fix is to backport a working po4a to buster, and add 
the updated po4a debs to our deb archive on wlo.


I'm working on this now, hope to have something up later today.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] is the buildbot running?

[Sebastian Kuzminsky]

On 6/7/22 08:52, gene heskett wrote:

Cheers, Gene Heskett.


Should be fixed now, thanks for the bug report.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bug#1011093: sip6: fails to process __delattr__ in libarcus 5.0~beta (works with sip 6.5)

[Sebastian Kuzminsky]

On 5/19/22 05:42, Dmitry Shachnev wrote:

Hi Sebastian!

On Mon, May 16, 2022 at 01:18:11PM -0600, Sebastian Kuzminsky wrote:

Package: sip6
Version: 6.6.1+dfsg-2
Severity: important
X-Debbugs-Cc: s...@highlab.com

When trying to build libArcus 5.0~beta (part of the Cura slicer),
sip-build 6.6 produces bogus C++ output that fails to compile:

[...]
sippyArcuspart3.cpp:424:102: error: ‘sipName___delattr__’ was not declared in 
this scope; did you mean ‘sipName___setattr__’?


Can you please check if this upstream commit fixes the issue for you?

https://riverbankcomputing.com/hg/sip/rev/a5601579b8ad


Yes, that upstream commit fixes the libArcus build problem, good find!

:-)

--
Sebastian Kuzminsky

Bug#1011093: sip6: fails to process __delattr__ in libarcus 5.0~beta (works with sip 6.5)

[Sebastian Kuzminsky]

Package: sip6
Version: 6.6.1+dfsg-2
Severity: important
X-Debbugs-Cc: s...@highlab.com

When trying to build libArcus 5.0~beta (part of the Cura slicer),
sip-build 6.6 produces bogus C++ output that fails to compile:

[ 95%] Building CXX object CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o
/usr/bin/c++ -DSIP_VERSION=0x060601 -Dsip_pyArcus_EXPORTS 
-I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/src
 -I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/python 
-I/tmp/do-gbp.debian_unstable.master.xf2HJ/source/src -isystem 
/usr/include/python3.10 -g -O2 
-ffile-prefix-map=/tmp/do-gbp.debian_unstable.master.xf2HJ/source=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -flto -fno-fat-lto-objects -fPIC -std=c++17 -MD -MT 
CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o -MF 
CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o.d -o 
CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o -c 
/tmp/do-gbp.debian_unstable.master.xf2HJ/source/python/PythonMessage.cpp
/tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/pyArcus/pyArcus/sippyArcuspart3.cpp:
 In function ‘int slot_PythonMessage___setattr__(PyObject*, PyObject*, 
PyObject*)’:
/tmp/do-gbp.debian_unstable.master.xf2HJ/source/.pybuild/cpython3_3.10/build/pyArcus/pyArcus/sippyArcuspart3.cpp:424:102:
 error: ‘sipName___delattr__’ was not declared in this scope; did you mean 
‘sipName___setattr__’?
  424 | static void release_PythonMessage(void *sipCppV, int sipState)
  | 
 ^
  | 
 sipName___setattr__
make[3]: *** [CMakeFiles/sip_pyArcus.dir/build.make:233: 
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart3.cpp.o] Error 1


sip-build 6.5 in testing produces correct output and the project builds
fine.  This looks like another instance of problems with the new parser
in 6.6.


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1010910: python3-sipbuild: sip-build crashes while trying to parse

[Sebastian Kuzminsky]

Package: python3-sipbuild
Version: 6.6.1+dfsg-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: s...@highlab.com

I'm having trouble building libSavitar 5.0-beta (part of Cura, a slicer
for 3d printers): 

When building with sip 6.6.1+dfsg-1 it fails with this traceback:

'/usr/bin/cmake' '-E' 'env' 
'PYTHONPATH=::/home/seb/cura-debs/libsavitar-docker-sandbox/.pybuild/cpython3_3.9/build'
 '/usr/bin/sip-build' '--pep484-pyi' '--no-protected-is-public' '--verbose'
Using the CMake builder
These bindings will be built: pySavitar.
Generating the source files
Generating the pySavitar bindings...
sip-build: An internal error occurred...
Traceback (most recent call last):
  File "/usr/bin/sip-build", line 33, in 
sys.exit(load_entry_point('sip==6.6.1', 'console_scripts', 
'sip-build')())
  File "/usr/lib/python3/dist-packages/sipbuild/tools/build.py", line 37, 
in main
handle_exception(e)
  File "/usr/lib/python3/dist-packages/sipbuild/exceptions.py", line 81, in 
handle_exception
raise e
  File "/usr/lib/python3/dist-packages/sipbuild/tools/build.py", line 34, 
in main
project.build()
  File "/usr/lib/python3/dist-packages/sipbuild/project.py", line 249, in 
build
self.builder.build()
  File 
"/home/seb/cura-debs/libsavitar-docker-sandbox/.pybuild/cpython3_3.9/build/CMakeBuilder.py",
 line 12, in build
self._generate_bindings()
  File "/usr/lib/python3/dist-packages/sipbuild/builder.py", line 277, in 
_generate_bindings
buildable = bindings.generate()
  File "/usr/lib/python3/dist-packages/sipbuild/bindings.py", line 166, in 
generate
spec, sip_files = parse(self.sip_file, SIP_VERSION, encoding,
  File 
"/usr/lib/python3/dist-packages/sipbuild/generator/parser/parser.py", line 35, 
in parse
protected_is_public, include_dirs, strict).parse(sip_file)
  File 
"/usr/lib/python3/dist-packages/sipbuild/generator/parser/parser_manager.py", 
line 1454, in parse
self._parser.parse(self._read(sip_file), lexer=self._lexer,
  File "/usr/lib/python3/dist-packages/ply/yacc.py", line 331, in parse
return self.parseopt(input, lexer, debug, tracking, tokenfunc)
  File "/usr/lib/python3/dist-packages/ply/yacc.py", line 823, in parseopt
p.callable(pslice)
  File "/usr/lib/python3/dist-packages/sipbuild/generator/parser/rules.py", 
line 3097, in p_variable
fq_cpp_name = normalised_scoped_name(cpp_name, pm.scope)
  File "/usr/lib/python3/dist-packages/sipbuild/generator/utils.py", line 
156, in normalised_scoped_name
fq_scoped_name.prepend(scope.iface_file.fq_cpp_name)
  File 
"/usr/lib/python3/dist-packages/sipbuild/generator/specification.py", line 748, 
in prepend
new_name = list(scoped_name._name)
AttributeError: 'NoneType' object has no attribute '_name'

Building the same version of libSavitar on testing, which has sip
6.5.1+dfsg-1, works fine.

The problem is present in upstream, and is due to upstream's ongoing
effort to switch from parsing with bison & flex, to parsing with PLY
instead.  The new pure-python parser is not quite fully functional yet.
(The sip 6.5 in testing still uses the old bison/flex-based parser.)

After applying patches from upstream's mercurial repo, r2748 through
r2761, the parser now successfully handles libSavitar 5.0-beta.

Here is a gbp branch with these changes from upstream applied:

https://salsa.debian.org/seb_kuzminsky-guest/sip6/-/commits/debian/master/

That probably isn't in the correct format, if you give me feedback i'll
try to fix it, or feel free to do with it what you will.

We may also want to consider staying on sip 6.5 for a while, until the
new parser is more mature, but I defer to your judgement on this.


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: [Emc-developers] buildbot seems down

[Sebastian Kuzminsky]

On 4/10/22 10:50, andy pugh wrote:

On Sun, 10 Apr 2022 at 15:54, Sebastian Kuzminsky  wrote:


Fixed, thanks for the bug report.


Is there scope for a Bullseye builder? (I am wondering about Bullseye for 2.9)


It's on my todo list, but i'm so distracted these days that it's slow 
going.  The main hurdle is that to run a buildbot worker on Bullseye 
(and newer) requires an upgraded buildmaster.  I've started that upgrade 
and it looks like it's going to work, but it's slow going because [see 
above].


This brings up a question though...  The only value of the buildbot 
(over github Actions) is that the buildbot tests with the RTAI kernel, 
right?  The other platform (uspace) is adequately tested in github's 
containers, it seems to me.  Is anyone planning to make an RTAI kernel 
deb for Bullseye+?  If not, maybe we don't need the buildbot any more. 
Thoughts?



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot seems down

[Sebastian Kuzminsky]

On 4/9/22 21:15, Chris Morley wrote:

some builds say offline.


Fixed, thanks for the bug report.


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-users] LinuxCNC in debian, but not there yet. When?

[Sebastian Kuzminsky]

On 3/10/22 22:19, gene heskett wrote:

This machine is running bullseye.


It'll be an unknown amount of time before linuxcnc makes it into 
Debian's bullseye distribution, if ever.


It's currently only in sid (unstable), and will hopefully also be in 
bookworm (testing) after some work on our part...



--
Sebastian Kuzminsky


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] buildbot down?

[Sebastian Kuzminsky]

Yep, the buildbot is down.  Hope to have it back up in the next day or so.

--
Sebastian Kuzminsky


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-developers] LinuxCNC is in Debian!

[Sebastian Kuzminsky]

On 2/27/22 04:00, Debian FTP Masters wrote:
> Accepted:
>

Format: 1.8
Date: Fri, 25 Feb 2022 18:40:12 +0100
Source: linuxcnc
Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr linuxcnc-doc-zh-cn 
linuxcnc-uspace linuxcnc-uspace-dbgsym linuxcnc-uspace-dev
Architecture: source all amd64
Version: 2.9.0~pre0+git20220224.3ba0951743-1
Distribution: unstable


Yayyy!  Thank you Steffen, and Petter and everyone who's been working on 
getting LinuxCNC into Debian!


If you're running sid/unstable you can now just `apt-get install 
linuxcnc-uspace`, right from the debian.org package archive:


<https://packages.debian.org/linuxcnc-uspace>


It'll hopefully make it into bookworm/testing in a couple of days. 
We'll work on bullseye after that.  :-)



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-users] tests hanging?

[Sebastian Kuzminsky]

Those tests run for a long time normally.  Try `runtests -v` to get output 
while the tests are running.

-- 
Sebastian Kuzminsky

On February 10, 2022 11:39:58 PM MST, Andy Howell  wrote:
>When I run the test suite there are a number of tests that seem to 
>hang.  It could be I am just impatient. For example:
>
>tests/linuxcncrsh-tcp
>
>tests/linuxcncrsh
>
>tests/mdi-queue/oword-queue-buster
>
>Should I expect all the tests to run?
>
>I running this under Ubuntu 21.10 on an older laptop, Intel(R) Core(TM) 
>i7-4810MQ CPU @ 2.80GHz, 32GB memory. SSD drive.
>
>Thanks,
>
>Andy
>
>
>
>___
>Emc-users mailing list
>Emc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/emc-users

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-developers] linuxcnc_2.9.0~pre0-1+git20211120.a2b87d299-1_amd64.changes REJECTED

[Sebastian Kuzminsky]

On 2/10/22 09:06, Steffen Möller wrote:


On 10.02.22 17:00, Thorsten Alteholz wrote:

This version does not appear in latest changelog anymore ...


Thorsten just rejected the first of two submissions, the second was a
smallish correction that indeed is agnostic about the version from the
day before.


Is the only objection that the version doesn't appear in the changelog? 
 Or did I miss some email explaining further?


--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers