←  [EN] Third-Party Development

Forums

»

Building own OpenPli4

ims's Photo ims 8 Sep 2013

and still same error when you continue in build ?

Quote

athoik's Photo athoik 8 Sep 2013

no build cannot continue, because bison is  build at the very beginning! 

Quote

ims's Photo 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.

Quote

betacentauri's Photo betacentauri 8 Sep 2013

Is there perhaps a newer flex binary available?

I have build yesterday openpli 4 the first time and it worked without problems.
Quote

athoik's Photo 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 ..)

Quote

Erik Slagter's Photo Erik Slagter 8 Sep 2013

Looks like your hoster/ubuntu has some borked version of lex or yacc/bison.

Quote

athoik's Photo 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.

Quote

athoik's Photo 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.
Quote

MiLo's Photo MiLo 10 Sep 2013

Sounds like you found a bug in GCC then.
Quote

athoik's Photo 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?

Quote

MiLo's Photo MiLo 12 Sep 2013

Problem might be the CPU detection with -march=native. If your CPU is of type "V5" but the VM only simulates a "V4" type, GCC may detect the V5 in your machine, but the VM prevents properly executing V5 code on the V4 machine. (V4 and V5 are just figments of my imagination).

Probably just leaving out the "-march" parameter alltogether will also fix it.
Quote

catastrofus's Photo 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.
Quote

athoik's Photo athoik 7 Oct 2013

Hello,

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
909962
Inside 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
    done
If 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
376650
Using 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.
Quote

betacentauri's Photo betacentauri 7 Oct 2013

I guess deleting old versions (e.g. of enigma2) under tmp/work shouldn't be a problem. Regarding temp files I'm not sure.
Quote

athoik's Photo athoik 9 Oct 2013

I guess deleting old versions (e.g. of enigma2) under tmp/work shouldn't be a problem. Regarding temp files I'm not sure.

Everything ok deleting old versions under tmp/work.
#!/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"
done
Using 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).
Quote

athoik's Photo 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.

Quote

athoik's Photo 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.
Quote

athoik's Photo 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.
Quote

athoik's Photo 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"

Quote

Erik Slagter's Photo Erik Slagter 21 Dec 2013

Yes, apparently I screwed up. It will get corrected shorly.


Edited by Erik Slagter, 21 December 2013 - 17:01.
Quote