Build my own Vix image

[birdman]

Not my day today, yahoo!!

That error message is what you'd get when running a python2 script (all of the xml2po.py ones are) with python3.

 

[Valiant]

Been a while since I built 5.3 for my miraclebox after vix support was dropped , so tried to build again and encountered an error straight away, miraclebox is not supported by the build process.

My environment is ok, I built vuuno4k and osmini images without error over the weekend after updating ubuntu.

If there is no way to build a later stable version for the miraclebox then I will leave it on 5.3.001 or 4 , I just thought there might be a local parameter or list I could change to allow the build to progress.

 

[twol]

Been a while since I built 5.3 for my miraclebox after vix support was dropped , so tried to build again and encountered an error straight away, miraclebox is not supported by the build process.

My environment is ok, I built vuuno4k and osmini images without error over the weekend after updating ubuntu.

If there is no way to build a later stable version for the miraclebox then I will leave it on 5.3.001 or 4 , I just thought there might be a local parameter or list I could change to allow the build to progress.

Its still in the makefile mbtwinplus, so no reason that it will not build - whether it will have enough to run the image is another story.

 

[ccs]

That error message is what you'd get when running a python2 script (all of the xml2po.py ones are) with python3.

Thanks, as always, that sorted it when I opted for python2. I was expecting python3 to be used now, is that not the case?

Can't get passed this (repeated, always the same) checksum error....

File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has md5 checksum 19bb20214e0a88629e17a5b6c605d45d when ea040ab9b4ca656b5229b89d6b822f13 was expected
File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has sha256 checksum 53a4b4b6569e8ef8b0aa6b7adbf736563467dba67aa77c6f4a37b7387b01508f when 288772cecfcd9a53694ffab108d1825a31ba77f3a8466b0401baeca3bc232a38 was expected

It suggests changing the checksums, maybe it's not advisable, but where do I find the relevant file? I've spent ages trying to find it, but failed miserably.

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] = "19bb20214e0a88629e17a5b6c605d45d"
SRC_URI[sha256sum] = "53a4b4b6569e8ef8b0aa6b7adbf736563467dba67aa77c6f4a37b7387b01508f"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.

 

[Valiant]

Thanks twol, ill have another go and post the error that I get.

 

[ccs]

Post #204.... md5 checksum confirmed as ok - 19bb20214e0a88629e17a5b6c605d45d after downloading the file onto a windows laptop.

 

[ccs]

For reference, the file is

http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p13.tar.gz

 

[lincsat]

How would I get the build to use my own passwd file so I don't have to manually set if a settings restore fails?

 

[twol]

Thanks, as always, that sorted it when I opted for python2. I was expecting python3 to be used now, is that not the case?

Can't get passed this (repeated, always the same) checksum error....

File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has md5 checksum 19bb20214e0a88629e17a5b6c605d45d when ea040ab9b4ca656b5229b89d6b822f13 was expected
File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has sha256 checksum 53a4b4b6569e8ef8b0aa6b7adbf736563467dba67aa77c6f4a37b7387b01508f when 288772cecfcd9a53694ffab108d1825a31ba77f3a8466b0401baeca3bc232a38 was expected

It suggests changing the checksums, maybe it's not advisable, but where do I find the relevant file? I've spent ages trying to find it, but failed miserably.

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] = "19bb20214e0a88629e17a5b6c605d45d"
SRC_URI[sha256sum] = "53a4b4b6569e8ef8b0aa6b7adbf736563467dba67aa77c6f4a37b7387b01508f"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.

If you look in the build log file you will see at what stage it failed and be able to find the .bb where you need to update the checksums

 

[ccs]

If you look in the build log file you will see at what stage it failed and be able to find the .bb where you need to update the checksums

If ~/openvix/build-enviroment/builds/openvix/dev/et10000/tmp/log/cooker/et10000/ is were the logs are stored, then I've found the relevant .bb file, with the wrong? checksum.

/home/openvixbuilder/openvix/build-enviroment/meta-openembedded/meta-networking/recipes-support/ntp/ntp_4.2.8p13.bb

Took a bit of finding is an understatement.

Why am I the only one seeing this checksum error? Am I picking up the wrong version of ntp?

I'll start again tomorrow when 5.4.000 is released, and dev/master are in sync. I started the build yesterday when 5.4 was just being finalised.

 

[Valiant]

Its still in the makefile mbtwinplus, so no reason that it will not build - whether it will have enough to run the image is another story.

Therein lies the answer, it helps if I get the machine name right! I've made notes rather than trusting to fickle memory. Successful build of 5.3.039, one warning, now to see if the mbtwinplus can accomodate it. Thanks twol.

 

[birdman]

