<PhoenixMage>
skoink[m]: The is a wic.vmdk image type gets recognised as a vmdk by vmware. I have just realised I am still using qemux86-64 as the machine type and thats probably my problem. Will switch to genericx86-64 but seems I need to create my own kernel config for that as linux-yocto-* does support genericx86-64
amitk has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
RobertBerger has joined #yocto
mcfrisk has joined #yocto
rber|res has quit [Ping timeout: 260 seconds]
OnkelUlla has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
GNUmoon2 has quit [Ping timeout: 258 seconds]
dtometzki has joined #yocto
xmn has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
xmn has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
davidinux has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
thomasd13 has joined #yocto
rob_w has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leon-anavi has joined #yocto
<thomasd13>
Good morning guys
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
goliath has joined #yocto
manuel1985 has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
davidinux has joined #yocto
manuel1985 has quit [Ping timeout: 248 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
* alessioigor
waves all
mvlad has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
zpfvo has joined #yocto
Schlumpf has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
rfuentess has joined #yocto
GNUmoon2 has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<mcfrisk>
sigh, dependencies between recipes which deploy things.. Always so racy and error prone. What's the best way around them? Stop using deploy for any intermediate binary blobs and deploy to e.g. /boot and mangle blobs together from there? Difficulty is then with initramfs things.. Or am I just missing some task level dependencies?
<qschulz>
mcfrisk: what exactly are you trying to do?
<qschulz>
because you can either properly configure your recipes to install in their SYSROOT_DIRS so it's available to other recipes via the DEPENDS mechanism, or explicit the dependency between tasks with do_taskA[depends] += "recipeB:do_taskB"
vladest has joined #yocto
<mcfrisk>
qschulz: recipe tries to take some input files from tmp/deploy to do stuff, and file is not there. I remember this from ages ago when a lot of recipes did this incorrectly and only worked with luck and timing. As you mention, the task depends must be explicitly set for this to work reliably
<mcfrisk>
so should I fix the dependies between do_depends() tasks of various things, or rather fix the recipes to deploy files using paths on the rootfs where normal DEPENDS would be sufficient.
<qschulz>
mcfrisk: if the files exist in recipe's sysroot, please use those
<mcfrisk>
qschulz: they normally don't, e.g. firmware blobs for bootloaders, but then again those maybe should be deployed to /boot so that they can be flashed. some for initramfs'es. that way the dependencies for do_deploy() would not need to be marked down.
florian has joined #yocto
<qschulz>
mcfrisk: installation into /boot is usually image specific, I'd personally go for a dependency on do_deploy tasks
<mcfrisk>
ok, deploy's it is then. no better alternatives..
xmn has quit [Ping timeout: 265 seconds]
ptsneves has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
xmn has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<rfuentess>
But, I have a question with those two sentences: "As part of the final stage of package installation, post installation scripts that are part of the packages are run. Any scripts that fail to run on the build host are run on the target when the target system is first booted."
<rfuentess>
by reading a recipe, how can I determine if a post_process command is going to be executed in the building host or in the target system ?
<qschulz>
rfuentess: you have pkg_postinst and pkg_postinst_ontarget
<qschulz>
the former I assume is documented by what you pasted above
<qschulz>
and the latter is for forcing the script to run at boot and not even attempt at build time
fuzzybear396533 has joined #yocto
<fuzzybear396533>
I have a package (foo) which should comes in two flavors: foo-A and foo-B. I want to conditionally build foo-A or foo-B depending on the build configuration.
zpfvo has quit [Ping timeout: 268 seconds]
<fuzzybear396533>
I was thinking of adding a value (env var) to BB_ENV_EXTRAWHITE at the top-level and consuming that at the recipe level. But, if that works then I only see a way to change the phases (configure, build, install) of the recipe. What I would _like_ to do is conditionally build an entirely separate recipe.
fuzzybear396533 has quit [Quit: Client closed]
fuzzybear396522 has joined #yocto
<rfuentess>
qschulz: ohhh, thanks
falk0n[m] has quit [Quit: You have been kicked for being idle]
<fuzzybear396522>
I dropped connection and I don't have a debouncer set up. Agh.
<fuzzybear396522>
Are there channel logs?
<fuzzybear396522>
Oh, yep.
falk0n[m] has joined #yocto
falk0n[m] has left #yocto [#yocto]
<qschulz>
fuzzybear396522: You're probably after a distro configuration file
<qschulz>
from that, you can modify/select configurations for recipes
<fuzzybear396522>
conf/distro/distro.conf ?
<qschulz>
(you could very much make use of DISTRO_FEATURES for example
<qschulz>
fuzzybear396522: well, your own, but yes, in my-layer/conf/distro/mydistro.conf
<fuzzybear396522>
So, DISTRO_FEATURES would be adjusted by the builder before running Bitbake and the logic for what that determines in terms of package selection would be in mydistro.conf?
<qschulz>
fuzzybear396522: the builder will select the appropriate distro which itself will select a feature that applies to all packages
<qschulz>
s/packages/recipes
<qschulz>
then you adapt your package recipe to make use of this DISTRO_FEATURES (via e.g. PACKAGECONFIG)
<fuzzybear396522>
Is "packages" deprecated in favor of recipes?
<qschulz>
fuzzybear396522: packages are outputs of package recipes
<fuzzybear396522>
Oh, okay. That makes sense. A package is an instance of a recipe (maybe for a given target).
<fuzzybear396522>
Okay, so the PACKAGECONFIG would include the logic for predicating the recipe selection based on the DISTRO_FEATURES values?
<qschulz>
fuzzybear396522: well, you can only build the recipe once, and this can (usually) generate multiple packages
<qschulz>
fuzzybear396522: no, you would have both "flavours" in the same recipe
<qschulz>
a recipe can be pretty complex, but if it's building the same exact same source, just with different compile time options, then it's meant to be put in the same recipe
<qschulz>
however, you *could* also make use of virtual recipes
<qschulz>
(PROVIDES mechanism)
<fuzzybear396522>
It's actually a bit more complicated.
<qschulz>
where you would have two recipes, one called recipe-flavora and recipe-flavorb both providing PROVIDES = "recipe"
<fuzzybear396522>
Oh, that sounds like the right solution.
<qschulz>
then have your distro configuration file set PREFERRED_PROVIDER_recipe = "recipe-flavora"
<qschulz>
but that's usually used for actual different sw providing the same features
<fuzzybear396522>
Allow me to explain a bit more in detail, because I believe PREFERRED_PROVIDER and PROVIDES (virtual recipes) is the best approach for me.
<qschulz>
think openssh vs dropbear
<qschulz>
or openssl vs libressl
<fuzzybear396522>
qschulz That's what I need, I believe.
zpfvo has joined #yocto
<fuzzybear396522>
Concretely, `foo-a` is a custom fork of OpenSSL without certain features enabled. `foo-b` is that custom fork with certain features enabled which requires a different unpack phase (a subdirectory of the source needs to be untarred and compiled before `foo-b` is compiled) and a different config phase.
<fuzzybear396522>
`foo-b` would then be provided as a build-time dependency to another recipe (a language compiler) which would actually need different source (a fork of the language compiler) if `foo-b` is used instead of `foo-a`.
<qschulz>
fuzzybear396522: the last one is an issue
<fuzzybear396522>
So, since the source and a number of core phases of the recipe are changing if `foo-b` is required instead of `foo-a` and since downstream dependencies would require different sources if `foo-b` is selected instead of `foo-a` I think that DISTRO_FEATURES and virtual recipes is a better fit for my problem
<qschulz>
fuzzybear396522: you'll likely need a PREFERRED_PROVIDER for your language-compiler
<qschulz>
because it won't know which recipe is taken when you add DEPENDS = foo to your language-compiler recipe
<fuzzybear396522>
Okay, so I would have two recipes for the language compiler (compiler-a and compiler-b) matching each of the OpenSSL recipes (foo-a and foo-b)?
<qschulz>
you could maybe read PREFERRED_PROVIDER_foo from your language-compiler recipe, but there's no guarantee it is set
<fuzzybear396522>
Each recipe would specify their own PREFERRED_PROVIDER?
<qschulz>
(I mean, Bitbake does not guarantee it)
<qschulz>
fuzzybear396522: PREFERRED_PROVIDER is on the global context, so it needs to be set in a configuration file
<fuzzybear396522>
Like in local.conf you mean?
<qschulz>
local.conf is not meant to be put under version control, so more like a distro configuration file
<fuzzybear396522>
Okay, but how would I select for foo-a vs. foo-b at build time? Would I use DISTRO_FEATURES to set a value for PREFERRED_PROVIDER_foo = "foo-a" or PREFERRED_PROVIDER_foo = "foo-b" ?
<qschulz>
fuzzybear396522: you can forget about DISTRO_FEATURES and only use PREFERRED_PROVIDER_foo in your distro.conf
<qschulz>
you'll need two distros of course
<qschulz>
one for foo-a, one for foo-b
<qschulz>
and for foo-a distro, also set the preferred provider for language-compiler-for-foo-a
<fuzzybear396522>
Oh, I see.
<fuzzybear396522>
So, I'd be manually selecting the dependency tree, effectively.
<fuzzybear396522>
At the top level I'd be specifying foo-a and compiler-a or foo-b and compiler-b .
<qschulz>
that's what I have in mind yes
<fuzzybear396522>
Okay, can you recommend an elegant way to specify the "a" branch vs. the "b" branch for the distro build?
<fuzzybear396522>
It's awkward to specify both recipes in this way (I'm thinking about the future if foo-a is a dependency of baz-a and qux-a).
<qschulz>
fuzzybear396522: if you have two recipes foo-a and foo-b, you already know which flavor the recipe is supposed to build, so just pass ;branch=a to your git SRC_URI?
<fuzzybear396522>
It's not a different branch of the same repo, though. It's different repo.
<qschulz>
fuzzybear396522: well, I would use DISTRO_FEATURES or distro overrides instead, and only have one recipe for each
<qschulz>
fuzzybear396522: ah, misunderstood your use of "branch"
<fuzzybear396522>
Sorry, yeah. "branch" in the build tree sense, not git sense.
<qschulz>
fuzzybear396522: this does not scale well honestly
<qschulz>
it might make sense to still go with DISTRO_FEATURES or something like that mechanism
<qschulz>
you also have the distro overrides mechanism
<qschulz>
so e.g. SRC_URI:distro-flavor-a = "git://source-foo-flavor-a" SRC_URI:distro-flavor-b = "git://source-foo-flavor-b"
<fuzzybear396522>
What doesn't scale well? Conditionally swapping out git sources for branches of the build tree depending on top-level config?
<qschulz>
fuzzybear396522: creating a recipe per flavor
<fuzzybear396522>
Oh, I didn't know about that feature of SRC_URI
<qschulz>
fuzzybear396522: it's not SRC_URI specific, you can have it for any variable or task
<fuzzybear396522>
qschulz I thought a recipe was locked to a particular repository/directory tree.
<qschulz>
FOO:distro-flavor-a, or do_compile:distro-flavor-a
<fuzzybear396522>
Oh, brilliant!
<fuzzybear396522>
Then I think that will do nicely.
<fuzzybear396522>
That keeps everything in the same recipe.
<fuzzybear396522>
It'll get a little hairy with large numbers of distro flavors.
<fuzzybear396522>
Is there a way that I could do something like foo-flavor-a.inc and foo-flavor-b.inc which include their own do_compile and do_unpack and conditionally require them?
<qschulz>
(I think, never used it but it's possible in some ways)
<fuzzybear396522>
That's supposed to be a smiling face with a single tear. Renders weirdly on Libera WebChat (as laughing emoji).
<fuzzybear396522>
Okay, I'll give this all a try. Thanks qschulz for the brain dump!
<qschulz>
fuzzybear396522: does not render on IRC so fine :)
<qschulz>
fuzzybear396522: cheers, let us know how it went :)
<fuzzybear396522>
:pray:
<fuzzybear396522>
qschulz I'll definitely circle back around.
<qschulz>
ah, this one emoji's broken :)
<qschulz>
(on my side, not the first time I have some broken)
<fuzzybear396522>
Actually, qschulz I'm back with a related question. Both foo-a and foo-b use the same source code (call it foo). foo-a can be compiled without much complication (1. extract foo, 2. configure foo-a, 3. make, 4. make install). However, foo-b requires an awkward extra set of steps because foo itself contains a module (call it module-b) which needs to
<fuzzybear396522>
be compiled before foo-b can be compiled. So, foo-b's build looks like (1. extract foo-b, 2. extract module-b (located at foo-b/sub/dir), 3. configure module-b, 4. make module-b, 5. make install module-b, 6. configure foo-b (pointing to the install directory of make install module-b), 7. make, 8. make install). I would _like_ to break module-b into
<fuzzybear396522>
a separate recipe, since it's actually a separate set of dynamic libraries, man pages, and executables and it would be great to be able to bitbake -c compile module-b. But, strictly speaking, a separate recipe wouldn't be required since module-b isn't used for anything except for foo-b.
<fuzzybear396522>
The simplest way would be to branch the unpack, configure, and build phases depending on the DISTRO_FEATURE for foo-a vs. foo-b and do all of this in the foo recipe.
<fuzzybear396522>
The "best" way would be to conditionally build another recipe (module-b) in the case that DISTRO_FEATURE specifies that foo-b should be built.
<qschulz>
fuzzybear396522: I would go with a separate recipe
<fuzzybear396522>
Do you know of a way to accomplish the "best" way?
<fuzzybear396522>
qschulz separate for module-b, right? Not foo.
<qschulz>
fuzzybear396522: I would have a module-b recipe, and foo-b DEPENDS on module-b recipe
<fuzzybear396522>
I guess you mean DEPENDS:append:distro-flavor-b = "module-b"
<qschulz>
yes
<qschulz>
fuzzybear396522: if the repo where the sources are is huge, you might take benefit from using a shared-source mechanism but I've never used it so can't guide you on that
<fuzzybear396522>
So, a distro override on DEPENDS. Do I have that right?
<fuzzybear396522>
No, they're very smalll.
<fuzzybear396522>
s/smalll/small
<qschulz>
fuzzybear396522: a distro override on a DEPENDS:append
<fuzzybear396522>
True. Don't want it overwriting DEPENDS.
<fuzzybear396522>
Okay, and this would allow me to `bitbake -c module-b` and run my tests. Yay!
<qschulz>
(pretty sure there's a better way to do it, look into poky for recipes using DISTRO_FEATURES
<fuzzybear396522>
Okay, deal.
<qschulz>
DEPENDS += *
khem has quit [Quit: Bridge terminating on SIGTERM]
zyga[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
cperon has quit [Quit: Bridge terminating on SIGTERM]
NicoMller[m] has quit [Quit: Bridge terminating on SIGTERM]
jackos888[m] has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
Salamandar has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX[m] has quit [Quit: Bridge terminating on SIGTERM]
majoribanksaud[m has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
DavidM[m] has quit [Quit: Bridge terminating on SIGTERM]
GuilhemArvilMari has quit [Quit: Bridge terminating on SIGTERM]
thierryE[m] has quit [Quit: Bridge terminating on SIGTERM]
eirikb[m] has quit [Quit: Bridge terminating on SIGTERM]
jclsn[m] has quit [Quit: Bridge terminating on SIGTERM]
skoink[m] has quit [Quit: Bridge terminating on SIGTERM]
mrybczyn[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
lrusak[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
simpat2022[m] has quit [Quit: Bridge terminating on SIGTERM]
arlort[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
apprehend3108[m] has quit [Quit: Bridge terminating on SIGTERM]
static_rocket has quit [Quit: Bridge terminating on SIGTERM]
ThomasRoos[m] has quit [Quit: Bridge terminating on SIGTERM]
Perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
kmaincent[m] has quit [Quit: Bridge terminating on SIGTERM]
kiwi_29_[m] has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
alvaropg[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
jarvis-owl[m] has quit [Quit: Bridge terminating on SIGTERM]
MichaelNazzareno has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
gstinocher[m] has quit [Quit: Bridge terminating on SIGTERM]
jaskij[m] has quit [Quit: Bridge terminating on SIGTERM]
pidge[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
<RP>
qschulz: wouldn't distro overrides work better?
<RP>
DEPENDS:append:distro-b = " module-b"
<qschulz>
RP: I suggested that a few lines above :)
<qschulz>
RP: does not scale very well though, if you have more than one distro
<qschulz>
or you add a common string to DISTROOVERRIDES too
<qschulz>
too many ways of doing it :)
dwagenk has joined #yocto
<RP>
qschulz: ah, yes, sorry. I did skim the scrollback but clearly not well!
zyga[m] has joined #yocto
Salamandar has joined #yocto
Alban[m] has joined #yocto
khem has joined #yocto
shoragan[m] has joined #yocto
barath has joined #yocto
jclsn[m] has joined #yocto
static_rocket has joined #yocto
patersonc[m] has joined #yocto
ericson2314 has joined #yocto
Tartarus has joined #yocto
lrusak[m] has joined #yocto
jordemort has joined #yocto
agherzan has joined #yocto
Saur[m] has joined #yocto
mrybczyn[m] has joined #yocto
T_UNIX[m] has joined #yocto
gstinocher[m] has joined #yocto
jackos888[m] has joined #yocto
<qschulz>
RP: I talk too much, hard to not miss some stuff :)
thierryE[m] has joined #yocto
ThomasRoos[m] has joined #yocto
berton[m] has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
Perceval[m] has joined #yocto
kayterina[m] has joined #yocto
kiwi_29_[m] has joined #yocto
apprehend3108[m] has joined #yocto
NicoMller[m] has joined #yocto
simpat2022[m] has joined #yocto
DavidM[m] has joined #yocto
alvaropg[m] has joined #yocto
kmaincent[m] has joined #yocto
jaskij[m] has joined #yocto
cperon has joined #yocto
GuilhemArvilMari has joined #yocto
alessioigor has quit [Quit: alessioigor]
jarvis-owl[m] has joined #yocto
alessioigor has joined #yocto
hmw[m] has joined #yocto
eirikb[m] has joined #yocto
majoribanksaud[m has joined #yocto
pidge[m] has joined #yocto
fabatera[m] has joined #yocto
PascalBach[m] has joined #yocto
arlort[m] has joined #yocto
MichaelNazzareno has joined #yocto
<rfuentess>
another rookie question. If I'm playing with ROOTFS_POSTPROCESS_COMMAND or with appendix to do_rootfs(). In theory I could add extra files and directories to the final image. Right? And `${IMAGE_ROOTFS}/` would be the equivalent to the root directory for the final filesystem
skoink[m] has joined #yocto
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #yocto
<rfuentess>
oh, I'm seeing my code in action :) . I was only requiring to run `-c clean` instead of only `-c rootfs`
<mcfrisk>
rfuentess: yes, you can check how the scripts, tasks and variables get called from "bitbake -e image" output
<qschulz>
rfuentess: depending on the files and directories, it might make sense to create a recipe just for those
zpfvo has joined #yocto
kanavin has quit [Remote host closed the connection]
paowz has quit [Ping timeout: 248 seconds]
fuzzybear396522 has quit [Quit: Ping timeout (120 seconds)]
zpfvo has quit [Ping timeout: 248 seconds]
zpfvo has joined #yocto
kanavin has joined #yocto
alessioigor has quit [Quit: alessioigor]
zkrx has quit []
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
paowz has joined #yocto
zkrx has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
barometz has quit [Ping timeout: 265 seconds]
barometz has joined #yocto
<manuel1985>
Can I remove a package from IMAGE_INSTALL if it got pulled in through a packagegroup?
formy84 has joined #yocto
<formy84>
sera
zpfvo has quit [Ping timeout: 268 seconds]
<ptsneves>
manuel1985: no. The package group is a package in it's own right, which installs the packages of the group through RDEPENDS
<landgraf>
manuel1985:it will cause broken dependencies on dnf level I think.
<landgraf>
manuel1985: drop it from the packagegroup deps using bbappend maybe?
zpfvo has joined #yocto
<ptsneves>
landgraf: would be the most straightforward way
formy84 has quit [Quit: formy84]
<manuel1985>
landgraf: That sounds good, thanks
<rburton>
RP: forgot to put a v2 on the patches, but two new dnf/qa patches are on the list now
<RP>
rburton: thanks, those look safer
d-s-e has joined #yocto
otavio has joined #yocto
GNUmoon2 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
ecdhe has quit [Ping timeout: 246 seconds]
GNUmoon2 has joined #yocto
ecdhe has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
sef has joined #yocto
<sef>
im looking for the libedgetpu(>1.0) recipe for imx, but i couldnt find it. anyone know where i can find it?
grma has quit [Ping timeout: 250 seconds]
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
Guest64 has joined #yocto
Guest64 has quit [Client Quit]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
sakoman has joined #yocto
<rburton>
sef: layer index says there isn't one
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<sef>
rburton thank you
<rfuentess>
qschulz: thanks for all the help. I was able to achieve my goals
<qschulz>
michaelo: a few referecnes missing in overview-manual/concepts.rst too BTW
<rfuentess>
(and understand much better all the chaos we have in our current recipes)
<qschulz>
rfuentess: nice :)
zpfvo has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
grma has joined #yocto
zpfvo has joined #yocto
sef has quit [Quit: Client closed]
cmd has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
NP9 has joined #yocto
rob_w has quit [Remote host closed the connection]
d-s-e has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
kscherer has joined #yocto
<NP9>
does someone know when the DEPLOY_DIR_IMAGE directory is created? it seems I've got a cve_check_write_rootfs_manifest that (sometimes) fails, seemingly when the directory does not exist yet
grma has quit [Ping timeout: 248 seconds]
thomasd13 has quit [Ping timeout: 252 seconds]
Schlumpf has quit [Quit: Client closed]
GNUmoon2 has quit [Remote host closed the connection]
Piraty has quit [Quit: -]
Piraty has joined #yocto
Piraty has quit [Client Quit]
Piraty has joined #yocto
Piraty has quit [Client Quit]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Piraty has joined #yocto
Piraty has quit [Client Quit]
manuel1985 has quit [Ping timeout: 265 seconds]
Piraty has joined #yocto
NP9 has quit [Quit: Client closed]
dev1990 has joined #yocto
zpfvo has quit [Quit: Leaving.]
sef has joined #yocto
rfuentess has quit [Remote host closed the connection]
<sef>
im trying to build a cpp base project and need to use the flatbuffer. i have linker problem even though i have successfully build flatbuffer. when i checked build files, i cant see any problem. what could it be caused by?
<sef>
im new to yocto so i might post something missing or wrong. sorry about that.
<rburton>
sef: using the meta-oe flatbuffers recipe?
<sef>
yes, 1.12.0.bb
mckoan is now known as mckoan|away
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rburton>
i'm guessing you need to actually search for the path to the library in your build files, whatever they are
<sef>
thanks for the idea
<rburton>
the docs say there's just a header file and no library , so <shrug>
vladest has quit [Ping timeout: 268 seconds]
<sef>
the build file has both libflatbuffers.a and libflatbuffers.so. i couldn't understand how it says no library in the documentation.
<sef>
i have to leave now but i left chat open so I can read your reply later. thanks in advance.
alessioigor has quit [Quit: alessioigor]
goliath has quit [Quit: SIGSEGV]
rabbi[11] has joined #yocto
<fabatera[m]>
In Honister, when the fetcher fails to find the mirrored source compressed file, it breaks the build with error "unable to fetch URL from any source".
<fabatera[m]>
In previous versions it proceeds to fetch sources from the git repo.
<fabatera[m]>
How to get the same in Honister?
<rabbi[11]>
I have two recipes one is meta-abc and other is meta-xyz, under meta-abc I have recipes-core/images/abc-image-initramfs-debug.bb (in here I have PACKAGE_INSTALL += test_123) and under meta-xyz I have recipes-core/images/abc-image-initramfs-debug.bbappend. I want test_123 to not compile and build so in the .bbappend I have done this
<rabbi[11]>
IMAGE_INSTALL:remove += test_123 and also tried PACKAGE_REMOVE but both didn’t work. I can’t change .bb file. Suggestions?
ecdhe has quit [Ping timeout: 252 seconds]
ecdhe has joined #yocto
<mischief>
rabbi[11]: did you check bitbake -e output for the recipe? it will list all variables and where they are modified.
<rabbi[11]>
mischief: let me check
geoffhp has quit [Ping timeout: 265 seconds]
zkrx has quit []
goliath has joined #yocto
zkrx has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<rabbi[11]>
mischief: in the image install I don't see it being there but I can still see it is getting compiled
<fabatera[m]>
you should use IMAGE_INSTALL instead of PACKAGE_INSTALL
<rabbi[11]>
fabatera[m]: you mean for removing? In the .bb PACKAGE_INSTALL is being used. BTW I tried IMAGE_INSTALL:remove = test_123
<fabatera[m]>
forget it, just saw it's recomended in the manual
paulg_ has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<fabatera[m]>
but I would try PACKAGE_INSTALL:remove .. just guessing
grma has joined #yocto
<rabbi[11]>
tried that and didn't work.
<fullstop>
Hi, I'm running low on space on my build server. Until I get that addressed I'd like to potentially clean up some bitbake stuff for resources which are already built and won't be changing for the time being.
<fullstop>
Is there an easy way to clean up sysroots?
<fullstop>
recipe-sysroot-native is identical for all of them and consumes ~400MiB per recipe.
<fullstop>
s/identical/nearly identical/
<fabatera[m]>
<rabbi[11]> "tried that and didn't work." <- Looks like it's in xyz DEPENDS
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
mvlad has quit [Remote host closed the connection]
florian_kc has joined #yocto
<rabbi[11]>
fabatera[m]: xyz has depends on the abc and abc has that package_install which I am trying to remove in xyz bbappend.
<fabatera[m]>
so , it's compiling because it's in DEPENDS.
zkrx has quit []
<rabbi[11]>
fabatera[m]: so yocto has no way to fix this or some workaround?
<fabatera[m]>
you are telling that xyz needs abc to build. So it builds abc. Need to search how to remove from DEPENDS
zkrx has joined #yocto
<fabatera[m]>
DEPENDS_xyz_remove = "abc"
<rabbi[11]>
let me try this...
<rabbi[11]>
DEPENDS_xyz_remove = "test_123" you meant i guesss
<fabatera[m]>
yes, use thefull nbame for both xyz and abc
zkrx has quit []
<rabbi[11]>
fabatera[m]: tried this DEPENDS_meta-xyz:remove="meta-abc:test_123" but it didn't work.
zkrx has joined #yocto
geoffhp has joined #yocto
leon-anavi has quit [Ping timeout: 252 seconds]
sef has quit [Quit: Client closed]
leon-anavi has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
kevinrowland has quit [Quit: Client closed]
amitk has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
odra_ has joined #yocto
odra has quit [Read error: Connection reset by peer]
leon-anavi has quit [Ping timeout: 244 seconds]
goliath has joined #yocto
paulg_ has quit [Quit: Leaving]
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
vladest has joined #yocto
kscherer has quit [Quit: Konversation terminated!]