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

2024-03-23 Thread 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

2024-03-23 Thread 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

2024-01-07 Thread 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

2023-12-27 Thread 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

2023-12-09 Thread 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

2023-11-05 Thread 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


[Emc-developers] Task/Motion startup race

2023-10-18 Thread 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?

2023-08-30 Thread 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

2023-08-30 Thread 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

2023-08-29 Thread 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

2023-08-10 Thread 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

2023-08-10 Thread 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-developers] website HTML docs are behind

2023-07-15 Thread 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: [Emc-developers] Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

2023-06-09 Thread 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

2023-06-07 Thread 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

2023-06-07 Thread 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

2023-05-03 Thread 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

2023-05-01 Thread 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

2023-04-22 Thread 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!

2023-04-22 Thread 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

2023-04-21 Thread 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

2023-04-12 Thread 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

2023-04-12 Thread 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

2023-04-07 Thread 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

2023-04-04 Thread 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

2023-03-26 Thread 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: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters

2023-03-21 Thread 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

2023-03-10 Thread 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!

2023-03-08 Thread 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!

2023-03-08 Thread 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?

2023-03-05 Thread 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-developers] Debian deadline.

2023-02-09 Thread 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


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

2023-01-13 Thread 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

2023-01-09 Thread 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

2023-01-09 Thread 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!

2023-01-04 Thread 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: [Emc-developers] Fwd: Bug#1025433: Copyright issue

2022-12-10 Thread 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

2022-12-10 Thread 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

2022-12-10 Thread 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.

2022-12-07 Thread 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

2022-12-05 Thread 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

2022-12-04 Thread 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

2022-12-04 Thread 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

2022-12-04 Thread 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

2022-12-01 Thread 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

2022-12-01 Thread 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

2022-11-27 Thread 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.

2022-11-24 Thread 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.

2022-11-23 Thread 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.

2022-11-23 Thread 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.

2022-11-15 Thread 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.

2022-11-15 Thread 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.

2022-11-14 Thread 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: [Emc-developers] linuxcnc on raspberry pi bullseye?

2022-09-16 Thread 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?

2022-09-15 Thread 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?

2022-09-14 Thread 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?

2022-09-05 Thread 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?

2022-09-05 Thread 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?

2022-09-04 Thread 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?

2022-09-04 Thread 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

2022-08-10 Thread 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

2022-08-06 Thread 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

2022-06-29 Thread 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-developers] Is it still possible to build RTAI debs?

2022-06-27 Thread 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


Re: [Emc-developers] Interfacing to Magnescale scales

2022-06-15 Thread 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

2022-06-14 Thread 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.

2022-06-10 Thread 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.

2022-06-09 Thread 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.

2022-06-09 Thread 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?

2022-06-07 Thread 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


Re: [Emc-developers] buildbot seems down

2022-04-10 Thread 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

2022-04-10 Thread 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


[Emc-developers] LinuxCNC is in Debian!

2022-02-27 Thread 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-developers] linuxcnc_2.9.0~pre0-1+git20211120.a2b87d299-1_amd64.changes REJECTED

2022-02-10 Thread 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


[Emc-developers] thinking about the next LinuxCNC release

2022-02-02 Thread Sebastian Kuzminsky
What are the big projects that need to get finished for the next 
release?  Some things I know vaguely about, but don't know the status of:


* Transition to gtk3 (required)

* Transition to python3 (required)

* Transition docs translations to po4a (optional but highly desired)

What is the status of those projects?

What in-progress projects are missing from this list?


--
Sebastian Kuzminsky


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


Re: [Emc-developers] @Seb, can we please have an RPi bullseye buildbot? Re: signed arm64 bullseye (armbian) binaries for download Re: trying to install linuxcnc built on buster on a bullseye system

2022-01-29 Thread Sebastian Kuzminsky

On 1/29/22 10:44 AM, Steffen Möller wrote:

