<ykrons>
However the SDK complains because when it tries to find watchdog-keepalive-dev it fallbacks on watchdog-dev which depends on watchdog which is in conflict with watchdog-keealive. What's the best approach to get rid of this issue?
<ykrons>
Does adding RDEPENDS_${PN}-dev = "" and RDEPENDS_${PN}-keepalive-dev = "" a good practice?
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
dev1990 has joined #yocto
tnovotny has joined #yocto
adrian__ has joined #yocto
Schlumpf has quit [Quit: Client closed]
adrian_ has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
troth has quit [Ping timeout: 252 seconds]
troth has joined #yocto
chrysh_ is now known as chrysh
troth has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
troth has joined #yocto
zpfvo has joined #yocto
dv_ has quit [Quit: WeeChat 2.8]
zpfvo has quit [Ping timeout: 250 seconds]
Pan5ky has joined #yocto
zpfvo has joined #yocto
florian has joined #yocto
lucaceresoli has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
manuel1985 has joined #yocto
michalkotyla has joined #yocto
kroon_ has joined #yocto
<rburton>
RP: hooray no new vim CVEs
kroon has quit [Ping timeout: 268 seconds]
<michalkotyla>
Hi, i need to remove "-Werror=format-security" flag for specific layer. How can I do that? i tried CXXFLAGS += "-Wnoerror=format-security"
<michalkotyla>
and TARGET_CXXFLAGS:remove = "-Werror=format-security" but this do not work. I see that unexcepted (for me) flag is placed in SECURITY_STRINGFORMAT (poky/meta/conf/distro/include/security_flags.inc) but i didnt see how it is used by CXX
<rburton>
set SECURITY_STRINGFORMAT="" for the recipes that break with that error enabled
<rburton>
TARGET_CFLAGS becomes CFLAGS for target builds, which is then respected in makefilesetc
<rburton>
obviously, the best solution is to fix the bugs, because that error is pointing out buggy code
<rburton>
RP: what happened to build-perf?
<michalkotyla>
rburton: thanky you very much, thats work for me
kroon has joined #yocto
kroon_ has quit [Ping timeout: 240 seconds]
<RP>
rburton: The shallow clones I added to speed up the AB broke it. I've been trying to remove the bad data from the results repo and can't quite fix it :(
<RP>
rburton: They appeared in some of the older release branches but yes, master looks good
<RP>
rburton: I asked Neal to update the members meeting slides due to the decreases :)
leon-anavi has joined #yocto
<wyre>
what's the most proper way to create an empty folder in /var/log for my app logs?
<wyre>
I've used install -d and included the path also in FILE_${PN}
<wyre>
but this is not working because the folder doesn't actually exist
<wyre>
File './var/log/stp16cpc26' cannot be packaged into 'python3-stp16cpc26-api' because its parent directory structure does not exist. One of its parent directories is a symlink whose target directory is not included in the package.
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
tempfiles and volatiles, as /var/log may well be a tmpfs
<wyre>
rburton, then how should I handle this?
<wyre>
rburton, now what you say that ... I've noticed /var/log is already tmpfs
<wyre>
but my point is I would like to create logs in /var/log/<my app folder>
<rburton>
see eg cups has volaties/tempfiles support to create that folder on boot
<wyre>
rburton, in the cups recipe?
<rburton>
yes
<frosteyes>
Hey folks. Is it possible to use old version of autotools in yocto. E.g. to select a specific autotools version.
<rburton>
only if you write a recipe for it
<rburton>
better to fix the configure script
<frosteyes>
Properly yes..
<wyre>
oh, /var/log is a symlink to /var/volatile/log
<wyre>
i see
<frosteyes>
Just had some code not working with autotools 2.71 in Honister
<frosteyes>
So was thinking if it was possible to inherit a specific version :) But properly better to update the configure script
Schlumpf has joined #yocto
<rburton>
we don't keep old versions around, it's easier to just update the configure.in than apply fixes to many different versions
<frosteyes>
thanks rburton :)
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
troth has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
camus has quit [Ping timeout: 268 seconds]
troth has joined #yocto
xmn has joined #yocto
Pan5ky has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
edgarmv has joined #yocto
<wyre>
rburton, when I try to do the very same than cups recipe I'm having this error https://bpa.st/RGVA
<rburton>
thats because sysconfdir is in the default FILES:${PN}
<wyre>
but why am I having that error then?
tgamblin has joined #yocto
<edgarmv>
Hi, I have a recipe which installs some binary files into the rootfs. These binaries are not intended to be run by the target, but by another processor programmed by the target. Is there a way to install this file as-is? (Without checking arch, debug split, stripping etc, DNF)
<wyre>
rburton, oh, apparently I forgot += in FILES:${PN} definition 😞
kroon has quit [Quit: Leaving]
<wyre>
so I was actually overriding FILES:${PN}, I guess
<dvorkindmitry>
why there is no definition of kernel-module-scsi-debug in yocto kernel?
<dvorkindmitry>
(honister)
<rburton>
dvorkindmitry: because your kernel isn't building it, or isn't building it *as a module*. All kernel depends should be recommends.
<edgarmv>
I have made some progress by adding things to INSANE_SKIP_${PN} and adding INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1", but it now fails on "do_rootfs: Could not invoke dnf, Problem: conflicting requests
<edgarmv>
- nothing provides libc.so.6"
<rburton>
dvorkindmitry: ah unless you have a custom kernel recipe which is broken
<coldspark29[m]>
JPEW: THings like devtool edit-recipe don't work in Pyrex, because it tries to open vi in the container, doesn't it?
<JosefHolzmayrThe>
edgarmv: have you looked up the "packagin externally produced" section in the dev-manual?
<rburton>
edgarmv: set EXCLUDE_FROM_SHLIBS iirc. that's likely the automatic "this binary links to these libraries" magic.
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<wyre>
rburton, is there soemthing like ${roothome} for /home/root?
troth has quit [Ping timeout: 250 seconds]
<edgarmv>
rburton, JosefHolzmayrThe: Thanks for the suggestions, but neither worked. It seems yocto still assumes I want to run the binary on the target and is unhappy because of a missing dependency
<JosefHolzmayrThe>
edgarmv: then chances are you got something in the variables name wrong, i'd say. i have shipped a lot of non-target runnable binaries already. maybe inspect by bitbake -e?
troth has joined #yocto
<dvorkindmitry>
rburton, it IS recommended only in two recipes. why honister won't build my recipe at all?
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Pan5ky has joined #yocto
<dvorkindmitry>
where can I find kenel 5.4 for honister?
<JPEW>
coldspark29[m]: I don't use devtool much, when does it open vi?
<JPEW>
Ah edit-recipe... Need more coffee
<coldspark29[m]>
JPEW: devtool edit-recipe
zpfvo has quit [Ping timeout: 260 seconds]
<JPEW>
coldspark29[m]: ya that probably won't work as well; not sure if there is much to do about that other than run it outside the container
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Pan5ky has joined #yocto
<rburton>
dvorkindmitry: the standard kernels provide kernel-module-* so you must be using a custom kernel which doesn't use any of the standard tooling. if so, use the standard tooling (kernel.bbclass)
<manuel1985>
Are the recorded talks of the Yocto Project Summit 2021.11 publically available? If so, I'd be glad if someone could send me a link. Thanks in advance.
<JosefHolzmayrThe>
manuel1985: not yet AFAIK, but hopefully soon.
<manuel1985>
JosefHolzmayrThe: Alrightey thnx
lexano has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<dvorkindmitry>
rburton, it is enabled in kernel only of "DISTRO_FEATURES" includes "ptest".
<dvorkindmitry>
rburton, there ar two recipes "RRECOMMENDS" "kernel-module-scsi-debug", but honister won't build my recipe at all.
sakoman has joined #yocto
<rburton>
dvorkindmitry: do you have a custom kernel, or are you using linux-yocto
<dvorkindmitry>
the chain is: 'gtk+', 'glib-2.0', 'util-linux', 'kernel-module-scsi-debug'. There is no rdepends, only rrecomends for -scsi-debug.
<dvorkindmitry>
rburton, I copied the standart kernel recipe, updated the file name and description only now. that is.
<rburton>
then it should be setting PACKAGES_DYNAMIC=linux-module-*, so is a provider for kernel-module-scsi-debug
jpuhlman has quit [Killed (mercury.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
paulg_ has joined #yocto
lexano has joined #yocto
mariusz has quit [Ping timeout: 256 seconds]
raghavgururajan has quit [Ping timeout: 268 seconds]
Wouter0100 has quit [Ping timeout: 260 seconds]
Wouter0100 has joined #yocto
Tyaku has joined #yocto
<coldspark29[m]>
<JPEW> "coldspark29: ya that probably..." <- I don’t think that is possible as the container would need access to the host, which is a security issue
<JPEW>
coldspark29[m]: Correct; you make it start outside the container in the first place instead of running in the container and trying to break out
Tyaku has left #yocto [#yocto]
<JPEW>
coldspark29[m]: Pyrex has a list of commands it excludes from running in the container; It *might* be possible to exclude all of devtool, or Pyrex would need to learn about specific devtool commands
<wyre>
rburton, I've followed the curl recipe for the /var/log thing ... but I still cannot see the folder in there, this is my recipe http://ix.io/3I8X
<JPEW>
That seems like it's more complicated that we need
<wyre>
in fact 99_python3-stp16cpc26-api file is in /etc/default/volatiles
<wyre>
but how is /var/log/stp16cpc26 created?
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<rburton>
wyre: created on boot. if you're using systemd then you need to use tempfiles, not volatile.
<neverpanic>
"By default the selinux components are disabled. This conforms to the Yocto Project compatible guideline that indicate that simply including a layer should not change the system behavior. "
<neverpanic>
including their layer does (ideally) nothing, you have to enable it in your distro config using DISTRO_FEATURES_append.
<dvorkindmitry>
qschulz, for example, openamp. If I add it - I'll have libs in my SDK. Seems I have no possibility to disable TOOLCHAIN_TARGET_TASK:append in my image if I have no "openamp" layer, but have DISTRO_FEATURE += "openamp" in my distro
<dvorkindmitry>
case openamp is not compatible with honister I'd like to be able to enable it or disable it if directory exists or not (layers.conf). If I'll add extra flags user has to edit, It will be more complicated
<dvorkindmitry>
neverpanic, ok. I have DISTRO_FEATURES:append = "openamp" in my distro conf by default. To be able to run without it I have to create one more distro file with all variables copied? Not good. One central point is layers.conf. I'd like not to annoy users with an instructions like "if you want to enable openamp, you shoul clone it and then edit layers... also do not forget to edit distro file".
pgowda_ has quit [Quit: Connection closed for inactivity]
<neverpanic>
That's the way this usually works. Users clone, add to layers.conf, and edit their distro.conf for the distros where they want to use the feature. E.g., somebody could be building multiple distros from a single source tree (e.g., for different CPU architectures, target devices), and might only want your feature on some of them.
<neverpanic>
If you add your feature to all distros automatically, that prevents users from making this choice. Instead, they now have to explicitly remove your feature in the distros where they don't want it.
<neverpanic>
Better to clearly tell people what they need to do to enable your feature (which also means they'll know how to disable it), rather doing it automagically, IMHO.
<qschulz>
dvorkindmitry: you can include one distro conf file from another
rfuentess has quit [Quit: en la busqueda de la sagrada chela del lunes]
<fray>
ya my combined basis is 112.49 right now..
<fray>
well that was the wrong window
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
<rburton>
khem: fixed srecord. no idea how it worked in the first place )
zpfvo has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
florian has quit [Quit: Ex-Chat]
bps has quit [Ping timeout: 268 seconds]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
manuel1985 has quit [Quit: Leaving]
zpfvo has quit [Remote host closed the connection]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
lexano has quit [Ping timeout: 250 seconds]
Pan5ky has joined #yocto
mckoan is now known as mckoan|away
lexano has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
Pan5ky has quit [Quit: Pan5ky]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
lucaceresoli has quit [Quit: Leaving]
Tokamak has joined #yocto
vladest has joined #yocto
florian has joined #yocto
<khem>
rburton: yes it works here now too, thanks for patch
<khem>
rburton: everything else seems ok with clang too
<rburton>
honestly not sure how srecord built before
<rburton>
more luck than judgement
<tlwoerner>
i'm working on adding zram as an IMAGE_FEATURE. zram needs util-linux-libmount but the build is complaining about depending on something that gets renamed
<tlwoerner>
i need the "mount" that comes with util-linux-libmount
<tlwoerner>
is "libmount" a pseudo "virtual" standin for any "mount" or does it mean the util-linux-libmount one specifically?
<rburton>
maybe paste the actual error?
<rburton>
(what util-linux-libmount)
<rburton>
oh right now i see the split
<rburton>
that's just the libraries and not the mount binary, right?
<khem>
rburton: yeah I dont have a dunfell build handy here but it would be in the libtool file there perhaps it was using native libtool and overriding enough of vars to let it cross compile
<rburton>
maybe, but nothing should have changed...
<khem>
I wonder are libtool scripts same ? before and after
<khem>
autotools-fu is an AI in itself, I am glad its on its way out
grembeter[m] has joined #yocto
leon-anavi has quit [Quit: Leaving]
vd has quit [Quit: Client closed]
vd has joined #yocto
amitk_ has joined #yocto
<vd>
is there an issue with multiple 'inherit foo' lines in a recipe?
amitk has quit [Ping timeout: 250 seconds]
geoffhp has joined #yocto
adrian__ has quit [Quit: Leaving]
kiran_ has quit [Ping timeout: 252 seconds]
mariusz has joined #yocto
<Saur>
vd: Multiple inherit lines should work.
kiran_ has joined #yocto
<vd>
I mean inheriting multiple times the same class
<vd>
as in literally multiple 'inherit foo' lines
<Saur>
It very much depends on what the class actually does, but generally it should be avoided.
<vd>
what is the common practice when "extending" an existing class, should the new class inherit the base class or should the new class assume that the base class will be inherited in the recipe?
<Saur>
It depends a lot on your use case and which class it is. You can make a local class with a new name, that inherits the original class. This is suitable if you only want to use the extended class in your own recipes. An alternative is to make a local wrapper class with the same name as the upstream class. Then let that class require (not inherit) the wrapped class. That way your extensions will be used by all recipes using the class, whet
<Saur>
her they are upstream or local.
<Saur>
You can of course also backport a bbclass file as is to a local layer and modify it. This is suitable if you need to make modifications that cannot be made by extending a class. This of course have the drawback that you will need to keep your local copy in sync with upstream changes.
<vd>
Saur thank you, I didn't know you could require a .bbclass file. That is handy to "append" a class with a temporary patch, similarly to a .bbappend file for a recipe.
<Saur>
Well, require just inserts the contents of another file into whatever file is currently being parsed, so you can use it to insert any recipe, bbclass or other file.
<vd>
makes sense
<vd>
Saur: it makes even more sense to use this mechanism in a meta-patches custom layer to temporarily hold changes before they are applied upstream
<Saur>
That should work.
<vd>
Can you specify conflicts for packagegroups?
<Saur>
How do you mean? Packagegroups are just normal recipes.
<vd>
that means yes?
<Saur>
If you mean RCONFLICT, then yes, it should work.
<dvorkindmitry>
neverpanic, sounds logically! thank you
otavio has quit [Remote host closed the connection]
<vd>
I'm trying to figure out the difference between a packagegroup installed via CORE_IMAGE_EXTRA_INSTALL += "packagegroup-foo" (or e.g. IMAGE_INSTALL:append) and a FEATURE_PACKAGES_foo = "packagegroup-foo" that you install with EXTRA_IMAGE_FEATURES += "foo".
<Saur>
Well, either should work. The latter should be the preferred method though.
<vd>
what is the value added with pure packagegroup image features?
<vd>
(by pure packagegroup feature I mean image feature which do not also add postprocess functions and other tweaks.)
dtometzki has joined #yocto
<Saur>
Well, I guess it is just an extra layer of indirections where you focus on the features you want in your image rather than what packages should be added to it.
GNUmoon has quit [Ping timeout: 276 seconds]
<vd>
Saur but isn't it what package does already? It provides an abstraction for a set of packages adding support for a "feature"
<Saur>
True. But maybe there is only one package when you first introduce a new feature and thus you let FEATURE_PACKAGES_foo point directly at it. Then later when you realize you need to add some more packages to the feature you introduce packagegroup-foo and let FEATURE_PACKAGES_foo point to it instead. Not a major reason to use one over the other, but I know we have done this now and then.
<vd>
I see. But the exact same reasoning goes with a packagegroup which can initially container a single package.
<Saur>
Yes, but that is an extra recipe you don't need if the feature will only ever have one recipe included. ;)
<vd>
Saur but in this case (the example you gave) you could also just add the second package to the FEATURE_PACKAGES_foo. It doesn't have to contain a single packagegroup.
<Saur>
Basically, it comes down to if you want to use IMAGE_INSTALL and/or IMAGE_FEATURES to add packages to your image. In our case we have chosen to go with IMAGE_FEATURES, so we have FEATURE_PACKAGES for everything we may want to include and don't use IMAGE_INSTALL at all.
<vd>
Since conflicts seem to be described in packagegroups as well, the only added value I can see so far for features is the ability to replace a set of features by another with e.g. IMAGE_FEATURES_REPLACES_mysmarterfeature = "common-feature1 common-feature2" or IMAGE_FEATURES_REPLACES_sampleapp = "defaultapp" (even though this might be a preferred
<vd>
provider/version instead).
kroon has joined #yocto
mariusz has quit [Ping timeout: 256 seconds]
<vd>
Saur do you use IMAGE_FEATURES_REPLACES and IMAGE_FEATURES_CONFLICTS?
<Saur>
No.
tnovotny has quit [Quit: Leaving]
<tlwoerner>
rburton: oops, sorry, i didn't catch your replies
<tlwoerner>
actual error:
<tlwoerner>
packagegroup-core-zram-swap-1.0-r1 do_package_write_ipk: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (util-linux-libmount to libmount1)
goliath has quit [Quit: SIGSEGV]
kroon has quit [Quit: Leaving]
florian has quit [Ping timeout: 240 seconds]
<Perceval[m]>
hello all :) I'm trying to bitbake dbus 1.12.12, but I have the following error :
<Perceval[m]>
I tried to bitbake autoconf-archive and autoconf-archive-native first (with success) but I still have th error
<Perceval[m]>
I also tried to use dbus v1.12.20 recipe, but the error is still there
<Perceval[m]>
dbus is using autotool to build. I tried to build it manually (outside bitbake) but I have the same error (and autoconf-archive is installed on my system)
<Perceval[m]>
could you please help me if you have any idea on where it could come from?