emc-developers — Developer specific. For issues of interest to users see emc-users list (below)

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Bertho S. <lc...@va...>]

On 10/23/26 4:10 PM, Robert Schöftner wrote:
> I think discourse deployment is recommended via the docker image. 
> Maintenance should be limited to keeping the docker image up to date and
> happy. Though I don't really like the "hiding" of all the stuff, docker
> just really is a fancy chroot, and IME it works fine and takes the
> hassle out of keeping up to date with dependencies and security updates.
That would put you in the situation that you download a docker image, 
which you have no control over how it was built. Otherwise, you need to 
rebuild it for every change and are again in the same position I 
described before. It is essentially a >borked< if you do and >borked< if 
you don't situation.

What can be created from the Debian repositories (or other distros)? 
That has generally a long life and a well-defined update/upgrade path. 
It is better to reduce bells and whistles for stability as well as easy 
and ordered system administration.


> discourse itself is GPL2
>   https://github.com/discourse/discourse/blob/main/LICENSE.txt

Yes, it is FOSS. But, its not about the license as such. Its about the 
deployment and the effort it takes to keep it running and up-to-date 
without any data loss, doing so with the available resources.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618and CVE-2026-109619

[Gene H. <ghe...@sh...>]

On 10/23/26 06:32, Bertho Stultiens wrote:
>>> Maybe then also think about if kunena/joomla really is the way to go
>>> forward, or something a bit more modern (discourse) would be better in
>>> the long run.
>
> Replacing one dependency for a "free" commercial dependency is a bad 
> move. To see how bad the idea is to use "free" hosted discourse, just 
> go to their license and privacy policy pages and try to make sense of 
> it. The "free" always comes with a price.
>
> The only real option is to do self-hosting and assure 1) an isolated 
> instance not doing call-backs to any third parties and assured data 
> privacy and 2) have a well-defined path from the current forum data to 
> the new database, preserving history.
>
> Even then, if you read through the list of things you need to 
> install/run it self-hosted, including NPM, then I'm not sure it is a 
> good idea at all. Keeping a local install up to data from a git clone 
> is hard and it requiring NPM, with a significant history of 
> supply-chain attacks, is also a problem. The alternative is to become 
> dependent on the commercial vendor, which is just as problematic, 
> especially if you want to assure point 1.
>
> So, in the end we trade the PHP problem for multiple new ones. That 
> does not sound like a good change.
I'm with Bertho.  Fix the PHP but move it to our control.  The last time 
I looked at the PHP docs it was pretty straight forward.

-- 
There are 4 boxes to defend liberty
Soap, ballot, jury, ammo
Please use in that order

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Robert S. <rm...@un...>]

Am Freitag, dem 23.10.2026 um 12:32 +0200 schrieb Bertho Stultiens:
> > > Maybe then also think about if kunena/joomla really is the way to
> > > go
> > > forward, or something a bit more modern (discourse) would be
> > > better in
> > > the long run.
> 
> Replacing one dependency for a "free" commercial dependency is a bad 
> move. To see how bad the idea is to use "free" hosted discourse, just
> go 
> to their license and privacy policy pages and try to make sense of
> it. 
> The "free" always comes with a price.
> 
> The only real option is to do self-hosting and assure 1) an isolated 
> instance not doing call-backs to any third parties and assured data 
> privacy and 2) have a well-defined path from the current forum data
> to 
> the new database, preserving history.
> 

I agree self-hosting is the way to go. Either way, we have to take
measures to avoid another semi-permanent "wiki certificate"-situation
that can only be fixed with a time-machine or spooky action at a
distance through a wormhole. 

> Even then, if you read through the list of things you need to 
> install/run it self-hosted, including NPM, then I'm not sure it is a 
> good idea at all. Keeping a local install up to data from a git clone
> is 
> hard and it requiring NPM, with a significant history of supply-chain
> attacks, is also a problem. The alternative is to become dependent on
> the commercial vendor, which is just as problematic, especially if
> you 
> want to assure point 1.
> 
> So, in the end we trade the PHP problem for multiple new ones. That
> does 
> not sound like a good change.
> 

I think discourse deployment is recommended via the docker image.
Maintenance should be limited to keeping the docker image up to date
and happy. Though I don't really like the "hiding" of all the stuff,
docker just really is a fancy chroot, and IME it works fine and takes
the hassle out of keeping up to date with dependencies and security
updates.

