40 replies to this topic

[Erik Slagter]

Would the imageversion file still contain a date then?

[blzr]

yeah, but forget it...

just cleansstated the image and after rebuild I got familiar taskhash mismatch error (no idea why it's been temporarily absent when I tested before?)

anyway, I still got this error only for et9500 so it suggests the problem lays in bsp layer(s)
(and still may by caused by this {DATE} in the ubi_append, but the solution is not correct /?/)

[athoik]

I think this one explain our problems: https://patchwork.op...g/patch/121025/

 

 

Lets see this one..

diff --git a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
index f14d2f0..0115258 100644
--- a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
+++ b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
@@ -92,3 +92,4 @@ IMAGE_INSTALL += " \
        "

 export IMAGE_BASENAME = "openpli-enigma2"
+IMAGE_CMD[vardepsexclude] = "DATE"

Edited by athoik, 3 August 2016 - 14:53.

[blzr]

after quick test - seems to do the job

(I thought about this at first too, but somehow was afraid that date won't be added to imageversion with this, so I turned toward more difficult solutions instead just try )

[Erik Slagter]

Athoik, this indeed looks familiar. I guess it's the appropriate solution.

[blzr]

bummer :-/
today I had taskhash mismatch error again
so exclude DATE didn't help (for long...)

[Erik Slagter]

For your own building environment you could always resort to my "solution", just disable the two lines of python code that perform the check

[blzr]

well, this error seems to be completely harmless,
as I said, image is built successfully despite it...
so, that's rather cosmetics

[MiLo]

Looks like that "imageversion" hack ought to be removed from all layers.

Proper way to do that is in the image recipe, as a post-rootfs step. That way, it doesn't participate in the hash.

[athoik]

So we need to use ROOTFS_POSTPROCESS_COMMAND?

openembedded-core/meta/classes/rootfs-postcommands.bbclass:ROOTFS_POSTPROCESS_COMMAND += "rootfs_update_timestamp ; "


# Can be use to create /etc/timestamp during image construction to give a reasonably
# sane default time setting
rootfs_update_timestamp () {
        date -u +%4Y%2m%2d%2H%2M%2S >${IMAGE_ROOTFS}/etc/timestamp
}

Something like the following?

ROOTFS_POSTPROCESS_COMMAND += "deploy_dir_imageversion ; "

deploy_dir_imageversion () {
        echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion
}

[blzr]

you need to create IMAGEDIR first,
I exeperimented with something similar:

createimageversionfile() {
	mkdir ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}
	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion
}
ROOTFS_POSTINSTALL_COMMAND += "createimageversionfile;"

and it did the job,

however, the problem is how to exclude boxes that don't need it (dm, vu, wetek, xsarius)?
for vu it just creates unnecessary IMAGEDIR/imageversion in deploy but build is ok, but for xsarius build fails with this

[mirakels]

doesn't something like ROOTFS_POSTINSTALL_COMMAND_machinename work?

[blzr]

it does not...

[MiLo]

How about simply removing that DATE? I doubt it's actually being used at all.

[blzr]

might be the easiest solution for this gordian knot indeed (still would need bsp layers adjustments though)...

the only use of this DATE in imageversion that I know is that it could have saved you once from accidental flashing some ooold image
(which somehow happened to be on your pendrive instead of that brand new you were going to install )

[Erik Slagter]

How about an alternative to include the date without OE noticing it

[MiLo]

I've only found putting date stamps and such into software a stupid idea. It should not matter when something was built. And if I build the same software twice, using the same compiler and settings, I should get the exact same result.

[Erik Slagter]

The first comment, opinions may differ, but the second, yeah, I guess you have a strong point there.

[mirakels]

yeah, like I have two version, no dates or version numbers. So which is the latest one?

And when you build something twice, without differences, this 'date' also shouldn't change so you end up with the same thing (unless for some reason you want to contain the builddate in your build)

[MiLo]

I don't know what kind of machine you're using, but on my machine, the date changes quite often. At least once a day.