Re: [Emc-developers] Status of LinuxCNC in Debian
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
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
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
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
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
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
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?
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
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
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
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
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
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?
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
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!
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!
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?
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.
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
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
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
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!
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
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
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
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.
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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?
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?
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?
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?
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?
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?
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?
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
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
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
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?
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
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
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.
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.
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.
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?
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
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
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!
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
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
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
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
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
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
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!
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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?
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
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