discourse itself is GPL2
 https://github.com/discourse/discourse/blob/main/LICENSE.txt
-- 
Robert Schöftner <rm...@un...>

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Stuart S. <st...@gm...>]

Sounds like a job for AI.


Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.


On Fri, Oct 23, 2026 at 5:33 AM Bertho Stultiens <lc...@va...> wrote:

> >> Maybe then also think about if kunena/joomla really is the way to go
> >> forward, or something a bit more modern (discourse) would be better in
> >> the long run.
>
> Replacing one dependency for a "free" commercial dependency is a bad
> move. To see how bad the idea is to use "free" hosted discourse, just go
> to their license and privacy policy pages and try to make sense of it.
> The "free" always comes with a price.
>
> The only real option is to do self-hosting and assure 1) an isolated
> instance not doing call-backs to any third parties and assured data
> privacy and 2) have a well-defined path from the current forum data to
> the new database, preserving history.
>
> Even then, if you read through the list of things you need to
> install/run it self-hosted, including NPM, then I'm not sure it is a
> good idea at all. Keeping a local install up to data from a git clone is
> hard and it requiring NPM, with a significant history of supply-chain
> attacks, is also a problem. The alternative is to become dependent on
> the commercial vendor, which is just as problematic, especially if you
> want to assure point 1.
>
> So, in the end we trade the PHP problem for multiple new ones. That does
> not sound like a good change.
>
> --
> Greetings Bertho
>
> (disclaimers are disclaimed)
>
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Bertho S. <lc...@va...>]

>> Maybe then also think about if kunena/joomla really is the way to go
>> forward, or something a bit more modern (discourse) would be better in
>> the long run.

Replacing one dependency for a "free" commercial dependency is a bad 
move. To see how bad the idea is to use "free" hosted discourse, just go 
to their license and privacy policy pages and try to make sense of it. 
The "free" always comes with a price.

The only real option is to do self-hosting and assure 1) an isolated 
instance not doing call-backs to any third parties and assured data 
privacy and 2) have a well-defined path from the current forum data to 
the new database, preserving history.

Even then, if you read through the list of things you need to 
install/run it self-hosted, including NPM, then I'm not sure it is a 
good idea at all. Keeping a local install up to data from a git clone is 
hard and it requiring NPM, with a significant history of supply-chain 
attacks, is also a problem. The alternative is to become dependent on 
the commercial vendor, which is just as problematic, especially if you 
want to assure point 1.

So, in the end we trade the PHP problem for multiple new ones. That does 
not sound like a good change.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Luca T. <lu...@ai...>]

I've looked at it before, actually made linuxcnc.dicourse.org but it seems not to be up anymore, they have free hosting for open source community, and there was some path to transfer from kunena, but I was not able to test it. I could experiment on my own PC to see what's possible, I'd need a copy of the database, or access to the current server.


On October 23, 2026 5:26:53 PM GMT+08:00, andy pugh <bod...@gm...> wrote:
>On Fri, 23 Oct 2026 at 09:54, Robert Schöftner <rm...@un...> wrote:
>
>> Maybe then also think about if kunena/joomla really is the way to go
>> forward, or something a bit more modern (discourse) would be better in
>> the long run.
>
>There would have to be a reliable conversion path for the message
>database for that to be an option.
>
>I am not discounting the idea, but I don't know who would want to take it on.
>
>-- 
>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...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[andy p. <bod...@gm...>]

On Fri, 23 Oct 2026 at 09:54, Robert Schöftner <rm...@un...> wrote:

> Maybe then also think about if kunena/joomla really is the way to go
> forward, or something a bit more modern (discourse) would be better in
> the long run.

There would have to be a reliable conversion path for the message
database for that to be an option.

I am not discounting the idea, but I don't know who would want to take it on.

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

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[Robert S. <rm...@un...>]

