<zeddii>
this is why you have a licencing issue if you let go fetch for you
<Saur[m]>
That's insane.
<zeddii>
I'll try hacking in the shallow clone option and see how much it speeds up.
<Saur[m]>
I guess you don't have all of those in SRCREV_FORMAT? Would make for a veeeeeery long revision string...
<zeddii>
hah. no, just the k3s main one, and the major secondary one.
* RP
-> sleep
Starfoxxes has quit [Ping timeout: 240 seconds]
Starfoxxes has joined #yocto
sakoman has quit [Quit: Leaving.]
olani has quit [Ping timeout: 256 seconds]
olani has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
Tokamak_ has quit [Ping timeout: 240 seconds]
pasherring has quit [Read error: Connection reset by peer]
pasherring has joined #yocto
Tokamak has joined #yocto
leon-anavi has quit [Quit: Leaving]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 250 seconds]
amitk has joined #yocto
osama2 has joined #yocto
osama1 has quit [Read error: Connection reset by peer]
jclsn79 has joined #yocto
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn79 is now known as jclsn7
pgowda_ has joined #yocto
Guest25 has joined #yocto
Guest96 has joined #yocto
Guest25 has quit [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Wouter0100 has quit [Ping timeout: 272 seconds]
Wouter0100 has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
Guest96 has quit [Quit: Ping timeout (120 seconds)]
xmn has quit [Ping timeout: 256 seconds]
rfuentess has joined #yocto
thekappe has joined #yocto
<thekappe>
Hello guys, I've a question. I wan to ship "openssl" in a yocto image. I've addded RDEPENDS_${PN} = "openssl" to the recipe of a package that requires openssl being installed. This package is adedd to the list of packages required for the image. By the way the openssl binary is not available. Any hint ?
mvlad has joined #yocto
mvlad_ has joined #yocto
mvlad_ has quit [Client Quit]
Schlumpf has joined #yocto
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
<jclsn[m]>
Morning
<jclsn[m]>
Any tips on how to debug why the weston.service fails?
<jclsn[m]>
`systemctl status weston` does not give any useful information
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
vladest has joined #yocto
<landgraf>
jclsn[m]: You can edit service file to run weston under strace (and save logs somewhere). like prepend with strace -o/tmp/weston.out [original weston command]
rob_w has quit [Remote host closed the connection]
<qschulz>
thekappe: very likely openssl-bin package. You can check with oe-pkgdata-util find-path '*openssl*' to find which package isntalls the file you're after
<thekappe>
qschulz: thanks
Spectrejan[m] has quit [Quit: You have been kicked for being idle]
FredericOuellet[ has quit [Quit: You have been kicked for being idle]
<kanavin>
moto-timo, RP: do you need help with python things?
prabhakarlad has joined #yocto
Guest86 has joined #yocto
<RP>
kanavin: Yesterday, yes. I think after the changes last night we might be just about there though, at least for the core changes, thanks
<dwagenk>
jclsn[m]: weston has it's own log somewhere.
<dwagenk>
at least on sysVInit systems. I'll deal with a project involbing weston later today, so I can look up the path
<dwagenk>
<thekappe> "Hello guys, I've a question. I..." <- since openssl is also a lib it's possible you need to install/RDEPEND on openssl-bin
<dwagenk>
<jclsn[m]> "https://pastebin.com/HjZ9R9zf" <- Dunfell build, nothing special, systemd, without changing the weston config I also get `/var/log/weston.log` on the running system.
<dwagenk>
Last line of `/usr/bin/weston-start` is this: `exec openvt $openvt_args -- $launcher $weston_args --log=/var/log/weston.log`
<landgraf>
dwagenk: looks like weston doesn't start at all and fails on earlier stage (without logs). strace should answer this question
<landgraf>
or maybe some preinit stuff unable to start
<RP>
landgraf: oh, that is rather annoying :(
<RP>
landgraf: I'm fairly sure what I did was run oe-selftest on the autobuilder with BB_SERVER_TIMEOUT=60 or something like that
<RP>
landgraf: question was why that caused failures, it shouldn't have
<landgraf>
RP is it reproducible localy?
<RP>
landgraf: should be but oe-selftest takes a long time :/
<landgraf>
RP: I know... will see
<landgraf>
there're some failures already
<RP>
landgraf: I'll see if I can run this on the AB quickly now
Schlumpf has quit [Ping timeout: 256 seconds]
<RP>
landgraf: scheduled, we're short on workers so it isn't running yet
<landgraf>
at least it will heat up my house a bit :)
<RP>
landgraf: Build servers do help with that! :D
<landgraf>
RP: gentoo does as well :)
goliath has quit [Quit: SIGSEGV]
pgowda_ has quit [Quit: Connection closed for inactivity]
<rburton>
khem: is there an explanation as to why all the layers in meta-oe have different priorities, or is it just historical. personally I'd say a layer having a priority different to core needs to have *very strong* justification.
<rburton>
as it entirely overrides other layers
<rburton>
eg the py-wheel thing
<turquoisetree>
I couldn't find anything about include files. So, what is an include file? How does it differ from a recipe file?
<rburton>
an include file isn't anything special, it's just a file which is included during a recipe parse
<rburton>
recipe says require foo.inc, foo.inc is parsed at that point
<Saur[m]>
rburton: Isn't that the point with the layer priorities, to know deterministically which order recipes are used. How will I otherwise know which variant of a recipe is used, if the layers it exists in have the same priorities?
<turquoisetree>
rburton: I see, can an include file specifiy tasks, so that a recipe could build on them?
<RP>
LetoThe2nd: multiverse would include all multiconfigs?
<RP>
we should do that :)
<JaMa>
LetoThe2nd: don't even start with multiverse, it's only couple characters away from metaverse :)
<LetoThe2nd>
RP: count me in!
<RP>
JaMa: metaverse needs to be a recipe in the meta-meta layer
<JaMa>
it will be terrible when meta joins yocto project
<JaMa>
but at least people will forget about naming confusion caused by poky :)
<RP>
JaMa: it already did
<JaMa>
oh :)
<landgraf>
RP: Thanks for the logs
otavio has quit [Read error: Connection reset by peer]
<RP>
landgraf: there should be more, that was just the first to complete
* RP
worries that the autobuilder can't connect to downloads.yoctoproject.org intermittently. Guess we wait and see what the datacentre move does now
tnovotny has quit [Quit: Leaving]
thekappe has quit [Quit: Client closed]
osama2 has joined #yocto
osama3 has joined #yocto
osama2 has quit [Ping timeout: 240 seconds]
turquoisetree has joined #yocto
<pasherring>
Hey there! I am trying to debug an issue with device trees. If I got it right, it would be better to do it with devtool.
<pasherring>
But, after changing a dts file on the workspace, and running devtool build <rn>, the dtb files aren't recompiled.
<pasherring>
I am clearly doing something wrong here, because right now, I run devtool build --clean <rn>, and then a new build command
<pasherring>
Any one care to share how to do it efficiently? :)
<kanavin>
RP: it probably does, but hopefully only once when the commit is pulled in?
<RP>
rburton: I've just merged python-wheel into core. I didn't take much of the other python stuff yet
<RP>
kanavin: you have to wipe tmpdir and start again. People don't expect this and the weird sstate build errors will confuse people :(
<RP>
kanavin: we don't often force people to wipe tmpdir
<RP>
kanavin: I think this is why I never made that particular change :(
<kanavin>
RP: I'm fine if this goes in post-LTS, but I don't think you can have both binutils-cross-x86 and binutils-cross-arm in a sysroot any other way :-/
<RP>
kanavin: I'm not saying the change is wrong. I'm saying it breaks things for users trying upgrade paths so we'd have to think more about how to handle migration paths
<RP>
kanavin: we have a load of code designed to migrate TMPDIR to new changes. sstate and all of it's uninstall functionality handles most of that now but you're changing the sstate code so it can't help
<kanavin>
RP: maybe add a specific advice to wipe tmp/ to the error that's going to happen? not ideal, but better than a completely cryptic error
<RP>
kanavin: the migration code is sanity_handle_abichanges in sanity.bbclass
* RP
remembers there are open bugs against that code
<RP>
kanavin: I think that code could probably uninstall the cross manifests and update the tmpdir abi
<RP>
kanavin: the error is https://paste.debian.net/1232219/ but could be in gcc-stahed-builddir or gcc-cross or some other cross recipe
<RP>
ignore the first two systemd lines there, that is something else
<RP>
there are many more lines to it but that gives the idea
<RP>
kanavin: now I think about this more, I'm also worried about whether we have any cross recipes left which don't have TARGET_ARCH in PN?
<RP>
A quick check says we're ok since libtool-cross doesn't inherit cross
Guest53 has joined #yocto
<RP>
kanavin: FWIW the reason this sstate code was like this is that the cross recipes used to install into the target workdir and didn't have the arch in the PN
<kanavin>
RP: I checked from the other direction, what does inherit cross - I think it's just binutils/gcc/gdb/go/rust
<RP>
kanavin: you are picking up where I left of with some of this, it is just taking me a bit of paging back in :/
<kanavin>
RP: so what would be the right way to uninstall manifests?
<RP>
kanavin: have a look at sstate_eventhandler_reachablestamps
<RP>
kanavin: we'd need to call sstate_clean_manifest() on all the cross manifests which were no longer correct
dixtater has quit [Quit: Client closed]
<RP>
kanavin: I'm thinking a custom version of something like that function in the sanity abihandler codepath
<RP>
kanavin: I mention that function just as it shows how to iterate manifests and clean them
jmiehe has joined #yocto
<kanavin>
RP: thanks, I can look into it
<jclsn[m]>
Is 5.14.x+fslc not used yet or deprecated? The last commit is from November. I thought this was the latest kernel to use
<jclsn[m]>
On 5.10.x+fslc the last commit is from February. Weird
<agherzan>
Did the time of bitbake.conf parsing change from dunfell?
<agherzan>
A ?= definition in a distro file now is not taken into account under master.
<RP>
agherzan: no, it didn't
<agherzan>
RP: was it always the case that bitbake.conf was parsed before the distro configuration?
sakoman has joined #yocto
<rburton>
bitbake.conf is parsed first, always
<moto-timo>
RP: did the reproducible jobs pass?
<agherzan>
That was what I always knew too. But somehow I get a strange behavior now.
osama3 has quit [Read error: Connection reset by peer]
turquoisetree has joined #yocto
Guest53 has quit [Quit: Client closed]
Etheryon has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prabhakarlad has joined #yocto
akiCA has joined #yocto
<RP>
moto-timo: yes
<moto-timo>
\o/
<moto-timo>
My local run must have had some wonky sstate
* moto-timo
was changing a lot of things
<RP>
agherzan: yes, has always been the case
<RP>
agherzan: you can see the includes at the end of bitbake.conf, that is unchanged since forever :)
tre has quit [Remote host closed the connection]
<agherzan>
I'll dig deeper
<RP>
moto-timo: Decision made, merged
codavi has joined #yocto
<moto-timo>
RP: let the hate mail begin
<moto-timo>
RP: thank you for all the hardwork yesterday
akiCA has quit [Ping timeout: 256 seconds]
olani has joined #yocto
<RP>
sgw: I'm guessing there will be a v2 of the INCOMPATIBLE_LICENSE_EXCEPTIONS change?
<sgw>
RP: morning, just got in.
<RP>
sgw: I noticed we probably need to change LGPL-3.0 -> LGPL-3.0-only in your patch too
<sgw>
I see I fubar'ed the license.py patch (sorry)
<RP>
sgw: also, execption -> exception
<RP>
sgw: I've fixed that one. I meant to squash the fix but failed but I did merge it
goliath has quit [Quit: SIGSEGV]
<agherzan>
RP: I have found the issue. TCLIBC is was now moved to `bitbake.conf` when it was in `defaultsetup.conf` before. This has the side effect that a assignment in bitbake.conf will be picked as opposed to one in the distro file when using a weak assignment.
<agherzan>
To be more specific a distro file that includes `defaultsetup.conf` + `TCLIBC ?= "musl"` will not work anymore.
<rfs613>
rburton: morning! It looks like "cve-check: get_cve_info should open the database read-only" got merged in master, but not the revert of "cve-check: add lockfile to task"... or are my eyes tricking me?
<RP>
rfs613: I was going to ask rburton what the plan is with the other patch. I suspect he will say he thinks it should also go in
<rfs613>
I was about to ask if I should send a "tested-by" or similar... IMHO they should both go in, and into the older branches, ASAP.
<RP>
agherzan: this is the challenge with our rather problematic variable defaults syntaxes :(
<agherzan>
Indeed.
<rfs613>
RP: Anyone who keeps their DL_DIR on a NFS share will see some pretty horrendous slowdown due to the lockfile... like a 2 hour build taking 2 days...
<agherzan>
At its core, the issue was that when it was moved, it was moved before including the distro conf. To keep the same behavior, it should have been included afterwards.
<agherzan>
I'm wondering if that was intentional by any chance.
<agherzan>
JaMa: might know ^
<agherzan>
I can push a simple fix if this was not intended.
<moto-timo>
the setuptoobl3.bbclass needs to be held off (I'm almost done) but the pip_install_wheel one should be ok?
<RP>
moto-timo: I thought you meant hold that series
<moto-timo>
and yes I can see why it was confusing... my bad...
<RP>
moto-timo: I've merged it to master without test. Lets hope that doesn't break anything
<moto-timo>
I promise to fix it if it does break
xmn has joined #yocto
<smurray>
jclsn[m]: from looking at meta-freescale, I'd guess the effort moved to 5.15.x+fslc, which is a better choice anyways since that kernel's LTS
<kergoth>
RP: did anything ever come of your experimentations with the bitbake operators and laziness and all, before you rolled out the overrides syntax change? i remember you experimenting
<RP>
kanavin: remove your patch, bitbake bash, add your patch, keep the same tmpdir ?
<RP>
kergoth: nothing certain. I ran into a ton of problems in the data store as it was all too magic. The first was knowing what was an actual override. That is now solved. The second was the wide selection of weird variables we supported, like :append += "x". That is also now cleaned up
florian has quit [Quit: Ex-Chat]
<RP>
kergoth: so slow progress and I think my older data store patches work work better and be simpler now we've solved that second issue too
<RP>
kergoth: its purely a time thing, I just can't concentrate on it and that work needs concentration
<kergoth>
Makes sense. What patches are those, and are there any old prototype branches that are worth looking at? It's interesting stuff
<RP>
kergoth: I do have some horrible code somewhere, not sure if I made it public
<RP>
kergoth: that one was trying to see if we could optimise the internal overridedata piece inside bitbake to take advantage of the fact we now know what is an override
<RP>
kergoth: basically making override data variable local
<RP>
kergoth: there are chunks of that I did fix properly like the hasOverrides method
<kergoth>
So much of our behavior, file format, and data model are so tightly intertwined, it's hard to change any piece in isolation. Hard to avoid that, though
<kergoth>
Makes sense
<RP>
I think that patch would be easier now but never got back to it
<RP>
kergoth: I'm definitely open to ideas on what we could do to try and improve from here.
* kergoth
nods
<RP>
kergoth: I just found it near impossible to do anything with where we were at. Now we have the markup and reduced the syntax options a little, it should help open up other routes forward
<kergoth>
You've got a million things on your plate, no complaints from me, just looking at the future directions and old unmerged branches and stuff while mulling over both how we should use our resources and what i personally want to hack on
* kergoth
nods
<RP>
I was sad that patch removed the cookie monster!
<moto-timo>
it's rather daunting how intertwined things are... and I don't have nearly the depth of knowledge that I fool myself into thinking I have
<JPEW>
Is downloads.yoctoproject.org down for anyone else?
<moto-timo>
RP was running circles around me yesterday :)
<RP>
JPEW: this might be the start of the data centre move
<JPEW>
Guess we'll see how good our local mirror is!
<RP>
JPEW: it did just respond to me FWIW, rather slowly
<RP>
kergoth: I'd love to have your help in trying to improve some of the things we've long since wanted to move forward!
Thorn has quit [Ping timeout: 256 seconds]
<JaMa>
agherzan: is there reason for the distro which included defaultsetup.conf to use ?= for TCLIBC? why not normal assignment?
Thorn has joined #yocto
<moto-timo>
not for TCLIBC, but other variables I needed them ?= so they could be overridden in e.g. kas for a different MACHINE etc.
<moto-timo>
I suppose there are bigger hammers
<JaMa>
well it's not any different to e.g. TMPDIR, why should TCLIBC work differently than TMPDIR?
<JaMa>
TMPDIR might be even worse (for people who don't want to use the default version) as there is also
<JaMa>
TCLIBCAPPEND ?= "-${TCLIBC}"
<JaMa>
TMPDIR .= "${TCLIBCAPPEND}"
<RP>
kergoth: one question I still have is around the confusion of XXX:append:YYY vs XXX:YYY:append
goliath has joined #yocto
rfuentess has quit [Remote host closed the connection]
<kanavin>
RP: that worked perfectly :-/ (build bash on master without sstate or tmp/, add patch, build bash again)
<RP>
kanavin: did you force a recompile of bash?
<kanavin>
ah!
<kanavin>
heheh
<kanavin>
let me try :)
<RP>
kergoth: I may come to regret making ${PN} and override for packaging for that reason, not sure
<RP>
s/and/an/
<kanavin>
RP: now I have it
<agherzan>
JaMa: Because I want to have the ability to inherit existing distros and be able to override that configuration.
leon-anavi has quit [Quit: Leaving]
turquoisetree has quit [Quit: Client closed]
<khem>
rburton: I think for layers on openembedded perhaps its fine to stay at same priority as core
<khem>
perhaps we can set a good example by doing so
<khem>
sometimes we may have need to host a newer component since some other component may need it but oe-core may be carrying older versions
<khem>
having same priority means we need to test these layers more firmly with oe-core and also weigh in commits to oe-core based on that a bit
<JaMa>
agherzan: and ?= is preventing you to do that? why?
<RP>
khem: matching core would be something I'd support
<RP>
khem: we should be resolving any conflict quickly (and I think we do?)
mckoan is now known as mckoan|away
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<agherzan>
The idea JaMa is that behaviour changed
<agherzan>
The ?= Is now ignored in a distro because the bitbake ?= takes it first now.
<agherzan>
This was not the case when the variable was defined in the default setup inc.
<RP>
agherzan: We have so many different behaviours with different variables I'm not sure I would say this was a bug as such but more just highlights what a mess our default options are
<JaMa>
but why should TCLIBC behave differently than e.g. TMPDIR?
<agherzan>
Because the ?= order has changed
<JaMa>
TMPDIR is set in bitbake.conf with ?= as well
<JaMa>
so it's consistent with TCLIBC
<agherzan>
Fair. Maybe it's the same situation there too
<agherzan>
So if the reason was to unify the behaviour, I can understand
<khem>
RP: these days its not as bad I suppose, but I will ask wider community also if they see any issues that I might be blind to
<JaMa>
the reason was to set the CACHE in one place as explained in the commit message
<agherzan>
Right. But that had a change in behaviour too
<JaMa>
unifying the behavior is just a small side effect (and I don't see it as bad side effect)
<moto-timo>
any clues what might be causing: tmp/sstate-control/manifest-x86_64-rust-cross-core2-64-glibc.populate_sysroot not found in x86_64 (variant '')?
<agherzan>
A side effect in how this interacts with definitions in distros.
<RP>
moto-timo: master-next with kanavin's change?
<moto-timo>
this is for either python3-cryptography or python3-pyruvate with the patch just sent to oe-dev to fix python3-setuptools-rust-natve
<moto-timo>
RP: oh yes
<moto-timo>
sigh
<moto-timo>
thank you!
<kanavin>
I don't think I'll ever run out of things I never saw before in oe-core
<moto-timo>
kanavin: me either
<kanavin>
wrapping my head around tmp/sstate-control now :)
<moto-timo>
I'm just glad it isn't something specific to setuptools_rust or else I would probably scream a little bit
<kanavin>
moto-timo, always rebase on master :)
<moto-timo>
kanavin: for the last few days it had to be master-next ;)
<JaMa>
agherzan: yes, but it still doesn't explain why the distro doesn't use normal = for TCLIBC when it needs to use normal = for TMPDIR (or many other variables)
<moto-timo>
phew, that was indeed the problem
<RP>
kanavin: that area of the code is such fun
<JaMa>
agherzan: we have stack of 4 distributions inheritting each other and just including upper-distro.inc in the right order allows us to easily set whatever we need (including overwritting whatever defaults we got from intial defaultsetup and bitbake.conf)
<RP>
kanavin: it started so nice and simple and then the corner cases starts
<moto-timo>
hmmm... maybe PyO3 has a flag for build dir...
<RP>
kergoth: I'm still thinking about the idea of a defaultval override level, thereby allowing you to change the default value with the overrides mechanism
behanw has joined #yocto
<RP>
kergoth: even having people like yourself with time to think about and play with these ideas would be valuable IMO as we need to do that to work out what makes sense
<kanavin>
RP: I am still somewhat confused. The error I am getting is:
<kanavin>
ERROR: bash-5.1.16-r0 do_prepare_recipe_sysroot: Manifest /srv/storage/alex/poky/build-gcc-cross/tmp/sstate-control/manifest-x86_64-gcc-cross-x86_64.populate_sysroot not found in x86_64 (variant '')?
<kanavin>
which is, 'new-style manifest not found'
<kanavin>
how would removing old-style manifests help here?
<agherzan>
JaMa let me remember now why we went down that route. I think it was to allow command line overrides too.
nateglims has joined #yocto
<JaMa>
we have TCLIBC in BB_ENV_PASSTHROUGH_ADDITIONS and I think it still works as well
<RP>
kanavin: basically before you hit this, you need to ensure the old style stuff is removed. The sanity checks run right at the start of the build allowing you to do that before the state gets broken
* RP
-> afk
nateglims89 has joined #yocto
nateglims has quit [Ping timeout: 256 seconds]
<fray>
I'm looking for a clue. We've got a few out of tree kernel modules. These modules need device nodes created (we have udev rules for this), but I'm resistant for people patching systemd to add udev rules.. Is it reasonable to add udev rules into an out-of-tree kernel-module package? Do a need a 'new' package? Thoughts?
pasherring has quit [Quit: Leaving]
<kanavin>
usually I would ask, how does 'desktop distro on my laptop' do it?
kevinrowland has joined #yocto
<fray>
I can't find any examples for out of tree modules
<fray>
intree, the udev stuff ends up with either the application, ctrl logic or library it seems..
<RP>
fray: Adding udev rules in the module package would seem reasonable
<RP>
the two would seem to only work together
florian_kc has joined #yocto
<fray>
RP ok, I wasn't sure if there was something preventing that
nateglims89 has quit [Quit: Client closed]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
<sgw>
RP: I know it's late friday for you, I have an update to the incompatible license code, that I think addresses the open issues, do you want a patch that you can squash or a v2 of the exiting re-work patch?
kevinrowland has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 272 seconds]
prabhakarlad has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
leon-anavi has joined #yocto
<halstead>
Brief outage of downloads.yoctoproject.org coming shortly in order to prepare the for move tomorrow.
yocti has quit [Ping timeout: 250 seconds]
yocti has joined #yocto
<halstead>
Outage complete.
amitk has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
mvlad has quit [Remote host closed the connection]
florian_kc has joined #yocto
florian_kc is now known as florian
chep has quit [Read error: Connection reset by peer]
chep` has joined #yocto
chep` is now known as chep
codavi has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
Androo has joined #yocto
<Androo>
Have a .bb that tries to copy the entire contents of a directory to the rootfs (https://pastebin.com/raw/gRw9B7sL -- see "file://migrations-post"). But have noticed that sometimes if we rename these files yocto will not rebuild the package, and even if we clean the package may get rebuilt but the rootfs will not. Any suggestions on how to improve this?