On Wed, Nov 6, 2019 at 2:19 PM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
>
> Yes, I did.
>
> On Wed, 6 Nov 2019 at 15:58, Nicolas Dechesne
> <nicolas.dechesne(a)linaro.org> wrote:
> >
> > hi Maxim,
> >
> > your original email didn't make it to the mailing list.. not sure why,
> > you might want to check. I am adding the list here again.
> >
> > On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> > >
> > > looks like it is. after this patch:
> > > http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
> > > I see error:
> > > ERROR: ExpansionError during parsing
> > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > Traceback (most recent call last):
> > > File "Var <SRCPV>", line 1, in <module>
> > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at
> > > 0x7faa98f59e48>, method_name='sortable_revision'):
> > > raise FetchError("The SRCREV_FORMAT variable must be set
> > > when multiple SCMs are used.\n"\
> > > > "The SCMs are:\n%s" % '\n'.join(scms))
> > >
> > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > > FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set
> > > when multiple SCMs are used.
> >
> > I don't understand the situation. do we have a problem or did you fix it?
> >
> > and btw, are we really still using this recipe from 2014? or did you
> > find that by accident?
> >
> yea fresh version of openjdk is in meta-java. But it has some issues
> to compile on aarch64.
>
> Issue with meta-linaro can be fixed in a few ways:
> 1. add SRCREV_FORMAT = "jdk8" and apply this patch
> http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
>
> or
>
> 2. HG can allow to download tar balls. So we can switch from hg:// to https://.
>
> or
>
> 3. Simple drop openjdk from meta-linaro and fix meta-java version.
>
> For my issue meta-linaro/aarch64 was in ledge rp build. And parser
> of .bb files started to fail on that recipe after we switched to zeus
> branch. Because we don't need openjdk I simply removed it from ledge
> rp layer. That fixed my current issue. But in general it will be good
> to fix it.
I think we should fix upstream. I think we used this recipe initially
for the bring up, but it should be removed now. Would be nice to have
some background on this recipe.. or at least someone who can confirm
it's safe to be removed now.
>
> Maxim.
>
> > > The SCMs are:
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools…
> > > hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n…
> > >
> > >
> > >
> > > On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> > > >
> > > > Hi Nicolas,
> > > >
> > > > is that known bug?
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Maxim Uvarov <maxim.uvarov(a)linaro.org>
> > > > Date: Tue, 5 Nov 2019 at 23:09
> > > > Subject: openjdk is broken on zeus branch
> > > > To: <openembedded(a)lists.linaro.org>
> > > >
> > > >
> > > > It looks like ${AUTOREV} with hg tool project is broken. openjdk from
> > > > meta-java also does not use AUTOREV. I'm not sure what is better fix
> > > > for that - remove AUTOREV or fix it?
> > > >
> > > > BR,
> > > > Maxim.
> > > >
> > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > > > Exception during build_dependencies for AUTOREV | ETA:
> > > > --:--:--
> > > > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > > > Error during finalise of
> > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > > ERROR: ExpansionError during parsing
> > > > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > > > Traceback (most recent call last):
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart
> > > > object at 0x7fddc1423b38>):
> > > > for name in self.names:
> > > > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > > >
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > if srcrev == "AUTOINC":
> > > > > srcrev = ud.method.latest_revision(ud, d, name)
> > > >
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
> > > > > key = self.generate_revision_key(ud, d, name)
> > > > try:
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object
> > > > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at
> > > > 0x7fddc1423b38>, name='jdk8'):
> > > > def generate_revision_key(self, ud, d, name):
> > > > > key = self._revision_key(ud, d, name)
> > > > return "%s-%s" % (key, d.getVar("PN") or "")
> > > > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py",
> > > > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at
> > > > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > > > name='jdk8'):
> > > > """
> > > > > return "hg:" + ud.moddir
> > > >
> > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > > > AttributeError: 'FetchData' object has no attribute 'moddir'
hi Maxim,
your original email didn't make it to the mailing list.. not sure why,
you might want to check. I am adding the list here again.
On Wed, Nov 6, 2019 at 10:54 AM Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
>
> looks like it is. after this patch:
> http://lists.openembedded.org/pipermail/bitbake-devel/2017-November/009097.…
> I see error:
> ERROR: ExpansionError during parsing
> /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> Traceback (most recent call last):
> File "Var <SRCPV>", line 1, in <module>
> File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> line 768, in get_srcrev(d=<bb.data_smart.DataSmart object at
> 0x7faa98f59e48>, method_name='sortable_revision'):
> raise FetchError("The SRCREV_FORMAT variable must be set
> when multiple SCMs are used.\n"\
> > "The SCMs are:\n%s" % '\n'.join(scms))
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set
> when multiple SCMs are used.
I don't understand the situation. do we have a problem or did you fix it?
and btw, are we really still using this recipe from 2014? or did you
find that by accident?
> The SCMs are:
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk8;name…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/corba;nam…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/hotspot;n…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxp;name…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jaxws;nam…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/jdk;name=…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/langtools…
> hg://hg.openjdk.java.net/aarch64-port;protocol=http;destsuffix=hg/nashorn;n…
>
>
>
> On Wed, 6 Nov 2019 at 12:33, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote:
> >
> > Hi Nicolas,
> >
> > is that known bug?
> >
> > ---------- Forwarded message ---------
> > From: Maxim Uvarov <maxim.uvarov(a)linaro.org>
> > Date: Tue, 5 Nov 2019 at 23:09
> > Subject: openjdk is broken on zeus branch
> > To: <openembedded(a)lists.linaro.org>
> >
> >
> > It looks like ${AUTOREV} with hg tool project is broken. openjdk from
> > meta-java also does not use AUTOREV. I'm not sure what is better fix
> > for that - remove AUTOREV or fix it?
> >
> > BR,
> > Maxim.
> >
> > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > Exception during build_dependencies for AUTOREV | ETA:
> > --:--:--
> > WARNING: /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb:
> > Error during finalise of
> > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > ERROR: ExpansionError during parsing
> > /home/maxim.uvarov/build-test-update/build-rpb/conf/../../layers/meta-linaro/meta-aarch64/recipes-core/openjdk/openjdk-8_0.1.bb
> > Traceback (most recent call last):
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1302, in FetchData.setup_revisions(d=<bb.data_smart.DataSmart
> > object at 0x7fddc1423b38>):
> > for name in self.names:
> > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> >
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1167, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > if srcrev == "AUTOINC":
> > > srcrev = ud.method.latest_revision(ud, d, name)
> >
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1558, in Hg.latest_revision(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
> > > key = self.generate_revision_key(ud, d, name)
> > try:
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/__init__.py",
> > line 1570, in Hg.generate_revision_key(ud=<bb.fetch2.FetchData object
> > at 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at
> > 0x7fddc1423b38>, name='jdk8'):
> > def generate_revision_key(self, ud, d, name):
> > > key = self._revision_key(ud, d, name)
> > return "%s-%s" % (key, d.getVar("PN") or "")
> > File "/home/maxim.uvarov/build-test-update/bitbake/lib/bb/fetch2/hg.py",
> > line 225, in Hg._revision_key(ud=<bb.fetch2.FetchData object at
> > 0x7fddc17d8e80>, d=<bb.data_smart.DataSmart object at 0x7fddc1423b38>,
> > name='jdk8'):
> > """
> > > return "hg:" + ud.moddir
> >
> > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > expression was ${(a)bb.fetch2.get_srcrev(d)} which triggered exception
> > AttributeError: 'FetchData' object has no attribute 'moddir'
hi there,
I've pushed all needed changes to get started with Zeus builds for the
Linaro OE RPB CI:
* created zeus branch on meta-backports, meta-qcom
* created zeus branch on oe-rpb-manifest
* i did not create zeus and i am keeping master for meta-rpb,
meta-96boards, meta-linaro. it's compatible, at least for now
* our zeus manifest is using master for other layers when they don't
have a zeus branch
Build #1 is scheduled for now.. we will see how bad it goes.
I have also create the qcom/zeus branch (I recall that it is a
stripped down version of the overall Linaro manifest that only focuses
on Qualcomm BSP).
Of course, if you can keep an eye on builds and help fixing issues,
that would be much appreciated.
cheers
nico
Hi,
I have a working system based on Sumo. The system boots with a read-only
rootfs, then applies are read-write overlay for /etc.
When I migrate to Warrior, systemd-resolved fails to start. If I mount the
same rootfs via NFS, it starts and works fine. systemd-timesyncd is also
failing, but I haven't looked into that yet. It also works fine on the NFS
mounted system.
The resolve problem seems to be caused by two things:
- /var/volatile is read-only
- /run/systemd/resolve has the wrong ownership
drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23
resolve/
I think this permissions problem may be a result of the /var/volatile
mounting
problems; it looks fine on the NFS mounted system.
If I manually mount /var/volatile (it's in fstab) and change the ownership
on /run/systemd/resolve, the service starts just fine.
I also notice that /tmp is not mounted at all, which may be related.
Here are the various tmp mount points on my read-only rootfs:
$ mount | grep tmp
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=112036k,nr_inodes=28009,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
overlay on /etc type overlay
(rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=23840k,mode=700)
On the NFS mounted system, I see these:
$ mount | grep tmp
devtmpfs on /dev type devtmpfs
(rw,relatime,size=118180k,nr_inodes=29545,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /var/volatile type tmpfs (rw,relatime)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=23840k,mode=700)
As you can see, NFS has these extra mounts:
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /var/volatile type tmpfs (rw,relatime)
I've tried reverting a few commits that may be related, but I haven't had
any luck working out things have changed, eg:
c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available
[Matt Hoosier]
Advice would be appreciated. Are there any particular areas I should be
looking to work out what's going wrong?
Kind regards,
Ryan.
Hi Team, I have downloaded the lhg-oe-manifest source and builded it successfully for Dragonboard-410c.After flashing it on device i am only able to play the clearkey encrypted video but when i am trying to play the widevine encrypted content,it is showing like there is no supported key system.Is there any support of playing widevine encrypted content in this code.If not can you help me how to play widevine encrypted video.I have downloaded the code from below manifest $repo init -u https://github.com/linaro-mmwg/lhg-oe-manifests.git -b morty
It would be a great help for me if you provide me any way to get out of it.
Thanks and RegardsN.Tarani
Daniel,
as discussed, I've experimented with meta-rpb and the Yocto Compatible
check scripts.. see :
https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#making-s…
There are many obvious reasons why it's a good idea to make sure that
layers can pass this script..
I was able to get meta-rpb to pass the compatibility check with the
following patches:
https://github.com/ndechesne/meta-rpb/tree/check-layer
The simplest way to run the script is to use a copy of Poky git:
$ git clone http://git.yoctoproject.org/git/poky
$ cd poky
$ source oe-init-build-env
$ yocto-check-layer <oe-rpb folder>/layers/meta-rpb/ --dependency
<oe-rpb folder>/layers/
The main things that the script will test are:
1. Adding your layer in bblayers.conf will not change any recipe
content/checksum
2. All dependencies are properly tracked
For meta-rpb, we depend on meta-virtualization (docker) and that layer
breaks compatibility in many ways.. so I had to remove references to
docker and meta-virt to run the script..
I will be doing a bit more testing/review, and submit the PR.
cheers
nico
hi,
i've started to push some updates about OE warrior for our Linaro builds.
The branch warrior was added to meta-rpb, meta-96boards, meta-qcom,
meta-linaro, meta-backports.
I have added a 'warrior' branch to the oe-rpb-manifest as well, see:
https://github.com/96boards/oe-rpb-manifest/commit/dd60a2322845adb9cfe7e82e…
Some layers still don't have a warrior branch, in which case we use master.
I have submitted a change to start build based on warrior..
Let's see how things go with this new branch!
cheers
nico
Hi all,
I'm trying to use the thud branch of Yocto Project with the Arago distro and the Linaro toolchain.
The external-linaro-toolchain.bb recipe includes glibc-package.inc from oe-core which has been modified in 2018 to install a makedbs.sh script [1] and to handle the floatn.h header introduced in glibc 2.26 [2]. The first change definitely breaks the external-linaro-toolchain recipe as no makedbs.sh script is present - in the oe-core glibc recipe this is included as a file and referenced in SRC_URI. The second change breaks if the Linaro toolchain includes a version of glibc prior to 2.26.
I see that an attempt to fix the above issues has been posted to this mailing list [3] but this wasn't merged and no other fix has gone into the meta-linaro repository. The was also a report of this issue posted to the Yocto mailing list in January [4]. So it looks like this has been broken for a few months but obviously hasn't been noticed more widely.
Is the external-linaro-toolchain recipe expected to work on the thud branch? If not, what should I be using instead?
[1]: https://git.openembedded.org/openembedded-core/commit/?h=thud&id=13cf502fce…
[2]: https://git.openembedded.org/openembedded-core/commit/?h=thud&id=650c59c8b6…
[3]: https://lists.linaro.org/pipermail/openembedded/2019-January/000159.html
[4]: https://lists.yoctoproject.org/pipermail/yocto/2019-January/043747.html
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
