Date   

Issue related to .wic image

NIKHIL PATIL
 

Hi ,
    We are compiling a core-image-sato-sdk.wic  image  using bitbake  that time i am not able to copy anything into /lib/firmware  folder. 
     but when i am compiling core-image-sato-sdk.hddimg   that time its work fine .     
    for wic image getting following error .
  
root@intel-corei7-64:~# cp tests/Firmware/* /lib/firmware/
cp: cannot create regular file '/lib/firmware/RS9113_AP_BT_DUAL_MODE.rps': Read-only file system
cp: cannot create regular file '/lib/firmware/RS9113_WC_BL.rps': Read-only file system


#yocto zeus X11 keyboard #yocto

Monsees, Steven C (US)
 

 

I am running zeus based image (that runs without the following error under  my rocko build), under zeus build I am now seeing the following :

 

The XKEYBOARD keymap compiler (xkbcomp) reports:

> Warning:          Unsupported high keycode 372 for name <I372> ignored

>                   X11 cannot support keycodes above 255.

>                   This warning only shows for the first high keycode.

Errors from xkbcomp are not fatal to the X server

 

Under: .../share/X11/xkb/keycodes/evfev I372 is defined as:

        // Extended keys that may be generated on "Internet" keyboards.

        // evdev has standardize names for these.

 

        <I372> = 372;   // #define KEY_FAVORITES           364

 

Is there a build option for this component I can tweak to correct for this ?

 

Thanks,

Steve


Re: Split kernel patches over different machines

Bel Hadj Salem Talel
 

Hi,
Thanks for the reply,

Yes, that did the trick.

Thanks, Talel


Re: Split kernel patches over different machines

Quentin Schulz
 

Hi Talel,

On Wed, Nov 11, 2020 at 03:30:33AM -0800, Bel Hadj Salem Talel wrote:
Hi All,

I created two different machines "menzu-console" and "menzu-media"
I have main patch for device tree for both , and only one patch specific for menzu-media machine
So in the linux recipe bbappend I want to set something like this:
SRC_URI += "file://main.patch" # FOR BOTH MACHINES
SRC_URI_menzu-media += "file://media.patch" # FOR menzu-media ONLY
SRC_URI_append_mezu-media = " file://media.patch"
is what you should use.

The issue with your suggestion is that it **replaces** the original
variable iff the recipe is built for menzu-media. What you want is to
append to the variable iff the recipe is built for menzu-media, that's
what the line above does.

Quentin


Split kernel patches over different machines

Bel Hadj Salem Talel
 

Hi All,

I created two different machines "menzu-console" and "menzu-media"
I have main patch for device tree for both , and only one patch specific for menzu-media machine
So in the linux recipe bbappend I want to set something like this:
SRC_URI += "file://main.patch" # FOR BOTH MACHINES
SRC_URI_menzu-media += "file://media.patch" # FOR menzu-media ONLY

But this didn't work, only "media.patch" is unpacked and moreover the kernel recipe workdir does not contain a content as if unpack didn't work properly.
How can I do it ?

Thanks, Talel


Re: : When compiling code, how to make a package not hash checked?

ouyangxuan10@163.com
 

hi Quentin,








At 2020-11-10 21:16:15, "Quentin Schulz" <quentin.schulz@...> wrote: >Hi Byron, > >On Tue, Nov 10, 2020 at 09:09:05PM +0800, ouyangxuan10@... wrote: >> Dear all, >> >> >> I would like to ask the reasons for the following problems and how to solve them? When compiling a program, how to make a package not hash checked? >> > >Did you execute the commands that were suggested in the log you sent? > >Can you send us the content of the log of the second command please?
>
This is another package with the same problem:(Run the above command.)

the log in locked-sigs.inc

I would like to ask, is there any way to separate this package from the verification function?

>Basically, two possible ways this happens: > 1. you modified the recipe while bitbake was running. Solution => don't > do that. > 2. bitbake parses tasks multiple times during a run, therefore, if a > variable changes between parses your task will have a different hash. > This usually happens with DATETIME. If you don't absolutely need this > variable, remove it or find a replacement. If you have to, I think the > vardepsexclude variable flag is the way to do it? >
>Quentin

Thanks,
Byron


 


Re: python bump

Mikko Rapeli
 

On Wed, Nov 11, 2020 at 08:39:42AM +0100, Belisko Marek wrote:
On Wed, Nov 11, 2020 at 8:04 AM <Mikko.Rapeli@bmw.de> wrote:

Hi,

On Tue, Nov 10, 2020 at 07:44:39PM +0100, Marek Belisko wrote:
Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
| File "setup.py", line 25, in <module>
| from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?
When backporting changes, I find it better to cherry-pick the changes for e.g.
python3 update from master to the old branch that I have to use. In my case I can
not update anything which breaks ABIs on target images but can update all
development tools like python3. Often fixes and/or updates to components which
fail to build are also easy to find from master and cherry-pick, especially if you
don't need to build all recipes from poky but only a certain subset. Over
time this will make your local branch look horrible though, but at least
merges from stable branches will in most cases work, if they are still alive.
Thanks for sharing. But I'm using official poky release from git so I
cannot cherry pick changes.
Or you have clone of poky repo and add changes on top from newest versions?
Locally, as developer you always have a local branch where you can cherry-pick
changes. With git submodules and repo tooling, you should use a local or
project specific clone of poky. Or move all updates and changes to your own
layers, but I find this doesn't scale and instead branching in git works
better.

Cheers,

-Mikko


How to create new variable in Yocto to use it in a recipe ?

Bel Hadj Salem Talel
 

Hi All,

I'm not trying to export or create a variable inside a recipe because that's easy and not my case.
But I want to create a variable that a user can define in local.conf or in other conf files and a recipe that checks the value of that variable and do some stuff with it like:
python (){
 a = d.getVar('MY_VARIABLE' or '')
}
How can I do this?
Thanks, Talel


Re: python bump

Martin Jansa
 

If you don't really need 3.8 and 3.7.5 from warrior would be good enough for you, then backporting it to thud was relatively straightforward as implemented in:
and as it's in a separate layer it doesn't make your main distro layer more ugly or difficult to maintain (just drop backports layers when upgrading to newer release instead of trying to find out all backported bits and pieces across a whole set of layers).

But even this "small" upgrade from 3.6 to 3.7 introduces ABI change as shown in:
so it's better to upgrade completely to a new release if possible at all.

On Tue, Nov 10, 2020 at 7:45 PM Marek Belisko <marek.belisko@...> wrote:
Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
|   File "setup.py", line 25, in <module>
|     from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com




Re: python bump

Marek Belisko
 

On Wed, Nov 11, 2020 at 8:04 AM <Mikko.Rapeli@bmw.de> wrote:

Hi,

On Tue, Nov 10, 2020 at 07:44:39PM +0100, Marek Belisko wrote:
Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
| File "setup.py", line 25, in <module>
| from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?
When backporting changes, I find it better to cherry-pick the changes for e.g.
python3 update from master to the old branch that I have to use. In my case I can
not update anything which breaks ABIs on target images but can update all
development tools like python3. Often fixes and/or updates to components which
fail to build are also easy to find from master and cherry-pick, especially if you
don't need to build all recipes from poky but only a certain subset. Over
time this will make your local branch look horrible though, but at least
merges from stable branches will in most cases work, if they are still alive.
Thanks for sharing. But I'm using official poky release from git so I
cannot cherry pick changes.
Or you have clone of poky repo and add changes on top from newest versions?

But like Alex said, using 3.1 dunfell LTS or 3.2 gatesgarth would be better.
Yes but it's not an option for me to do it now ;).

Hope this helps,

-Mikko
Thanks,

Marek


Re: Error when building eSDK for a `docker load`able tarball

Josef Holzmayr
 

Howdy!

Am Mi., 11. Nov. 2020 um 08:18 Uhr schrieb Robert Berger@yocto.user
<robert.berger.yocto.user@gmail.com>:
<snip>

So it looks like it's extensible SDK specific.

Can you please try with the "standard" sdk instead of the extensible sdk
to see if this works for you?
<snip>

Tried that. Standard SDK works, it's definitely related to the tasks
of the eSDK.

