On Fri, Mar 15, 2019 at 05:16:06PM -0600, Anibal Limon wrote:
> I sent a review request,
>
> https://review.linaro.org/c/openembedded/meta-linaro/+/30779
Any updates? I'm still getting a lot of warnings during parsing, e.g.:
WARNING: .../meta-linaro/meta-linaro-toolchain/recipes-core/glibc/glibc_linaro-2.20.bb: Unable to get checksum for glibc SRC_URI entry ld.so.conf: file could not be found
WARNING: .../meta-linaro/meta-linaro-toolchain/recipes-core/glibc/glibc_linaro-2.20.bb: Unable to get checksum for glibc SRC_URI entry 0022-Add-ILP32-to-makefiles.patch: file could not be found
Denys
> On Fri, 15 Mar 2019 at 14:46, Anibal Limon <anibal.limon(a)linaro.org> wrote:
>
> >
> >
> > On Fri, Mar 15, 2019, 1:54 PM Denys Dmytriyenko <denis(a)denix.org> wrote:
> >
> >> On Fri, Mar 15, 2019 at 09:55:21AM -0600, Anibal Limon wrote:
> >> > Hi Denys,
> >> >
> >> > I'm not see a PV set on glibc_linaro-2.20.bb, there is a PV set on gcc
> >> > recipes with linaro-2.20.
> >>
> >> As my previous email states - PV is set by the filename. Moreover, you
> >> are
> >> erroneously referrring to the recipe as "glibc_linaro", while it's
> >> "glibc"
> >> instead. And "linaro-2.20" is actually recipe's PV. The underscore in the
> >> filename separates recipe name from recipe version. From the manual:
> >>
> >>
> >> https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manu…
> >>
> >> | In this example, a recipe called "something_1.2.3.bb" sets PN to
> >> "something"
> >> | and PV to "1.2.3".
> >>
> >> Hence, in this case, glibc_linaro-2.20.bb used to set PN to "glibc" and
> >> PV to
> >> "linaro-2.20". And it used to work for years.
> >>
> >> Moreover, since ${FILESPATH} below expects ${FILE_DIRNAME}/glibc-${PV}
> >> and
> >> there's "glibc-linaro-2.20" directory with whole bunch of patches:
> >>
> >> https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-linaro-toolch…
> >>
> >> So, with your change, it would instead try to look into "glibc-2.20" and
> >> fail
> >> to find any patches. Not even sure how it was tested...
> >>
> >
> > You are right, I not see the error because I'm using upstream glibc (2.29)
> > and the build didn't fail.
> >
> > I will update the PV in the common file.
> >
> > Regards,
> > Anibal
> >
> >
> >> --
> >> Denys
> >>
> >>
> >> > ...
> >> > $ git grep PV .
> >> > glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ reads
> >> from
> >> > the PVR register. */
> >> > glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+
> >> emulates
> >> > PowerPC mfspr reads from the PVR register. */
> >> > glibc_linaro-2.20.bb:SRC_URI = "
> >> >
> >> http://releases.linaro.org/archive/${MMYY}/components/toolchain/glibc-linar…
> >> > \
> >> > glibc_linaro-2.20.bb:S = "${WORKDIR}/glibc-${PV}-${RELEASE}"
> >> > glibc_linaro-2.20.bb:FILESPATH = "${@base_set_filespath([
> >> > '${FILE_DIRNAME}/glibc-${PV}', '${FILE_DIRNAME}/glibc',
> >> > '${FILE_DIRNAME}/files', '${FILE_DIRNAME}' ], d)}"
> >> > glibc_linaro.inc:PV = "2.20"
> >> > ...
> >> >
> >> > What is the error that you have noticed?
> >> >
> >> > Regards,
> >> > Anibal
> >> >
> >> > On Fri, 8 Mar 2019 at 14:32, Denys Dmytriyenko <denis(a)denix.org> wrote:
> >> >
> >> > >
> >> > >
> >> https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
> >> > >
> >> > > meta-linaro-toolchain: Set PV on glibc_linaro
> >> > > Recently a common file was introudced to set PV for glibc [1]
> >> > > in oe-core causing failures becuase glibc_linaro is trying
> >> > > to download the latest oe-core version (2.29).
> >> > >
> >> > > [1]
> >> https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
> >> > >
> >> > > Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
> >> > > Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
> >> > >
> >> > >
> >> > > The problem is that all those modified recipes already had PV set in
> >> their
> >> > > filename and it was "linaro-2.20", not just "2.20".
> >
> > > >
> >> > > --
> >> > > Denys
> >> > >
> >>
> >
On Fri, Mar 15, 2019 at 09:55:21AM -0600, Anibal Limon wrote:
> Hi Denys,
>
> I'm not see a PV set on glibc_linaro-2.20.bb, there is a PV set on gcc
> recipes with linaro-2.20.
As my previous email states - PV is set by the filename. Moreover, you are
erroneously referrring to the recipe as "glibc_linaro", while it's "glibc"
instead. And "linaro-2.20" is actually recipe's PV. The underscore in the
filename separates recipe name from recipe version. From the manual:
https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manu…
| In this example, a recipe called "something_1.2.3.bb" sets PN to "something"
| and PV to "1.2.3".
Hence, in this case, glibc_linaro-2.20.bb used to set PN to "glibc" and PV to
"linaro-2.20". And it used to work for years.
Moreover, since ${FILESPATH} below expects ${FILE_DIRNAME}/glibc-${PV} and
there's "glibc-linaro-2.20" directory with whole bunch of patches:
https://git.linaro.org/openembedded/meta-linaro.git/tree/meta-linaro-toolch…
So, with your change, it would instead try to look into "glibc-2.20" and fail
to find any patches. Not even sure how it was tested...
--
Denys
> ...
> $ git grep PV .
> glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ reads from
> the PVR register. */
> glibc-linaro-2.20/eglibc-ppc8xx-cache-line-workaround.patch:+ emulates
> PowerPC mfspr reads from the PVR register. */
> glibc_linaro-2.20.bb:SRC_URI = "
> http://releases.linaro.org/archive/${MMYY}/components/toolchain/glibc-linar…
> \
> glibc_linaro-2.20.bb:S = "${WORKDIR}/glibc-${PV}-${RELEASE}"
> glibc_linaro-2.20.bb:FILESPATH = "${@base_set_filespath([
> '${FILE_DIRNAME}/glibc-${PV}', '${FILE_DIRNAME}/glibc',
> '${FILE_DIRNAME}/files', '${FILE_DIRNAME}' ], d)}"
> glibc_linaro.inc:PV = "2.20"
> ...
>
> What is the error that you have noticed?
>
> Regards,
> Anibal
>
> On Fri, 8 Mar 2019 at 14:32, Denys Dmytriyenko <denis(a)denix.org> wrote:
>
> >
> > https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
> >
> > meta-linaro-toolchain: Set PV on glibc_linaro
> > Recently a common file was introudced to set PV for glibc [1]
> > in oe-core causing failures becuase glibc_linaro is trying
> > to download the latest oe-core version (2.29).
> >
> > [1] https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
> >
> > Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
> > Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
> >
> >
> > The problem is that all those modified recipes already had PV set in their
> > filename and it was "linaro-2.20", not just "2.20".
> >
> > --
> > Denys
> >
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=768925270cc2…
meta-linaro-toolchain: Set PV on glibc_linaro
Recently a common file was introudced to set PV for glibc [1]
in oe-core causing failures becuase glibc_linaro is trying
to download the latest oe-core version (2.29).
[1] https://git.openembedded.org/openembedded-core/commit/?id=41093cb6c6
Change-Id: I5c99c25a953f00a64614046ba40e578795553bc1
Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org>
The problem is that all those modified recipes already had PV set in their
filename and it was "linaro-2.20", not just "2.20".
--
Denys
Hi all,
I tried the new external-arm feature.
I had a problem in building gdb-7.8, attached the patch I used to
solve the problem,an in the following the patch for the layer, but
anyway why gdb-7.8 is still used in the master branch? why do not
upgrade to a newer version?
Regards,
d.
diff --git a/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
b/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
index 630d43c..841b1ed 100644
--- a/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
+++ b/meta-linaro-toolchain/recipes-devtools/gdb/gdb_linaro-7.8.bb
@@ -6,6 +6,8 @@ inherit python-dir
PACKAGECONFIG ??= ""
PACKAGECONFIG[python] =
"--with-python=${WORKDIR}/python,--without-python,python"
+SRC_URI += "file://0001-Fix-compilation-external-gcc-arm-8.2-2018.11.patch"
+
do_configure_prepend() {
if [ -n "${(a)bb.utils.contains('PACKAGECONFIG', 'python',
'python', '', d)}" ]; then
cat > ${WORKDIR}/python << EOF
From: Denys Dmytriyenko <denys(a)ti.com>
Fixes for the recently introduced external ARM toolchain support.
Denys Dmytriyenko (15):
tcmode-external-arm: use correct EAT_ prefix instead of ELT_ for
TARGET_SYS
external-arm-toolchain: also support 32-bit arm toolchains
tcmode-external-arm: uncomment preference for
virtual/${TARGET_PREFIX}binutils
external-arm-toolchain: package header files into
linux-libc-headers-dev
external-arm-toolchain: libgcc_s.so in base_libdir is not a symlink,
but a linker script
external-arm-toolchain: package c++ headers
external-arm-toolchain: some packages rdepend on ldd, so allow
creating empty package
external-arm-toolchain: fix host contamination QA issue
external-arm-toolchain: switch from ${COREBASE}/LICENSE to
${COMMON_LICENSE_DIR}/MIT
external-arm-toolchain: libasan/libubsan bump major version number
external-arm-toolchain: libcidn is no longer packaged
external-arm-toolchain: libnsl was split off of glibc and is a
separate package now
external-arm-toolchain: rpcsvc/rquota.* headers are now provided by
separate quota package
external-arm-toolchain: also provide virtual/libc-locale
external-arm-toolchain: also set proper RPROVIDES for glibc-staticdev
.../include/external-arm-toolchain-versions.inc | 8 +--
.../conf/distro/include/tcmode-external-arm.inc | 17 +++--
.../external-arm-toolchain.bb | 76 ++++++++++++----------
3 files changed, 56 insertions(+), 45 deletions(-)
--
2.7.4
hi there,
as discussed recently, we are starting to put together the thud builds
for Linaro OE RPB.
* The oe-rpb-manifest now has the 'thud' branch, see [1]. Some layers
are still missing thud branch themselves, in which case we use master.
* we created thud branches for all Linaro layers (meta-linaro,
meta-backports, meta-rpb, meta-96boards, meta-qcom)
* A new build was created on ci.linaro, see [2] , and is now enabled
(which means it will trigger on any change on one of the thud branches
we track)
The first 2 builds failed during the weekend, but it was
infrastructure issues, however we just got a new failure that is a
valid failure.. see [3]. Looks like LTP fails to build.
Daniel: is that something you can check and fix?
cheers
nico
[1] https://github.com/96boards/oe-rpb-manifest/tree/thud
[2] https://review.linaro.org/#/c/ci/job/configs/+/29110/
[3] https://ci.linaro.org/job/96boards-reference-platform-openembedded-thud/
Adding the Linaro OE mailing list.
I am not familiar with the details of what you are doing, but it looks
like your layer needs to be updated. See
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3314, the getVar()
function was updated and that requires updating your layer.
nico
On Thu, Oct 18, 2018 at 9:06 PM Park, Kyung Min
<kyung.min.park(a)intel.com> wrote:
>
> Copying Nicolas/Fathi here.
>
>
>
> Hi Nicolas/Fathi,
>
> Can you comment on this?
>
>
>
> Thanks,
>
> Kyung Min
>
>
>
> From: Dey, Megha
> Sent: Wednesday, October 17, 2018 4:40 PM
> To: Park, Kyung Min <kyung.min.park(a)intel.com>; koen.kooi(a)linaro.org
> Subject: RE: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We are trying to configure LUV (Linux UEFI Validation) using the OE-RPB model, as per our discussion at the Linaro connect.
>
>
>
> As a start, we tried to build the oe-rpb-manifest with the default morty branch and everything builds fine. However, if we switch to the sumo branch, we see the error below.
>
>
>
> We wanted to confirm if the sumo branch build fine on your end and if we are missing something on our end.
>
>
>
> Please let us know.
>
>
>
> Thanks,
>
> Megha
>
>
>
> From: Park, Kyung Min
> Sent: Tuesday, October 9, 2018 5:22 PM
> To: koen.kooi(a)linaro.org
> Cc: Dey, Megha <megha.dey(a)intel.com>
> Subject: oe-rpb-manifest sumo branch?
>
>
>
> Hi Koen,
>
>
>
> We’ve been trying to build the oe-rpb-manifest with ‘sumo’ branch. But, we’re getting an error in data_smart.py as below.
>
> Do you know if anybody tried sumo branch or validated? Everything went well with ‘morty’ branch.
>
>
>
> # git repo
>
> https://github.com/96boards/oe-rpb-manifest
>
>
>
> # error log when build
>
> ERROR: Unable to parse /home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py
>
> Traceback (most recent call last):
>
> File "/home/km/Documents/rpb-yocto-tue/oe-rpb-manifest/bitbake/lib/bb/data_smart.py", line 401, in DataSmart.ex pandWithRefs(s="${(a)os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}", varname='PATH[ :=]'):
>
> raise ExpansionError(varname, s, exc) from exc
>
>
>
> bb.data_smart.ExpansionError: Failure expanding variable PATH[:=], expression was ${(a)os.path.dirname(bb.utils.whi ch(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR} which triggered exception TypeError: getVar() missing 1 require d positional argument: 'expand'
>
>
>
> Thanks,
>
> Kyung Min
