Jump to content


Photo

Building own OpenPli4


  • Please log in to reply
69 replies to this topic

Re: Building own OpenPli4 #21 ims

  • PLi® Core member
  • 13,603 posts

+210
Excellent

Posted 8 September 2013 - 08:30

and still same error when you continue in build ?


Kdo nic nedělá, nic nezkazí!

Re: Building own OpenPli4 #22 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 8 September 2013 - 08:53

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


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #23 ims

  • PLi® Core member
  • 13,603 posts

+210
Excellent

Posted 8 September 2013 - 09:00

When you run it again, It stops on same? Time to time is there errors, when is compilling, due conflict in multiprocess, imho.


Kdo nic nedělá, nic nezkazí!

Re: Building own OpenPli4 #24 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 8 September 2013 - 09:15

Is there perhaps a newer flex binary available?

I have build yesterday openpli 4 the first time and it worked without problems.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Building own OpenPli4 #25 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 8 September 2013 - 09:31

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 ..)


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #26 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 8 September 2013 - 09:33

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


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Building own OpenPli4 #27 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 8 September 2013 - 17:04

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.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #28 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 10 September 2013 - 13:25

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #29 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 10 September 2013 - 13:40

Sounds like you found a bug in GCC then.
Real musicians never die - they just decompose

Re: Building own OpenPli4 #30 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 10 September 2013 - 20:57

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?


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #31 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 12 September 2013 - 06:59

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.
Real musicians never die - they just decompose

Re: Building own OpenPli4 #32 catastrofus

  • Senior Member
  • 3,440 posts

+43
Good

Posted 5 October 2013 - 20:12

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.

2 x ultimo4k (dvb-c fbc + 1 dvb-s2, 8.3r/nb) + een et10k/osmini (geen tuners en dus fallbackclient, nb) met een Synology ds214+ (2 x 6 TB) op DSM 7.1.1 in ziggo oost (voormalig @Home) + A1/A2/A3/HB (TechniSat)
 


Re: Building own OpenPli4 #33 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 7 October 2013 - 19:11

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.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #34 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 7 October 2013 - 19:47

I guess deleting old versions (e.g. of enigma2) under tmp/work shouldn't be a problem. Regarding temp files I'm not sure.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Building own OpenPli4 #35 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 9 October 2013 - 18:45

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).
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #36 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 9 October 2013 - 23:12

I think there no problem deleting temp folder.

At least OE-Alliance implements rm_deepwork class where temp folder is removed.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #37 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 December 2013 - 13:50

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #38 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 December 2013 - 14:42

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.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #39 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 21 December 2013 - 15:43

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"


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Building own OpenPli4 #40 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 21 December 2013 - 16:27

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


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

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users