sbach has quit [Remote host closed the connection]
d0ku has quit [Ping timeout: 250 seconds]
sbach has joined #yocto
sbach has quit [Remote host closed the connection]
<moto-timo>
vmeson: $ rustc --print cfg
<moto-timo>
vmeson: error: Error loading target specification: Could not find specification for target "x86_64-linux". Run `rustc --print target-list` for a list of built-in targets
<moto-timo>
vmeson: $ rustc --print target-list throws the same error
<tgamblin>
vmeson: had a python3-cryptography recipe started, not finished but trying to build with the rust addons now
<RP>
kanavin_: right, it ends up being a bit of random chance with hashequiv :/
<RP>
kanavin_: basically there is a hash equiv entry in the database which says that both of those outputs are available from the input config. When you "fix" it without changing the output, the bad output hash is mapped with the good one
rob_w has quit [Remote host closed the connection]
<kanavin_>
RP: I see, I can make a patch for that, but looking at mc fail now
<kanavin_>
host contamination by probing supported options of /usr/bin/file
<kanavin_>
patches coming... :)
goliath has quit [Quit: SIGSEGV]
<RP>
kanavin_: sounds good :)
<RP>
kanavin_: nice to have something relatively simple!
florian has joined #yocto
tnovotny has joined #yocto
<kanavin_>
RP: I think it's time to bring in gtk 4.x, perhaps at the start of the next cycle. I'll cook up a recipe.
<kanavin_>
somehow, nothing wants it yet :) but 3.x won't last much longer
<kanavin_>
rburton, ^^^
<kanavin_>
also a good moment to drop both 3 and + from the recipe name
<RP>
kanavin_: I still remember the gtk+ "1" recipe! :)
<RP>
There was one rust failure on the AB on the last run and I don't understand it :(
<kanavin_>
RP: gtk 1 was certainly an improvement over those 1980s style flat X widgets :)
<kanavin_>
but it's peculiar how widget fashion changes, from flat (because graphics hw is too slow) to bulging, to flat again (to make it look less cluttered)
<kanavin_>
also peculiar that gimp still does not have a 3.x gtk based release
<RP>
kanavin_: it is interesting to see how things evolve and views change over time
* RP
is happy the memory issues in apps on my gnome desktop looks better in the new version. Just have to restart the shell after resuming from suspend to "fix" the graphics driver glitches
prabhakarlad has joined #yocto
<kanavin_>
hah, first two patches from my linutronix identity :)
zyga has quit [Quit: Leaving]
rfuentess has joined #yocto
goliath has joined #yocto
zyga has joined #yocto
<LetoThe2nd>
kanavin_: \o/
<rfuentess>
hi! Anyone has experience with Srtool ? (I'm just asking due is hosted by the yocto project)
<rfuentess>
I was running the zeus-s recipe for cve-chek and I got some recently CVEs that are not available at SRtool side. Even if I force the updates with the starting script (I'm still a rookie with srtool)
<rfuentess>
so, not sure where to look next
eduardas has joined #yocto
<RP>
kanavin_: and they were fast track merged too ;)
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<rburton>
rfuentess: you want to talk to david rainer, he's sometimes here but easier to mail
<rfuentess>
rburton: thanks! I suppose he is also on the ML concerning the srtool ?
<rburton>
one wouldl hope so!
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
thekappe has quit [Ping timeout: 252 seconds]
thekappe has joined #yocto
lukma has quit [Ping timeout: 252 seconds]
lukma has joined #yocto
erbo_ has quit [Ping timeout: 252 seconds]
erbo has joined #yocto
<barath>
Does anyone know why do_package tasks would not be sstate cached? Ie I see that there seem to be no sstate cache files in my sstate directory relating to do_package tasks... But the manual seems to imply that do_package is an example of what can be cached
<barath>
This happens for base packages like m4
<RP>
barath: native or target recipes?
<RP>
do_package should be cached in sstate
<barath>
Hm. Ive printed our the exact names of the tasks which sstate is counting as "missed", and an example is <recipe path>/base-files_3.0.14.bb:do_package
<barath>
So the name itself doesn't contain anything referencing native, but I'm not sure whether that's something to be expected
<barath>
Base-files contains stuff to be installed on the target
<RP>
barath: base-files wouldn't be native, I was wondering about something that isn't relevant based on your reply
<RP>
barath: there is a difference between sstate not matching and it not being present at all
<RP>
Hmm, more out of space issues on the AB. I think we're stressing it too much
<barath>
Hmm
<barath>
In my case the sstate cache server is our own, so I guess we could've somehow screwed up and prevented that sstate cached task from being stored...
<barath>
So missing might mean just not there OR not matching? Thanks for the pointer, I'll try to check up on that
eduardas has quit [Quit: Konversation terminated!]
lucaceresoli has joined #yocto
<RP>
barath: you should see some *base-files*package* files in there
Net147 has quit [Ping timeout: 245 seconds]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
jwillikers has joined #yocto
Net147 has quit [Ping timeout: 250 seconds]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
kranzo has joined #yocto
<kranzo>
hi there, i got an dunfell setup, python-netifaces from meta-openembedded is overlayed by a high prio layer, this one has `require recipes-devtools/python/python-netifaces.inc` wich is present in both layers, but its picked up from the low prio layer any idea why?
paulg has joined #yocto
Belsirk has joined #yocto
rfuentess has quit [Ping timeout: 240 seconds]
<JaMa>
kranzo: use "require python-netifaces.inc" to include the one next to your recipe (or just fold it into the recipe)
<JaMa>
also check BBPATH variable, it's convenient to sort BBLAYERS in a way that higher prio layers are listed in BBPATH earlier
<kranzo>
JaMa ah my bad: there is a third layer with the highest prio where i wanna use the inc file from
<kranzo>
so the sorting matters? that could be the problem
<JaMa>
use bitbake -e or bitbake-getvar to see your BBPATH variable and adjust bblayers.conf accordingly
eduardas has joined #yocto
<JaMa>
keep in mind that layer.conf handling of BBPATH is up to the maintainer, so you can have a layer which prepends itself to BBPATH instead of more common append to BBPATH
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
ndec[m] has quit [Quit: You have been idle for 30+ days]
tokamak[m] has quit [Quit: You have been idle for 30+ days]
<kranzo>
JaMa ah ok, so prio is just for the bb-files and everything else is managed by include order?
ndec[m] has joined #yocto
<qschulz>
kranzo: by BBPATH, which by default is appended by layer.conf files, which are parsed in the order in which they are listed in BBLAYERS in bblayers.conf file
<qschulz>
but relying on the order of BBPATH is a very bad practice
<vmeson>
[20:54] <moto-timo> vmeson: $ rustc --print cfg <--- I've seen that before and we had a fix. I'll dig it up and test it...
<JPEW>
qschulz: I've rolled around the idea of making a QA checker that warns/errors if the order of layers in BBPATH doesn't match the priority of the layers
lucaceresoli has quit [Ping timeout: 250 seconds]
tp43_ has joined #yocto
lucaceresoli has joined #yocto
<cengiz_io>
hello. how can I add a patch to be applied on openembedded core?
<cengiz_io>
there's an issue with lttng-modules that's not been backported to dunfell yet
<cengiz_io>
there's a patch but the patch is applied to a recipe in /meta
gchamp has quit [Remote host closed the connection]
<cengiz_io>
sorry. that's not applicable when you're using layers over layers, all managed with repo tool.
rburton has quit []
rburton has joined #yocto
lucaceresoli has quit [Ping timeout: 250 seconds]
Guest7 has joined #yocto
<Guest7>
How do I make my image depend on my DISTRO_VERSION? I changed it, but bitbake isn't re-building.
<RP>
vmeson: there is something odd going on as these failures don't always reproduce :(
<RP>
paulg: I was looking at the reproducible build issue with proc/version and I don't think the code was quite intended to do what you observed :(
sakoman has joined #yocto
<RP>
paulg: It is supposed to make the file consistent for a given build import, not hide things. I'd be interested in trying to fix it somehow
<paulg>
RP - well, given that /proc/version contains a date/time within - I'm not sure how you'll reconcile that with binary reproducibility..
<RP>
paulg: ah, it was the date/time you wanted? :/
<RP>
paulg: I think the idea was that most things would be committed
<paulg>
If it wants to play games with that data, then I think the feature should be off by default -- forcing people to opt out vs. opt-in on stuff like that violates the principle of least surprise.
lucaceresoli has joined #yocto
<RP>
paulg: at this point binary reproducibility is what people want by default
<paulg>
maybe at final build/deploy time - as they go GA. But not during a devel cycle - there it just becomes an obfuscating PITA.
<RP>
paulg: if they don't have it at dev time, they will struggle to turn it on later, too many issues too late
<paulg>
I guess we'll have to agree to disagree.
<RP>
I think there must be a way to have the default reproducible and show changes on top of the original config
<paulg>
I'll be killing it with fire every time I come across it.
<RP>
paulg: I simple don't have the option if we want to project to be credible
<RP>
paulg: I hadn't realise it was the date/time you wanted though. I'll try and think about what we can do
Belsirk is now known as rfuentess
<paulg>
well, consider the workflow - I change something in some crusty ppc uart driver ; recompile and reboot ; it is a subtle change and with all the various runqemu and intervening infrastructure of build dir vs tmp/deploy/images - I want to be 100% sure I've booted with the change made.
<paulg>
I don't want to hack init/main.c and add printk("paulg: build 0002\n");
<mcfrisk>
in that case you want to be sure your kernel version and git hash is what you expect
<paulg>
normally I've got LOCALVERSION_AUTO on, yes.
<paulg>
but with uncommited test changes in flight, I also want to see the timestamp of the vmlinux
<paulg>
since locaversion will just append "dirty" if you've got test changes that aren't committed.
<RP>
paulg: I understand the usecase, it is why I'd like to figure out a way to help that.
<mcfrisk>
when people ask for time as a reference, I always want to ask what they really want
<paulg>
OK. I want to know "Did I just build this less than 60s ago?"
<paulg>
(and of course the tag/SCM hash etc.)
<RP>
paulg: are you triggering that build with -f ?
<Guest7>
When I build it shows my new DISTRO_VERSION, but says nothing needs to be run. Buildhistory shows the old DISTRO_VERSION.
<paulg>
maybe ; maybe not ; might be running make within a devshell to eliminate all the whirling and churning of bitbake.
<mcfrisk>
due to various reasons, build time may not give you that info. for uncommitted changes I don't see a good way to test and verify that all your changes are in. commit the change to a developer branch and make sure your commit in version.
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
<Guest7>
paulg: I use "externalsrc" for testing the kernel.
rob_w has quit [Quit: Leaving]
<paulg>
mcfrisk and Guest7 , thanks but I have no problem working around the issue in one way or another - what I'm saying is the default is broken for a routine developer who is tasked with a contract for something like making/updating a kernel portion of a BSP and hasn't extensive yocto experience.
jmiehe has joined #yocto
tnovotny has quit [Quit: Leaving]
<paulg>
it violates the principle of least surprise and makes their life more difficult.
<paulg>
and that isn't good for the Yocto project as a whole.
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
<mcfrisk>
for initial development, an SDK is better. that's clear. once you have something release-ready, then bitbake and yocto.
<Guest7>
I came in late... is it caching the build time? I teach my coworkers to use externalsrc since you can use git locally, easily know what's in your build, and there's no risk of bitbake blowing away your changes
<vmeson>
cengiz_io I use repo too and typically, I'll do: repo start <branch> . ; git cherry-pick. , test, push to upstream master repository.-- what happens if you do that?
<qschulz>
cengiz_io: use a simple bbappend in your layer
angolini has quit []
angolini has joined #yocto
<Guest7>
If I run `bitbake-dumpsig -t dey-image-tsp-dev rootfs` I see a list of variables in "Task dependencies". How do I add DISTRO_VERSION to that list?
<cengiz_io>
qschulz: it's a patch to lttng-modules which introduces a c header patch and changes the src_uri branch. I have decided to skip lttng-modules instead. way too much work.
<Guest7>
or can I make my images depend on the DISTRO_VERSION variable?
<Guest7>
I don't see why my distro config file changing doesn't trigger an image re-build.
zpfvo has quit [Remote host closed the connection]
rmmr has quit []
rmmr has joined #yocto
Bardon has quit [Ping timeout: 258 seconds]
lucaceresoli has quit [Ping timeout: 240 seconds]
tp43_ has joined #yocto
florian has quit [Quit: Ex-Chat]
goliath has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
eduardas has quit [Quit: Konversation terminated!]
vmeson has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
vd has quit [Quit: Client closed]
mattsm has quit [Ping timeout: 268 seconds]
jmiehe has quit [Ping timeout: 240 seconds]
Bardon has joined #yocto
frieder has quit [Remote host closed the connection]
dev1990 has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
<tlwoerner>
sidenote: if :p indicates "sticking one's tongue out" does :q indicate "sticking one's tongue down one's throat" or is :q simply the left-handed version of :p ?
<tlwoerner>
;-)
vd has joined #yocto
d0ku has joined #yocto
vmeson has joined #yocto
vmeson has quit [Ping timeout: 250 seconds]
vmeson has joined #yocto
<kanavin_>
tlwoerner, I'd say it's 'trying to reach the nose with a tongue' ;)
* kanavin_
tries
<tlwoerner>
kanavin_: that's better than what i was coming up with
<FO>
Question: Anyway to save a variable value before overriding it ? in a .conf or .bb ? B="${A}" A="newvalue" doesnt work
<FO>
nevermind i found it :=
vmeson has quit [Ping timeout: 240 seconds]
<vd>
hi there -- how can I group targets? kinda like a packagegroup
<vd>
I can create a dumb recipe but I prefer to avoid having an "empty" recipe
<vd>
JPEW hehe, I'm doing kind of the same as whisk does, so I wanted to avoid duplicated my targets for every multiconfig ;-)
<JPEW>
vd: Yep
<vd>
JPEW neat. two remarks: 1) could you have used BBTARGETS? 2) I would prefer a multiconfig-agnostic recipe "a" adding targets "b", "c", "d", so that I can just build mc:foo:a and mc:bar:a
<JPEW>
vd: You could, but I found that a lot of other scripts don't like BBTARGETS to be changed
<vd>
ho I didn't know that
<JPEW>
vd: It's really a bug in the other scripts (can't remember which ones ATM)
<vd>
JPEW but thanks I'll hardcode a single recipe based on your class content for now
<JPEW>
vd: anyway, you could build up the list in anon python... maybe something like `TARGETS = "${@"mc:%s:a" % m for m in d.getVar("BBMULTICONFIG").split()}"`
<vd>
hum I could even use such recipe to copy the interesting built images in a specific directory
<vd>
JPEW yeah yeah yeah I'll switch to whisk I will ;-D
Ad0 has joined #yocto
<vd>
nah seriously good job, whisk is actually pretty well designed, I'm kinda going the same path and reinventing the wheel the same way, but I'm kinda stuck with kas at the moment, so ... a custom minimal whisk-like setup it is for me at the moment
<JPEW>
Code is Apache-2, you can copy it if you want :)
<vd>
JPEW btw I was thinking that such build tweaks must be ideally implemented as a features so that it could integrate nicely within existing systems or even tools (kas for example). Would whisk support that?
<JPEW>
vd: Can you clarify "such build tweaks"?
<vd>
JPEW tweaking image names, output directories, overrides, etc., based on the multiconfig
<vd>
these could be enabled on request rather now forced by the build system itself
goliath has quit [Quit: SIGSEGV]
<vd>
JPEW what whisk "modes" do you use in your systems btw? dev/prod/etc.?
<tlwoerner>
JPEW: have you given a talk on whisk yet? we should consider one for the next YPS, if nothing else
<lukma>
Dear Community, is there any limitation on the "depth" of shell functions execution in bbclass files?
<lukma>
I do observe strange behaviour for 'for' statement when I do have it placed in third "level" of shell function
<lukma>
placed in a single bbclass file
<JPEW>
tlwoerner: Ya, I can give a talk on it
amitk has quit [Ping timeout: 240 seconds]
<JPEW>
vd: ya, dev/prod. We call them "engineering" and "release", but same idea
<tlwoerner>
JPEW: or a hands-on… ;-)
<vd>
The notion of "distro" is OpenEmbedded is kinda hard to tackle, but I see these build tweaks as a distro features
<JPEW>
vd: I'm not quite following, but I *think* that's one of the purpose of multiconfigs is to allow you to capture all of this
vmeson has joined #yocto
<JPEW>
You can simply write a multiconfig .conf file and use it as the configuration you want
<JPEW>
Or, if you want to share configuration between multiple different.... "layer managers?" (whisk, kas, etc.) write a common .conf file and include it from the multiconfig/local.conf/whatever
<vd>
JPEW sure but your images are affected by this common configuration (like embedded images), so image features could reflect that
<vd>
the whole concept is that image/machine/distro must be orthogonal, but in reality it's hard to maintain. I imagine features kinda give a scope for this at least
leon-anavi has joined #yocto
bradfa has quit []
bradfa has joined #yocto
JaMa has quit [Quit: leaving]
<vd>
JPEW in your build system, does an image reference images from other multiconfig (aka products/modes)?
<JPEW>
vd: Yes
<vd>
ok, that's one difference with my simple which is a bit simple. I have no product/mode and mcdepends, but just build profiles (multiconfig) and depends. I had no need yet to cross reference images
d0ku has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
* vmeson
tests openssl-1.1.1l for master and then hardknott.
<paulg>
r00tk1t
<vd>
with my setup*
florian has quit [Ping timeout: 250 seconds]
kanavin has joined #yocto
kanavin_ has quit [Ping timeout: 252 seconds]
dl9pf has quit []
dl9pf has joined #yocto
Guest82 has joined #yocto
Guest82 has quit [Client Quit]
CookieMonster has joined #yocto
bluelightning has quit [Remote host closed the connection]
bluelightning has joined #yocto
<CookieMonster>
Hi! I'm trying to include an out-of-tree device driver (ASoC) in my project. This requires an in-tree header file which is not found when building the recipe. The example project (hello-mod) doesn't have any dependencies, so it doesn't provide any info on how that's done. Any suggestions would be greatly appreciated!
jmiehe has joined #yocto
leon-anavi has quit [Quit: Leaving]
tp43_ has quit [Ping timeout: 250 seconds]
CookieMonster has quit [Quit: Ping timeout (120 seconds)]
manuel1985 has quit [Remote host closed the connection]
<moto-timo>
vmeson: so the only option left (other than 'fixing' rustc) would be host rust toolchain via HOSTTOOLS... :/ ugly
<vmeson>
moto-timo: yeah it's a bug. I think most people who just generate a recipe don't encounter it so that's why it's still around.
<moto-timo>
vmeson: bummer
* paulg
looks at the glibc pseudo hackery with the hardcoded wget. Stylin!
<moto-timo>
Hard code all the things!
* moto-timo
ducks
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
vagaruy has joined #yocto
<vagaruy>
Hello all - Trying to add a few NPM packages according to the instructions https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM .However, some of them eg. devtool add "npm://registry.npmjs.org;package=hjson;version=3.2.2" fails with a python error in do_fetch related to ExpansionError: Failure expanding variable TUNE_FEATURES_tune-core2-64 during
<vagaruy>
devtool build . Any clue what might be causing this.