Build Instructions Added!

[Yang Wang]

Hello all,

I finished writing and testing the build instructions for ISOBlue 2.0. You can try it out at https://www.isoblue.org/docs/build.html

Let us know if you have any trouble or confusion within the instructions. We would be glad to help.

Regards,

Yang

[Josep Pijuan]

Dear Yang, 

I've been following your build instructions with no succes at all at the moment. 

I've did the tests in a empty ubuntu 18.04 as I tried with the ubuntu 16.10 version but I had so many problems with repositories.

I've changed a bit the dependencies as I've installed the libcrypto++6 but I've arrived until the step of buling the image wiht bitbake but I always have an error wiht the sanity checks. 

This is the command used for libraries intallation:

sudo apt-get install curl dosfstools gawk g++-multilib gcc-multilib lib32z1-dev \

libcrypto++6:i386 libcrypto++-dev:i386 liblzo2-dev:i386 lzop libsdl1.2-dev \

libstdc++-5-dev:i386 libusb-1.0-0:i386 libusb-1.0-0-dev:i386 uuid-dev:i386 \

texinfo chrpath

And this is the error I have when bitbake is executed.

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.

    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).

    Following is the list of potential problems / advisories:

    PATH contains '.', './' or '' (empty element), which will break the build, please remove this.

Parsed PATH is ['/home/isoblue-core/layers/openembedded-core/scripts', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/arm-angstrom-linux-gnueabi', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin', '/home/isoblue-core/build/tmp-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/bin', '', '/home/isoblue-core/build/tmp-glibc/hosttools']

You will be able to see some "1.0-r0" folder. Any of you have any idea about the reason for that problems and how to solve?

Thanks in advance

Josep

El dissabte, 3 març de 2018 20:49:00 UTC+1, Yang Wang va escriure:

[Yang Wang]

Hello Joseph,

I've been following your build instructions with no succes at all at the moment. 

Bummer!

I've did the tests in a empty ubuntu 18.04 as I tried with the ubuntu 16.10 version but I had so many problems with repositories.

What repositories? And what problems did you have?

I've changed a bit the dependencies as I've installed the libcrypto++6 but I've arrived until the step of buling the image wiht bitbake but I always have an error wiht the sanity checks. 

I did some tests on 18.04 before and I had to install libcrypto++6 as you did since 18.04 does not have libcrypto++9v5:i386 any more. For my system, libcryptopp.so.6 was installed in /usr/lib/i386-linux-gnu so for adding the symlink as in the build instructions, I had to run: cd /usr/lib; sudo ln -s libcrypto++.so.6 /usr/lib/i386-linux-gnu/libcryptopp.so.6

Make sure you did that.

A side note: I did some test builds in 18.04 as well and I always got failed builds with this error (see this issue and this issue that described the error) and it is mostly likely caused by the changes in toolchains that Ubuntu 18.04 installs. I don't have the fix for this error at the moment.

My recommendation is to stick with 16.10 or 16.04 since we have successfully built the image in these two Ubuntu versions.

PATH contains '.', './' or '' (empty element), which will break the build, please remove this. 

After some googling this error, I see this.

What this is saying is that you probably messed with your shell's $PATH after you use `. export` to set it up. What do you see when you run `echo $PATH`? If you $PATH contains '.', './', '', try removing it. Or a simpler way is to open up another terminal and run `. export` to set up a fresh build environment.

[Josep Pijuan]

Dear Yang,

First of all thank you for your answer and help.

I followed your recommendations about ubuntu distribution and now I'm working with an Ubuntu 16.04. Let me add that I'm working in a docker environment in case it could make any difference. 

Now, I don't have any repository problem and after installing python3 and solve a locale issue, I'm able to execute the build with the bitbake command. However, when I do, I have the same problem than using Ubuntu 18.04. I also have "." in the bitbake path.

I've tried to print my PATH and this is the result:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

So, I discard that I have the same issue you shared. I suspect that it is something related to dependencies of any needed library using a folder path with the folder "1.0-r0". 

Again thanks for your support.

Josep

El dimecres, 24 octubre de 2018 5:46:39 UTC+2, Yang Wang va escriure:

[Yang Wang]

