cerna
commented
4 years ago @zultron,
I can't quite tell what you've done. I think I remember there still being Multi-Arch: problems in MK's (and LCNC's) package dependencies in Stretch, where it was impossible to co-install all the required host-arch dependency packages without apt uninstalling required build-arch dependencies. Have you found this isn't true (at least for most architectures)?
I have prepared a branch which illustrates it better - at least I think, tell me if this is not so: Jessie killing.
You can test like this:
docker run -it --rm -v "$(pwd):/mk" debian:buster
apt update
apt-get install build-essential fakeroot devscripts
curl -1sLf 'https://dl.cloudsmith.io/public/machinekit/machinekit/cfg/setup/bash.deb.sh' | bash
dpkg --add-architecture armhf
apt update
cd /mk
debian/configure
mk-build-deps --host-arch=armhf --build-arch=amd64 -ir
scripts/build_source_package false
CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ dpkg-buildpackage -uc -us -t arm-linux-gnueabihf -B(On Stretch you need to pass the option -d to dpkg-buildpackage.)
For the i686 problem, can you try using the amd64-arch gcc-6 package on i686, and just pass in CFLAGS=-m32 and LDFLAGS=elf_i386 as we do in the current system?
The compilation is not the problem. Problem is the Debian patched binutils package which takes care of the multiarch paths to linked libraries. (Plus the headers problem too.)
I have been trying to build the required package gcc-6-cross in supported version 30 with porting down the required dependencies, but so far without success - and not even on building this package, but so far I failed on building its dependencies.
I will try again - but I need a break.
Also, the command mk-build-deps where ${HOST} != ${BUILD} automagically depends on crossbuild-essential-${HOST}:${BUILD} and will require either dummy or the actual package.
If you can make this work, it would be absolutely fantastic. The /sysroot hacks were never meant to be permanent. They solved the problem of their time, but they're absolutely hideously hairy and ugly, and it will be a relief if we can get rid of them FOREVER.
There is the problem with cerna/machinekit-hal@bc7486cfc8eb521f899bfe9df4fb5b5ea4fb20af - I don't know if yours solution is the regression or if @ArcEye's one is. Any opinion?
zultron
gibsonc
the-snowwhite
Tracking progress:
dpkg-sigCMOCKAtestsamd64,armhfandarm64runtests in Drone Cloud CIyamlscript into saner form - JSONScript with autoregeneration by git hookyamlscript into saner form[ ] Implement saner git hook solution using Lefthook
As you probably know, the Machinekit buildserver (
jenkins.machinekit.io) was turned off. It was done quietly, so I have no idea when exactly it happened. It ran test on pull requests and uploaded debian packages into the Machinekit'sdeb.machinekit.iorepository. This is important for the C4 as without testing nothing can be merged, respective everything has to be merged.So as an emergency measure the Travis build system was turned back on for the Machinekit-HAL repository. In response to discussion with @luminize - where we agreed that some artifact output from CI run would be nice, so users can download the
.debpackages and usedpkg -icommand to install - I implemented simple Github Actions workflow in thequick&dirtystyle as Travis doesn't allow keeping artifacts for later download and it's nice for users to have automated build of packages in theirs forks. Github keeps the build artifacts for 90 days after the fact.Given the volatile situation with
*.machinekit.ioserver, I think that its state should be conserved and package upload should be resumed into the Packagecloud and Cloudsmith repositories (for redundancy). I can start the upload now or when the package build for Machinekit-CNC is ready (currently Machinekit-CNC repository has no CI for testing and package build), but I think that the time for it is after both Machinekit-HAL and Machinekit-CNC can be installed. I also think that it is a time to drop Jessie support (Jessie will be obsolete in 3 months) and make sure that Machinekit-HAL runs and produces packages on Bullseye.If I understand it correctly, the reason behind own Jenkins server was the 50 minuter running limit of Travis CI. Well, situation is vastly different today with everybody's mother giving Open-Source Projects free minutes on their cloud services. So how relevant is for example this issue for the current status of the project? Given that CI/CD rework will have to include solving the machinekit/machinekit-hal#195 issue, there is quite big window for any changes. Including the build Dockerfiles will also hopefully solve the current issues with image availability. (Machinekit-HAL currently uses my own DockerHUB account, as there are some missing images in the DovetailAutomata account, which caused machinekit/machinekit-hal#263.)
CI tools of today are also using the
container-firstapproach, for which the current scriptbuild_with_dockeris poorly suited. This script should be left for home use and the build commands exported to functions that then can be called directly from the container.There is also provider called Drone Cloud which gives Open-Source projects free build minutes directly on
armhfandarm64hardware. This could be used to test Machinekit-HAL not only onamd64as it is now but also on ARMs.Last but not least, there are now
cmockatests in Machinekit-HAL. I am all in for unit testing. However, no tests are actually run now and the build server are not even installing thecmockadebian package. So that will also need to be addressed.