Greetz


Re: Error when building eSDK for a `docker load`able tarball

Robert Berger
 

Hi,

And as far as I understand you tried to build some extensible SDK against an x86-64 container.

Please note, that my SDK most likely contains a bit more than the "standard" stuff[0], but this should not make much of a difference here.

[0] https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend

I take a container-x86-64:

bitbake app-container-image-mosquitto-oci [1]

[1] https://pastebin.com/T9hX1H8f

bitbake app-container-image-mosquitto-oci -c populate_sdk [2]

[2] https://pastebin.com/eujc57DG

bitbake app-container-image-mosquitto-oci -c populate_sdk_ext

breaks in a similar way[3]

[3] https://pastebin.com/rV9ewZa9

So it looks like it's extensible SDK specific.

Can you please try with the "standard" sdk instead of the extensible sdk to see if this works for you?

You might want to play with IMAGE_CONTAINER_NO_DUMMY = "1" which is defined in poky/meta/classes/image-container.bbclass and try to build a container with a kernel as a workaround in case you build an eSDK.

Regards,

Robert


Re: python bump

Mikko Rapeli
 

Hi,

On Tue, Nov 10, 2020 at 07:44:39PM +0100, Marek Belisko wrote:
Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
| File "setup.py", line 25, in <module>
| from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?
When backporting changes, I find it better to cherry-pick the changes for e.g.
python3 update from master to the old branch that I have to use. In my case I can
not update anything which breaks ABIs on target images but can update all
development tools like python3. Often fixes and/or updates to components which
fail to build are also easy to find from master and cherry-pick, especially if you
don't need to build all recipes from poky but only a certain subset. Over
time this will make your local branch look horrible though, but at least
merges from stable branches will in most cases work, if they are still alive.

But like Alex said, using 3.1 dunfell LTS or 3.2 gatesgarth would be better.

Hope this helps,

-Mikko


Re: python bump

Alexander Kanavin
 

You should rather move to a yocto release that has the needed python, backporting major pieces like that is difficult to impossible.

Alex


On Tue, 10 Nov 2020 at 19:45, Marek Belisko <marek.belisko@...> wrote:
Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
|   File "setup.py", line 25, in <module>
|     from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com




python bump

Marek Belisko
 

Hi,

I'm using poky release thud and would like to bump python3 to 3.8.x. I
took recipe from most recent poky version but I'm hitting issue with
e.g. meson build like:
Log data follows:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
| File "setup.py", line 25, in <module>
| from setuptools import setup
| ModuleNotFoundError: No module named 'setuptools'

Are there some other things I need to take care when want to bump python3?

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Re: Missing vardeps in meta/classes/roofs_rpm.bbclass?

Alexander Kanavin
 

This seems like you need to make a patch (for master branch) and send it to oe-core list? :)

Alex


On Tue, 10 Nov 2020 at 19:04, Loic Domaigne <tech@...> wrote:
Salut,

We were playing with rpm package management lately.

To configure the yum repos in the image, we're setting the following variables in conf/local.conf:
FEED_PACKAGE_URIS
FEED_PACKAGE_BASE_PATHS

We made a typo, and forgot the S at the end of FEED_PACKAGE_BASE_PATHS
Not surprising, the repo file generated didn't have the right url:

$ cat oe-remote-repo-user1.repo
[oe-remote-repo-user1]
name=OE Remote Repo: user1
baseurl=http://192.168.7.1/user1
gpgcheck=0


After fixing the typo and bitbaking the image again, still no avail.
The repo file remains unchanged.

In fact, changing FEED_PACKAGE_BASE_PATHS did not re-trigger a new image build. We found this behavior surprising.

AFAICS:
1) As per oe/lib/meta/lib/oe/rootfs.py and lib/oe/package_manager.py, the URL is defined as the join paths of FEED_PACKAGE_URIS and FEED_PACKAGE_BASE_PATHS.
2) However, in meta/classes/rootfs_rpm.bbclass, do_rootfs only specifies a build dependency to FEED_PACKAGE_URIS:
do_rootfs[vardeps] += "PACKAGE_FEED_URIS"

Shouldn't the rootfs task depend on both PACKAGE_FEEDS_URIS and PACKAGE_FEED_BASE_PATHS, ie.
do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS"

After fixing this dependency, the repo file got updated as expected:
cat oe-remote-repo-user1-rpm.repo
[oe-remote-repo-user1-rpm]
name=OE Remote Repo: user1 rpm
baseurl=http://192.168.7.1/user1/rpm
gpgcheck=0

Does that make sense?

I have conducted this analysis on Zeus. The problem isn't fixed with Dunfell AFAICS. Also, the other package classes (deb,ipk) are impacted as well.

Hope this helps!
Loic




Missing vardeps in meta/classes/roofs_rpm.bbclass?

Loic Domaigne
 

Salut,

We were playing with rpm package management lately.

To configure the yum repos in the image, we're setting the following variables in conf/local.conf:
FEED_PACKAGE_URIS
FEED_PACKAGE_BASE_PATHS

We made a typo, and forgot the S at the end of FEED_PACKAGE_BASE_PATHS
Not surprising, the repo file generated didn't have the right url:

$ cat oe-remote-repo-user1.repo
[oe-remote-repo-user1]
name=OE Remote Repo: user1
baseurl=http://192.168.7.1/user1
gpgcheck=0


After fixing the typo and bitbaking the image again, still no avail.
The repo file remains unchanged.

In fact, changing FEED_PACKAGE_BASE_PATHS did not re-trigger a new image build. We found this behavior surprising.

AFAICS:
1) As per oe/lib/meta/lib/oe/rootfs.py and lib/oe/package_manager.py, the URL is defined as the join paths of FEED_PACKAGE_URIS and FEED_PACKAGE_BASE_PATHS.
2) However, in meta/classes/rootfs_rpm.bbclass, do_rootfs only specifies a build dependency to FEED_PACKAGE_URIS:
do_rootfs[vardeps] += "PACKAGE_FEED_URIS"

Shouldn't the rootfs task depend on both PACKAGE_FEEDS_URIS and PACKAGE_FEED_BASE_PATHS, ie.
do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS"

After fixing this dependency, the repo file got updated as expected:
cat oe-remote-repo-user1-rpm.repo
[oe-remote-repo-user1-rpm]
name=OE Remote Repo: user1 rpm
baseurl=http://192.168.7.1/user1/rpm
gpgcheck=0

Does that make sense?

I have conducted this analysis on Zeus. The problem isn't fixed with Dunfell AFAICS. Also, the other package classes (deb,ipk) are impacted as well.

Hope this helps!
Loic


Re: [gtk+3][zeus] building only with wayland backend, no x11

Alexander Kanavin
 

This seems like libepoxy was not properly rebuilt when you changed DISTRO_FEATURS, even though it should have been. Can you try to reproduce the issue on master please?

Alex


On Tue, 10 Nov 2020 at 16:14, Adrian Fiergolski <adrian.fiergolski@...> wrote:

Hi Alex,

Thank you for the hint. It led me to the source of the problem, which was libepoxy.

It looks that after changing configuration (DISTRO_FEATURES_remove = " x11"), SSTATE was still populating sysroot of gtk+3 with the older version of libepoxy configuration file (*.pc) creating dependency to 'gl' and 'x11'. In my case I had to call:

bitbake -c cleanall libepoxy

bitbake -c cleanall gtk+3

bitbake gtk+3

In order to avoid such issues in the future, is there any way to force bitbake (after such considerable configuration change like modification of DISTRO_FEATURES) to rebuild sysroot for each recipe if necessary instead of grabbing them from the cache ? I know, one could delete sstate-cache directory, but obviously it will enormously increase rebuild time. I have been wondering whether there is an intermediate solution.

Regards,

Adrian

On 09.11.2020 15:28, Alexander Kanavin wrote:
Do you actually need gtk+3 in your image?

There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors:
so I'd suggest you reproduce that, get it to build, then investigate where your build diverges.

Alex

On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:

Hi,

I am building an image based on core-image-weston.

I would like to use only wayland backend, thus I defined in my machine's configuration:

DISTRO_FEATURES_append = " wayland"
DISTRO_FEATURES_remove = " x11"

I have a problem with build of gtk+3:

| checking for pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7... no
| configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7) were not met:
|
| Package 'x11', required by 'gl', not found

The configuration flags in config.log seems to be ok:

  $ ../gtk+-3.24.8/configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot --enable-introspection --disable-gtk-doc --disable-glibtest --disable-xinerama --enable-modules --disable-colord --disable-gtk-doc --disable-static --disable-cups --disable-glx --enable-opengl --enable-wayland-backend --disable-x11-backend --enable-nls

Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version.

Regards,

Adrian






Yocto Project Status WW45'20

Stephen Jolley
 

Current Dev Position: YP 3.3 M1 development

Next Deadline: 7th December 2020 YP 3.3 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2 has been released
  • Master has now opened up for 3.3 development. Unfortunately there have been a lot of issues showing up with some of the more adventurous patches being proposed, the issues are being worked through.
  • Intermittent autobuilder issues continue to occur. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • A YP 3.3 planning document has been created for ideas about what may happen in the YP 3.3 release (assuming there are people to work on the items):

https://docs.google.com/document/d/1IHiE0NU0XspDocgxZeLQ_W7o-yr0nVeBjbqImQUtH5A/edit Request edit/suggest access if you want to add to it.

  • YP 3.3 dates for builds, milestones and release have been added below.
  • Anuj Mittal has kindly agreed to maintain the YP 3.2 series (gatesgarth), thanks!
  • The SWAT team has been re-established. A new mailing has been created as swat@... to support this and a number of member organisations have agreed to help staff this team. We are in the process of getting the process running again and in due course there will be the option of other community members being able to help too. The tools and processes are under review to allow us to optimise the process. Thanks to the members and everyone participating to make this happen!

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M4 released

 

YP 3.3 Milestone Dates:

  • YP 3.3 M1 build date 2020/12/07
  • YP 3.3 M1 Release date 2020/12/18
  • YP 3.3 M2 build date 2021/01/18
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13
  • YP 3.2.1 build date 2020/11/16
  • YP 3.2.1 release date 2020/12/4
  • YP 3.1.5 build date 2021/01/11
  • YP 3.1.5 release date 2021/01/22
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [gtk+3][zeus] building only with wayland backend, no x11

Adrian
 

Hi Alex,

Thank you for the hint. It led me to the source of the problem, which was libepoxy.

It looks that after changing configuration (DISTRO_FEATURES_remove = " x11"), SSTATE was still populating sysroot of gtk+3 with the older version of libepoxy configuration file (*.pc) creating dependency to 'gl' and 'x11'. In my case I had to call:

bitbake -c cleanall libepoxy

bitbake -c cleanall gtk+3

bitbake gtk+3

In order to avoid such issues in the future, is there any way to force bitbake (after such considerable configuration change like modification of DISTRO_FEATURES) to rebuild sysroot for each recipe if necessary instead of grabbing them from the cache ? I know, one could delete sstate-cache directory, but obviously it will enormously increase rebuild time. I have been wondering whether there is an intermediate solution.

Regards,

Adrian

On 09.11.2020 15:28, Alexander Kanavin wrote:
Do you actually need gtk+3 in your image?

There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors:
so I'd suggest you reproduce that, get it to build, then investigate where your build diverges.

Alex

On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:

Hi,

I am building an image based on core-image-weston.

I would like to use only wayland backend, thus I defined in my machine's configuration:

DISTRO_FEATURES_append = " wayland"
DISTRO_FEATURES_remove = " x11"

I have a problem with build of gtk+3:

| checking for pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7... no
| configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7) were not met:
|
| Package 'x11', required by 'gl', not found

The configuration flags in config.log seems to be ok:

  $ ../gtk+-3.24.8/configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot --enable-introspection --disable-gtk-doc --disable-glibtest --disable-xinerama --enable-modules --disable-colord --disable-gtk-doc --disable-static --disable-cups --disable-glx --enable-opengl --enable-wayland-backend --disable-x11-backend --enable-nls

Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version.

Regards,

Adrian





2581 - 2600 of 53919