32 or 64 bits, well, I think we want to see packages for both. Let's
wait for what Sebastian replies. I just saw on his page
http://buildbot.linuxcnc.org/buildslave-admin-guide.html that there are
buildbot difficulties with newer version that ship with bullseye and up.


The difficulty is that I haven't gotten around to upgrading the 
buildmaster - that's the limiting factor.  I've quietly done some tests 
and it seems that a new (bullseye/bookworm) buildbot master will happily 
talk to ancient (precise/wheezy) buildbot workers, so i think that 
particular hurtle isn't a blocker (unless there's something I missed, 
which is totally possible).


The issue with ARM builds is mostly in how annoying ARM hardware is, 
still.  The first ARM build "cluster" I made for the buildbot was a 
couple of Odroid U2's, running Debian (with the Odroid custom kernel) 
off micro SD cards.  They kept overheating and corrupting their SD 
cards, not fun to maintain.


The current ARM presence in the buildbot is a single Raspberry Pi 4 
running Raspbian off a Micro SD card, doing the builds and pbuilder on 
an old spinning-metal hard drive via a USB-to-SATA enclosure.  It's been 
rock solid, but it's very much not a "data center" quality setup.


I've heard maybe with recent firmware the Pi4 can boot off a 
USB-connected hard drive?  So maybe the SD card isn't needed for a 
modern build?


So one option is to buy a stack of Pi4's, USB-to-SATA enclosures (and 
maybe SD cards if that's still needed to boot from), and hard disks. 
One for each platform we want to run RIP tests on.  Each one costs maybe 
$100-$150.  (Once the Pi 4 becomes available again...)


Are there any good alternatives for building ARM clusters these days? 
All our x86/amd64 builds are done in VMs, on big amd64 servers, and that 
works really well.  Something similar for arm/adm64 would be ideal.



--
Sebastian Kuzminsky


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


[Emc-developers] Problematic race condition in LinuxCNC/HAL startup

2022-01-24 Thread Sebastian Kuzminsky
ey both think they hold the 
lock, and both think they are the one that should initialize `hal_data`.


5. The first process to run (`io` in the buildbot case above) 
initializes the `hal_data` structure, then unlocks, `init_hal_data()` 
returns to `hal_init()`, which adds the comp to the `hal_data` comp list.


6. The second process (`halcmd` in our case) then re-initializes the 
`hal_data`, which throws away the list of comps that had `io` in it, and 
now thing are irreparably broken - `halcmd` will never find `io`, 
because `io` is not in the list of hal comps any more.


[5]: https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/hal/hal_lib.c#L168

[6]: 
https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/rtapi/uspace_common.h#L55


[7]: https://man7.org/linux/man-pages/man2/shmget.2.html#DESCRIPTION

[8]: https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/hal/hal_lib.c#L2782

Why are things this way?  The obvious solution *for uspace* is to change 
`init_hal_data()` to take `hal_data->mutex`, using `rtapi_mutex_get()` 
not `rtapi_mutex_try()`, before checking `hal_data->version`, like 
this[9].  Since `shmget()` guarantees that a newly minted shared memory 
block is initialized to all bytes zero, and since all-bytes-zero is a 
valid, unlocked rtapi mutex, everything is good.


[9]: 
https://github.com/LinuxCNC/linuxcnc/commit/2f6c01fa09850b693e16e0dd50b6933b1a796fdb


I think possibly the weird startup stems from a shortcoming in RTAI, 
whose documentation[10][11][12] does *not* promise to initialize all 
bytes to zero the first time.  It seems we thus can't rely on 
`hal_data->mutex` being a valid unlocked mutex the first time, and thus: 
trylock, and the disaster that unfolds.


[10]: 
https://www.rtai.org/userfiles/documentation/magma/html/api/group__shm.html#ga63


[11]: 
https://www.rtai.org/userfiles/documentation/magma/html/api/group__shm.html#ga68