Am Donnerstag, dem 22.10.2026 um 13:56 +0100 schrieb andy pugh:
> On Thu, 22 Oct 2026 at 13:04, John Thornton <jt...@gn...> wrote:
> > 
> > AFAIK only Jeff knew how to upgrade the forum. I've never attempted
> > to
> > do that and Jeff didn't leave me any instructions on how to do
> > that.
> 
> There are some instructions here:
> https://www.kunena.org/docs/en/basics/upgrade/upgrade-k6-x
> 
> But that would need to follow an update of PHP and all other things.
> 
> This might be the time to switch to a different account? Possibly
> still with DigitalOcean, but on an account that "we" own.
> 
> Then we could do a clean setup, and then migrate the database.
> 

Maybe then also think about if kunena/joomla really is the way to go
forward, or something a bit more modern (discourse) would be better in
the long run.
-- 
Robert Schöftner <rm...@un...>

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618and CVE-2026-109619

[Gene H. <ghe...@sh...>]

On 10/22/26 08:49, andy pugh wrote:
> On Thu, 22 Oct 2026 at 13:04, John Thornton <jt...@gn...> wrote:
>> AFAIK only Jeff knew how to upgrade the forum. I've never attempted to
>> do that and Jeff didn't leave me any instructions on how to do that.
> I think that the account owner at Digital Ocean is Stephen Padnos?
Possibly Andy, but its been a looooooong time since I've seen that name 
here, or anyplace else. Is he still with us?
>
-- 
There are 4 boxes to defend liberty
Soap, ballot, jury, ammo

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[John T. <jt...@gn...>]

AFAIK only Jeff knew how to upgrade the forum. I've never attempted to 
do that and Jeff didn't leave me any instructions on how to do that. I 
looked into doing that but couldn't find any "clear" instructions on how 
to upgrade.

I know that Stephen Diercouff "sdg" on the forum and "roycroft" on the 
IRC has made at least one attempt to do an off site upgrade but ran into 
some kind of problem. I added Stephen to this email if the email I have 
is current for him.

I know upgrading the forum involves creating a "droplet" what ever that 
is and installing a new up to date OS, installing Joomula and installing 
Kunena then somehow copying the database from the old to the new.

The only other person I know of that might know how is Alex Joni, he 
created the forum.

JT

On 10/22/26 04:35, andy pugh wrote:
> The forum runs Joomla and Kunena, which are PHP apps, so very much affected.
>
> Digital Ocean report that:
>
> "patches are only available for currently supported PHP versions (8.2
> and later). If you are running an end-of-life PHP version (8.1 or
> earlier), no official patch will be available and you should plan an
> immediate upgrade to a supported version."
>
> Looking at the forum admin panel:
>
> "We have detected that your server is using PHP 7.4.3-4ubuntu2.29
> which is obsolete and no longer receives official security updates by
> its developers. Furthermore, we cannot recommend a newer PHP version
> because you are using an outdated Joomla! version. We recommend
> updating Joomla! and then following further PHP upgrade instructions."
>
> It looks like we need to make a major upgrade.
>
> Do any of us know _how_ to upgrade the forum server? I think that JT might?
>

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[andy p. <bod...@gm...>]

On Thu, 22 Oct 2026 at 13:04, John Thornton <jt...@gn...> wrote:
>
> AFAIK only Jeff knew how to upgrade the forum. I've never attempted to
> do that and Jeff didn't leave me any instructions on how to do that.

There are some instructions here:
https://www.kunena.org/docs/en/basics/upgrade/upgrade-k6-x

But that would need to follow an update of PHP and all other things.

This might be the time to switch to a different account? Possibly
still with DigitalOcean, but on an account that "we" own.

Then we could do a clean setup, and then migrate the database.

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

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[John T. <jt...@gn...>]

Got a pm from Stephen

we can't upgrade php easily on the vps that we're using - I've been 
thinking of alternatives over the past few days anyway, but i don't have 
a solid plan yet. I'll take steps to mitigate the vulnerability tonight 
(if i get home in time) or tomorrow (and I'll be gone until late in the 
day tomorrow)

JT

On 10/22/26 04:35, andy pugh wrote:
> The forum runs Joomla and Kunena, which are PHP apps, so very much affected.
>
> Digital Ocean report that:
>
> "patches are only available for currently supported PHP versions (8.2
> and later). If you are running an end-of-life PHP version (8.1 or
> earlier), no official patch will be available and you should plan an
> immediate upgrade to a supported version."
>
> Looking at the forum admin panel:
>
> "We have detected that your server is using PHP 7.4.3-4ubuntu2.29
> which is obsolete and no longer receives official security updates by
> its developers. Furthermore, we cannot recommend a newer PHP version
> because you are using an outdated Joomla! version. We recommend
> updating Joomla! and then following further PHP upgrade instructions."
>
> It looks like we need to make a major upgrade.
>
> Do any of us know _how_ to upgrade the forum server? I think that JT might?
>

