> On Oct 7, 2016, at 5:21 PM, Khem Raj <raj.k...@gmail.com> wrote: > > On Fri, Oct 7, 2016 at 4:14 PM, Randy Mortensen <randy.m...@gmail.com> wrote: >> >> On Oct 6, 2016, at 8:35 PM, Khem Raj <raj.k...@gmail.com> wrote: >> >> >> On Oct 6, 2016, at 7:07 PM, Randy Mortensen <randy.m...@gmail.com> wrote: >> >> >> On Oct 5, 2016, at 7:14 PM, Darcy Watkins <dwatk...@sierrawireless.com> >> wrote: >> >> >> >> On Oct 5, 2016, at 4:52 PM, Khem Raj <raj.k...@gmail.com> wrote: >> >> On Oct 5, 2016, at 4:45 PM, Randy Mortensen <ran...@stratagemsystems.com> >> wrote: >> >> On Oct 5, 2016, at 5:04 PM, Darcy Watkins <dwatk...@sierrawireless.com> >> wrote: >> >> From what I gleaned from recent discussions of fetcher errors, this is >> somehow connected with rollout of Python related security fixes to various >> Linux distributions and/or some ...-native recipes. >> >> It was a bunch of tar balls that are named as mercurial hashes from within >> iced tea rather than the yocto fetch. I worked around it by grabbing the >> tarballs from a different checkout since I didn't have time to dig into it. >> >> It affected a fresh checkout I was building from scratch. >> >> Thanks for the response. This also happened to me when trying to build from >> scratch. >> For my clarification, did you already have the tar balls downloaded or were >> you able to download them from a previous (icedtea) commit somehow? >> >> >> I had the tar balls in a different build that I had around for some time. >> The reason I never cached these ones in a shared location on our server was >> I felt that tar balls with small hashes as filenames was too prone to >> collisions, especially without a package name as a prefix. I don't know if >> that is a convention of iced tea, or how the fetcher handles mercurial. >> >> Can you check if the tarballs have been rebuilt upstream ? if so we should >> try to find out what changed. >> It could also be an oversight that a recipe update forgot or updated the >> checksums wrongly. but we should try to root cause it >> >> >> I agree here. We should root cause it. >> >> >> I’m not sure how this is all supposed to work, but I managed to get past the >> fetch failures by changing the md5sum and sha256sum checksums in >> icedtea7-native_2.1.3.bb. >> I used the the checksums helpfully suggested by bitbake when it reported the >> errors. >> >> I compared one of the problematic tar balls with a “good” one from a >> previous download and the only change I could identify was 3 extra lines >> added to a hidden file .hgtag (which I presume maps a tag to a commit). Not >> sure why requesting the same hg commit results in a different tarball >> output. >> >> >> could it be that its generating the tarballs from mercurial directly and >> thats flawed somehow ? >> >> That seems likely but I don’t know how to fix that. >> >> I also don’t understand why the configure task fails after the fetch task >> successfully downloads the tarballs. >> >> >> >> Now however iced tea fails to configure due to checksum errors. The >> configure task seems to re-download each tarball and check the sha256sum >> which is failing. >> > > I wonder if this failure will still happen again when it rebuilds the > tarball internally. I have > a hunch that might happen again Probably. I did manage a workaround by implementing two changes. One was to override all the SRC_URI md5sum and sha256sum values from a recipes-core/icedtea/icedtea7-native_2.1.3.bbappend file. The other was to add a patch to fix the checksums listed in icedtea-2.1.3/Makefile.am by adding a patch file to the SRC_URI in the same bbappend file. (Apparently the old (erroneous) checksums are baked-into Makefile.am.)
> >> I’m not sure where to go from here to try and resolve so any more help is >> welcome. >> >>
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
