×
Important information

To file a bug, find instructions here: Reporting bugs

Please only post images or files to this forum which you either own the copyright to or you are sure can be distributed under an open source license.

Docker containers for building deviation

More
20 Apr 2016 19:05 #46892 by PhracturedBlue
try it now (just rerun your existing 'deviation-build' no need to pull anything. It should update to version 0.9.1 of the build script.
You should now have a 'Shell' button. While not as useful for you, I also fixed it so that if you hit the 'Update GIT now" button, it will return you to the gui when done

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 19:21 - 20 Apr 2016 19:25 #46893 by silpstream
Getting out to shell works beautifully!

Now how do I get back into the GUI from shell? LOL.
Nevermind, found it. Just type "exit". :lol:
Thanks!
Last Edit: 20 Apr 2016 19:25 by silpstream.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 19:34 #46895 by silpstream
Just tried to make TARGET=devo7e from shell. Got this error:
make[2]: arm-none-eabi-gcc: Command not found
make[2]: *** [adc.o] Error 127
make[1]: *** [lib/stm32/f1] Error 2
make: *** [libopencm3/lib/libopencm3_stm32f1.a] Error 2

I've not dug around to see how you set up through build.py, but it might be a path thing cause I saw that gcc was downloaded when I first ran a build through the gui.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 20:39 #46897 by PhracturedBlue
yes that isn't supported. You need to add /root/gcc-arm-none-eabi-4_8-2013q4/bin to your path.

I'm not sure I want to update it. thh vanilla image does not include the cross-compiler. It is installed as part of the 'build' process on demand. Which means it may not be there when you get to a shell. Maybe I'll add support to install dependencies without running make, and set the env variables automatically if the dependencies are met.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 23:46 #46908 by HappyHarry
i just spun up an ubuntu 15.10 vm to test the docker setup and everything went ok bar one thing that might catch newcomers out, docker requires root privileges to run so you will need to use sudo before the commands PB has shown, or you can add your own user account to the 'docker' group by using the following command which will allow you to run docker without using sudo.

sudo gpasswd -a ${USER} docker

PB i really like what you have added to these docker images, the persistence is really nice and the gui is very straight forward to use, kudos!. i have ran a build of the 7e, 7e-256 and devo10 both the emu's and tx images and all work fine. i came up against some problems building for the devo12 though firstly the emu build threw this error

 + Compiling 'target/common/emu/fltk.cpp'
In file included from /root/fltk-1.3.3-w32/include/FL/fl_draw.H:30,
                 from target/common/emu/fltk.cpp:34:
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:244: warning: unused parameter 'str'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:244: warning: unused parameter 'n'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:244: warning: unused parameter 'x'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:244: warning: unused parameter 'y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:249: warning: unused parameter 'angle'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:249: warning: unused parameter 'str'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:249: warning: unused parameter 'n'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:249: warning: unused parameter 'x'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:249: warning: unused parameter 'y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:251: warning: unused parameter 'str'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:251: warning: unused parameter 'n'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:251: warning: unused parameter 'x'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:251: warning: unused parameter 'y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:255: warning: unused parameter 'r'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:255: warning: unused parameter 'g'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:255: warning: unused parameter 'b'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'buf'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'X'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'Y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'W'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'H'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'D'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:344: warning: unused parameter 'L'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'buf'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'X'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'Y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'W'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'H'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'D'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:346: warning: unused parameter 'L'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'cb'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'data'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'X'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'Y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'W'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'H'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:348: warning: unused parameter 'D'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'cb'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'data'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'X'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'Y'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'W'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'H'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:350: warning: unused parameter 'D'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'rgb'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'XP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'YP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'WP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'HP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'cx'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:357: warning: unused parameter 'cy'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'pxm'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'XP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'YP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'WP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'HP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'cx'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:363: warning: unused parameter 'cy'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'bm'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'XP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'YP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'WP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'HP'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'cx'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:369: warning: unused parameter 'cy'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:385: warning: unused parameter 'str'
/root/fltk-1.3.3-w32/include/FL/Fl_Device.H:385: warning: unused parameter 'n'
 + Building 'emu_devo12.exe'
  adding: deviation-emu_devo12-v4.0.1-8ada152.exe (deflated 66%)
  adding: libportaudio-2.dll (deflated 60%)
	zip warning: name not matched: filesystem/devo12
make[1]: *** [emu_devo12.zip] Error 12
make: *** [zip_win_emu_devo12] Error 2

and building the tx image threw this error

phil@ubuntu:~/devodock$ build-devo 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7169  100  7169    0     0  22578      0 --:--:-- --:--:-- --:--:-- 22615
Updating build.py
Already up-to-date.
Building zip_devo12
Preparing for ARM build
 + Compiling 'target/devo12/backlight.c'
 + Compiling 'target/devo12/channels.c'
 + Compiling 'target/devo12/crc.c'
 + Compiling 'target/devo12/lcd.c'
 + Compiling 'target/devo12/par_flash.c'
 + Compiling 'target/devo12/tx_buttons.c'
 + Compiling 'target/common/stm32/fgets.c'
 + Compiling 'target/common/stm32/printf.c'
 + Compiling 'target/common/devo/adc.c'
 + Compiling 'target/common/devo/clock.c'
In file included from ./libopencm3/include/libopencm3/cm3/nvic.h:135:0,
                 from target/common/devo/clock.c:21:
./libopencm3/include/libopencm3/dispatch/nvic.h:4:39: fatal error: libopencm3/stm32/f1/nvic.h: No such file or directory
 # include <libopencm3/stm32/f1/nvic.h>
                                       ^
compilation terminated.
make[1]: *** [objs/devo12/clock.o] Error 1
make: *** [zip_devo12] Error 2

if you need more info or require any farther tests ran for this ubuntu vm use case just let me know

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 01:15 #46911 by PhracturedBlue
The warnings are expected, the error not so much. I can replicate this. It isn't a docker-image problem but a makefile problem. I'll work on it.

I updated the build to 0.9.2 (again, no reason to re-pull, it will auto-update). Now you can 'make' from the shell, and it includes some info on using the shell.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 07:03 #46920 by mwm
You can get out of the GUI by launching a different command when you start the container. If you really wanted to, you could plug starting the container into a make file to run different command there.

BSD is a Unix system, not a Linux system. While the kernel does have a Linux emulation mode, it only supports 32 bit binaries. They didn't go the VM route for the docker port so they could get proper integration between ZFS and docker. If you really want to run docker images on a VM, you still can. And docker on ZFS is a serious win.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 12:40 #46934 by PhracturedBlue
Which BSD do you use? my searches indicated that 64bit linux support was there in FreeBSD at least.
I don't want to have users create new docker images with different commands. My image downloads and builds the necessary pre-requisites into persistent storage, but that storage is only persistent for a given instance. So if you redo 'docker run' you need to redownload and build the env. I could have included it in the image already, but this way we can change the build environment without requiring users to download a new image (and it more closely matches what I do in travis). Actually, now that I have a python wrapper, I wonder if I can parse and execute the travis.yml file for execution....

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 14:45 - 21 Apr 2016 14:52 #46940 by HappyHarry
ok i just run a full build of all tx's and emu's and everything went like clockwork apart from the x9 tx image which threw this error
phil@ubuntu:~$ build-devo 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8360  100  8360    0     0  55613      0 --:--:-- --:--:-- --:--:-- 55733
Updating build.py

Already up-to-date.
Building zip_x9d
Preparing for ARM build
 + Compiling 'target/x9d/adc.c'
target/x9d/adc.c:15:37: fatal error: libopencm3/stm32/f2/adc.h: No such file or directory
 #include <libopencm3/stm32/f2/adc.h>
                                     ^
compilation terminated.
make[1]: *** [objs/x9d/adc.o] Error 1
make: *** [zip_x9d] Error 2

checking libopencm3's git adc.h only seems to exist in f1, f3, and f4 but not f2? also the x9d emu build went fine.

dropping to the shell to build works perfectly though i had to install nano :p
Last Edit: 21 Apr 2016 14:52 by HappyHarry.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 15:02 #46943 by PhracturedBlue
x9d doesn't actually work right now. There wasn't much point in it until we have a multi-module for it. Theoretically, having the devof12e supported will make it easier as we made all displays template based, so there should be no need to lock into a 128x64 display any more. I'll get to it some day.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 15:04 #46944 by PhracturedBlue
by the way, mwm, if you want to pull the github repo, you can tweak the Dockerfile to support a 32bit build and make sure it works for you if 64bit is really not an option. Ping me before checking it in though. I'm not sure I want to do that vs creating a deviaton-docker:32 image yet.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 15:34 - 21 Apr 2016 15:34 #46948 by HappyHarry

PhracturedBlue wrote: x9d doesn't actually work right now. There wasn't much point in it until we have a multi-module for it. Theoretically, having the devof12e supported will make it easier as we made all displays template based, so there should be no need to lock into a 128x64 display any more. I'll get to it some day.


yeah that makes sense, well then that gives the docker build setup on linux a clean bill of health

i'll try to test on windows and get back to you if no one else has done so buy then
Last Edit: 21 Apr 2016 15:34 by HappyHarry.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 16:49 - 21 Apr 2016 16:50 #46952 by HappyHarry
i was looking into why all gcc-arm builds since 2013q4 have been making larger code than previously and i came accross this >> answers.launchpad.net/gcc-arm-embedded/+question/255381 i wonder if nano-libs was recompiled it would help? or is it even worth looking in too?
Last Edit: 21 Apr 2016 16:50 by HappyHarry.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 17:28 #46953 by PhracturedBlue
I looked at the assembly output at one time, and the fact is that they just chose to optimize differently. We use very few of the stdlib library functions, and this isn't a significant impact. I don't know much about compilers, but I like the code produced by our current compiler better than what I saw from newer ones for the few cases I compared. That said, the differences aren't all that significant, it just turns out we are very tight on space for some transmitters. This is especially critical for the DSM protocol which is sitting right at the edge right now. I do not know how to reduce its size further, and the last time I tried, no other compiler could build it into the 4k size limit.

Once 5.0 is released, I'll look into upgrading the tool chain again.

Please Log in or Create an account to join the conversation.

More
21 Apr 2016 19:22 #46960 by HappyHarry
my knowledge in this area is miniscule so i'll bow to your findings, i just found it confusing that the compiled code was getting bigger instead of smaller with newer revisions of the compiler. the 4k protocol limit, that affects the 7e, the f4 and f7 yeah? does it affect the 7e-256 also?

Please Log in or Create an account to join the conversation.

More
22 Apr 2016 09:41 #46973 by mwm

PhracturedBlue wrote: Which BSD do you use? my searches indicated that 64bit linux support was there in FreeBSD at least.


FreeBSD. I went back and double checked, and the Handbook still says "32-bit binary compatibility". Possibly 64-bit support is in the dev branch, but I'm not really willing to run that on my desktop. And it wouldn't surprise me if that broke running 32-bit binaries on the linux image, which at least my docker images need to work.

I don't want to have users create new docker images with different commands. My image downloads and builds the necessary pre-requisites into persistent storage, but that storage is only persistent for a given instance. So if you redo 'docker run' you need to redownload and build the env. I could have included it in the image already, but this way we can change the build environment without requiring users to download a new image (and it more closely matches what I do in travis). Actually, now that I have a python wrapper, I wonder if I can parse and execute the travis.yml file for execution....


Personally, I don't like leaving docker containers laying around unused. I'm not sure how well that works on OSX or Windows: does shutting down the VM they are running in throw them out? If so, then you have to leave the entire VM around, not just the non-running container.

If you can let figure out how to let users get a shell on your container, cool. If not, then they can create a second container from the image with shell access. At least for now. And this is part of the reason I left the source out of my images.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
22 Apr 2016 12:46 #46980 by PhracturedBlue
I really recommend trying what I have. I think all answers will be revealed. It has been tested on Windows and Mac and Linux and works as desired.

Please Log in or Create an account to join the conversation.

More
22 Apr 2016 21:35 #47009 by HappyHarry
tested the setup and build on windows and can give it a clean bill of health.

i wonder is there a way to build a specific commit? as for instance just now the latest code doesn't build so is there a way to pull and build the previous comit apart from using the shell commands?

Please Log in or Create an account to join the conversation.

More
22 Apr 2016 21:38 #47010 by PhracturedBlue
I may add support for building specific branches (like choosing between 5.0 and latest), but I don't think selecting individual builds is something most users want to deal with. Now that we have travis, build failures should be dealt with pretty quickly.

Please Log in or Create an account to join the conversation.

More
22 Apr 2016 21:44 #47011 by HappyHarry
yeah i get most wont need it, and those who do will likely know how to use the shell. yeah i'll say that was a pretty quick fix lol :)

Please Log in or Create an account to join the conversation.

Time to create page: 0.273 seconds
Powered by Kunena Forum