Re: [Emc-developers] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[andy p. <bod...@gm...>]

On Thu, 22 Oct 2026 at 13:04, John Thornton <jt...@gn...> wrote:
>
> AFAIK only Jeff knew how to upgrade the forum. I've never attempted to
> do that and Jeff didn't leave me any instructions on how to do that.

I think that the account owner at Digital Ocean is Stephen Padnos?

-- 
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] Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619

[andy p. <bod...@gm...>]

The forum runs Joomla and Kunena, which are PHP apps, so very much affected.

Digital Ocean report that:

"patches are only available for currently supported PHP versions (8.2
and later). If you are running an end-of-life PHP version (8.1 or
earlier), no official patch will be available and you should plan an
immediate upgrade to a supported version."

Looking at the forum admin panel:

"We have detected that your server is using PHP 7.4.3-4ubuntu2.29
which is obsolete and no longer receives official security updates by
its developers. Furthermore, we cannot recommend a newer PHP version
because you are using an outdated Joomla! version. We recommend
updating Joomla! and then following further PHP upgrade instructions."

It looks like we need to make a major upgrade.

Do any of us know _how_ to upgrade the forum server? I think that JT might?

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

Re: [Emc-developers] branch protection turned on

[Chris M. <chr...@ho...>]

It was a PR.
I understand it's annoying for code to be broken and merge fixing conflicts.
If your code went in it probably would have broken my code.
My pr has been available to look at and comment on for about a year.
I was in contact with the one collaborator that was interested in the code.
I told him I was going to push.

Whether I did it by pushing the merge button or pushed directly would not have changed what happened nor would be out of the ordinary. The code I was working on I'm pretty familiar with. Having to wait for others to approve has never been formally agreed to.

Gladevcp was a project I started and worked on for many years.
Gmoccapy started off as a Gscreen based project, Norbert and I did much work together on Gladevcp and Gmoccapy to get what he wanted.
In other words I'm invested in both and would have worked on any bugs I caused. You sometimes break little things to make things better.

But yes I will probably do less work in linuxcnc and I guess I will ask for permission to work on my code.

Chris




________________________________
From: David Mueller <mue...@ho...>
Sent: September 18, 2026 1:21 AM
To: emc...@li... <emc...@li...>
Subject: Re: [Emc-developers] branch protection turned on

Pushing directly may be acceptable for sections of code that only you
are working on, like QTdragon, but it is not OK for sections where you
collaborate with others.

I've had a PR open for 3 weeks that fixes issues in gmoccapy and some
gladevcp widgets it uses. Your push drove right over it, not only
causing merge conflicts but actually introducing new issues.

So I would VERY much appreciate it if you could file those changes that
touch gladevcp and gmoccapy as a PR.

Thank you

David



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

Re: [Emc-developers] Why don't we get Github Copilot for free?

[andy p. <bod...@gm...>]

On Mon, 12 Oct 2026 at 12:09, andy pugh <bod...@gm...> wrote:
>
> There reply was no help at all,

"Their" reply, sorry. At least you can tell that not the whole message
was AI generated.

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

Re: [Emc-developers] Why don't we get Github Copilot for free?

[Luca T. <lu...@ai...>]

Worth a try, it doesn't actually changes any licensing, just how they are organized so that GH can parse them proper, sounds reasonable, are you sending a PR?



