search

LinuxCNC / linuxcnc

LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.
http://linuxcnc.org/
GNU General Public License v2.0
1.78k stars 1.14k forks source link

Upload of LinuxCNC to Debian distribution? #1269

Open smoe opened 2 years ago

smoe commented 2 years ago

Hello, you seem to care for Debian but your package is not part of that distribution, which would then also see LinuxCNC passed to derivatives like Ubuntu and Mint. Did you just never get around to it (I can help) or do you just prefer to distribute your work directly? Best, Steffen

SebKuzminsky commented 2 years ago

Hi there, we're very much interested in getting LinuxCNC into Debian and its derivatives. Thank you for your kind offer of help.

For a long time LinuxCNC required a custom kernel that wasn't part of Debian (RTAI: https://www.rtai.org/), so getting into Debian was a daunting task. Nowdays LinuxCNC can run on either RTAI or Preempt-RT (which is part of Debian: https://packages.debian.org/linux-image-rt), so the task is much more manageable.

We'd love to have your help getting LinuxCNC into Debian. I've given this task some though, and I think some things that need to be addressed are:

There are probably other issues I'm forgetting at the moment.

I'm happy to talk more about this, here on github or on the linuxcnc-dev mailing list (http://linuxcnc.org/community/). I tend to not be very active on our IRC channels anymore, though other LinuxCNC developers are.

rene-dev commented 2 years ago

as most stuff works with preempt rt, having only preempt rt is ok imho. Im working on a new build system using cmake, which solves many problems, and makes building packages easier.

  • We Recommend two helper packages, mesaflash (https://github.com/LinuxCNC/mesaflash/) and hostmot2-firmware (https://github.com/LinuxCNC/hostmot2-firmware). Both are open source, but hostmot2-firmware builds using a non-free VHDL compiler from Xilinx. LinuxCNC can be used without these, but especially with the Preempt-RT kernel we benefit greatly from offloading part of the work to a Hostmot2 FPGA, and then those packages are required.

firmware files are not a runtime dependencie anymore. all mesa cards with spartan6 have a flash memory which contains the firmware. you only need to download and load the firmware once.

  • We currently have some out-of-date dependencies (python2, gtk2). Active efforts are underway to modernize these dependencies, but those projects are not done yet.

all fixed in master already, only waiting for a new release, and few bugfixes.

  • Our binary packages probably don't conform to the Debian Filesystem Hierarchy Standard.

so do the python modules, but this is also fixed with cmake.

smoe commented 2 years ago

Thank your for the swift and friendly feedback, @rene-dev and @SebKuzminsky. The bullseye release just went out, so we have some two years to get into the next. I suggest I'll dive into your source tree a bit and see how far I get. Any non-free dependencies, since they are optional, do not matter too much. These would become packages on their own as time permits.

Debian has a Science(+Engineering) team, ans an Electronics team, i.e. friendly folks who help each other out when something changes somewhere (like a new standards version) who exchange their debian folders on salsa.debian.org (a gitlab instance). Since you are autogenerating the debian folder if I interpreted the build instructions right, it may however be preferable to maintain all the Debian-bits in your source tree on github and just have me as an uploader ("sponsor" in Debian lingo).

Thank you for these good early vibes, Steffen

smoe commented 2 years ago

So, somewhat unplanned I rewarded myself with an early look at linuxcnc :) My immediate feedback made it into https://github.com/LinuxCNC/linuxcnc/pull/1270 . The rest is a bit of extra care, I think, that may be triggered by Debian's limitations but would be motivated to help your user base at large:

I do not really know about how urgent the separation of the RT bits is from the rest. This should not be required if there is already a good understanding from your side that someone who just wants to install this without an RT module to see the GUI would have no worries. For me it is more of a feel-good factor and maybe there would be too much confusion? Or would it actually help since nobody could try what would not work reliably? Should not be too difficult to separate, would it?

The build dependencies need a clean-up. Can you have the documentation triggered separately in build-indep? All packages only needed for the doc should then go to Build-Depends-Indep. Packages that are only needed for testing should then move to the bottom of the Build-Depends and get a " <!nocheck>" tag behind the package name and before the comma.

Can the autotest run without a realtime kernel? The testing would need to be added to d/rules.

Like I already said in my PR - nice! I do not think there is much to do for an initial upload. It took me a while to understand that your CI is on focal. I like how you care for different distributions in d/configure and so I would then introduce the one or other exception for debian/unstable - like specs for d/compat.

rene-dev commented 2 years ago
  • can we separate the realtime-dependent bits (linuxcnc package) from the rest (linuxcnc-core (?) package) so all the folks with an inappropriate kernel do not need to worry about the init script you added?

all tests run without rt kernel. RT preempt runs in user mode, so its the same binary! if the renice syscall fails, it still works fine, just with more jitter.

rene-dev commented 2 years ago

obviously not for machine control, but for testing and development this is fine.

smoe commented 2 years ago

I was just worried about /etc/init.d/realtime - but if you know this to be harmless - no separate package, then.

rene-dev commented 2 years ago

Im not sure what that does, or if it is even used.

SebKuzminsky commented 2 years ago

Our realtime init script loads the basic kernel modules needed to start RTAI. It is not used for userspace-only builds using Preempt-RT or vanilla kernels.

smoe commented 2 years ago

I had also skimmed through the realtime script and was not overly happy about it trying to install kernel modules. It is just something that average joe user who installs linuxcnc may not expect. My gut feeling is that you want to prepare a separate linuxcnc-rtai binary package, but this is all on you to decide.

Concerning the packaging I think the final bits prior to the upload is to remove build dependencies that are not required to be explicitly listed. I can do that.

On https://github.com/LinuxCNC/linuxcnc/pull/1270 I introduced a Debian-version. Since you do not want to tag new releases for any change that is Debian-specific this sounds like a good idea for me (and is a must-have for the upload). That had consequences for your testing routines since it now required a source tarball, so all my patches are not completely off.

The next steps are on you, I think.

I'll have a look at mesaflash and hostmot2-firmware in the meantime.

petterreinholdtsen commented 2 years ago

For the record, https://bugs.debian.org/969416 is the request for linuxcnc in Debian.

smoe commented 2 years ago

Yesterday I failed to find that ITP. At least I did not create a new one.

petterreinholdtsen commented 2 years ago

[Steffen Möller]

Yesterday I failed to find that ITP. At least I did not create a new one.

It is <URL: https://bugs.debian.org/969416 >. We can add it to the changelog in the next upload. :) -- Happy hacking Petter Reinholdtsen

petterreinholdtsen commented 2 years ago

The upload already happened, and the package is waiting in the Debian NEW queue for approval by the Debian archive maintainers. Once it is accepted it will show up on https://tracker.debian.org/linuxcnc .