[12]: 
https://www.rtai.org/userfiles/documentation/magma/html/api/group__shm.html#ga24


But in my experimentation here locally, it appears that RTAI *does* zero 
shared memory the first time you allocate it.  It makes sense: if it 
didn't then userspace could look at old kernel memory, which is possibly 
a security problem...  Can any RTAI experts hit me with the clue bat here?


(There's a whole other weirdness in the `rt_shmem_new()` implementation 
in RTAI RTAPI, but i haven't looked at that in any detail.)


I have tested the proposed fix above on uspace (on Buster) and RTAI 3.9 
(on Wheezy) and it's been solid here.  I'd really like feedback before 
merging this into 2.8 & master...



--
Sebastian Kuzminsky


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


Re: [Emc-developers] Buildbot Hung

2022-01-10 Thread Sebastian Kuzminsky

On 1/10/22 4:39 PM, Phill C wrote:

The Builbot appears to have been hung for a while.


Kicked it, 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-developers] Confused about emcmotCommand

2021-12-31 Thread Sebastian Kuzminsky
It should probably be a tagged union.

https://en.m.wikipedia.org/wiki/Tagged_union

--
Sebastian Kuzminsky

On Fri, Dec 31, 2021, 09:22 andy pugh  wrote:

>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/motion.h#L216
>
> Basically the command to be executed goes in the command field, and
> then the system chooses the data fields that it wants to look at.
>
> But it seems rather wasteful. Would it not be more sensible to simply
> have "enough" doubles, ints, bools etc for each command, with generic
> names ("double_1" for example)
>
> As things stand, every time a new command is added, a few more
> variables get added to the struct, to be used once or never every
> run
>
> --
> 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-developers] Help us translate LinuxCNC into your language!

2021-12-11 Thread Sebastian Kuzminsky

On 12/11/21 8:10 AM, mar...@r-bechtold.de wrote:

why not just dont translate it all and start documentation the
functionality in a way a new users can actually use it?

for example the German version is extremely bad, don't fit in the
layout and makes totally no sense. everybody i know here in Germany
is using the english version because the documentation and the forum
fits to this.

I think we should make the documentation better and reduce it to 1
usefull Documentation not 4 before we bother to translate it to
french.


This Weblate interface only applies to the parts of LinuxCNC that are 
translated using gettext/po.  This is currently only the software, *not* 
the documentation.


The translations of the documentation has been neglected in LinuxCNC, 
largely because it predates good open-source tools for translating docs.


Those tools now exist (po4a!), and a group of developers (primarily 
Petter, Steffen, and Silopolis) are working to extend this 
gettext/po/Weblate translation system to our documentation, but as you 
correctly point out there's a bunch of work that needs to happen to 
clean up the docs before that can be useful.  It's in the works, but we 
want to get feedback on Weblate early.



--
Sebastian Kuzminsky


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


[Emc-developers] Help us translate LinuxCNC into your language!

2021-12-10 Thread Sebastian Kuzminsky
Hello everyone, I'm pleased to announce an easy new tool for improving 
the translations of LinuxCNC:


https://hosted.weblate.org/projects/linuxcnc/

You don't need to be a programmer, you don't need to install any special 
software on your computer -- you just need to know CNC terminology in 
your (non-English) language.


We welcome your translations!


--
Sebastian Kuzminsky


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


Re: [Emc-developers] Proposal: Delete the French Docs

2021-11-20 Thread Sebastian Kuzminsky

On 11/20/21 12:42 PM, Jérémie Tarot wrote:


So, I may restructure french doc and remove fixed lie width from main
documentation before comparing both translations, or, just remove fixed
line width from main doc and move all french files to a docs/archive/fr/
directory and start fresh, eventually using archived file as help...

Please share ideas and opinions to help carve the best path. Also please
tell me on which branch I should base these tasks.