On October 12, 2026 7:09:12 PM GMT+08:00, andy pugh <bod...@gm...> wrote:
>I asked Github support why LinuxCNC doesn't qualify for the free "Pro"
>license offered to Open-source developers. There reply was no help at
>all, basically saying that there is no manual override and it's all
>automatic.
>
>So, I asked the Google AI, and it suggested that the issue is maybe
>with the licence.
>(It is also entirely possible that we just aren't a big enough
>project, currently the LinuxCNC org is ranked at 5214 on Gitstar)
>
><BEGIN AI OPINION>
>
>"The fact that GitHub displays the license as "GPL-2.0, License
>licenses found" is the exact reason why you are being blocked.
>This phrasing indicates that GitHub's automated license scanner
>(Licensee) is confused. Instead of seeing one clean, standardized
>license, it is detecting a messy mix of multiple conflicting license
>files or custom blocks of text within your repository.
>Because GitHub's automated algorithm requires a 100% clear, single,
>OSI-approved open-source license to grant free benefits, this "License
>licenses found" error causes the system to skip your account entirely
>and redirect you to the standard paid checkout screen.
>
>Why this is happening on LinuxCNC
>
>LinuxCNC is a massive, historic project with a deep dependency tree
>and decades of contributions. Over the years, files have been brought
>in under various licenses (GPL-2.0-or-later, LGPL, and custom
>headers).
>• GitHub's automation scans for a file named exactly LICENSE, COPYING,
>or README in your repository root.
>• If you have both a LICENSE file and a COPYING file, or if your
>primary license file contains multiple different license texts pasted
>together, the automated parser breaks. It classifies the repo's
>licensing status as ambiguous.
>
>How to fix this and trigger the benefit
>
>To get the automated algorithm to recognize your maintainer status,
>you need to fix how GitHub indexes your repository's primary license.
>
>Step 1: Clean up the Root License Files
>
>Ensure that you only have one single primary license file in the root
>directory of your repository (ideally named LICENSE or COPYING).
>• The content of this root file should strictly be the standard,
>unmodified text of the GPL-2.0 license.
>• If you have other licenses for specific sub-folders or modules, move
>those specific license texts into those sub-folders (e.g.,
>/src/modules/LICENSE.lgpl) rather than keeping them in the root
>directory."
>
>
>-- 
>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...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Why don't we get Github Copilot for free?

[Julian W. <jul...@we...>]

That sounds like a Claude max job for a few days and then "a lot!"™ Of testing and checking afterwards...
I would offer the first, I have experience doing such things but the testing and checking is out of my possibilities 

Yours Julian 

On 12 October 2026 13:09:12 CEST, andy pugh <bod...@gm...> wrote:
>I asked Github support why LinuxCNC doesn't qualify for the free "Pro"
>license offered to Open-source developers. There reply was no help at
>all, basically saying that there is no manual override and it's all
>automatic.
>
>So, I asked the Google AI, and it suggested that the issue is maybe
>with the licence.
>(It is also entirely possible that we just aren't a big enough
>project, currently the LinuxCNC org is ranked at 5214 on Gitstar)
>
><BEGIN AI OPINION>
>
>"The fact that GitHub displays the license as "GPL-2.0, License
>licenses found" is the exact reason why you are being blocked.
>This phrasing indicates that GitHub's automated license scanner
>(Licensee) is confused. Instead of seeing one clean, standardized
>license, it is detecting a messy mix of multiple conflicting license
>files or custom blocks of text within your repository.
>Because GitHub's automated algorithm requires a 100% clear, single,
>OSI-approved open-source license to grant free benefits, this "License
>licenses found" error causes the system to skip your account entirely
>and redirect you to the standard paid checkout screen.
>
>Why this is happening on LinuxCNC
>
>LinuxCNC is a massive, historic project with a deep dependency tree
>and decades of contributions. Over the years, files have been brought
>in under various licenses (GPL-2.0-or-later, LGPL, and custom
>headers).
>• GitHub's automation scans for a file named exactly LICENSE, COPYING,
>or README in your repository root.
>• If you have both a LICENSE file and a COPYING file, or if your
>primary license file contains multiple different license texts pasted
>together, the automated parser breaks. It classifies the repo's
>licensing status as ambiguous.
>
>How to fix this and trigger the benefit
>
>To get the automated algorithm to recognize your maintainer status,
>you need to fix how GitHub indexes your repository's primary license.
>
>Step 1: Clean up the Root License Files
>
>Ensure that you only have one single primary license file in the root
>directory of your repository (ideally named LICENSE or COPYING).
>• The content of this root file should strictly be the standard,
>unmodified text of the GPL-2.0 license.
>• If you have other licenses for specific sub-folders or modules, move
>those specific license texts into those sub-folders (e.g.,
>/src/modules/LICENSE.lgpl) rather than keeping them in the root
>directory."
>
>
>-- 
>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...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Mit freundlichen Grüßen aus Pinneberg
Julian Wingert

Subtilitas Consulting

Holstenstr. 25
25421 Pinneberg

Phone: 0170/4516094
FAX: 03212-1479681
Mail: jul...@su...

USt-IdNr.: DE272503212

[Emc-developers] Why don't we get Github Copilot for free?

[andy p. <bod...@gm...>]

I asked Github support why LinuxCNC doesn't qualify for the free "Pro"
license offered to Open-source developers. There reply was no help at
all, basically saying that there is no manual override and it's all
automatic.

So, I asked the Google AI, and it suggested that the issue is maybe
with the licence.
(It is also entirely possible that we just aren't a big enough
project, currently the LinuxCNC org is ranked at 5214 on Gitstar)

<BEGIN AI OPINION>

"The fact that GitHub displays the license as "GPL-2.0, License
licenses found" is the exact reason why you are being blocked.
This phrasing indicates that GitHub's automated license scanner
(Licensee) is confused. Instead of seeing one clean, standardized
license, it is detecting a messy mix of multiple conflicting license
files or custom blocks of text within your repository.
Because GitHub's automated algorithm requires a 100% clear, single,
OSI-approved open-source license to grant free benefits, this "License
licenses found" error causes the system to skip your account entirely
and redirect you to the standard paid checkout screen.

Why this is happening on LinuxCNC

LinuxCNC is a massive, historic project with a deep dependency tree
and decades of contributions. Over the years, files have been brought
in under various licenses (GPL-2.0-or-later, LGPL, and custom
headers).
• GitHub's automation scans for a file named exactly LICENSE, COPYING,
or README in your repository root.
• If you have both a LICENSE file and a COPYING file, or if your
primary license file contains multiple different license texts pasted
together, the automated parser breaks. It classifies the repo's
licensing status as ambiguous.

How to fix this and trigger the benefit

To get the automated algorithm to recognize your maintainer status,
you need to fix how GitHub indexes your repository's primary license.

Step 1: Clean up the Root License Files

Ensure that you only have one single primary license file in the root
directory of your repository (ideally named LICENSE or COPYING).
• The content of this root file should strictly be the standard,
unmodified text of the GPL-2.0 license.
• If you have other licenses for specific sub-folders or modules, move
those specific license texts into those sub-folders (e.g.,
/src/modules/LICENSE.lgpl) rather than keeping them in the root
directory."


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

Re: [Emc-developers] Will we release before more major changes?

[Bertho S. <lc...@va...>]

On 10/9/26 5:00 PM, andy pugh wrote:
>> Please do not split yet. The HAL changes are not yet done.
> Work on 2.10 would continue after the split, just as it does now on 2,9.

Yes, but it is double work and needs testing on two branches. There is 
already a lack of testing now.


> But it would also mean that things _not_ intended for 2.10 could be
> committed (to master only)

Yes, but new features can wait. It is called a development freeze where 
the current features are frozen and only bugs and projects in progress 
are fixed. People can always use their own branches and get them merged 
when the freeze period is over.

Doing a development freeze comes before you branch off. It gives you a 
chance to concentrate on preparing the release body without the double 
work you otherwise would need.

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Will we release before more major changes?

[andy p. <bod...@gm...>]

On Fri, 9 Oct 2026 at 16:00, andy pugh <bod...@gm...> wrote:

> Work on 2.10 would continue after the split, just as it does now on 2.9.

This would be a "new stable branch" as described in
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList

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

Re: [Emc-developers] Will we release before more major changes?

[andy p. <bod...@gm...>]

On Fri, 9 Oct 2026 at 10:55, Bertho Stultiens <lc...@va...> wrote:

> Please do not split yet. The HAL changes are not yet done.

Work on 2.10 would continue after the split, just as it does now on 2,9.

It would be expected that things intended for 2.10 would be committed
to 2.10, then merged into master periodically, in the same way that
2.9 does.

But it would also mean that things _not_ intended for 2.10 could be
committed (to master only)

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

Re: [Emc-developers] Will we release before more major changes?

[Bertho S. <lc...@va...>]

