search

AsteroidOS / asteroid

Build script for AsteroidOS, an open-source operating system for smartwatches
http://asteroidos.org
GNU General Public License v2.0
881 stars 64 forks source link

[Bass] Compilation not working #115

Closed tioui closed 4 years ago

tioui commented 4 years ago

Hi! I cannot compile AsteroidOS for Bass. When I do the bitbake asteroid-image command, It works for a long time and after a while, I get this error:

ERROR: asteroid-image-1.0-r0 do_package_index: Fatal errors occurred in subprocesses:
Command ' -r /home/louis_uncrypted/prog/asteroid/build/tmp-glibc/deploy/ipk/all/Packages -p /home/louis_uncrypted/prog/asteroid/build/tmp-glibc/deploy/ipk/all/Packages -m /home/louis_uncrypted/prog/asteroid/build/tmp-glibc/deploy/ipk/all' returned non-zero exit status 127.
Subprocess output:/bin/sh: 1: -r: not found

It look as if a command is missing in the command line (before the -r). I have the same problem when I compile directly on my PC or when I use the Docker method.

I have use bitbake -v asteroid-image to get more information and I have put the result in here: https://nuage.libreti.net/index.php/s/tXxcHLeej3cdQig .

MagneFire commented 4 years ago

Hi tioui, This is a weird error. Can you post the output of the command bitbake package-index?

tioui commented 4 years ago

Here it is:

Loading cache: 100% |###########################################################| Time: 0:00:00
Loaded 3588 entries from dependency cache.
Parsing recipes: 100% |#########################################################| Time: 0:00:01
Parsing of 2516 .bb files complete (2496 cached, 20 parsed). 3608 targets, 358 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.42.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-19.04"
TARGET_SYS           = "arm-oe-linux-gnueabi"
MACHINE              = "bass"
DISTRO               = "asteroid"
DISTRO_VERSION       = "1.1-nightly"
TUNE_FEATURES        = "arm armv7ve vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta-qt5             = "HEAD:8bc72a78b13f2f4c5e1cebebaef9e98b9abbb056"
meta                 = "warrior:ca019eec1304ca2a400ea744c0eaafe0a766d5d1"
meta-asteroid        = "master:a2b3b09c8d9e34708abb75c1ebb0326d846eabf2"
meta-oe              
meta-multimedia      
meta-gnome           
meta-networking      = "warrior:a24acf94d48d635eca668ea34598c6e5c857e3f8"
meta-android         = "warrior:a9d1a062f049b8b50223fe49d200343fba78f482"
meta-python          
meta-filesystems     = "warrior:a24acf94d48d635eca668ea34598c6e5c857e3f8"
meta-anthias-hybris  = "master:5f89fd26124f18274d3a82c6d97a3648dbef7872"
meta-sparrow-hybris  = "master:31ae712d9d494e2a150844ce881c6bddb0f4ea5a"
meta-sprat-hybris    = "master:dffb304bb530ab58ed27e4b51e20c69d2bfb7a29"
meta-tetra-hybris    = "master:469a6b30491f0976a958915592aeb03917057610"
meta-bass-hybris     = "master:380ba21e09491f31bc44ec0efe6086621a560c6d"
meta-dory-hybris     = "master:5a77ec835d98c8cc1e8f1e132d7f27a3f681515f"
meta-lenok-hybris    = "master:6f61cb9c154bdb5f5e01419af83bdc69921b3221"
meta-sturgeon-hybris = "master:83e7dca0e0308823f4a0fdce8119d1848954362f"
meta-mtk6580-hybris  = "master:b177482cb48b37e4cfd2e7eb83ed1af3f2b33f7b"
meta-mooneye-hybris  = "master:f18c8cd9fc4e731cc62d3994bd5c6be16233556d"
meta-swift-hybris    = "master:41d87ae86ffb085c6c5837d1020c2affac014566"
meta-wren-hybris     = "master:b1e41f3feec04fa40b09ff4291205cd4f3c9e4b4"

Initialising tasks: 100% |######################################################| Time: 0:00:00
Sstate summary: Wanted 1 Found 0 Missed 1 Current 44 (0% match, 97% complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 356 tasks of which 353 didn't need to be rerun and all succeeded.
tioui commented 4 years ago

It is possible that I have found where the problem occured. In the file src/oe-core/meta/lib/oe/package_manager.py, the script use a command line that seems very like the one that fail. See: https://github.com/openembedded/openembedded-core/blob/warrior/meta/lib/oe/package_manager.py#L220 .

Seems like it does not found the opkg-make-index command. This command appear a lot in the compilation directory tree:

$ find . -name opkg-make-index
./build/tmp-glibc/work/bass-oe-linux-gnueabi/shadow-securetty/4.6-r3/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/bass-oe-linux-gnueabi/base-files/3.0.14-r89/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/initscripts/1.0-r155/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/qemuwrapper-cross/1.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/opkg-utils/0.4.0-r0/opkg-utils-0.4.0/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/opkg-utils/0.4.0-r0/opkg-utils-0.4.0/.pc/0001-Switch-all-scripts-to-use-Python-3.x.patch/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/linux-libc-headers/5.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/armv7vet2hf-neon-oe-linux-gnueabi/package-index/1.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/run-postinsts/1.0-r10/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/update-rc.d/0.8-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/autoconf-archive/2018.03.13-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/wayland-protocols/1.17-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/volatile-binds/1.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/tzdata/2019c-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/os-release/1.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/all-oe-linux/iso-codes/4.2-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/sysroot-destdir/asteroid/build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/opkg-utils-0.4.0/opkg-make-index
./build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/opkg-utils-0.4.0/.pc/0001-Switch-all-scripts-to-use-Python-3.x.patch/opkg-make-index
./build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/image/asteroid/build/tmp-glibc/work/x86_64-linux/opkg-utils-native/0.4.0-r0/recipe-sysroot-native/usr/bin/opkg-make-index
./build/tmp-glibc/sysroots-components/x86_64/opkg-utils-native/usr/bin/opkg-make-index
MagneFire commented 4 years ago

We recently had an issue where the package-index wouldn't be generated while creating the asteroid-image. This was solved in https://github.com/AsteroidOS/meta-asteroid/commit/bf607bf2f6684e37a635e302e858718ca29a8e83#diff-092c9a1630196c63ec66cf7144a62b6a. Which is taken from https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/meta/package-index.bb.

Now that I look into the package-index recipe it might be possible that we need https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/meta/package-index.bb#L19 to fix this issue.

Can you try append do_package_index[depends] += "${PACKAGEINDEXDEPS}" to https://github.com/AsteroidOS/meta-asteroid/blob/master/classes/asteroid-image.bbclass to see if that solves the problem?

tioui commented 4 years ago

It works. Thanks a lot.