#linuxcnc-devel Logs

Oct 07 2023

#linuxcnc-devel Calendar

02:33 AM pere: andypugh: believe I found the problem. In 339a94933bacfcc28c256cb0e2dce82c0d4fd85f you removed the heading "Calibration (emccalib.tcl)", which is linked to from docs/src/gui/qtvcp-widgets.adoc under "CALIBRATION".
04:38 AM rigid: pere: there seem to be more issues. also "../docs/html/nb/hal/rtcomps.html:863: parser error : Entity 'pi' not defined second. Change to 60 for RPM, to 360 for degrees per second, 6.283185 (= 2*π"
04:40 AM pere: rigid: yeah, but I believe that one is ignored during build, so not to worry. Perhaps we should use the unicode char instead?
04:40 AM rigid: (i'd just use the unicode symbol here: π)
04:40 AM rigid: it says "parser error" so I guess it's causing the early abnormal exit
04:41 AM rigid: or were those errors present in previous suceeding runs aswell? hm
04:41 AM pere: the abnormal exit is something else, broken links. <URL: https://github.com/LinuxCNC/linuxcnc/pull/2681 > should fix it.
04:42 AM pere: the &pi; has been there for a long time, so it is not fatal. no idea if it show up properly in the PDF, thought.
04:43 AM pere: rigid: perhaps you can check out the PDF and make a pull request for &pi;->π?
04:46 AM rigid: pere: i'm currently struggling with linuxcncrsh and broken CMS. But you can try to run this to change all occurences: "cd docs && find -name '*.adoc' -exec sed -i 's|&pi;|π|g' {} \;"
04:47 AM rigid: this will find all .adoc files inside the doc/ directory and replace any &pi; with π
04:50 AM rigid: hm, the HTML doc build seems to throw a lot of errors. Like "grep: ../docs/man/man1/emccalib.1: No such file or directory"
04:56 AM pere: rigid: git is not completely at your command, I take it? :)
04:57 AM pere: emccalib.1 was just added by me. perhaps a typo.
04:57 AM rigid: pere: not sure what you mean
04:57 AM rigid: ah ok
04:58 AM pere: if git was completely at your command, making a new branch and pushing a new change would be a quick job that did not interfere with your linuxcncrsh work. :)
05:00 AM pere: rigid: I take you too are not in Stuttgart. :)
05:04 AM rigid: pere: git is not an issue. time is. There's paid-work stuff to be done :-(
05:04 AM rigid: no, I'm in Munich. Stuttgart is lovely tho :) Some kind of LinuxCNC meeting?
05:05 AM pere: found and fixed emccalib related typo.
05:05 AM rigid: yay \o/
05:05 AM pere: rigid: yes, this weekend. at least andypugh and rene-dev5 are there.
05:05 AM rigid: ah
05:07 AM pere: time is a limited resource here too, and I want to check out pi in the PDF to know if it is just cosmetic or a visual error.
05:07 AM rigid: sadly I got no time, I could show some nice photos of huge machine hall all run by linuxcnc
05:07 AM pere: nice. I only got one old Mazak running LinuxCNC. :)
05:07 AM rigid: unicode should "just work" (tm)
05:08 AM pere: slowly we are getting where UTF-8 just work, but I prefer to test and verify, not just believe and trust. :)
05:08 AM rigid: pere: it's not mine. I got a cheapo chinese open-loop CNC mill here for testing (~190€ lock & stock). Still fun tho :)
05:09 AM pere: Started a new build, will know in an hour.
05:09 AM * rigid crosses fingers
05:10 AM pere: perhaps emccalib.tcl(1) should be emccalib.tcl(9) instead?
05:11 AM pere: The script is in /usr/lib/tcltk/linuxcnc/bin/, so not in PATH.
08:28 AM pere: andypugh: did you not like the man page I wrote in <URL: https://github.com/LinuxCNC/linuxcnc/pull/2681 >?
08:39 AM pere: rigid: doc build in master should be working now. you might want to rebase.
08:45 AM rigid: pere: cool, tnx
09:05 AM pere: rigid: note, merging master into your branch can cause merge issues later, while rebasing on master will cause you to discover these issues sooner.
09:13 AM rigid: pere: I synced master via github and the ran "git rebase master" from each branch and pushed
09:13 AM rigid: what issues could arise when there are no conflicts?
09:13 AM pere: aha. I just saw the email about merging master.
09:14 AM pere: I've seen merges gone wrong, cleaned up the wrong way and ending up removing changes from master that were intended to be in master.
09:15 AM rigid: hm, git should prevent that. Hasty conflict resolving or blind merge approval could cause these issues.
09:15 AM rigid: but tbh, it's easy to mess up with git :)
09:16 AM pere: using rebase on master, it is obviuos from the diff presented in the web interface which changes will be included in the pull request. with merges from master into the pull request branch it is not so clear.
09:17 AM rigid: pere: ah you mean the merge from master to 2.9 I tried yesterday?
09:18 AM rigid: cause the diff doesn't show other commits despite the merge: https://github.com/LinuxCNC/linuxcnc/pull/2679/files
09:19 AM rigid: i tried the github-web-ui-method to change the branch of the PR to 2.9 with edit -> select another bracnh but that totally messed it up.
09:19 AM pere: perhaps you are not heeplr on github?
09:19 AM rigid: i am
09:19 AM pere: I mean emails I received today.
09:19 AM rigid: hm, strange
09:20 AM pere: for example this message: @heeplr pushed 1 commit. c6ed5a32985b18a2eb2c46f7c855ac644c2cf9d2 Merge branch 'LinuxCNC:master' into fix-toolnml-build
09:21 AM rigid: yep, it's also shown here: https://github.com/LinuxCNC/linuxcnc/pull/2679/commits
09:22 AM rigid: but the diffs didn't change and I'm not sure why it says merge. Maybe because I synced my master via github web ui
09:22 AM rigid: ...then rebased the linuxcncrsh-test branch to that
09:23 AM rigid: should merge fine unless someone touches the relevant test-files in the meantime
09:27 AM pere: hm, the tests/interp/g72-facing/ and tests/interp/g72-missing-iteration output seem to have changed between 2.9 and master. :/
09:30 AM rigid: pere: git blame?
09:32 AM rigid: oh, another linuxcncrsh bug: "if (spindle < 0 || spindle > EMCMOT_MAX_SPINDLES)" is off by one when starting at 0
09:33 AM rigid: shoudda rewrite the whole thang :-P
09:34 AM pere: rigid: no need. I know who is to blame, and the fix is to update the expected files.
09:35 AM rigid: spiderman_pointing_at_spiderman.jpg
09:38 AM pere: no idea why START_CHANGE() disappeared and CHANGE_TOOL(2) became CHANGE_TOOL(). andypugh, do you have any idea what is going on?
09:39 AM pere: See for example the failing tests in <URL: https://github.com/LinuxCNC/linuxcnc/actions/runs/6441522995/job/17491411267?pr=2669 >.
09:44 AM pere: <URL: https://github.com/LinuxCNC/linuxcnc/pull/2682 > should fix it, but I do not understand why it is needed.
09:58 AM rigid: hm, the docs at the head of https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/emcrsh.cc#L49 and the man page at http://linuxcnc.org/docs/devel/html/man/man1/linuxcncrsh.1.html are out of sync
09:59 AM rigid: honestly I'd just remove it completly and replace it with the URL to the man page. that's clickable in most IDEs
10:03 AM rigid: also some of the signatures are wrongly documented when they differ between get and set
10:08 AM pere: seem like code review have failed to hold the quality high. perhaps you can help. I try to send a patch for everything I discover, as I do not expect anyone else to do so.
10:10 AM rigid: yeah, code quality review should be automated to some extent. foss lives from users like you.
10:11 AM rigid: i'm just trying to get NML networking going again to maybe upgrade some ancient setups. maybe adding missing features to get all GUIs working outside the realtime environment...
10:12 AM rigid: ...my PRs are just the first brickwalls I encountered :)
10:13 AM pere: rigid: aha. what is NML used for outside linuxcnc?
10:15 AM rigid: pere: good question, I didn't find anything. It's basically a free implementation of the NIST rcslib. RCS seems to be some standard in the industry (or has been? not sure)
10:16 AM pere: I have heard linuxcnc developers suggest to drop nml as it is only making development harder without any advantages. perhaps you agree?
10:17 AM rigid: point is, linuxcnc has a complete network architecture allowing you to run core components on different hosts. i.e. HAL on machine controller, monitoring on a remote host, GUI on a site host. But that broke at some point.
10:19 AM rigid: I don't agree at all. It's why people used it initially. To not be forced to run some windows environment on your controller and still have a single suite for CNC. Alternatives were shitty controllers or a ton of different software suites for control/monitoring/erp etc.
10:20 AM rigid: But NML code (as a lot of other code I've seen) is not up to modern standards anymore. There are modern alternatives that can do exactly the same thing and (theoretically) need zero maintenance.
10:20 AM pere: is RCS used anywhere, then?
10:20 AM rigid: not sure but there is a lot of code running that plugs into NML
10:21 AM pere: URL to such code?
10:21 AM rigid: i've seen nothing open but on the forum are a few threads if you're interested: https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc
10:22 AM rigid: i suppose the majority of companies don't publish their code
10:23 AM rigid: don't get me wrong: i wouldn't disagree to force those to upgrade to modern standards but locking them out or redesign their stuff to get it work with other interfaces might be a showstopper
10:24 AM pere: I guess <URL: https://github.com/LinuxCNC/linuxcnc/pull/2531 > demonstrate some of the current problems with todays NML.
10:24 AM pere: I suspect macros, classes and other machinery could make life a lot easier, but todays implementation is horrible to update and extend.
10:24 AM rigid: i mean, removing NML without replacement basically makes a simple desktop app from what was a fullblown industry suite before.
10:25 AM rigid: yeah, the code is very cumbersome to work with
10:27 AM rigid: pere: not too sure but glancing at that PR suggests that some generic HAL support is missing, right?
10:27 AM pere: having to update a lot of files just to get one minor change in can be done better. :)
10:27 AM pere: rigid: it was basicly my first draft for standardizing a worklight pin, modeled after the coolant pins.
10:28 AM pere: probably not the right approach, but it gave me an idea how to update NML, and I did not like it. :)
10:28 AM rigid: pere: yeah. I'd guess that coolant pins have been implemented differently once before HAL was a thing. Hard to say
10:29 AM pere: I too believe HAL is newer.
10:29 AM rigid: pere: looks clean tho. did you have to look up a lot of docs or take a long time to get it to work?
10:30 AM rigid: since verboseness is just a side effect of C/C++
10:30 AM pere: not really. searched for coolant, replicated as worklight. :)
10:30 AM rigid: saying that, I think 90% of linuxcnc should be ported to python :-P
10:30 AM pere: I expected 1-5 line change to add a new pin...
10:31 AM rigid: yeah, not in C
10:31 AM pere: it could have been using macros and classes, but that is not the current code. :)
10:33 AM rigid: ah, https://github.com/LinuxCNC/linuxcnc/pull/2531#issuecomment-1597676640
10:33 AM rigid: i see
10:35 AM rigid: the nml stack could serve an abstract HAL interface. If HAL introduces pin/signal/... classes & descriptions, UIs could use those transparently
10:36 AM rigid: pere: like you don't need any code change of the NML stuff. you just configure your worklight pin, assign it a free class-id like "worklight" and implement that class in the UIs
10:37 AM rigid: i mean, HAL could in theory even define some icon name that's passed around all the way to UIs. I wouldn't do that tho...
10:38 AM Roguish: Interesting discussion. Just remember that there has been an exponential evolution of hardware and software since NIST started this thing.
10:39 AM pere: since TCP/IP was standardized too.
10:39 AM rigid: Roguish: sure, current linuxcnc wouldn't pass industry requirements in a lot of countries.
10:42 AM pere: why not?
10:43 AM rigid: ...also ppl were built differently back then. I bet an old version of libnml doesn't yield nearly as much cppcheck errors as the rest of the code
10:45 AM rigid: pere: memory leaks for example.
10:46 AM pere: I believe the first quote from grown ups complaining about the youth of today is from Aristotle, 2500 years ago. I assume it is equally true today as it was then.
10:47 AM rigid: heh yeah. But take into account that those people had a LOT of time to spend on their code back then. And complexity was miniscule, so you had time for details.
10:47 AM rigid: that's a LOT of manhours
10:49 AM pere: it is a lot of manhours, for sure. these days we have coverity, valgrind and a lot of tools to help us, and the free software mentality and movement, and these have raised the quality of software a look
10:49 AM pere: s/look/lot//
10:49 AM rigid: but "built differently" also. they sat on wooden chairs :-P
10:50 AM rigid: pere: well, that's right. but neither valgrind nor coverty or the best CI doesn't help if you don't use it
10:50 AM pere: yeah
10:50 AM rigid: do we measure test coverage in linuxcnc?
10:51 AM pere: not that I am aware of.
10:51 AM rigid: haven't seen any
10:51 AM rigid: never done that in C. it's probably a pain.
10:52 AM pere: not that painful, but python is a lot easier. :)
10:52 AM rigid: ah, there's gcov. if it's similar to gprof, it's quite straight forward
10:53 AM pere: I've been pushing for more scripts in tests/, but it is a long way before we can be confident things work based on automated tests.
10:53 AM rigid: it's hard to really screw up in python
10:53 AM pere: haha. No it is not. :P
10:53 AM rigid: with a decent testkit? nah...
10:54 AM rigid: and smelly code is also easy to recognize
10:56 AM rigid: well, static code checking would be a good start for linuxcnc. cppcheck, shellcheck, flake8 inside CI should cover almost everything I guess
10:59 AM pere: rigid: perhaps you can help with <URL: https://github.com/LinuxCNC/linuxcnc/pull/1581 > :)
11:00 AM pere: The github CI runs have helped a lot avoiding stupid mistakes from entering the code base. :)
11:02 AM pere: for example it automatically check translations for build breaking typos before we merke them. :)
11:13 AM rigid: ah nice, haven't seen that
11:15 AM rigid: hm... i wonder if cppcheck should be integrated into the build system at all. Just make it non-fatal in CI and you're golden
11:15 AM rigid: or fatal even
11:15 AM rigid: and maintain exceptions for false-positive in the code
11:16 AM pere: non-fatal first, then fix issues and make it fatal, I guess.
11:16 AM rigid: yea
11:19 AM rigid: looks sound to me. maybe maintain directories in separate variables
11:20 AM rigid: why isn't it merged?
11:24 AM rigid: tbf, github web ui is really slick to use
11:25 AM rigid: pere: I created https://github.com/smoe/linuxcnc/pull/3
11:43 AM rigid: lol, I did see that. even liked it and forgot about it. tsts
11:45 AM pere: not quite sure why that effort stopped. assume steffen just ran out of time to work on it.
12:23 PM pere: rigid: any idea why <URL: https://github.com/LinuxCNC/linuxcnc/actions/runs/6442135133/job/17492647271 > failed?
12:35 PM rigid: pere: gcode-output file missing?
12:36 PM pere: incomplete test or something else?
12:36 PM rigid: no, linuxcnc isn't generating the gcode-output file in that run for some reason
12:38 PM rigid: pere: that's done by defining [RS274NGC] USER_M_PATH in the ini and then in a "M100" script write each command to gcode-output
12:38 PM rigid: maybe you changed something that M100 isn't called anymore?
12:38 PM rigid: dunno
12:39 PM pere: I do not know either, but doubt something changed to do this explicitly.
12:41 PM rigid: well, ever "set mdi ..." command fails, so something broke
12:43 PM rigid: otoh, i also suspected some rather non-deterministic stuff during testing. but didn't look further into it.
12:50 PM pere: Perhaps the same problem as with <URL: https://github.com/LinuxCNC/linuxcnc/issues/2644 >?
12:50 PM Unterhaus_ is now known as Unterhausen
12:58 PM linuxcnc-build2: Worker `precise-rtai-i386` is missing. It was seen last on Sat Oct 7 10:54:52 2023.
12:58 PM linuxcnc-build2: Worker `checkin` is missing. It was seen last on Sat Oct 7 10:54:52 2023.
01:03 PM rigid: pere: no, the raster test never failed for me
01:04 PM pere: it only fail once in a while on github. no idea why.
01:04 PM rigid: nice, smoe merged my PR
01:05 PM rigid: i'm trying to introduce a bit more robustness into linuxcncrsh ... let's see how ppl like it, maybe i'll touch deeper then
01:37 PM pere: look like we are overloading the github CI system. a huge backlog of runs.
01:48 PM rigid: yeah, and runs are not really optimized
01:50 PM rigid: hm, seems I can stop working on linuxcncrsh if network support will go. telnet alone would be like going back to serial comm :-P
02:01 PM rigid: is gmoccapy here with different nick? off topic issue conversation on github just feels wrong
02:05 PM rigid: ...i suppose no one in here has their tooltable connected to their ERP framework. But anyone must have heard about it?
02:08 PM rigid: *someone
02:08 PM pere: rigid: do not believe he is here.
02:08 PM pere: I have not heard of it. :P
02:08 PM rigid: he should
02:09 PM pere: I believe all developers should be here, but apparently I am not in the majority. :)
02:10 PM rigid: is there some discord or something?
02:10 PM rigid: discord seems to be the bees knees now
02:20 PM pere: no idea, and not as far as I know.
02:21 PM pere: I believe it is email, irc, forum and github.
03:12 PM linuxcnc-build: build #3499 of 1660.rip-buster-python3 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/3499 blamelist: Phillip Carter <phillc54@users.noreply.github.com>
03:16 PM rene-dev5: Rigid will be possible soon. Any feature requests?
03:18 PM rigid: rene-dev5: well, basically just keep the NML layer capability (or something similar global)
03:18 PM pere: rene-dev5: talking about your sqlite work?
03:19 PM rigid: the interface seems to need just a few lines of code. https://github.com/search?q=repo%3ALinuxCNC%2Flinuxcnc%20TOOL_NML&type=code
03:19 PM rigid: so maybe it's not a lot of effort
03:19 PM rene-dev5: Trust me there is more to it. The interface is broken by design.
03:20 PM rigid: in what way? maybe it's worth to go great lengths to fix it
03:21 PM rene-dev5: Im in the process of fixing it
03:21 PM rene-dev5: will do a writeup about it.
03:21 PM rene-dev5: did you get the renote ui to work?
03:23 PM rigid: I can use (my fixed) linuxcncrsh now but as said, it's currently broken at different levels. I'm in the process of fixing it. But if toolnml is one of many components removed from the NML interface, it's somewhat of a showstopper for me.
03:23 PM rigid: unless there's an alternative to telnet
03:24 PM rigid: (*linuxcncrsh remotely on a host that doesn't run the server or a realtime environment)
03:25 PM rene-dev5: Why does the whole tooltable need to be in nml?
03:25 PM rene-dev5: task only ever needs to know the current tool
03:25 PM linuxcnc-build2: Worker `precise-rtai-i386` is back online.
03:26 PM rigid: i guess so you can query stuff over network transparently. How do UIs currently handle the tooltable?
03:27 PM rene-dev5: They just read the file directly. While task also reads the file.
03:27 PM rigid: in a multi machine setup you also might want to share a single tooltable with different linuxcnc instances. should be possible with current NML i guess.
03:28 PM rigid: ah, that suggests that the tooltable stuff was bolted on at some later point
03:34 PM pere: rene-dev5: latest master commit failed in github CI check.
03:34 PM rigid: rene-dev5: there's quite some design issues but breaking further away from the CMS paradigma would mean - for me at least - a shift from "awesome industry-level production codebase" to "desktop app". I thought about going the other way round: adding support for HAL and tooltable (and other missing components) to NML (and replace NML with something protobuffy eventually)
03:34 PM rigid: but I also don't know every quirk of the design, yet so looking forward to your writeup
03:35 PM pere: rene-dev5: the tests/linuxcncrsh/ test failed.
03:46 PM linuxcnc-build2: Worker `checkin` is back online.
03:48 PM rigid: rene-dev5: besides, it makes no sense to reject a two line fix if the tooltable-NML removal doesn't make it into the next release.
03:49 PM rigid: although it probably affects no one when that parts of tcp NML are broken anyway
03:49 PM rigid: ...besides me
03:49 PM linuxcnc-build: build #3020 of 4041.deb-buster-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/3020 blamelist: Norbert Schechner <nieson@web.de>, Petter Reinholdtsen <pere@hungry.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, andypugh
03:49 PM linuxcnc-build: <andy@bodgesoc.org>
04:01 PM rene-dev5: rigid it was bolted on later.
04:02 PM rigid: yeah like HAL. Otherwise the utils would be in emc/user_intf
04:02 PM rigid: (which is a horrible 8+1-legacy directory name btw) :)
04:02 PM rigid: ehrn, 8+3
04:03 PM rene-dev5: rigid can you explain how nml tooltable helps with network setup? Im trying to understand why it would be useful in any way.
04:04 PM rene-dev5: rigid currently you cant share a tooltable file.
04:07 PM rigid: rene-dev5: as far as I understand (and that is certainly not much) there's one NML channel for toolCmd and one for toolSts that provides an interface for all sorts of linuxcnc components
04:09 PM rene-dev5: correct. and it isnt used by any UI.
04:09 PM rigid: you can configure them for different hosts (RW-access, master or slave replicating a master, various encodings like xdr, ascii, queued/non queued and tons of other possible config features)
04:09 PM rigid: rene-dev5: was it used by any UI once in the past?
04:10 PM rigid: I also guess it's used in a lot of custom tailored apps. UI or machine-to-machine wise.
04:12 PM rigid: i mentioned https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc before as an example from the forum. But I suppose it's not possible to be aware of the majority of applications, since they're custom by definition.
04:14 PM linuxcnc-build: build #3901 of 1640.rip-buster-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1640.rip-buster-rtpreempt-amd64/builds/3901 blamelist: Phillip Carter <phillc54@users.noreply.github.com>
04:14 PM rene-dev5: show me the line in the code where it is used. I cannot find any. as far as Im aware no UI is currently using it.
04:14 PM rene-dev5: its also not possible to use it for the tooledit in the UI, as its readonly.
04:15 PM rigid: i believe you that it's not currently used. i mean in the past
04:15 PM rigid: why is it readonly?
04:16 PM rigid: you mean no RW in the config .nml file or are there additionally access controls?
04:18 PM rene-dev5: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/extensions/emcmodule.cc#L824
04:19 PM rene-dev5: its readonly because the setter is NULL
04:20 PM rigid: ah, so it never got implemented
04:22 PM rene-dev5: its not trivial to implement. you need a single source of truth for the tooltable. thats hard to do when you have multiple copies all over the code.
04:24 PM rigid: yeah, i suppose that's why NML supports defining server/master for processes/channel
04:25 PM linuxcnc-build: build #2911 of 4042.deb-buster-rtpreempt-rpi4 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4042.deb-buster-rtpreempt-rpi4/builds/2911 blamelist: Norbert Schechner <nieson@web.de>, Petter Reinholdtsen <pere@hungry.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, andypugh
04:25 PM linuxcnc-build: <andy@bodgesoc.org>
04:28 PM rene-dev5: the interpreter has a copy, and can write to it, the UI has a copy, nml has a copy, and task has a copy. how do you sync them?
04:28 PM rigid: using NML update calls i thought
04:28 PM rigid: i've seen them for emcStatus ... not sure about toolSts
04:29 PM rigid: it basically feels like ancient pubsub. but in theory, it should work fine.
04:47 PM rene-dev5: rigid are you heeplr on github?
04:47 PM rigid: yes. my IRC account is much older than that github account :)
04:48 PM rigid: well... the freenode one was
04:55 PM Unterhaus_ is now known as Unterhausen
05:03 PM linuxcnc-build2: Worker `checkin` is missing. It was seen last on Sat Oct 7 15:00:42 2023.
05:11 PM linuxcnc-build: build #3661 of 1650.rip-buster-rtpreempt-rpi4 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1650.rip-buster-rtpreempt-rpi4/builds/3661 blamelist: Phillip Carter <phillc54@users.noreply.github.com>
05:11 PM linuxcnc-build: build #10319 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/10319 blamelist: Phillip Carter <phillc54@users.noreply.github.com>
05:54 PM linuxcnc-build: build #3500 of 1660.rip-buster-python3 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/3500 blamelist: looping40 <36304961+looping40@users.noreply.github.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh <andy@bodgesoc.org>, Eryk Michalak
05:54 PM linuxcnc-build: <gnu.ewm@protonmail.com>, Daniel Hiepler <d-git@coderdu.de>, heeplr <32984777+heeplr@users.noreply.github.com>, Phillip Carter <phillc54@icloud.com>, N. Camil <nicolas.camil@airbus.com>, Norbert Schechner <nieson@web.de>, Ilya Koubatkin <ilya@kubatkin.ru>, ighvh <115996604+ighvh@users.noreply.github.com>, andy <bodgesoc@gmail.com>, Mark
05:54 PM linuxcnc-build: <mark.vandoesburg@hetnet.nl>, petterreinholdtsen <pere-github@hungry.com>, c-morley <c-morley@users.noreply.github.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, nico <n.camil@free.fr>
06:02 PM linuxcnc-build: build #3902 of 1640.rip-buster-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1640.rip-buster-rtpreempt-amd64/builds/3902 blamelist: looping40 <36304961+looping40@users.noreply.github.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh <andy@bodgesoc.org>, Eryk
06:02 PM linuxcnc-build: Michalak <gnu.ewm@protonmail.com>, Daniel Hiepler <d-git@coderdu.de>, heeplr <32984777+heeplr@users.noreply.github.com>, Phillip Carter <phillc54@icloud.com>, N. Camil <nicolas.camil@airbus.com>, Norbert Schechner <nieson@web.de>, Ilya Koubatkin <ilya@kubatkin.ru>, ighvh <115996604+ighvh@users.noreply.github.com>, andy <bodgesoc@gmail.com>, Mark
06:02 PM linuxcnc-build: <mark.vandoesburg@hetnet.nl>, petterreinholdtsen <pere-github@hungry.com>, c-morley <c-morley@users.noreply.github.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, nico <n.camil@free.fr>
06:17 PM linuxcnc-build: build #3662 of 1650.rip-buster-rtpreempt-rpi4 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1650.rip-buster-rtpreempt-rpi4/builds/3662 blamelist: looping40 <36304961+looping40@users.noreply.github.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh <andy@bodgesoc.org>, Eryk
06:17 PM linuxcnc-build: Michalak <gnu.ewm@protonmail.com>, Daniel Hiepler <d-git@coderdu.de>, heeplr <32984777+heeplr@users.noreply.github.com>, Phillip Carter <phillc54@icloud.com>, N. Camil <nicolas.camil@airbus.com>, Norbert Schechner <nieson@web.de>, Ilya Koubatkin <ilya@kubatkin.ru>, ighvh <115996604+ighvh@users.noreply.github.com>, andy <bodgesoc@gmail.com>, Mark
06:17 PM linuxcnc-build: <mark.vandoesburg@hetnet.nl>, petterreinholdtsen <pere-github@hungry.com>, c-morley <c-morley@users.noreply.github.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, nico <n.camil@free.fr>
06:18 PM linuxcnc-build: build #10320 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/10320 blamelist: looping40 <36304961+looping40@users.noreply.github.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh <andy@bodgesoc.org>, Eryk Michalak <gnu.ewm@protonmail.com>, Daniel Hiepler
06:18 PM linuxcnc-build: <d-git@coderdu.de>, heeplr <32984777+heeplr@users.noreply.github.com>, Phillip Carter <phillc54@icloud.com>, N. Camil <nicolas.camil@airbus.com>, Norbert Schechner <nieson@web.de>, Ilya Koubatkin <ilya@kubatkin.ru>, ighvh <115996604+ighvh@users.noreply.github.com>, andy <bodgesoc@gmail.com>, Mark <mark.vandoesburg@hetnet.nl>, petterreinholdtsen <pere-
06:18 PM linuxcnc-build: github@hungry.com>, c-morley <c-morley@users.noreply.github.com>, Andy Pugh <andypugh@FlyPenguin.bodgesoc>, nico <n.camil@free.fr>
09:22 PM rigid: ha! that SET MODE NAK was easy to fix
09:24 PM linuxcnc-build: build #3021 of 4041.deb-buster-rtpreempt-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/3021 blamelist: Norbert Schechner <nieson@web.de>, Peter Wallace <pcw@mesanet.com>, Petter Reinholdtsen <pere@hungry.com>, Phillip Carter
09:24 PM linuxcnc-build: <phillc54@icloud.com>
10:01 PM linuxcnc-build: build #2912 of 4042.deb-buster-rtpreempt-rpi4 is complete: Failure [4failed shell_3 shell_4] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4042.deb-buster-rtpreempt-rpi4/builds/2912 blamelist: Norbert Schechner <nieson@web.de>, Peter Wallace <pcw@mesanet.com>, Petter Reinholdtsen <pere@hungry.com>, Phillip Carter
10:01 PM linuxcnc-build: <phillc54@icloud.com>