On 10/9/26 10:01 AM, andy pugh wrote:
>> IMHO we should release before any wholesale NML changes go in at the very least.

The NML change is a 3.0 thing. It is such a large change that you cannot 
possibly do this in a short time. It isn't even clear what the future 
should look like. But discussing it can be, ehm, interesting ;-)


> Agreed. We have a new trajectory planner and a new HIL. I think that
> we do need a period of stabilisation.
> One possibility would be to split 2.10 from master at this point.
Please do not split yet. The HAL changes are not yet done.

The user visible break has been done. The last phase, making the code 
64-bit clean, is still in progress. The really big one there, hostmot2, 
has yet to be done. And you do not want to split before encoders are 
fixed to be 64-bit counters for all components and drivers.

Speed has been slower recently because life interfered (and, unless 
someone is willing to pay me for working on LCNC, life's interference 
tops LCNC).


Besides, before 2.10 is split off there should be a thorough look 
through the issues and PRs of what must still be fixed. Maybe on the 
todo list?

-- 
Greetings Bertho

(disclaimers are disclaimed)

Re: [Emc-developers] Will we release before more major changes?

[Luca T. <lu...@ai...>]

For the release the multiaxis if we get to the G53.x would be good for a release.

And I was thinking the ini_updater is that coming along?

PS:
I'll be a bit late Sunday, I'm flying back home, and I have a layover in Hong Kong which matches up with the meeting, roughly :-)



On October 9, 2026 5:01:51 PM GMT+09:00, "Robert Schöftner" <rm...@un...> wrote:
>Am Freitag, dem 09.10.2026 um 01:48 +0000 schrieb Chris Morley:
>> I see much talk and some code hints to major changes coming in the
>> code.
>> Should we not pause and consider releasing before upsetting the code
>> base.
>> The HAL changes them selves are a very large change.
>> 
>> From previous experience, a major code change requires a minimum of 6
>> months to more commonly a year before code settles again. And a
>> release candidate is at least 6 months for stabilization.
>> 
>> IMHO we should release before any wholesale NML changes go in at the
>> very least.
>
>I agree, IMO as soon as the HAL changes are done we should branch off
>2.10 and put out a release candidate. NML replacement will take some
>time until it is even clear what and how to do. We will discuss this on
>sunday.
>
>https://github.com/LinuxCNC/linuxcnc/discussions/4615
>
>Andy's list from january had 1) simplifying HAL types (32/64bit etc...)
>2) getting rid of parameter limitations in HAL and 3) new tormach TP.
>
>IMO integration of the new tormach TP isn't going to happen, there
>seems to be more stuff going on regarding trajectory planning, and we
>should probably release 2.10 before any really major architectural
>stuff is changed. 
>
>
>
>At the last video meeting I learned that sunday morning in US timezones
>is inconvenient for some people. Please suggest more convenient
>weekdays/times than what we do currently for regular online video
>meetings.
>
>_______________________________________________
>Emc-developers mailing list
>Emc...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Will we release before more major changes?

[Robert S. <rm...@un...>]

Am Freitag, dem 09.10.2026 um 01:48 +0000 schrieb Chris Morley:
> I see much talk and some code hints to major changes coming in the
> code.
> Should we not pause and consider releasing before upsetting the code
> base.
> The HAL changes them selves are a very large change.
> 
> From previous experience, a major code change requires a minimum of 6
> months to more commonly a year before code settles again. And a
> release candidate is at least 6 months for stabilization.
> 
> IMHO we should release before any wholesale NML changes go in at the
> very least.

I agree, IMO as soon as the HAL changes are done we should branch off
2.10 and put out a release candidate. NML replacement will take some
time until it is even clear what and how to do. We will discuss this on
sunday.

https://github.com/LinuxCNC/linuxcnc/discussions/4615

Andy's list from january had 1) simplifying HAL types (32/64bit etc...)
2) getting rid of parameter limitations in HAL and 3) new tormach TP.

IMO integration of the new tormach TP isn't going to happen, there
seems to be more stuff going on regarding trajectory planning, and we
should probably release 2.10 before any really major architectural
stuff is changed. 



At the last video meeting I learned that sunday morning in US timezones
is inconvenient for some people. Please suggest more convenient
weekdays/times than what we do currently for regular online video
meetings.