On Monday 01 July 2019 14:10:46 Sebastian Kuzminsky wrote: > On 7/1/19 11:55 AM, andy pugh wrote: > > On Mon, 1 Jul 2019 at 17:09, Sebastian Kuzminsky > > > > <seb.kuzmin...@gmail.com> wrote: > >>> Also when I look at this page > >>> http://buildbot.linuxcnc.org/dists/stretch/ > >>> <http://buildbot.linuxcnc.org/dists/stretch/> it shows master and > >>> 2.7 haven’t been updated since 09-Jun > >> > >> Oops! Fixed, thanks for letting me know. > > > > Any plans for a Buster Buildbot? > > I'd very much like to add Buster builders to the Buildbot. > > LinuxCNC builds on Buster and the tests pass, so run-in-place style > build-and-test should be doable today. > > But some parts of LinuxCNC have runtime dependencies that are not > available in Buster. We'd have to figure out what to do about those > parts before we can start shipping Buster debs... > I had a similar problem installing what I built on the pi running realtime stretch when I went to install what I had built, following your instructions that use dpkg-buildpackage. When I ran apt to install those dependencies, I wound up with a downgrade of an already installed package. apt recommended a --fix-broken, which apparently completed the removal of the updated package, then finished the install, and linuxcnc is running normally now.
I found a realtime-buster and put it on a card about 1:30 ago, and it booted to a text login but without finding either the keyboard or the mouse, so that u-sd is in my pocket, waiting the RealtimePi to finish a buster conversion, but I already know the video will still crawl as it downgrading the buster 4.19.50 kernel to a 4.14.114, which I do not think has the new video drivers in it kit. We'll see in 2 or 3 hours when thats done. If it doesn't bail out early because the ssd went read-only. That faint knocking sound? Yup. :) Its probably warming up the pi some too as I see by the build.log, that make was issued with a -j4 argument. > > Is it worth looking at cross-compiling for armhf if native arm > > boards are not reliable enough? > > (It's not particularly useful for build process testing, but having > > the debs would at least get some users testing) > Like me. But I'm actually building on the pi, and I'm not hiding it, if it works I have zero objections to shareing what works here. I'm not doing much to a git clone except setting the ARCH=arm. For my purposes I could probably strip it (the buster image) to half the size it is now by making modules out of stuff I don't use here. I don't use any sound and wifi is disabled too to keep the neighbors out. I don't think they are doing it on purpose but they've used as much as 80G one month before I disabled it in dd-wrt, and I can't bridge to anyplace but my own net from the pi. And I don't need to setup iptables on every machine to keep the curious from snooping. > I'd much rather do native arm builds, both because of the test > coverage issue you mentioned and also to keep the build process > unified across hardware architectures. Take care Seb. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