Hello Josep,

I've tried to print my PATH and this is the result: 

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

After I ran `. export` to set up the build environment, this is the result I got from running `echo $PATH `:

/home/yang/isoblue-core/layers/openembedded-core/scripts:/home/yang/isoblue-core/layers/openembedded-core/bitbake/bin:/home/yang/bin:/home/yang/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Notice the extra openembedded-core directories which your path doesn't have. Based on your $PATH, I don't think your environment was properly set up for bitbaking the image.

Let me add that I'm working in a docker environment in case it could make any difference. 

Maybe that does make the difference? We haven't tried any test build in a docker environment but I did find a repo a while ago: https://github.com/kmikolaj/docker-debian-toradex

I tried it once and I don't think I had any success with it. Perhaps it could help you as a reference.

Would you mind try building the image without docker?

Regards,

Yang

[Aaron Ault]

Or, perhaps Josep would be willing to push up his docker image to docker hub and we can take a look on our end?

Thanks

Aaron

--
You received this message because you are subscribed to the Google Groups "ISOBlue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isoblue+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josep Pijuan]

Dear Yang,

Thanks for your help, I have some good news but again new issues.

I think that my problem was with the path as you mentioned, after exporting the bulding path again I'm able to run the build. However, it finishes abruptly with errors. This is the log I have:

test@46805c4795d9:/home/isoblue-core/build$ /home/isoblue-core/layers/openembedded-core/bitbake/bin/bitbake -v -r ../isoblue.conf console-isoblue-image

Loading cache: 100% |#########################################################################################################################################################| Time: 0:00:01

Loaded 3845 entries from dependency cache.

WARNING: No recipes available for:

  /home/isoblue-core/build/../layers/meta-freescale/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bbappend

  /home/isoblue-core/build/../layers/meta-freescale/dynamic-layers/browser-layer/recipes-browser/chromium/chromium_52.0.2743.76.bbappend

  /home/isoblue-core/build/../layers/meta-jetson-tk1/recipes-graphics/mesa/mesa_11.1.1.bbappend

  /home/isoblue-core/build/../layers/meta-isoblue-demos/recipes-support/icu/icu_57%.bbappend

  /home/isoblue-core/build/../layers/meta-isoblue-demos/recipes-support/opencv/opencv_2.4.bbappend

NOTE: Resolving any missing task queue dependencies

NOTE: selecting u-boot-toradex to satisfy virtual/bootloader due to PREFERRED_PROVIDERS

NOTE: selecting opkg-utils-native to satisfy virtual/update-alternatives-native due to PREFERRED_PROVIDERS

NOTE: selecting opkg-native to satisfy opkg-native due to PREFERRED_PROVIDERS

NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to PREFERRED_PROVIDERS

NOTE: selecting linux-toradex to satisfy virtual/kernel due to PREFERRED_PROVIDERS

NOTE: selecting opkg-utils to satisfy runtime update-alternatives-opkg due to PREFERRED_PROVIDER_virtual/update-alternatives = opkg-utils

NOTE: selecting u-boot-toradex to satisfy runtime u-boot-toradex due to PREFERRED_PROVIDER_virtual/bootloader = u-boot-toradex

NOTE: selecting systemd to satisfy runtime systemd due to PREFERRED_PROVIDER_udev = systemd

NOTE: selecting glibc to satisfy runtime ldd due to PREFERRED_PROVIDER_virtual/libc = glibc

NOTE: selecting linux-toradex to satisfy runtime kernel-base due to PREFERRED_PROVIDER_virtual/kernel = linux-toradex

NOTE: selecting linux-toradex to satisfy runtime kernel-image-zimage due to PREFERRED_PROVIDER_virtual/kernel = linux-toradex

NOTE: selecting glibc-locale to satisfy runtime locale-base-en-us due to PREFERRED_PROVIDER_virtual/libc-locale = glibc-locale

NOTE: selecting u-boot-toradex to satisfy runtime u-boot-toradex-dev due to PREFERRED_PROVIDER_virtual/bootloader = u-boot-toradex

