#linuxcnc-devel Logs

Oct 08 2023

02:35 AM NoSpark: concidering porting remora-cnc to this: https://www.beagleboard.org/boards/beagleplay
02:43 AM NoSpark: still trying to figure out how to build a very high quality CNC control sytem as cheaply as possible, and the MPU in the beagle play seems almost ideal for the price
04:11 AM pere: andypugh_: hi. :)
04:15 AM pere: andypugh_: bye. :)
06:04 AM andypugh_: Hi. Trying to build the 2.9.1 release tarball
06:05 AM andypugh_: Have smoe sat on the same bench
07:13 AM pere: andypugh rene-dev5: build failure for tag 1.9.1?
07:14 AM pere: <URL: https://github.com/LinuxCNC/linuxcnc/actions/runs/6447113710/job/17503023971 >?
07:18 AM rigid: pere: how would I rebase my PR branch inside my fork to the master of the forked directory without using the web UI? Just add the upstream and "git rebase forked/master"?
07:19 AM rigid: never done that. i always used the webui for that, never had any problems.
07:20 AM pere: rigid: first, switch away from your master: 'git checkout -b new-branch-name; git checkout master; git reset origin/master; git checkout .' This create a new branch and reset your master to match origin/master.
07:21 AM pere: Next, switch to your new branch and rebase it on top of master: 'git checkout new-branch-name; git rebase -i master'. the interactive (-i) option allow you to edit or squash commits if you want to.
07:21 AM rigid: pere: but origin/master (heeplr/linuxcnc) is still behind the forked repo (LinuxCNC/linuxcnc)
07:21 AM pere: ah, I assumed origin/master was LinuxCNC/linuxcnc/. what is the remote for upstream?
07:22 AM rigid: nah, I can't push there. I'm working on a fork creating PRs
07:22 AM pere: to update your origin/master you can use 'git push origin master -f' to force push the reset branch, once it is OK.
07:22 AM pere: I am quite sure you can, let me check the details.
07:23 AM rigid: pere: if I could commit to the LinuxCNC repo accounts, that would be a security risk. (unless someone whitelisted me)
07:24 AM pere: rigid: is it one of patch-1 or patch2 on <URL: https://github.com/heeplr/linuxcnc >?
07:24 AM pere: rigid: remind me, are we talking about a pull request you want to update? Which one?
07:24 AM rigid: pere: nope, it's linuxcncrsh-test and linuxcncrsh (latter ha no PR, yet)
07:25 AM pere: you have local changes in your master that you want to rebase on top of the official master?
07:25 AM rigid: pere: you wrote "Please rebase on top of latest master, so the CI jobs have a chance of succeeding." and you mentioned possible issues yesterday when I did it like always. Hence i'm wondering how to do it, so the commit won't show up in the PR
07:26 AM pere: right. I always have a separate branches per pull request. I recommend it strongly. I assume you do not?
07:27 AM rigid: sure I have. linuxcncrsh and linuxcncrsh-test
07:27 AM rigid: they are in my fork of the offical master and the origin of my PRs. But they are behind the official master.
07:28 AM rigid: normally I go to github.com/heeplr/linuxcnc, select the branch, click "sync" and then pull all my local repos to rebase to the most recent official commit
07:28 AM pere: ok. So lets assume your master is without local patches. Then you 'git checkout master; git pull upstreamremote' to fetch the latest changes, and then 'git checkout linuxcncrsh; git rebase -i master' to rebase on your updated master, or just 'git rebase -i upstream/master' if 'upstream' is the remote for the official repo.
07:28 AM rigid: I think the only other way without web UI would be adding the official master as upstream and rebasing to that. but it should result in the same thing.
07:29 AM pere: di you have LinuxCNC/linuxcnc repo as a remote?
07:29 AM pere: I normally leave upstream as origin and put my local github copy as 'myfork', allowing 'git pull' in master to pull from upstream, and then I always push to myfork for stuff that should become pull requests.
07:30 AM rigid: no. I just did "git clone github.com/heeplr/linuxcnc" to work on my fork
07:30 AM rigid: *forked repo
07:31 AM pere: if you do 'git remote add upstream https://github.com/LinuxCNC/linuxcnc.git', you will get a new upstream remote to pull form.
07:31 AM rigid: pere: and what remote does "myfork" have then?
07:31 AM pere: my myfork remote is git@github.com:petterreinholdtsen/linuxcnc.git
07:31 AM rigid: you can't send a PR from a local repo without remote upstream, can you?
07:31 AM pere: that is correct.
07:32 AM rigid: ok, I see. i'll try to add another remote
07:34 AM pere: if you want to swap origin, upstream and myfork, you can edit .git/config and do 'git fetch' to update the remotes.
07:44 AM rigid: pere: did you find out why user defined M-codes broke yesterday?
07:45 AM pere: did not investigate, no idea.
07:45 AM rigid: since now the test is just disabled
07:45 AM pere: I disabled the test as it was unstable.
07:46 AM rigid: i know the first bad commit but there are tons of commits that don't even compile and some have A LOT of changes. Very cumbersome to track down.
07:46 AM rigid: ok, i'll try to track that down. (would rather get linuxcncrsh fully running)
07:47 AM pere: rigid: not sure we talk about the same thing? I talk about tests/linuxcncrsh/, which always failed and made it impossible to detect new problems introduced by pull requests, so I disabled the test.
07:47 AM pere: (perhaps not always, but often enough to make life harder for all other pull requests.)
07:47 AM rigid: pere: it didn't always fail
07:47 AM rigid: and yes, we're talking about that
07:48 AM pere: if it always fail it is broken, if it sometime fails it is unstable. so it was unstable, and my first explanation holds. :)
07:49 AM pere: I hope we can figure out what the problem is, fix it and enable the test soon.
07:51 AM pere: andypugh_: good to hear smoe is at hand. :)
07:51 AM andypugh_: He just left….
07:52 AM pere: heh
07:53 AM pere: I got him on Signal.org when I need him. :)
07:55 AM andypugh_: And I have concluded that I am simply not competent to be release manager.
07:55 AM rigid: pere: when I created the PR, it didn't fail since it accepted wrong output of buggy linuxcncrsh. Then in a later commit, I changed it to the correct output since I intended to fix the bug before merge, so the test failed (outputting a diff). Then I synced with master and suddenly the user M-Code script didn't produce the file "gcode-output" anymore, so the test was still failing, but for another reason. That would have also faile
07:55 AM rigid: d the original version of the test before my PR. Then my (breaking) PR was merged although I didn't fix the bugs in linuxcncrsh, yet.
07:55 AM rigid: it'd be better if breaking stuff wouldn't be merged into master.
07:56 AM rigid: andypugh_: what? define competence.
07:56 AM rigid: I at least never had that impression
07:56 AM pere: andypugh_: to me you seem competent enough, I must admit. :)
07:57 AM andypugh_: This time there were new remote commits when I tried to push the new tag, and so it pushed the tag but not the commit. Now the builbots and CI are all unhappy and failing tests / builds.
07:57 AM rigid: i mean... it's not trivial anyway
07:57 AM pere: rigid: so something broke between 2.9 and master, I take it?
07:58 AM pere: andypugh_: how bad is it? did you solve it?
07:58 AM rigid: andypugh_: btw. why the policy for cherrypicking from release-branch to master instead of backporting from master to release-branch? I've seen both but always found the latter seemingly easier.
07:58 AM rigid: pere: yes, seems so
07:59 AM andypugh_: rigid: Dunno, the process was defined way before I started doing this and I have no opinon on the matter.
08:00 AM pere: rigid: the 'merge forward' approach is not my favorite, I must admit.
08:00 AM rigid: i mean like "everything passing tests and ready to be tested by humans goes into master. Important stuff is backported to upcoming release branch. Critical stuff is backported to all supported major-release branches"
08:00 AM rigid: andypugh_: ah... so legacy
08:01 AM andypugh_: But I think that the logic is that bugfixes go in at the point that the bug was introduced, and then are propogated forwards to all affected branches.
08:04 AM rigid: andypugh_: but if you would do LTS for multiple major releases (say 2.7.x, 2.8.x is still supported for people who can't accept breaking changes, yet) and there's a critical security fix. you'd add that to the 2.9 branch and then cherrypick it into 2.7 and 2.8 and later master so you can do a new 2.7.x+1 and 2.8.x+1 release before 2.9 is released.
08:05 AM pere: rigid: it is not cherry-picked. 2.8 is merged into 2.9 and 2.9 into master.
08:05 AM rigid: well, in the end it doesn't really matter. I guess there are also cases where a fix for 2.9 wouldn't apply anymore for master, so pushing it to master first would make no sense
08:06 AM rigid: pere: yeah, but without cherrypicking it, you can only fix bugs in the latest release branch. not 2.8 or 2.7 for example
08:06 AM pere: I wished the project would switch away from merge forward and switch to backport fixes from master instead. but do not plan to champion such change any time soon.
08:06 AM andypugh_: rigid: Are you offering to take on the release manager job? I would be more than happy to give it to you.
08:07 AM rigid: well, it's just policy and andypugh_ adviced me in the past. but without advice it's hard to decide which change should be part of the next release and and which belongs to master
08:08 AM pere: we barely have the people needed to maintain one release, yet we try to support three releases...
08:09 AM rigid: andypugh_: sadly I don't have the time but linuxcnc is an interesting project I'd be willed to spend some time on. I can't express how much I appreciate you (and people like you) doing it.
08:09 AM rigid: i also always advocate to request public funds so there is at least a bit of monetary appreciation
08:10 AM pere: rigid: perhaps you can find some sponsor funding for developer gatherings?
08:10 AM rigid: pere: yeah. there's no need for multiple supported releases or long term support for linuxcnc. But that might be the reason why people use master as "central point" by default and going from there.
08:10 AM pere: I plan to repeat the Norwegian gathering this spring, to bring people together and motivate the developers.
08:11 AM andypugh_: <not in the mood for this conversation>
08:11 AM pere: I know others believe we should provide long term support, so we provide fixes for 2.8, 2.9 and master. :)
08:11 AM rigid: pere: i'll ask around. if you had a booth on the automatic fair, you'd meet lots of possible sponsors. And the industry is currently pouring money in education (and they're not exactly poor)
08:11 AM rigid: *automata
08:12 AM pere: rigid: but I do not believe money is the limiting factor, time and skills are.
08:12 AM rigid: pere: cool
08:12 AM rigid: actually only time. skills can be gathered and honed
08:13 AM rigid: and I mean... software is hard. linuxcnc is an old capable beast.
08:13 AM pere: that is not my experience. very few are both skilled machinists and programmers, and it is hard or impossible to turn one into the other. :)
08:14 AM rigid: you don't need to be one to do the other. you just have to colaborate. and that's really easy nowadays with github/chats/forums/mailinglists...
08:16 AM rigid: plus I wouldn't say linuxcnc has a machinist/user-related problem. It has programmer problems. Some nasty ones no one likes to take care of :)
08:17 AM rigid: I hope it's not a too sensitive topic since andy left.
08:18 AM pere: I suspect he is frustrated, and know he do not want to be the release manager. in addition he too do not believe money is the limiting factor, and he is not interested in money to work on linuxcnc.
08:19 AM rigid: pere: is it a general "linuxcnc isn't fun anymore for our maintainer so please DON'T mention the WAR?" or newly facing stress because of problems from the 2.9 merge?
08:20 AM pere: I suspect it is newly facing stress.
08:20 AM pere: the machinekit mess is more like the former. :)
08:21 AM rigid: I think there's no fault to blame the release manager. It's always the acting community that's responsible if no one objects something.
08:21 AM rigid: machinekit mess? you mean that 64 bit thing from mk?
08:22 AM pere: nope, the history leading up to the fork and project split.
08:22 AM rigid: ah
08:23 AM pere: I do not really understand what happened with the v2.9.1 tag, so no idea who is to "blame". In general I find spreading blame a rather useless exercise. I am sure we can solve it and move on.
08:24 AM pere: perhaps we just need a merge and a v2.9.2 tag. :)
08:24 AM rigid: i'll try to find that M-Command bug and not go down the TOOL_NML thing for now. Maybe we can fix at least some stress factors quickly.
08:25 AM pere: git diff master 2.9 should give you enought to look at to find the bug. :)
08:25 AM pere: perhaps also write a test case isolating the issue independent of linuxcncrsh
08:25 AM rigid: the bug is in both. i have to bisect
08:26 AM rigid: that's exactly what I thought. testing it separatly (and more thoroughly) would be a good idea.
08:27 AM rigid: pere: keep in mind that I just wanted "to give linuxcncrsh a try" :) I wouldn't say I'm SUPER frustrated, but... well :-P
08:28 AM rigid: it all started with a segfault :-)
08:38 AM pere: :)
08:38 AM pere: I got to run, see you later. Keep up the good work. I find that writing test cases is a great way to help those that know the code to find and fix bugs. :)
08:39 AM rigid: o/
05:12 PM solarwind_ is now known as solarwind
05:43 PM pere: rigid: yet another unstable test inherited from 2.9? <URL: https://github.com/LinuxCNC/linuxcnc/actions/runs/6449479090/job/17507838754 >
06:04 PM rigid: pere: the g-code file missing bug is not inherited from 2.9. I tracked it down. It's caused by the segfault bug I trigger in the new test. Strangely, sometimes diff doesn't complain about the missing file and sometimes it does.
06:05 PM rigid: This thing seems to fail the gcode because of the SET MDI NAKs. Is there a way to get the "result" file from that run somehow without rewriting the test?
06:05 PM rigid: unfortunatly, linuxcncrsh errors are not very verbose.
06:08 PM pere: perhaps runtest --verbose?
06:08 PM rigid: that would do it but produces output for every single test. adds a lot of output
06:09 PM pere: yes. if you specify the test or subdirectory of tests you want to run as the runtest argument, you get less output.
06:10 PM rigid: yeah, but not in CI
06:13 PM linuxcnc-build: build #3904 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/3904 blamelist: Peter Wallace <pcw@mesanet.com>, CMorley <chrisinnanaimo@hotmail.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh
06:13 PM linuxcnc-build: <andy@bodgesoc.org>, heeplr <32984777+heeplr@users.noreply.github.com>, Rene Hopf <renehopf@mac.com>, Hosted Weblate <hosted@weblate.org>, Norbert Schechner <nieson@web.de>, andy <bodgesoc@gmail.com>, petterreinholdtsen <pere-github@hungry.com>
06:31 PM linuxcnc-build: build #10322 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/10322 blamelist: Peter Wallace <pcw@mesanet.com>, CMorley <chrisinnanaimo@hotmail.com>, Petter Reinholdtsen <pere@hungry.com>, andypugh <andy@bodgesoc.org>, heeplr
06:31 PM linuxcnc-build: <32984777+heeplr@users.noreply.github.com>, Rene Hopf <renehopf@mac.com>, Hosted Weblate <hosted@weblate.org>, Norbert Schechner <nieson@web.de>, andy <bodgesoc@gmail.com>, petterreinholdtsen <pere-github@hungry.com>
07:50 PM Unterhaus_ is now known as Unterhausen