Re: [Emc-developers] 2.9 Release Manager Required.
I can make sure RTAI works with LinuxCNC myself, no need for Seb's stuff or anyone's VMs for that matter. Adding back in RTAI support though to the LinuxCNC Debian configure script would be helpful. I started on it but it's not finished. https://github.com/LinuxCNC/linuxcnc/issues/2052 In case the link gets truncated, it's issue 2052 on the LinuxCNC Github. The most I'll need is someone with Intel hardware to test my changes but all of that has already been tested thanks to Rainer Stelzer. Alec On Monday, November 14, 2022 at 07:57:21 PM CST, m...@mattshaver.com wrote: On 2022-11-14 15:54, Sebastian Kuzminsky wrote: > In order to support testing LinuxCNC on RTAI the buildbot uses custom > VMs which i created a long time ago and maintain poorly. It all runs > on hardware in my house, on my local network, so I am reluctant to > open it up to a more collaborative mode of development/maintenance. Is there some way of replicating your home based setup (or obtaining a compatible hardware/software environment) by contracting with a commercial hosting company, or co-location facility, or something like that? If this could be done for a reasonable amount of money, I'd be happy to pay for it, or at least chip in. I can't do much to help, but I can spend money! Thanks, Matt ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On 2022-11-14 15:54, Sebastian Kuzminsky wrote: In order to support testing LinuxCNC on RTAI the buildbot uses custom VMs which i created a long time ago and maintain poorly. It all runs on hardware in my house, on my local network, so I am reluctant to open it up to a more collaborative mode of development/maintenance. Is there some way of replicating your home based setup (or obtaining a compatible hardware/software environment) by contracting with a commercial hosting company, or co-location facility, or something like that? If this could be done for a reasonable amount of money, I'd be happy to pay for it, or at least chip in. I can't do much to help, but I can spend money! Thanks, Matt ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
https://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg23329.html full link in case it gets truncated and you get a 404 On 11/14/22 18:55, Alec Ari via Emc-developers wrote: I don't mind building LinuxCNC RTAI packages but the problem is actually a license problem. LinuxCNC keeps complaining after the ./configure about how it's a non-distributable build, but that flag has to be set due to the readline GPL-v2/LGPL starting with Debian Bullseye, otherwise the configure will fail. Building RTAI kernel debs for LinuxCNC is easy, it's literally download source, patch, make -j`nproc` bindeb-pkg and voila. https://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg23329.html Curious, how are you guys legally hosting LinuxCNC Debian packages for Bullseye or Bookworm? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I don't mind building LinuxCNC RTAI packages but the problem is actually a license problem. LinuxCNC keeps complaining after the ./configure about how it's a non-distributable build, but that flag has to be set due to the readline GPL-v2/LGPL starting with Debian Bullseye, otherwise the configure will fail. Building RTAI kernel debs for LinuxCNC is easy, it's literally download source, patch, make -j`nproc` bindeb-pkg and voila. https://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg23329.html Curious, how are you guys legally hosting LinuxCNC Debian packages for Bullseye or Bookworm? I'm going to be working with Paolo on getting RTAI and PREEMPT_RT on the same kernel, I have 99.9% of the code done (all the kernel code itself is done) but I'm stuck on literally one line of C in the RTAI mailbox driver. You could theoretically even patch LinuxCNC to let you choose at runtime or in the settings somewhere what you want, RTAI or PREEMPT_RT, cutting the need for two different LinuxCNC packages. Just a thought. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I'll just wait until you guys decide on a way forward and iff the offer we have is required. Perhaps the Github actions could be extended to build the 2.9 branch? If that were possible, maybe the VM here does the RTAI build? I'm not sure git will host the resulting debs but it might be worth mentioning the Open build Service I linked to earlier can be incorporated right into sources.list with the appropriate security keys. See the list of builds on the right. https://build.opensuse.org/project/show/home:bone1:branches:science:EtherLab Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Tue, 15 Nov 2022 at 09:21, Bari wrote: > On 11/14/22 15:54, Sebastian Kuzminsky wrote: > > > > > The difficulty with building and testing LinuxCNC in docker containers > > or in off-the-shelf VMs (as in Github Actions) is that our 'RTAI' > > configuration needs a special kernel, and needs to load and unload > > kernel modules to run & test LinuxCNC. > > > > (Unlike RTAI, the 'uspace' config *can* be built and tested in docker > > containers, though we don't currently do that in our Github Actions. > > The LinuxCNC/mesaflash project builds in docker in Github Actions, and > > I agree, it's great and super convenient.) > > > > In order to support testing LinuxCNC on RTAI the buildbot uses custom > > VMs which i created a long time ago and maintain poorly. It all runs > > on hardware in my house, on my local network, so I am reluctant to > > open it up to a more collaborative mode of development/maintenance. > > > > > Seb, > > Yes you only have so much time and thankfully you have donated so much > of it over the years and also your home based sever buildbot. > > Alec already mentioned supporting and maintaining the RTAI packages. > I'll check back with him on what he recommends we do for a public > build-bot. He spent the last coupe of years automating cloud setups and > even has been included in a patent on doing so. > > Rod has already found us some free VM space. Alec didn't see a problem > with getting it all connected and setup. He also works closely with Andy > and building RTAI. > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On 11/14/22 15:54, Sebastian Kuzminsky wrote: The difficulty with building and testing LinuxCNC in docker containers or in off-the-shelf VMs (as in Github Actions) is that our 'RTAI' configuration needs a special kernel, and needs to load and unload kernel modules to run & test LinuxCNC. (Unlike RTAI, the 'uspace' config *can* be built and tested in docker containers, though we don't currently do that in our Github Actions. The LinuxCNC/mesaflash project builds in docker in Github Actions, and I agree, it's great and super convenient.) In order to support testing LinuxCNC on RTAI the buildbot uses custom VMs which i created a long time ago and maintain poorly. It all runs on hardware in my house, on my local network, so I am reluctant to open it up to a more collaborative mode of development/maintenance. Seb, Yes you only have so much time and thankfully you have donated so much of it over the years and also your home based sever buildbot. Alec already mentioned supporting and maintaining the RTAI packages. I'll check back with him on what he recommends we do for a public build-bot. He spent the last coupe of years automating cloud setups and even has been included in a patent on doing so. Rod has already found us some free VM space. Alec didn't see a problem with getting it all connected and setup. He also works closely with Andy and building RTAI. ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On 11/14/22 13:37, Jérémie Tarot wrote: Could someone explain me how relocating the buildbot on someone's machine can be better for the project than migrating it to GitHub Actions, build farm and package hoster ? Don't get me wrong John and Rod, I very much appreciate your proposal and investment but I believe your time and resources would be better employed. I'm looking at you MesaCT, EtherCAT... From what I've found and understood, it could be enough to upgrade our current ci.yml to use docker containers to build all our packages for the desired architectures and selected distributions/releases, and then use one of the PackageCloud actions available to push artifacts to a specialised host. The difficulty with building and testing LinuxCNC in docker containers or in off-the-shelf VMs (as in Github Actions) is that our 'RTAI' configuration needs a special kernel, and needs to load and unload kernel modules to run & test LinuxCNC. (Unlike RTAI, the 'uspace' config *can* be built and tested in docker containers, though we don't currently do that in our Github Actions. The LinuxCNC/mesaflash project builds in docker in Github Actions, and I agree, it's great and super convenient.) In order to support testing LinuxCNC on RTAI the buildbot uses custom VMs which i created a long time ago and maintain poorly. It all runs on hardware in my house, on my local network, so I am reluctant to open it up to a more collaborative mode of development/maintenance. -- Sebastian Kuzminsky ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
This sounds like a good long term solution if it's free. In the mean time I'm trying to at least get some debs uploaded to http://linuxcnc.org/dists/ as soon as I get my ssh key sorted out. JT On 11/14/2022 2:37 PM, Jérémie Tarot wrote: Le dim. 13 nov. 2022 à 18:39, Jérémie Tarot a écrit : Hello Andy, Well, at least you're not alone to feel ignored sometimes... Could someone explain me how relocating the buildbot on someone's machine can be better for the project than migrating it to GitHub Actions, build farm and package hoster ? Don't get me wrong John and Rod, I very much appreciate your proposal and investment but I believe your time and resources would be better employed. I'm looking at you MesaCT, EtherCAT... From what I've found and understood, it could be enough to upgrade our current ci.yml to use docker containers to build all our packages for the desired architectures and selected distributions/releases, and then use one of the PackageCloud actions available to push artifacts to a specialised host. Nothing to ask to anyone, no human dependency, no friendship to stretch, all managed openly in main repository, git+gh goodness included, all on massively distributed infrastructure... Just missing a free beer ! We have enough contacts with other projects already putting this tooling to great use, FreeCAD comes to mind first, so we could call for advises and directions to ease the process and strengthen the output. Further, Actions marketplace and ecosystem opens a great bunch of possibilities for our CI pipeline... TY J ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
Ooops Python 3.9 Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Tue, 15 Nov 2022 at 06:53, Rod Webster wrote: > I think some of those features on github might incurr a cost. I'm sure we > have more than 500 mb of code. > You could also consider this free openbuild servce > https://build.opensuse.org/ > The etherlab guys use it to build debs as per the sticky I put in our > ethercat forum. > They have a connector from github called osc. I tried running it recently > but it uses a Python lib which was deprecated in Python 9. > I don't think the users will be impacted if the end result gets hosted on > http://linuxcnc.org/dists/ as part of the build process. > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Tue, 15 Nov 2022 at 06:38, Jérémie Tarot wrote: > >> Le dim. 13 nov. 2022 à 18:39, Jérémie Tarot a >> écrit : >> > >> > Hello Andy, >> > >> >> Well, at least you're not alone to feel ignored sometimes... >> >> Could someone explain me how relocating the buildbot on someone's >> machine can be better for the project than migrating it to GitHub >> Actions, build farm and package hoster ? >> Don't get me wrong John and Rod, I very much appreciate your proposal >> and investment but I believe your time and resources would be better >> employed. I'm looking at you MesaCT, EtherCAT... >> >> From what I've found and understood, it could be enough to upgrade our >> current ci.yml to use docker containers to build all our packages for >> the desired architectures and selected distributions/releases, and >> then use one of the PackageCloud actions available to push artifacts >> to a specialised host. >> Nothing to ask to anyone, no human dependency, no friendship to >> stretch, all managed openly in main repository, git+gh goodness >> included, all on massively distributed infrastructure... Just missing >> a free beer ! >> >> We have enough contacts with other projects already putting this >> tooling to great use, FreeCAD comes to mind first, so we could call >> for advises and directions to ease the process and strengthen the >> output. >> >> Further, Actions marketplace and ecosystem opens a great bunch of >> possibilities for our CI pipeline... >> >> TY >> J >> >> >> ___ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I think some of those features on github might incurr a cost. I'm sure we have more than 500 mb of code. You could also consider this free openbuild servce https://build.opensuse.org/ The etherlab guys use it to build debs as per the sticky I put in our ethercat forum. They have a connector from github called osc. I tried running it recently but it uses a Python lib which was deprecated in Python 9. I don't think the users will be impacted if the end result gets hosted on http://linuxcnc.org/dists/ as part of the build process. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Tue, 15 Nov 2022 at 06:38, Jérémie Tarot wrote: > Le dim. 13 nov. 2022 à 18:39, Jérémie Tarot a écrit > : > > > > Hello Andy, > > > > Well, at least you're not alone to feel ignored sometimes... > > Could someone explain me how relocating the buildbot on someone's > machine can be better for the project than migrating it to GitHub > Actions, build farm and package hoster ? > Don't get me wrong John and Rod, I very much appreciate your proposal > and investment but I believe your time and resources would be better > employed. I'm looking at you MesaCT, EtherCAT... > > From what I've found and understood, it could be enough to upgrade our > current ci.yml to use docker containers to build all our packages for > the desired architectures and selected distributions/releases, and > then use one of the PackageCloud actions available to push artifacts > to a specialised host. > Nothing to ask to anyone, no human dependency, no friendship to > stretch, all managed openly in main repository, git+gh goodness > included, all on massively distributed infrastructure... Just missing > a free beer ! > > We have enough contacts with other projects already putting this > tooling to great use, FreeCAD comes to mind first, so we could call > for advises and directions to ease the process and strengthen the > output. > > Further, Actions marketplace and ecosystem opens a great bunch of > possibilities for our CI pipeline... > > TY > J > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On Mon, 14 Nov 2022 at 20:42, Jérémie Tarot wrote: > Could someone explain me how relocating the buildbot on someone's > machine can be better for the project than migrating it to GitHub > Actions, build farm and package hoster ? What would the user install instructions look like in that scenario? -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
Le dim. 13 nov. 2022 à 18:39, Jérémie Tarot a écrit : > > Hello Andy, > Well, at least you're not alone to feel ignored sometimes... Could someone explain me how relocating the buildbot on someone's machine can be better for the project than migrating it to GitHub Actions, build farm and package hoster ? Don't get me wrong John and Rod, I very much appreciate your proposal and investment but I believe your time and resources would be better employed. I'm looking at you MesaCT, EtherCAT... From what I've found and understood, it could be enough to upgrade our current ci.yml to use docker containers to build all our packages for the desired architectures and selected distributions/releases, and then use one of the PackageCloud actions available to push artifacts to a specialised host. Nothing to ask to anyone, no human dependency, no friendship to stretch, all managed openly in main repository, git+gh goodness included, all on massively distributed infrastructure... Just missing a free beer ! We have enough contacts with other projects already putting this tooling to great use, FreeCAD comes to mind first, so we could call for advises and directions to ease the process and strengthen the output. Further, Actions marketplace and ecosystem opens a great bunch of possibilities for our CI pipeline... TY J ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Python3 is available also for buster Aw: Re: 2.9 Release Manager Required.
On Mon, 14 Nov 2022 at 14:26, Steffen Möller wrote: > > If all the dependencies of the RTAI version are in Debian then I see no > reason why only the RTAI version should be built. The main dependency of the RTAI version is the RTAI kernel. And that isn't in Debian. -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Plans for the USB sticks anyone?
On Mon, 14 Nov 2022 at 14:53, Steffen Möller wrote: > I am tempted to suggest that the LiveCD may run with bookworm. My line of > thought is that when we release, bookworm will already be "frozen", such that > the parts of Debian we are using are unlikely to see much of a change until > the release gets out. I would be much more comfortable releasing LinuxCNC on a released OS. Making a Bullseye branch in live-build is basically trivial. https://github.com/LinuxCNC/linuxcnc-live-build/blob/buster/config/build -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] linuxcnc.org/dists
If someone can supply me with the credentials for http://linuxcnc.org/dists/ I can build debs and upload them via sftp for the ones that the current buildbot does not create. JT ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Plans for the USB sticks anyone?
> Gesendet: Montag, 14. November 2022 um 10:28 Uhr > Von: "andy pugh" > An: "EMC developers" > Betreff: Re: [Emc-developers] Plans for the USB sticks anyone? > > On Mon, 14 Nov 2022 at 08:52, Steffen Möller wrote: > > > b) the Live USB stick with LinuxCNC (and other useful or eye candy bits) on > > it > > > > Is there any "production team" for b) already? I would like to discuss what > > is missing and/or should be updated. > > It uses live-build and is controlled by: > https://github.com/LinuxCNC/linuxcnc-live-build Found it. Thank you for the pointer. That repository features a branch "bookworm" next to a branch "buster", nothing for "bullseye". I am tempted to suggest that the LiveCD may run with bookworm. My line of thought is that when we release, bookworm will already be "frozen", such that the parts of Debian we are using are unlikely to see much of a change until the release gets out. Best, Steffen ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Python3 is available also for buster Aw: Re: 2.9 Release Manager Required.
If all the dependencies of the RTAI version are in Debian then I see no reason why only the RTAI version should be built. Python3 is in all versions of Debian https://tracker.debian.org/pkg/python3-defaults. Best, Steffen > Gesendet: Montag, 14. November 2022 um 13:44 Uhr > Von: "Rod Webster" > An: "EMC developers" > Betreff: Re: [Emc-developers] 2.9 Release Manager Required. > > OK, > I wonder if we could organise a Google meet to discuss this before I go > back to Damien so I understand requirements. Also it would be good if > somebody could find out memory requirements for a buildbot. > > I am GMT +10 so off to bed now. > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Mon, 14 Nov 2022 at 21:28, andy pugh wrote: > > > On Mon, 14 Nov 2022 at 10:18, Rod Webster wrote: > > > > > > Do we really need a Bullseye release? > > > > I think so. I have the impression that the 2.9 release is already > > considered "late" and our LiveCD is currently based on Buster (which > > is out of date, though still supported as oldstable, I think?) > > > > Bookworm is due to be released in the middle of next year, which seems > > a long time to be distributing a Buster ISO. > > > > > If the Debian release freeze starts In January and we've always had to > > > build from source on Bullseye, aren't we going backwards and doubling the > > > maintenance? > > > > No, going forward from Buster, which is our current release platform > > (buildbot debs and ISO OS) > > We would theoretically be reducing maintenance as 2.9 abandons support > > for Python2 and GTK2. > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions > > That means supporting Buster, Bullseye, Bookworm and Focal but not > > bothering any more with being compatible with Precise, Wheezy, Jessie > > or Stretch. > > > > Even when Bookworm is out we still have a bit of a gap if we want to > > continue to support RTAI as the Debian infrastructure is (probably) > > only going to build the uspace version. > > > > There are helper apps that work fairly well to run linuxcnc-uspace on > > RTAI or Xenomai kernels. Would we want to add those to Debian too? > > > > I think that we would continue to host the less mainstream debs at > > www.linuxcnc.org/dists along with some of or backported packages > > (where required) > > > > > > > > -- > > 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-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
OK, I wonder if we could organise a Google meet to discuss this before I go back to Damien so I understand requirements. Also it would be good if somebody could find out memory requirements for a buildbot. I am GMT +10 so off to bed now. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Mon, 14 Nov 2022 at 21:28, andy pugh wrote: > On Mon, 14 Nov 2022 at 10:18, Rod Webster wrote: > > > > Do we really need a Bullseye release? > > I think so. I have the impression that the 2.9 release is already > considered "late" and our LiveCD is currently based on Buster (which > is out of date, though still supported as oldstable, I think?) > > Bookworm is due to be released in the middle of next year, which seems > a long time to be distributing a Buster ISO. > > > If the Debian release freeze starts In January and we've always had to > > build from source on Bullseye, aren't we going backwards and doubling the > > maintenance? > > No, going forward from Buster, which is our current release platform > (buildbot debs and ISO OS) > We would theoretically be reducing maintenance as 2.9 abandons support > for Python2 and GTK2. > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions > That means supporting Buster, Bullseye, Bookworm and Focal but not > bothering any more with being compatible with Precise, Wheezy, Jessie > or Stretch. > > Even when Bookworm is out we still have a bit of a gap if we want to > continue to support RTAI as the Debian infrastructure is (probably) > only going to build the uspace version. > > There are helper apps that work fairly well to run linuxcnc-uspace on > RTAI or Xenomai kernels. Would we want to add those to Debian too? > > I think that we would continue to host the less mainstream debs at > www.linuxcnc.org/dists along with some of or backported packages > (where required) > > > > -- > 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-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On Mon, 14 Nov 2022 at 10:18, Rod Webster wrote: > > Do we really need a Bullseye release? I think so. I have the impression that the 2.9 release is already considered "late" and our LiveCD is currently based on Buster (which is out of date, though still supported as oldstable, I think?) Bookworm is due to be released in the middle of next year, which seems a long time to be distributing a Buster ISO. > If the Debian release freeze starts In January and we've always had to > build from source on Bullseye, aren't we going backwards and doubling the > maintenance? No, going forward from Buster, which is our current release platform (buildbot debs and ISO OS) We would theoretically be reducing maintenance as 2.9 abandons support for Python2 and GTK2. http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions That means supporting Buster, Bullseye, Bookworm and Focal but not bothering any more with being compatible with Precise, Wheezy, Jessie or Stretch. Even when Bookworm is out we still have a bit of a gap if we want to continue to support RTAI as the Debian infrastructure is (probably) only going to build the uspace version. There are helper apps that work fairly well to run linuxcnc-uspace on RTAI or Xenomai kernels. Would we want to add those to Debian too? I think that we would continue to host the less mainstream debs at www.linuxcnc.org/dists along with some of or backported packages (where required) -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
Do we really need a Bullseye release? If the Debian release freeze starts In January and we've always had to build from source on Bullseye, aren't we going backwards and doubling the maintenance? Can it be done in a chroot environment? I thought that's what buildbots did. I can ask nicely, but don't want to stretch the friendship unless we have to. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Mon, 14 Nov 2022 at 19:26, andy pugh wrote: > On Mon, 14 Nov 2022 at 08:34, Steffen Möller > wrote: > > > But I think that we still would need a Bullseye Buildbot. > > -- > 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-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Plans for the USB sticks anyone?
On Mon, 14 Nov 2022 at 08:52, Steffen Möller wrote: > b) the Live USB stick with LinuxCNC (and other useful or eye candy bits) on it > > Is there any "production team" for b) already? I would like to discuss what > is missing and/or should be updated. It uses live-build and is controlled by: https://github.com/LinuxCNC/linuxcnc-live-build -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
On Mon, 14 Nov 2022 at 08:34, Steffen Möller wrote: > The primary challenge for the build bots may be to place the resulting .debs > in a location from where they can then be installed with apt. I have no idea > how the current system does it. Semi-manually. There are some scripts: https://github.com/LinuxCNC/infrastructure It seems that some of the steps mentioned in http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList that I thought needed to be done in the Builbot are done here (so I could do them) But I think that we still would need a Bullseye Buildbot. -- 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Plans for the USB sticks anyone?
Dear all, I keep thinking that we are releasing two different things together a) LinuxCNC b) the Live USB stick with LinuxCNC (and other useful or eye candy bits) on it Is there any "production team" for b) already? I would like to discuss what is missing and/or should be updated. Best, Steffen ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.9 Release Manager Required.
I have not yet fully understood what is happening but I like all the vibes you are sending. > Gesendet: Sonntag, 13. November 2022 um 22:50 Uhr > Von: "John Thornton" > > I've been putzing around with buildbot and just now have it showing > changes in a scratch github repo. Now to make it build a deb... The .deb-building I suggest to copy from the ci.yml file (https://github.com/LinuxCNC/linuxcnc/blob/master/.github/workflows/ci.yml): eatmydata apt-get --yes --quiet build-dep --arch-only . eatmydata debuild -us -uc --build=any The debuild (or dpkg-buildpackage) is executed from within the source tree. The primary challenge for the build bots may be to place the resulting .debs in a location from where they can then be installed with apt. I have no idea how the current system does it. Best, Steffen > > JT > > On 11/13/2022 3:43 PM, andy pugh wrote: > > On Sun, 13 Nov 2022 at 21:15, Bari wrote: > > > >> Rod, > >> > >> Have you had a chance to check with your web host on getting a free VM? > >> > >> How much VM do we need to host a new buildbot? > > > > The existing buildbot (should) work for Buster and previous OSes. > > > > And Debian will be building Bookworm + uspace > > > > So I think we would need > > > > Bullseye amd64 uspace > > Bullseye amd64 RTAI > > Bullseye arm64 uspace > > Bookworm amd64 RTAI > > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