Took a bit of finding is an understatement.

You know it's likely to be an ntp*.bb file, so:

cd ..../oe-alliance
find meta* open* -iname 'ntp*.bb'

will list the likely config file candidates.

 

[ccs]

I've checked versions p9 thru' to p15 and none have the expected md5 checksum. I feel like I'm hitting my head against a brick wall.

File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has md5 checksum 19bb20214e0a88629e17a5b6c605d45d when ea040ab9b4ca656b5229b89d6b822f13 was expected
File: '/home/openvixbuilder/openvix/build-enviroment/sources/ntp-4.2.8p13.tar.gz' has sha256 checksum 53a4b4b6569e8ef8b0aa6b7adbf736563467dba67aa77c6f4a37b7387b01508f when 288772cecfcd9a53694ffab108d1825a31ba77f3a8466b0401baeca3bc232a38 was expected

Only possible clue is that their .md5 file format has changed between p12 and p13...

1522d66574bae14abb2622746dad2bdc  ntp-4.2.8p12.tar.gz

MD5 (ntp-4.2.8p13.tar.gz) = 19bb20214e0a88629e17a5b6c605d45d

 

[Huevos]

I've checked versions p9 thru' to p15 and none have the expected md5 checksum. I feel like I'm hitting my head against a brick wall.

Only possible clue is that their .md5 file format has changed between p12 and p13...

1522d66574bae14abb2622746dad2bdc  ntp-4.2.8p12.tar.gz

MD5 (ntp-4.2.8p13.tar.gz) = 19bb20214e0a88629e17a5b6c605d45d

So why don't you just change the checksum in the .bb file?

 

[ccs]

So why don't you just change the checksum in the .bb file?

Obviously I can, but I'm trying to work out why the checksum is wrong, I appear to be the only one hitting this problem.

I could easily have made mistakes following the instructions in this thread, If I have, then I need to find out what I've done wrong.

The one thing I wonder about is I changed python from version 3 to version 2 half way thru' a build to get yahooweather sorted.

Could that explain anything?

I'm starting again from scratch soon, but at the moment, nothing will change from the last attempt.

 

[Huevos]

I just checked and Ea040ab9b4ca656b5229b89d6b822f13 is the correct hash. So if your file doesn't match that hash your file must be corrupt.

Unzip the attached file and put the contents in your sources folder and try again.

 

[ccs]

I just checked and Ea040ab9b4ca656b5229b89d6b822f13 is the correct hash. So if your file doesn't match that hash your file must be corrupt.

Unzip the attached file and put the contents in your sources folder and try again.

Thanks.

I've worked out what is happening, no corrupt files.

Your file comes from

https://www.eecis.udel.edu/~ntp/ntp_spool/[COLOR="#FF0000"]ntp4[/COLOR]/

with the checksum the build expects.

My file (in my build) comes from

https://www.eecis.udel.edu/~ntp/ntp_spool/[COLOR="#FF0000"]ntp4/ntp-4.2[/COLOR]/

with the same filename and a different checksum. A checksum which is correct for that file, but not what the build expects.

 

[Joe_90]

@ccs - are you moving source files between different systems (PC's) in your setup? I recently had issues when moving scripts between my mutant box and my main desktop (which is linux mint). A new install of FileZilla had helpfully changed the line endings of .sh files to ms-dos format .
It's just a left-of-field suggestion, but if you're ftp'ing files between systems it's worth checking.


edit - ok, belay that! You've found your difference...


further edit - a different md5 checksum means that the files are different, though. You need to compare the sources.

 

[BrianTheTechieSnail]

Thanks.

I've worked out what is happening, no corrupt files.

Your file comes from

https://www.eecis.udel.edu/~ntp/ntp_spool/[COLOR="#FF0000"]ntp4[/COLOR]/

with the checksum the build expects.

My file (in my build) comes from

https://www.eecis.udel.edu/~ntp/ntp_spool/[COLOR="#FF0000"]ntp4/ntp-4.2[/COLOR]/

with the same filename and a different checksum.

The contents are different too!
It doesn't look like tampering though, looks like somebody updated some stuff in the file without changing the file name.
I'll just call that definitely not clever at all.

 

[ccs]

@ccs - are you moving source files between different systems (PC's) in your setup? I recently had issues when moving scripts between my mutant box and my main desktop (which is linux mint). A new install of FileZilla had helpfully changed the line endings of .sh files to ms-dos format .
It's just a left-of-field suggestion, but if you're ftp'ing files between systems it's worth checking.


edit - ok, belay that! You've found your difference...

No, everything has been done on a fresh install of Ubuntu 20.04, which will be even fresher tomorrow when I replace the hd and start again.