Custom Mint-19.2 with Linuxcnc
There is no clear update path for packages, which users seem to be concerned about. I don't get it, take a car's ECU, how many think about updates for that, apart from a bit of fiddling with the fuel no one gives it a second thought. If the OS is stable and Linuxcnc runs the machine why the want for regular updates ? Going by the lack of reading people do I wonder if they even know what the updates are and why they would want or need them.
Someone even admitted to installing Mint and being concerned about updates without even knowing what Mint is. Seriously WTF.
Who would be so, I haven't got the words, that would just blindly install something from a DVD to run a cnc machine and want regular updates.
I'd happily build weekly packages from git, but have no place to host a repo. I use reprepro on a slackware server to keep local updates to save on bandwidth for the machines I use at home. I even have a signing key that's available via key server for signing.
So users will be stuck with one version of Linuxcnc, that has some mods to the debian build so the html docs are built and packaged separately to have a local copy of. Or they can build from source and either keep the miss matched html docs or delete them and install the new packages.
So basically I don't see the point with progressing with this, in a few months RTAI wont be an option for newer machines as it doesn't work with UEFI. UEFI seems to be an issue for real time, even the linux RT lowlatency patches of late have issue mounting efivars and causing install issues. Now that Intel deems that startup should be handled by UEFI only on Gemini Lake and later how many people are gunna be upset that their new MB is going on have issues with RealTime. Unless of course later kernels have fixed this, but I really haven't got the inclination to start building 5 series kernels to see what works with UEFI and what doesn't.
I don't even want to think about the mess it's going to cause when people want to dual boot with windows.
Seeing as the devs have a preference for debian and wish to continue down that path I thought best to pull out before too many become dependant on Mint and then get left with no support down the road.
I was fully prepared to put an idle Dual Quad core Xeon machine to do the builds for Bionic, as that is what the main repos for Mint 19.2 are, but I got no response, so that really drove home the path the devs wanted to follow.
I apologise to those I've inconvenienced it wasn't my intent.
And the black dog's been scratching at the door again.
i might add that you and others work did wake us devs up to getting a release done before you guys did it yourselves
I don't think that means there is no room for Mint builds for 2.8 and 2.9. Mint 2.7 is probably not required as hopefully 2.8 will be the release branch soon.
RTAI is certainly a different kettle of fish. Personally I dropped my machine speeds a bit on my parport machines so I could use PREEMPT with higher latency. Some say if it ain't broke don't fix it but using Wheezy on a relatively modern machine seems a bit odd to me.
I know what you mean about folk not reading but that issue is never going to go away.
I just think that V 2.8 is 12 months overdue and there was talk from one dev about adding another 3-4 ISO's and wanted to keep support for 32 bit hardware becasue he used that on his mill. So all I could see was further delays.
What I think should happen is that we get V2.8 deployed as fast as we can with the least possible path of resistance. That means Debian.
But then once we get distros for Mint and the Raspberry PI, then ISO's should be added for them in a V 2.8.1 et al.
Really its inexcusable that a release candidate has been languishing for the best part of 12 months. We need to get it done!
I am really excited that you, Chris and Andy have stepped up to get this done. Lets get 2.8 published at warp speed and then come back and sort out the ISO's.
One win, I think we will have is that the reverse run from Master that Phill did so long ago seems like it will get into V 2.8 becasue its had 12 months in master branch. Its also great to see Cam's work with the feedrate pin and Andy's recent work on State tags. So lets make a real commitment to get them into 2.9. If the feedrate pin gets to V 2.8 at warp speed then fine but if it needs time for testing, then surely it should be put into master branch, the same as what was decided for Reverse run.
There was a response of sorts, Seb said:
> Is it more practical to add remote buildslaves to support extra
> platforms or to try to add more to Seb's (possibly already over-taxed)
I'm running out of space on my build cluster, and the buildbot
infrastructure has evolved in such a way that it's no longer
straight-forward to run buildslaves off-site. That capability could
probably be revived with some effort, but not in the next month or so.
We also discussed the option of pointing a Mint installation at the Buster LinuxCNC repositories to see what happened. If that works then we could support Mint ISOs with a symbolic link, no dedicated buildslave required.