ERROR: Nothing RPROVIDES 'linux-firmware-sd8997' (but /home/isoblue-core/build/../layers/meta-isoblue-demos/recipes-images/images/console-isoblue-image.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'linux-firmware-sd8997' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['linux-firmware-sd8997']

NOTE: Target 'console-isoblue-image' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['console-isoblue-image', 'linux-firmware-sd8997']

ERROR: Required build target 'console-isoblue-image' has no buildable providers.

Missing or unbuildable dependency chain was: ['console-isoblue-image', 'linux-firmware-sd8997']

Summary: There was 1 WARNING message shown.

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

I've syncronized the repository and rerun the build but the result it's the same. Any idea?

Thanks again!

P.D. Answering Aaron I will try to make a dockerfile at the end of the process and share with it with this community. However, at the moment I'm not working with dockerfiles yet, just with a docker environment using a container with ubuntu 16.04 and manually executing all commands.

El dilluns, 29 octubre de 2018 14:17:54 UTC+1, Yang Wang va escriure:

[Yang Wang]

Hello Josep,

I think that my problem was with the path as you mentioned, after exporting the bulding path again I'm able to run the build.

Awesome!

However, it finishes abruptly with errors.

I have seen that error. I was messing with the isoblue-image repo yesterday and accidentally pushed some changes to the master branch (the branch you repo synced I believe) at one point. I thought I fixed but apparently no.

What hardware version of apalis computer module are you using? We have both V1.1B and V1.1C modules and Toradex have different versions of BSP for them (V2.7 for V1.1B and V2.8 for V1.1C).

I will test build the master branch today and fix any error and I will let you know once we have working image for V1.1C in case you have this hardware.

Regards,

Yang

[Josep Pijuan]

I have seen that error. I was messing with the isoblue-image repo yesterday and accidentally pushed some changes to the master branch (the branch you repo synced I believe)

Yes you are right, I'm using the master branch.

 

at one point. I thought I fixed but apparently no.

What hardware version of apalis computer module are you using? We have both V1.1B and V1.1C modules and Toradex have different versions of BSP for them (V2.7 for V1.1B and V2.8 for V1.1C).

I'm using Apalis IMX6 V1.1C, so I understand I should use the master branch

 

I will test build the master branch today and fix any error and I will let you know once we have working image for V1.1C in case you have this hardware.

OK Thank you a lot!

 

Regards,

Yang

[Bert van Brakel]

Would building everything from a docker image make life easier? All the right tools can be setup on that. Only need to distribute the Dockerfile.

It can then also be built from multiple OS'es

My 2 cents

 

[Yang Wang]

Hello Josep,

Hello Josep,

I cleaned up the master branch so now it should build an image that supports V1.1C apalis module.

In the directory you executed `repo sync`, please execute this command again to have the update-to-date recipes.

What I usually do to make things easier is just do a `rm -rf *` (make sure you deleted the .repo directory as well) in the directory you executed `repo init` and `repo sync` and reinitialize, synchronize the layers, and bitbake with a fresh environment.

Let me know if you run into any issues.

Regards,

Yang 

[Aaron Ault]

Yang,

This sounds like a great idea to me.  Can you try the build in a container and push to docker hub if it works?

Thanks

Aaron

[Yang Wang]

Hello Bert,

Would building everything from a docker image make life easier? All the right tools can be setup on that. Only need to distribute the Dockerfile.

Yes. Do you want to take a stab on that?

Regards,

Yang

[Josep Pijuan]

Hello Yang,

First of all thank you for your help durig may lasts posts. I come back to this issue after such a long time occupied wiht ohter projects.

Now I'm working in the objective to create a dockerfile that could enable the automation of this task. I've solved some problems when sorucing the "export" script by using absolute paths.

However, I'm having problems when I execute the bitbake command. I paste the output I have:

ERROR: Unable to start bitbake server
ERROR: Last 10 lines of server log for this session (/home/isoblue-core/build/bitbake-cookerdaemon.log):
         try:
    >        exec(code, get_context(), context)
         except (bb.BBHandledException, bb.parse.SkipRecipe, bb.build.FuncFailed, bb.data_smart.ExpansionError):
  File "exec_python_func() autogenerated", line 2, in <module>
  File "/home/isoblue-core/build/../layers/openembedded-core/meta/classes/sanity.bbclass", line 84, in oecore_update_bblayers(d=<bb.data_smart.DataSmart object at 0x7fb8973eccf8>):
         current_lconf = int(d.getVar('LCONF_VERSION'))
    >    lconf_version = int(d.getVar('LAYER_CONF_VERSION'))

TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

I've read here that it could be for encryption problems but I think that was not the problem as I'm using the default ubuntu 16.04 dockerfile. Finally I've solved the issue (not sure if it is the right solution) by adding a line to set in the bblayers.conf files a value to LAYER_CONF_VERSION. See the solution below:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"
LAYER_CONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

Now, I'm having another issue. The following text is the error ouput.

ERROR: Your version of local.conf was generated from an older/newer version of
local.conf.sample and there have been updates made to this file. Please compare the two
files and merge any changes before continuing.

I understant that the local.conf file is copied during the export script from openembedded-core folder. isn't it? So should any config be different?

Do you have any idea about where could be the problem? By the way I'm using the master branch from the isoblue repository.

El diumenge, 4 novembre de 2018 3:48:21 UTC+1, Yang Wang va escriure:

[Yang Wang]

Hello Josep,

I understant that the local.conf file is copied during the export script from openembedded-core folder. isn't it?

No. If you look into the `export ` script, you can see that if the script is been run for the first time, it is copying the local.conf from `../layers/meta-isoblue-demos/buildconf/` directory.

So should any config be different?

Not that I know of. I took this configuration file as it is from the board manufacturer's upstream.

The two minor changes: 1) I set `MACHINE ?= apalis-imx6` 2) I whitelisted oracle java layer by using `LICENSE_FLAGS_WHITELIST += "oracle_java"`.

Do you have any idea about where could be the problem? By the way I'm using the master branch from the isoblue repository.

I am out of ideas at this point. Both master and v2.7 branches are tested with successful builds without docker.

Actually would you mind sharing your steps to create your docker image? Even if it doesn't fully work, my colleagues and I could follow your steps to reproduce your error and see what we could do.

Regards,

Yang

[Josep Pijuan]

Hello Yang,

In order to advance in the generation of a dockerfile I share the current dockerfile I'm using. It requires two argments for git account configuration, however it could be edited to put your settings as default. The current docker file prepares an ubuntu 16.04 environment with all the build instruction from isoblue manual until . export. This command is not execued in the dockerfile. So, when running an image generated you can immediatley execute ". export" command an continue the guide.

I'm not sure if there have been changes on openembedded version or anywhere but after solving the LAYER_CONF_VERSION issue, create a sanity file via "touch conf/sanity.conf" and executring the bitbake command the output I have is the following:

root@e8b47a080467:/home/isoblue-core/build/conf# bitbake -r ../isoblue.conf console-isoblue-image

ERROR: Unable to start bitbake server

ERROR: Last 10 lines of server log for this session (/home/isoblue-core/build/conf/bitbake-cookerdaemon.log):
bb.BBHandledException

ERROR: Your version of local.conf was generated from an older/newer version of
local.conf.sample and there have been updates made to this file. Please compare the two
files and merge any changes before continuing.

Matching the version numbers will remove this message.

"meld conf/local.conf /home/isoblue-core/layers/openembedded-core/meta*/conf/local.conf.sample"

is a good way to visualise the changes.

Let' se if we can create a Dockerfile together.

El dijous, 14 març de 2019 15:55:31 UTC+1, Yang Wang va escriure:

[Yang Wang]

Hello Josep,

I will take a look at this. I have a quick question:

root@e8b47a080467:/home/isoblue-core/build/conf# bitbake -r ../isoblue.conf console-isoblue-image

When you are in the docker environment, why are you executing the bitbake command in the `conf` directory? Normally, if `. export` should put you in the `build` directory when everything's set up. You then execute the bitbake command in the `build` directory. Would you mind trying that?

Regards,

Yang

[Josep Pijuan]

Hello Yang, I usually(not always as stated) execute bitbake from build directory. I provably copied the output of a wrong test, from many I did. Sorry for this confusion.

El divendres, 15 març de 2019 15:11:50 UTC+1, Yang Wang va escriure: