Building own OpenPli4
ims 8 Sep 2013
When you run it again, It stops on same? Time to time is there errors, when is compilling, due conflict in multiprocess, imho.
betacentauri 8 Sep 2013
I have build yesterday openpli 4 the first time and it worked without problems.
athoik 8 Sep 2013
Even when i am trying to build openpli 3.0 again i am getting errors!
| build/gengtype.o: In function `adjust_field_type':
| gengtype.c:(.text+0x1cc6): undefined reference to `lexer_line'
| gengtype.c:(.text+0x1d4c): undefined reference to `lexer_line'
| gengtype.c:(.text+0x1dfa): undefined reference to `lexer_line'
| gengtype.c:(.text+0x1e95): undefined reference to `lexer_line'
| gengtype.c:(.text+0x209f): undefined reference to `lexer_line'
| build/gengtype.o:gengtype.c:(.text+0x215b): more undefined references to `lexer_line' follow
| build/gengtype-parse.o: In function `require2':
| gengtype-parse.c:(.text+0x1cc): undefined reference to `yylex'
| build/gengtype-parse.o: In function `require':
| gengtype-parse.c:(.text+0x265): undefined reference to `yylex'
I will reconfigure OpenVZ with Ubuntu 12.04 32bit. Till now i always though that virtulazation was transparant for host (at least on vmware esxi is ..)
Erik Slagter 8 Sep 2013
Looks like your hoster/ubuntu has some borked version of lex or yacc/bison.
athoik 8 Sep 2013
Same story, now with 32bit
The xz-native is not producing good xz binary. The xz produced by the bitbake doen't work! But if i compile the xz myself, then it works (using ./configure && make).
What is going wrong, what ticket can i open on the hoster when i cannot prove that OpenVZ causes the issue.
athoik 10 Sep 2013
Eureka!
The problem (Illegal instruction was all over the logs) gone away when i changed march to x86-64 (site.conf)!
-BUILD_OPTIMIZATION = "-march=native -O2 -pipe" +BUILD_OPTIMIZATION = "-march=x86-64 -O2 -pipe"
So if you are building images on Virtualized server use march=i686 when host is 32bit and march=x86-64 which build host is 64bit.
Edited by athoik, 10 September 2013 - 13:25.
athoik 10 Sep 2013
Sounds like you found a bug in GCC then.
Same problem happened on OpenVZ and KVM (32bit & 64bit) hosts, and it is reproducible.
Is there anything i can do to help (GCC) community?
MiLo 12 Sep 2013
Probably just leaving out the "-march" parameter alltogether will also fix it.
catastrofus 5 Oct 2013
The build of pli4 for works fine on a laptop (dell 6530) running kUbuntu 13.04!
The missing stuff was 'subversion'. After an install of subversion there was no problem (well, there were some warnings) generating the nfi for 8000 & 7020.
Edited by catastrofus, 5 October 2013 - 20:13.
athoik 7 Oct 2013
I notice that OpenPLi OE Core is keeping lot of temporary files, although "rm_work" it is used, and i need to keep inode usage low, because of quotas.
$ find /opt/openpli/openpli4/build/tmp/work -type f | grep "/temp/" | wc -l 909962Inside rm_work.bbcals i can see the following happens.
cd ${WORKDIR} for dir in * do # Retain only logs and other files in temp, safely ignore # failures of removing pseudo folers on NFS2/3 server. if [ $dir = 'pseudo' ]; then rm -rf $dir 2> /dev/null || true elif [ $dir != 'temp' ]; then rm -rf $dir fi doneIf it safe to delete old temp files, eg older than 15 days? (find $dir -mtime +15 -exec rm {} \
Also there are many revisions of the enigma2
$ find /opt/openpli/openpli4/build/tmp/work -type f | grep "/enigma2/" | wc -l 376650Using the following script i can delete older versions (and keep last two)
#!/bin/sh WORK_DIR=/opt/openpli/openpli4/build/tmp/work # Change to Build Directory cd $WORK_DIR keeplast(){ #keep last two builds folders shift && shift i=1 for a in $@ do i=0 echo $a done return $i } for d in */* do cd $WORK_DIR/$d || continue keeplast `ls -1t` && echo "To Delete under Directory: $WORK_DIR/$d" done ============================================== ... 2.7+gitAUTOINC+63d36dc230-r57 2.7+gitAUTOINC+30e22cc25d-r57 2.7+gitAUTOINC+277e9c008d-r57 2.7+gitAUTOINC+4707a9adfd-r57 2.7+gitAUTOINC+e1c739eb49-r57 2.7+gitAUTOINC+a0a48d1a66-r57 2.7+gitAUTOINC+69cb607d24-r57 2.7+gitAUTOINC+69cb607d24-r56 2.7+gitAUTOINC+599dde9afe-r55 2.7+gitAUTOINC+52cfb5272f-r55 2.7+gitAUTOINC+ea67c4052d-r55 2.7+gitAUTOINC+2fe4ddc7b0-r54 2.7+gitAUTOINC+2fe4ddc7b0-r53 2.7+gitAUTOINC+b3850657ed-r52 2.7+gitAUTOINC+b3850657ed-r51 2.7+gitAUTOINC+c27368793e-r51 2.7+gitAUTOINC+c27368793e-r50 2.7+gitAUTOINC+c27368793e-r49 To Delete under Directory: /opt/openpli/openpli4/build/tmp/work/vuduo2-oe-linux/enigma2 ...Do you think it is safe or it will cause problems?
Thanks for your ideas and/or suggestions.
betacentauri 7 Oct 2013
athoik 9 Oct 2013
Everything ok deleting old versions under tmp/work.I guess deleting old versions (e.g. of enigma2) under tmp/work shouldn't be a problem. Regarding temp files I'm not sure.
#!/bin/sh WORK_DIR=/opt/openpli/openpli4/build/tmp/work # Change to Build Directory cd $WORK_DIR keeplast(){ #keep last two builds folders shift && shift i=1 for a in $@ do i=0 [ -d $a ] && echo -n "Deleting directory $a deleting..." && sleep 1 && rm -rf $a && echo " Done!" done return $i } for d in */* do cd $WORK_DIR/$d || continue keeplast `ls -1t` && echo "Finish deleting items under directory: $WORK_DIR/$d" doneUsing the following we can find the temp (log,run) files older than 15 days.
$ cd /opt/openpli/openpli4/build/tmp/work $ find -type f -mtime +15 -regex ".*/temp/[lr][ou][gn]\..*" ... ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.autotools_preconfigure.3502 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_task_prefunc.5005 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.base_do_unpack.24308 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.package_name_hook.12700 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/log.do_packagedata.15561 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_task_prefunc.32579 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_unpack.4967 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_populate_sysroot.13077 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/log.do_package.12700 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_create_package.15561 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/log.do_configure.16554 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.patch_do_patch.11799 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_task_postfunc.5005 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_rm_work.25573 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.perform_packagecopy.32504 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_fetch.24135 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/log.do_fetch.4962 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.package_do_shlibs.12700 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_create_package.20718 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_package_setscene.13178 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_package.12700 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_qa_staging.13077 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.do_siteconfig.20718 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.emit_pkgdata.12700 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.sstate_unpack_package.8218 ./dm8000-oe-linux/enigma2-plugins/experimental-gitAUTOINC+bfb12d3547-r10/temp/run.package_depchains.12700 ...Next step is to delete them (maybe when i run out of inodes again, and above script doen't clean up enouph files).
athoik 9 Oct 2013
I think there no problem deleting temp folder.
At least OE-Alliance implements rm_deepwork class where temp folder is removed.
athoik 6 Dec 2013
Hello,
After lastest updates of Openpli 4 (merges from upstream-next) tuxtxt-enigma2.bb fails to build because it tries to import enigma2.bbappend!
DEBUG: Appending .bbappend file /opt/openpli/openpli4/meta-openpli/recipes-openpli/enigma2/enigma2.bbappend to /opt/openpli/openpli4/meta-openpli/recipes-multimedia/tuxtxt/tuxtxt-enigma2.bb
It's obvious that deleting enigma2.bbappend will fix issue, but this is not possible because it will break custom build .
Also above issue it seems to break .bbappend functionality, when you have a package alpha and package beta-alpha, since beta-alpha includes alpha.bbpapend!
Any idea how to solve it?
Edited by athoik, 6 December 2013 - 13:50.
athoik 6 Dec 2013
Hello,
Just got this information from OE IRC.
athoik: I think there was a patch merged to fix that already athoik: assuming you're on master, just update to the latest
Here is the patch that fixed that: http://git.openembed...1bfac8b99e33149
The 'bbappend in f' incorrectly compares the current recipe with the avaliable bbappends recipes.
This comparsion causes unrequested bbappend files to be appended, e.g. in the case of 'libgcc_4.8.bb', the bbappends for 'libgcc_4.8.bb' and 'gcc_4.8.bb' are added to the filelist (because 'gcc_4.8.bb' is contained in the 'libgcc_4.8.bb' string) which in turn causes the gcc_4.8.bbappend files to be appended to the libgcc_4.8 recipe.
This should be a 'bbappend == f' to match the previous implementation of this function, such that if no wildcard is present the recipe names must match exactly.
This issue was introduced by commit 31bc9af9cd56e7b318924869970e850993fafc5f, which it related to [YOCTO #5411].
Edited by athoik, 6 December 2013 - 14:42.
athoik 21 Dec 2013
Hello,
It seems checksums calculated wrong on commit: http://sourceforge.n...0025f8a25f7b7d/
WARNING: Checksum failure encountered with download of http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz - will attempt other sources if available WARNING: Renaming /opt/openpli/sources/vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz to /opt/openpli/sources/vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz_bad-checksum_276f0eb665f28ca49ba45ea44c0d5427 ERROR: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz'. Checksum mismatch! File: '/opt/openpli/sources/vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz' has md5 checksum 276f0eb665f28ca49ba45ea44c0d5427 when d41d8cd98f00b204e9800998ecf8427e was expected File: '/opt/openpli/sources/vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz' has sha256 checksum be1f1ea36196cef14d0ced0c8932779922730c324488cc07afacc019bd40b37c when e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = "276f0eb665f28ca49ba45ea44c0d5427" SRC_URI[sha256sum] = "be1f1ea36196cef14d0ced0c8932779922730c324488cc07afacc019bd40b37c" Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuuno-3.1.1-4.4.3-20131217.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /opt/openpli/openpli4/build/tmp/work/vuuno-oe-linux/vuplus-dvb-modules-vuuno/3.1.1+20131217-r0/temp/log.do_fetch.20642 ERROR: Task 3089 (/opt/openpli/openpli4/meta-openpli/recipes-bsp/vuplus/vuplus-dvb-modules-vuuno.bb, do_fetch) failed with exit code '1' WARNING: Checksum failure encountered with download of http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz - will attempt other sources if available WARNING: Renaming /opt/openpli/sources/vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz to /opt/openpli/sources/vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz_bad-checksum_6d366b9e37440c1655a49ba914195bde ERROR: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz'. Checksum mismatch! File: '/opt/openpli/sources/vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz' has md5 checksum 6d366b9e37440c1655a49ba914195bde when d41d8cd98f00b204e9800998ecf8427e was expected File: '/opt/openpli/sources/vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz' has sha256 checksum 1a7dc0caaf22ded8b787b55d6941c0c991bdfe7f23648c5444f039bca85eaf3c when e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = "6d366b9e37440c1655a49ba914195bde" SRC_URI[sha256sum] = "1a7dc0caaf22ded8b787b55d6941c0c991bdfe7f23648c5444f039bca85eaf3c" Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuultimo-3.1.1-4.4.3-20131217.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /opt/openpli/openpli4/build/tmp/work/vuultimo-oe-linux/vuplus-dvb-modules-vuultimo/3.1.1+20131217-r0/temp/log.do_fetch.23303 ERROR: Task 3089 (/opt/openpli/openpli4/meta-openpli/recipes-bsp/vuplus/vuplus-dvb-modules-vuultimo.bb, do_fetch) failed with exit code '1' WARNING: Checksum failure encountered with download of http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz - will attempt other sources if available WARNING: Renaming /opt/openpli/sources/vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz to /opt/openpli/sources/vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz_bad-checksum_2253b77bd3948c118cdf1c400fdd6fcb ERROR: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz'. Checksum mismatch! File: '/opt/openpli/sources/vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz' has md5 checksum 2253b77bd3948c118cdf1c400fdd6fcb when d41d8cd98f00b204e9800998ecf8427e was expected File: '/opt/openpli/sources/vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz' has sha256 checksum ab5e86df486357d24187511f5a977fccb6e9b969d143239fea6ce8381f833620 when e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = "2253b77bd3948c118cdf1c400fdd6fcb" SRC_URI[sha256sum] = "ab5e86df486357d24187511f5a977fccb6e9b969d143239fea6ce8381f833620" Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. ERROR: Function failed: Fetcher failure for URL: 'http://archive.vuplus.com/download/drivers//vuplus-dvb-modules-vuduo2-3.3.8-4.4.3-20131217.tar.gz'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /opt/openpli/openpli4/build/tmp/work/vuduo2-oe-linux/vuplus-dvb-modules-vuduo2/3.3.8+20131217-r0/temp/log.do_fetch.15380 ERROR: Task 3412 (/opt/openpli/openpli4/meta-openpli/recipes-bsp/vuplus/vuplus-dvb-modules-vuduo2.bb, do_fetch) failed with exit code '1'
vuduo2:
SRC_URI[md5sum] = "2253b77bd3948c118cdf1c400fdd6fcb"
SRC_URI[sha256sum] = "ab5e86df486357d24187511f5a977fccb6e9b969d143239fea6ce8381f833620"
vuultimo:
SRC_URI[md5sum] = "6d366b9e37440c1655a49ba914195bde"
SRC_URI[sha256sum] = "1a7dc0caaf22ded8b787b55d6941c0c991bdfe7f23648c5444f039bca85eaf3c"
vuuno:
SRC_URI[md5sum] = "276f0eb665f28ca49ba45ea44c0d5427"
SRC_URI[sha256sum] = "be1f1ea36196cef14d0ced0c8932779922730c324488cc07afacc019bd40b37c"
Erik Slagter 21 Dec 2013
Yes, apparently I screwed up. It will get corrected shorly.
Edited by Erik Slagter, 21 December 2013 - 17:01.