Unless there's a strong reason to, please avoid making whitespace 
changes (such as deleting newline characters to combine short lines of 
"flowed" or "word-wrapped" text into a single long line).


There are a couple of reasons for this:

Spurious whitespace changes make it harder to track changes over time.

The git revision control system is line-oriented, which means that lines 
that fit on a screen are much easier to work with than lines that are so 
long that they wrap, or that you have to scroll the screen to see the 
end of them.



This is part of our "best practices for contributing" guidelines:

http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_follow_the_style_of_the_surrounding_code


That said, if there's a compelling argument for why this situation is 
special and the usual norms should be reconsidered, I'd be happy to hear it.



--
Sebastian Kuzminsky


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


Re: [Emc-developers] mesaflash_3.4.0-1_amd64.changes REJECTED

2021-11-19 Thread Sebastian Kuzminsky

On 11/19/21 11:00 AM, Thorsten Alteholz wrote:


Hi Sebastian,

please replace "Copyright: #YEAR# #USERNAME# <#EMAIL#> " by something better.
There are also lots of copyright holder missing in your debian/copyright.

   Thorsten


I tried to fix this.  Steffen, does this look right to you?

https://github.com/LinuxCNC/mesaflash/pull/58


--
Sebastian Kuzminsky


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


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

2021-11-15 Thread Sebastian Kuzminsky

On 11/15/21 4:42 AM, Stuart Stevenson wrote:

Sebastian,
   This is all above my pay grade but if there is anything I can do to help
with this workload let me know. Retirement can give you opportunities
previously unavailable. :) I can contribute a few hours a day to a project.
You will need to educate me on how this needs to be done. Give me a small
project, tell me how/what to do. Evaluate whether I can save you time or
energy by "helping".


Thanks Stuart!  I hope you're enjoying retirement :-)

If you know any languages besides English, it would be great if you 
could evaluate and help with Petter's work on translations.  He's 
bringing our translated docs up from the stone age, but doing so 
requires re-examining and integrating all the old out-of-date(?) 
translations.


His work-in-progress is in the `translate-po4a` branch at 
<https://github.com/petterreinholdtsen/linuxcnc>


Another thing that needs doing is to review and update the docs in 
master (<http://linuxcnc.org/docs/devel/html/>), especially the Getting 
Started section - I bet it's all kinds of out of date.



--
Sebastian Kuzminsky


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


Re: [Emc-developers] Processing of linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes

2021-11-08 Thread Sebastian Kuzminsky

On 11/8/21 6:16 PM, Debian FTP Masters wrote:

linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.changes uploaded successfully 
to localhost
along with the files:
   linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1.dsc
   linuxcnc_2.9.0~pre0+git20211108.cf14c89a9.orig.tar.xz
   linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1.debian.tar.xz
   linuxcnc-doc-cn_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
   linuxcnc-doc-en_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
   linuxcnc-doc-es_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
   linuxcnc-doc-fr_2.9.0~pre0+git20211108.cf14c89a9-1_all.deb
   linuxcnc-uspace-dbgsym_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
   linuxcnc-uspace-dev_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
   linuxcnc-uspace_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.deb
   linuxcnc_2.9.0~pre0+git20211108.cf14c89a9-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)


Wooo h!

Huge thanks to Steffen Möller and Petter Reinholdtsen of the Debian 
project for all their work getting LinuxCNC into an acceptable state for 
inclusion into Debian, and for uploading our packages to the NEW queue.


There's surely more work to do, but if all goes well I expected starting 
with the next release of Debian 12 "Bookworm", users will be able to 
install LinuxCNC (and all dependencies, including the RT-Preempt 
realtime kernel) directly from the debian.org package archives.  Shortly 
thereafter the derivative distributions like Ubuntu and Mint will pick 
up LinuxCNC.


This will make it much easier for people to try out LinuxCNC, and will 
greatly increase our visibility in the CNC software world.


This is an exciting time for LinuxCNC, and we could not have done it 
without Steffen and Petter.  Thank you!  <3



--
Sebastian Kuzminsky


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


[Emc-developers] RFC: doc translations

2021-11-08 Thread Sebastian Kuzminsky
Hello LinuxCNC people, there's a possible change brewing that I'd like 
to ask for your feedback on.


The translations of our documentation into non-English languages has 
been handled in an unusual and cumbersome way, and a new developer has 
suggested a plan to modernize and streamline things.



How things are now:

* All our documentation is maintained in Asciidoc format in the git 
repo, and built into HTML and PDF by the build system.


* The "main" documentation is maintained in English.

* To create a new translation, a translator copies the asciidoc source 
of the English documentation to a new language-specific asciidoc source 
file.  For example: `README.adoc` -> `README_fr.adoc`.  They edit the 
new file and translate the words.


That's it!  Simple, but it has a couple of problems...


Problems with the current system:

* If the English-speaking developers change the main documentation file 
there is no automatic process to notify the translators, and the 
translated docs slowly drift out of date with the main English docs, 
without us really knowing.


* The translations of the docs are handled differently than the 
translations of the software.  The translations of the strings in the 
software is done using a widely used system called "gettext", which has 
a suite of tools to identify translatable strings in programs and 
maintain a database of what those strings should look like in different 
languages.  You can learn more about gettext here: 
<https://www.gnu.org/software/gettext/manual/gettext.html#Why>



The new proposal is basically to use gettext for everything, both the 
software and the documentation.  This would be done using a system 
called po4a: <https://po4a.org/>


Moving the docs translations to po4a would let us use the standard 
gettext tools, including online tools like Weblate, to maintain the 
translations.  gettext keeps track of what "main" english strings have 
changed, and flags the translations of those strings as "out of date", 
so that translators know they need attention.  Out-of-date translations 
automatically fall back to using the up-to-date english strings.


I'm not very experienced with translations, so I'm asking for comments 
from the folks who currently do the work of translating LinuxCNC (both 
docs & software) into non-English languages...


Do you have any concerns, input, or comments on this proposal?

Would you be willing to verify and update the translations into your 
languages?


What can we software people do to help make this task easier?


Thanks!


--
Sebastian Kuzminsky


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


Re: [Emc-developers] armhf just killed linuuxcnc

2021-10-18 Thread Sebastian Kuzminsky

On 10/18/21 11:42 AM, Sebastian Kuzminsky wrote:

On 10/18/21 5:01 AM, Gene Heskett wrote:

kmod_module_remove_module() could not remove 'spi_bcm2835':
Operation not permitted


Thanks for the bug report Gene.

I broke master, for rpi4 and everything else.  Sorry!  Fixing it now...


This is fixed now -- debs from the buildbot should work again.

--
Sebastian Kuzminsky


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


Re: [Emc-developers] armhf just killed linuuxcnc

2021-10-18 Thread Sebastian Kuzminsky

On 10/18/21 5:01 AM, Gene Heskett wrote:

A linuxcnc -l now exits:

pi@rpi4:~/linuxcnc/configs/sheldon-lathe $ linuxcnc -l
LINUXCNC - 2.9.0-pre0-4802-g948693d0a
Machine configuration directory is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX non-realtime
hm2: loading Mesa HostMot2 driver version 0.15
rmmod: ERROR: ../libkmod/libkmod-module.c:793 kmod_module_remove_module() could 
not remove 'spi_bcm2835':
Operation not permitted
rmmod: ERROR: could not remove module spi_bcm2835: Operation not permitted
hm2_rpspi: ERROR: Failed to execute '/sbin/rmmod spi_bcm2835'


Thanks for the bug report Gene.

I broke master, for rpi4 and everything else.  Sorry!  Fixing it now...


--
Sebastian Kuzminsky


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


Re: [Emc-developers] Updating linuxcnc

2021-10-05 Thread Sebastian Kuzminsky

On 10/5/21 7:09 PM, Sam Sokolik wrote:

I changed it back to  <http://linuxcnc.org>
deb http://linuxcnc.org stretch base 2.8-rtpreempt

And update/upgrade didn't change anything..  so it worked?


Try `apt-cache policy linuxcnc-uspace` to see what your local apt can 
get to, and what it thinks of its options.



$ apt-cache policy mesaflash
mesaflash:
  Installed: 3.4.0-1
  Candidate: 3.4.0-1
  Version table:
 *** 3.4.0-1 500
500 http://linuxcnc.org bullseye/base amd64 Packages
500 http://highlab.com/~seb bullseye/base amd64 Packages
100 /var/lib/dpkg/status




--
Sebastian Kuzminsky


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


Re: [Emc-developers] Proposal: Delete the French Docs

2021-08-17 Thread Sebastian Kuzminsky
I'm in favor of deleting out-of-date translations of documentation, sad 
as that is.  Better to have nothing than to have old misleading information.


There's a system for managing translations of documentation called 
`po4a`: https://po4a.org/index.php.en


More info here: https://po4a.org/man/man7/po4a.7.php

It uses the same `gettext` tools and PO files that we currently use for 
translating the software, which seems like a good thing.


Francis Tisserant (the main French translator person back in 2015) and I 
looked into it a little bit back in 2014/2015, it seemed very promising 
but as I recall the tools weren't quite usable yet and we dropped the 
project.  Maybe the tools have matured since then?  The branch is still 
in our git repo (`seb/master/po4a`).


--
Sebastian Kuzminsky

On 8/17/21 12:41 PM, JT wrote:
I'd think that from 2.8 on to delete the french documents in case 
someone is still using an old version.


JT

On 8/17/2021 7:22 AM, andy pugh wrote:

The French docs are so out of date that they have become misleading.

They are probably worse than useless. For example the "Getting
LinuxCNC" describes Ubuntu 10.04 as "current".




___
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-developers] Using `main` instead of `master` branch

2021-07-29 Thread Sebastian Kuzminsky

On 7/29/21 2:18 PM, Jeff Epler wrote:

For those who desire more background, both on the motivation and on the
breadth of organizations that are choosing to make this change:


The buildbot and surrounding scripts will need minimal updates to 
implement this change.


The buildbot deb archive will need a minor reorg, which means users will 
need to update their sources.list.


I volunteer to do this work.

--
Sebastian Kuzminsky


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


Re: [Emc-developers] Mesaflash Versions

2021-06-23 Thread Sebastian Kuzminsky

On 6/21/21 5:11 PM, andy pugh wrote:

The LinuxCNC repo carries Mesaflash 3.4.0~pre1, a tag released
something over a year ago.

Who is in charge of Mesaflash releasing? Does the buildbot make
packages, or is that a manual process?


The release process looks something like:

1. Update changelog.

2. Make a new release tag.

3. Make a dsc from that release tag.

4. Build the dsc by hand, using pbuilder, on all the supported platforms.


--
Sebastian Kuzminsky


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


Re: [Emc-developers] Buildbot

2021-03-07 Thread Sebastian Kuzminsky

On 3/6/21 11:49 PM, Phill Carter wrote:

Buildbot has a lost slave.



Bounced, 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-developers] BuildBot

2020-12-31 Thread Sebastian Kuzminsky

On 12/30/20 8:08 PM, Phill Carter wrote:

Buildbot seems to have been asleep for a while.


The wheezy-i386 buildslave locked up, I rebooted it and now the buildbot 
is making progress again.


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-developers] What to do about the docs?

2020-11-23 Thread Sebastian Kuzminsky

On 11/23/20 4:31 PM, andy pugh wrote:

On Sun, 22 Nov 2020 at 21:30, Jérémie Tarot  wrote:


https://crowdin.com/project/linuxcnc) would really help translators work
and maybe build a team for this task...

Does it cost money? The LinuxCNC project has literally no money.


To better benefit these, it seems preferable that l10n strings be stored in
dedicated files rather than embedded in source files. So could be that
adding gettext support to comps could be more better suited...

I _think_ that gettext only works in the context of source code. I
could be wrong, though.
I looked in to gettext for halcompile and couldn't see how to make it work.


Francis Tisserant and I played around with po4a a couple of years ago.  
po4a is a tool that helps maintain translations of documentation - it 
lets you use gettext on asciidoc docs.  I'm not sure if it would work on 
.comp files etc.


It wasn't quite ready back then, but I bet it is now.


--
Sebastian Kuzminsky


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


Re: [Emc-developers] Python3 on the buildbot

2020-11-15 Thread Sebastian Kuzminsky
We have that already:
http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3

On Sun, Nov 15, 2020, 12:26 Jose Luis  wrote:

> Hello,
>
> Could be possible to add python3 builds to the buildbot
>
>
> Thanks
>
>
>
> ___
> 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-developers] Buildbot

2020-10-13 Thread Sebastian Kuzminsky

On 10/10/20 7:18 PM, Phill Carter wrote:

Buildbot appers to be be asleep.


Fixed.  Thanks for the bug report.

When the buildbot takes a vacation it's nearly always because one of the 
builders crashed and needs to be manually rebooted.



--
Sebastian Kuzminsky


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


Re: [Emc-developers] Buster and F-~Engrave / True-Type-Tracer

2020-09-04 Thread Sebastian Kuzminsky
I agree, no need for f-engrave.


On Fri, Sep 4, 2020, 18:05 Phill Carter  wrote:

>
>
> > On 5 Sep 2020, at 4:52 am, andy pugh  wrote:
> >
> > The Debian Wheezy repository contains a few applications in addition
> > to LinuxCNC.
> > Should these also be included in the Debian Buster repository, or are
> > these abandoned projects?
>
> I see F-Engrave is available from Scorchwoks so probably no need for it to
> be included.
>
> Cheers, Phill
>
> ___
> 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-developers] Now what?

2020-08-30 Thread Sebastian Kuzminsky

On 8/30/20 4:07 PM, andy pugh wrote:

I had what I thought was a stable and "good enough" status to push 2.8.
But somehow pushing only a changelog change has led to a set of
runtests failures.

How is that possible?


This situation does happen from time to time.  It's most likely due to 
flaky tests - maybe due to race conditions, or some other form of 
indeterminacy, either in the tested code or in the test itself.


I just built the 2.8 branch on my computer here (Buster, rtpreempt, 
amd64, 8 CPUs, 32 GB RAM), and am running the test suite in a loop. 
I'll report back if anything fails...



--
Sebastian Kuzminsky


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


Re: [Emc-developers] 2.8.0-pre3

2020-08-27 Thread Sebastian Kuzminsky

On 8/24/20 6:31 PM, andy pugh wrote:

On Mon, 24 Aug 2020 at 11:25, Håvard Flaget Aasen
 wrote:


There is still a minor issue with the dependencies when you are packaging.
In debian/control.bottom.in this line has been added to Recommends:
python-gst-1.0 | python-gst0.10,


I see this here:
http://buildbot.linuxcnc.org/buildbot/builders/3303.dsc-stretch-rtpreempt/builds/1691/steps/shell/logs/warnings%20%284%29

It looks like we can quieten another warning there by changing the
Standards-Version in control.top.in.
But is that something you can just do if you don't even know what the
standards requirements are?


No.  Changing the Standards-Version in the control file signals that 
your package adheres to the new Standards-Version, so we would need 
significant work on our packages in order to do that.


Here are the changes between Standards-Versions.  This is a huge task.

https://www.debian.org/doc/debian-policy/upgrading-checklist.html


--
Sebastian Kuzminsky


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


  1   2   3   4   5   6   7   8   9   >