On Fri, Jun 23, 2017 at 04:04:24PM -0700, Khem Raj wrote: > On Fri, Jun 23, 2017 at 2:14 PM, Denys Dmytriyenko <[email protected]> wrote: > > On Fri, Jun 23, 2017 at 02:08:06PM -0700, Khem Raj wrote: > >> On Fri, Jun 23, 2017 at 1:52 PM, Denys Dmytriyenko <[email protected]> wrote: > >> > On Fri, Jun 23, 2017 at 01:46:28PM -0700, Khem Raj wrote: > >> >> On Fri, Jun 23, 2017 at 1:23 PM, Alejandro Mery > >> >> <[email protected]> wrote: > >> >> > From: Denys Dmytriyenko <[email protected]> > >> >> > > >> >> > The newly resurrected devmem2.c file besides having a new location, > >> >> > also > >> >> > updates its header, producing different checksums, which would > >> >> > conflict > >> >> > with any previously cached or mirrored instances. To avoid such > >> >> > conflicts, > >> >> > use a different filename in fetch(). Rename it back to original name > >> >> > at > >> >> > unpack() for devmem2-fixups-2.patch to succeed w/o modifications. > >> >> > > >> >> > WARNING: devmem2-1.0-r7 do_fetch: Fetcher failure for URL: > >> >> > 'http://www.free-electrons.com/pub/mirror/devmem2.c'. Checksum > >> >> > mismatch! > >> >> > File: '/OE/master/downloads/devmem2.c' has md5 checksum > >> >> > be12c0132a1ae118cbf5e79d98427c1d when > >> >> > e23f236e94be4c429aa1ceac0f01544b was expected > >> >> > File: '/OE/master/downloads/devmem2.c' has sha256 checksum > >> >> > ec382c90af3ef2f49695ff14a4d6521e58ac482c4e29d6c9ebca8768f699c191 when > >> >> > 3b15515693bae1ebd14d914e46d388edfec2175829ea1576a7a0c8606ebbe639 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] = "be12c0132a1ae118cbf5e79d98427c1d" > >> >> > SRC_URI[sha256sum] = > >> >> > "ec382c90af3ef2f49695ff14a4d6521e58ac482c4e29d6c9ebca8768f699c191" > >> >> > Otherwise you should retry the download and/or check with upstream to > >> >> > determine if the file has become corrupted or otherwise unexpectedly > >> >> > modified. > >> >> > > >> >> > WARNING: devmem2-1.0-r7 do_fetch: Renaming /OE/sources/devmem2.c to > >> >> > /OE/sources/devmem2.c_bad-checksum_be12c0132a1ae118cbf5e79d98427c1d > >> >> > > >> >> > Signed-off-by: Denys Dmytriyenko <[email protected]> > >> >> > Signed-off-by: Martin Jansa <[email protected]> > >> >> > --- > >> >> > meta-oe/recipes-support/devmem2/devmem2.bb | 6 +++++- > >> >> > 1 file changed, 5 insertions(+), 1 deletion(-) > >> >> > > >> >> > diff --git a/meta-oe/recipes-support/devmem2/devmem2.bb > >> >> > b/meta-oe/recipes-support/devmem2/devmem2.bb > >> >> > index c42eb5e0b..c86eb2e4b 100644 > >> >> > --- a/meta-oe/recipes-support/devmem2/devmem2.bb > >> >> > +++ b/meta-oe/recipes-support/devmem2/devmem2.bb > >> >> > @@ -3,12 +3,16 @@ LICENSE = "GPLv2+" > >> >> > LIC_FILES_CHKSUM = > >> >> > "file://devmem2.c;endline=38;md5=a9eb9f3890384519f435aedf986297cf" > >> >> > PR = "r7" > >> >> > > >> >> > -SRC_URI = "http://www.free-electrons.com/pub/mirror/devmem2.c \ > >> >> > +SRC_URI = > >> >> > "http://www.free-electrons.com/pub/mirror/devmem2.c;downloadfilename=devmem2-new.c > >> >> > \ > >> >> > file://devmem2-fixups-2.patch;apply=yes;striplevel=0" > >> >> > S = "${WORKDIR}" > >> >> > > >> >> > >> >> can we explore use of downloadfilename= parameter of http/ftp fetcher > >> > > >> > Sure, here are the corresponding sources where it's handled: > >> > http://cgit.openembedded.org/bitbake/tree/lib/bb/fetch2/wget.py#n65 > >> > > >> > >> ah this is rightly being used, I somehow thought it was not used but > >> that actually the change above. > >> > > >> >> > CFLAGS += "-DFORCE_STRICT_ALIGNMENT" > >> >> > > >> >> > +python do_unpack_append() { > >> >> > + os.rename("devmem2-new.c", "devmem2.c") > >> >> > +} > >> >> > + > >> > >> perhaps we do not need to rename it we can say do > >> > >> ${CC} -o devmem2 devmem2-new.c ${CFLAGS} ${LDFLAGS} > > > > This is the fourth or fifth time this is being suggested. We should merge it > > already, as I'm getting tired of explaining it... :) > > Thanks for being patient. may I then suggest to host the patch locally > after refreshing it against the renamed file ? upstream patch might > change and break things eventually > down the lane. This will also insulate it from such problems.
I was thinking of updating the patch locally, but decided to be less invasive. If we decide to do that, we need to do it in master first. We can go even further and host this whole .c file in metadata, so we won't be affected by it disappearing again... > > http://lists.openembedded.org/pipermail/openembedded-devel/2017-June/113042.html > > > > > >> >> > do_compile() { > >> >> > ${CC} -o devmem2 devmem2.c ${CFLAGS} ${LDFLAGS} > >> >> > } > >> >> > -- > >> >> > 2.13.0 > >> >> > > >> >> > -- > >> >> > _______________________________________________ > >> >> > Openembedded-devel mailing list > >> >> > [email protected] > >> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> >> -- > >> >> _______________________________________________ > >> >> Openembedded-devel mailing list > >> >> [email protected] > >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
