mraa do_dpkg_build error on building example image #1
Comments
|
Please also provide the console log where kas-docker was running. And probably also |
Hi jan-kiszka, |
|
No luck in understanding or even reproducing yet. I just ran and that worked. But my Ubuntu VM is a bit older (18.04.2), and so is the docker.io (18.09.7). Will have to refresh that setup, but that may take some days. Last thing to compare upfront: I was giving 4G RAM to the VM (and 8 cores, but that should not make the difference). How much does yours have? |
|
I can confirm that My VM has 4GB of RAM and two cores. |
|
We likely need a reference description for the setup of such a system. Still, I'd like to understand eventually where this issue comes from. Apparently, it was not only seen once. |
|
Another factor to specify, besides recommended RAM size, is free storage size. Both values should also go into our README. |
|
I'll try to setup a VM from scratch with Ubuntu 20.04 to see what steps are needed to setup such a system. |
|
The machine with problems was: I've tried with another VM on VMWare on my Notebook: And its working. I'm able to generate example image correctly. |
|
I suppose we can close the issue then. FWIW, I've scheduled some safety measure for kas-docker (siemens/kas@385e42f) to detect and reject execution as root so that at least one source of trouble will be eliminated in the future. |
|
I ran into this same issue (/usr/lib/jvm/default-java/bin/javac: not found). It was corrected by building on a debian 10 VB as opposed to Ubuntu 18 or by upgrading the MRAA patch to use python 3 exclusively (remove references to python 2.6). |
|
Do you mean you dropped |
|
Yes... initially I tried pulling a more recent version of mraa but the problem remained and was during the cmake. IIRC I did the cmake locally to resolve the build problems. This diff is based on a different version of mraa.bb but indicates the different DEBIAN_BUILD_DEPENDS (also turned off the cmake tests). Didn't get a change to test it as we determined that it would build on debian 10. |
|
It's a bit tricky to find the root change here. My feeling is that one of your chances disabled the java binding support and, thus, no longer needs the javac during build. That would obviously also avoid the issue. Or can you rule that out? |
|
javac is required for the cmake. I think that the default javac is not set up correctly with libpython-dev, libpython3-dev and default-jdk on some platforms. Removing libpython-dev and using the specific openjdk-11-jdk (as opposed to default-jdk) appears to set up javac in a more consistent manner across platforms. |
|
cmake (with the mraa-provided setup) probes for java, it does not require it. You can perfectly build mraa without any java installed. However, our recipe enforces it ( |
|
I also ran into the same issue, my machine is Actually I have compiled it successfully before on same machine, but when I cleaned the cache and try to rebuild, this issue occured. |
|
I changed -DBUILDSWIGJAVA=ON to -DBUILDSWIGJAVA=OFF, the issue is solved. |
|
I think I found the solution: Could you retry with that change and java enabled? Please do a clean rebuild. |
|
With configuration of default-jdk:native and -DBUILDSWIGJAVA=ON, the image is successfully compiled. What is difference between default-jdk and default-jdk:native? |
|
From the commit log of the upcoming fix: |
System:
Win10 + Virtual Machine VirtualBox 6.0.8 r130520
VM:
Kernel: 5.3.0-51-generic x86_64 bits: 64
Desktop: Gnome 3.28.4 Distro: Ubuntu 18.04.4 LTS
Docker version 19.03.6
The machine is the same used for building IOT2040 images.
I'm trying to build the example image as specified in README:
./kas-docker --isar build kas-iot2050-example.ymlbut I cannot generate the image only because I get one error on
mraa do_dpkg_build. Below the building result log lines:Analyzing the logfile
log.do_dpkg_build.2094seems that the error starts from Java compilation.Below the last lines from the logfile:
What can I do?
Thank you
Attached there is the complete logfile of the failure:
The text was updated successfully, but these errors were encountered: