On Sun, 2020-11-22 at 19:16 -0700, Michael Callahan wrote:

I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where
I
am setting a variable from a computed python function. What's the
magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION

If you set BB_DONT_CACHE = "1" in the recipe, it will force the recipe
to reparse each time. That should cause it to rerun find_version and
then change hash when the value changes. Its how SRCREV = "${AUTOREV}"
works behind the scenes.

Cheers,

Richard

I do not want do_compile to run again, it rebuilds the whole image.
What is the best way to always run find_version?

On 2020-11-23 2:26 p.m., Robert P. J. Day wrote:

  colleague wants to know if there is something available
in an OE/YP layer equivalent to mtree:
  https://linux.die.net/man/8/mtree
i'm looking at a few possibilities right now but nothing
seems really equivalent. thoughts?

It don't see anything in the layer index:
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=mtree

but the source has a configure file:
(Ubuntu: apt-get source mtree-netbsd)
so they should write a recipe and send it to meta-oe.

../Randy

rday

--
# Randy MacLeod
# Wind River Linux

The service is deployed with standard systemd package, which doesn't have that set as far as I see it (no SYSTEMD_AUTO_ENABLE_${PN} in the latest recipe revision)

I think, after browsing through the code of systemd - this "autostart" behavior comes from [1].
So I would say you can disable it with a drop-in file at
/etc/systemd/system/systemd-timesyncd.service.d/disable.conf
[Install]
WantedBy=

which also would be charming in a way that it isn't that invasive in the build system

[1] https://github.com/systemd/systemd/blob/5b639090d0b4a49d77ba58bebe180b2a6f8da322/units/systemd-timesyncd.service.in#L55

haven't tested it though, but you might wanna give that a shot, if Aaron's approach doesn't work.

colleague wants to know if there is something available
in an OE/YP layer equivalent to mtree:

https://linux.die.net/man/8/mtree

i'm looking at a few possibilities right now but nothing
seems really equivalent. thoughts?

rday

On 11/21/20 1:56 PM, Robert P. J. Day wrote:

while the bitbake user manual insists:

"The use of the ” % ” character is limited in that it only works
directly in front of the .bbappend portion of the append file’s name.
You cannot use the wildcard character in any other location of the
name."

i just ran across this in the meta-security layer:

recipes-kernel/linux/linux-%_5.%.bbappend

what is one supposed to make of that?

please send a patch to make to correct the situation.

-armin

rday

Thanks, Khem.

On 11/22/20 11:15 PM, Khem Raj wrote:

On Thu, Nov 19, 2020 at 7:38 PM Rudolf J Streif
<rudolf.streif@...> wrote:

I am trying to play back mp4 video (venerable Big Buck Bunny at this
time) on RPi3.

I added gstreamer1.0, gstreamer1.0-omx and the plugins to the image.

libgstomx.so is installed in usr/lib/gstreamer-1.0 on target.

However, gst-inspect-1.0 | grep omx does not return any results.

Consequently,

gst-launch-1.0 filesrc
location="/home/root/kiosk/kiosk/videos/bunny.mp4" ! qtdemux ! h264parse
! omxh264dec ! kmssink
WARNING: erroneous pipeline: no element "omxh264dec"

I guess I am missing something somewhere but I don't know what.

are you using userland for graphics or vc4 ?

Yes, I am. I actually discovered what the problem was: I built my system for 64-bit but Broadcom's proprietary libraries are 32-bit. I switched the system to 32-bit and now gst-inspect shows omx support.

Unfortunately, decoding is still not working. This works:

gst-launch-1.0  -v videotestsrc ! omxh264enc ! h264parse ! avdec_h264 ! autovideosink

However, this does not:

gst-launch-1.0  -v videotestsrc ! omxh264enc ! h264parse ! omxh264dec ! autovideosink

I also tried with kmssink with the same results.

I am using EGLFS backend. It appears to me that there is something off with the omxh264dec decoder plugin passing the decoded buffers on to the output sink. Unfortunately, I have not been able to figure out what that could be.

Ultimately, this would go into a Qt application. I have never had any issues with EGLFS and Qt hence I would be reluctant to switch the backend to Wayland/Weston or X11. But of course I also don't know if omxh264dec would work with either one of those backends.

Thanks,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Ok - I understand now.

Thanks for the explanation.

Charlie

On Mon, Nov 23, 2020 at 11:51 AM Charlie Davies
<charles.davies@...> wrote:

Hi All,

I am seeing some behaviour when creating my own packagegroups which I do not quite understand.

Using the example from the mega-manual:

DESCRIPTION = "My Custom Package Groups"

inherit packagegroup

PACKAGES = "\
packagegroup-custom-apps \
packagegroup-custom-tools \
"

RDEPENDS_packagegroup-custom-apps = "\
dropbear \
portmap \
psplash"

RDEPENDS_packagegroup-custom-tools = "\
oprofile \
oprofileui-server \
lttng-control \
lttng-viewer"

If I then include packagegroup-custom-apps in my image I am also seeing the packages in packagegroup-custom-tools being built (but not included in the image) while building my image.

Is this behaviour correct? I would not expect the packages in packagegroup-custom-tools to be built if the packagegroup-custom-tools is not included in the image.

This is correct. When at least one (binary) package is needed from a
recipe, then the recipe is built, and all the resulting packages are
built.
So when you include packagegroup-custom-apps in your image, you
request the whole packagegroup recipe to be built, which in turn will
build all binary packages (hence all packagegroups and their
dependencies).

Many Thanks,

Charlie

Hi All,

I am seeing some behaviour when creating my own packagegroups which I do not quite understand.

Using the example from the mega-manual:

DESCRIPTION = "My Custom Package Groups"
 
      inherit packagegroup
 
      PACKAGES = "\
          packagegroup-custom-apps \
          packagegroup-custom-tools \
          "
 
      RDEPENDS_packagegroup-custom-apps = "\
          dropbear \
          portmap \
          psplash"
 
      RDEPENDS_packagegroup-custom-tools = "\
          oprofile \
          oprofileui-server \
          lttng-control \
          lttng-viewer"

If I then include packagegroup-custom-apps in my image I am also seeing the packages in packagegroup-custom-tools being built (but not included in the image) while building my image.

Is this behaviour correct? I would not expect the packages in packagegroup-custom-tools to be built if the packagegroup-custom-tools is not included in the image.

Many Thanks,

Charlie

Hi!

I'm trying to integrate the Icinga (https://github.com/Icinga/icinga2) in our Yocto project. As there are no ready recipes for it, I'm trying to write my own, starting from the one used for Nagios which is the original project Icinga forked from.
Icinga uses CMake for the compile process. Problem is that the compilation relies on two binaries, mkclass and mkunity, that get built by the process itself and obviously the compilation stops because those commands cannot be found.

Searching the web I found only this hint in the Technical FAQ https://wiki.yoctoproject.org/wiki/Technical_FAQ#I_have_some_software_which_needs_to_build_a_binary_that_it_then_runs_as_part_of_its_own_build_process.2C_how_do_I_make_this_work.3F, but the problem is still there.

How can I get around this?

Best regards
Matteo Iervasi

On Thu, Nov 19, 2020 at 7:38 PM Rudolf J Streif
<rudolf.streif@...> wrote:

I am trying to play back mp4 video (venerable Big Buck Bunny at this
time) on RPi3.

I added gstreamer1.0, gstreamer1.0-omx and the plugins to the image.

libgstomx.so is installed in usr/lib/gstreamer-1.0 on target.

However, gst-inspect-1.0 | grep omx does not return any results.

Consequently,

gst-launch-1.0 filesrc
location="/home/root/kiosk/kiosk/videos/bunny.mp4" ! qtdemux ! h264parse
! omxh264dec ! kmssink
WARNING: erroneous pipeline: no element "omxh264dec"

I guess I am missing something somewhere but I don't know what.

are you using userland for graphics or vc4 ?

Thanks,
Rudi

perhaps asking it on https://github.com/linux4sam/u-boot-at91 via
github issues might be helpful too.

On Sun, Nov 22, 2020 at 6:17 PM Michael Callahan
<coder.callahan@...> wrote:

I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where I
am setting a variable from a computed python function. What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION

perhaps mark the task which is using this variable as nostamp.

I am having trouble with sstate caching of my os-release.bbappend and
am stuck. The simple example file looks like something below, where I
am setting a variable from a computed python function. What's the magic
to make the find_version(d) always run but do_compile to only run if
VERSION changes? I basically want something like
`find_version[nostamp]="1"` but that seems to only work for tasks.

def find_version(d):
import subprocess
cmd = "git describe --long"
return subprocess.check_output(cmd).rstrip().decode('utf-8')

VERSION = "${@find_version(d)}"
# do_compile uses $VERSION

while the bitbake user manual insists:

"The use of the ” % ” character is limited in that it only works
directly in front of the .bbappend portion of the append file’s name.
You cannot use the wildcard character in any other location of the
name."

i just ran across this in the meta-security layer:

recipes-kernel/linux/linux-%_5.%.bbappend

what is one supposed to make of that?

rday