brrm has quit [Read error: Connection reset by peer]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
linfax has joined #yocto
leon-anavi has joined #yocto
mckoan is now known as mckoan|away
ahussain has joined #yocto
ehussain has quit [Ping timeout: 268 seconds]
ahussain is now known as ehussain
mvlad has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
florian_kc has joined #yocto
GNUmoon2 has quit [Read error: Connection reset by peer]
GNUmoon2 has joined #yocto
alessioigor has joined #yocto
<Jones42>
is there some smart way to get a list of all tasks (that are run for a given recipe/target) and their varflags? I know i can get this on a per-recipe base with -e , but I imagine it would be interesting to have a file that allows me to inspect the whole datastore after the build.
enok has joined #yocto
<rburton>
Jones42: should be easy enough with a bit of python using the tinfoil API
<Jones42>
rburton: tinfoil looks great, wasn't aware something like that exists. thanks!
brrm has joined #yocto
jmiehe has joined #yocto
<rburton>
JPEW: was it you who had a script to sync the spdx master license list with our copies in common-licenses?
rob_w has quit [Remote host closed the connection]
Jones42 has quit [Ping timeout: 240 seconds]
wCPO8 has joined #yocto
enok has quit [Ping timeout: 240 seconds]
wCPO has quit [Ping timeout: 256 seconds]
wCPO8 is now known as wCPO
ad__ has quit [Ping timeout: 268 seconds]
derRichard has quit [Ping timeout: 252 seconds]
jmiehe has quit [Quit: jmiehe]
iokill has quit [Ping timeout: 264 seconds]
ad__ has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
iokill has joined #yocto
derRichard has joined #yocto
enok has joined #yocto
Vonter has joined #yocto
rfuentess has quit [Remote host closed the connection]
enok has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
florian has quit [Ping timeout: 246 seconds]
florian_kc has quit [Ping timeout: 246 seconds]
thomas_34 has quit [Ping timeout: 250 seconds]
florian_kc has joined #yocto
florian has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Vonter has quit [Quit: WeeChat 4.3.1]
ablu has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
ablu has joined #yocto
lexano has joined #yocto
enok has joined #yocto
zpfvo has joined #yocto
Ad0 has quit [Ping timeout: 268 seconds]
ehussain has quit [Quit: ehussain]
jmd has joined #yocto
alessioigor has quit [Quit: Client closed]
jmd has quit [Remote host closed the connection]
enok has quit [Ping timeout: 240 seconds]
jmd has joined #yocto
enok has joined #yocto
<qschulz>
moto-timo: is there a way for me to create a patch/do something to update a layer on the layerindex? meta-wayland has changed locations and is now outdated
<mbulut>
consider two recipes foo.bb and bar.bb, where foo installs an empty directory and bar installs a file in the same directory -- something like this:
<mbulut>
# foo.bb
<mbulut>
install -d ${D}${sysconfdir}/A/B
<mbulut>
do_install() {
<mbulut>
}
<mbulut>
FILES:foo += "${sysconfdir}/A/B"
<mbulut>
# bar.bb
<mbulut>
do_install() {
<mbulut>
install -D ${D}${sysconfdir}/A/B/C.dat
<mbulut>
}
<mbulut>
FILES:bar += "${sysconfdir}/A/B/C.dat"
<mbulut>
doing it like this, do_package will complain about installed vs. shipped because ${sysconfdir}/A/B is not in FILES:${PN}
<mbulut>
adding it to FILES:${PN} produces a conflict between foo and bar, because the latter has it in its FILES:${PN}
<mbulut>
but:
<mbulut>
when I remove the -D switch in bar's install command, the name clash does not pop and everything's fine
roussinm has joined #yocto
<mbulut>
can anyone explain this behavior? because, effectively both variants of install should do the same, shouldn't they?
<mbulut>
forgot to mention, in addition to removing the -D in bar's install is doing an explicit install -d on the target directory before installing the file
<RP>
mbulut: do the permissions for the directory change between the two cases and the different permissions cause the conflict?
<mbulut>
oh, good point
<mbulut>
foo installs the directory with default permissions but bar installs the file with 644
<mbulut>
not sure if the permissions are also applied to the parent directories if -D is set
<mbulut>
lemme check
<mbulut>
just did a dry run in plain bash and interestingly, if you do 'install -m0644 -D file.dat A/B' the A directory is created with default directory permissions (755) but B gets 644 ...
<mbulut>
funny behavior
<mbulut>
this explains why do_package/do_rootfs complain -- thx for the pointer
<moto-timo>
qschulz: I was trying to help Markus get his maintainer account set up properly. He let me know the layer had moved. Looks like rburton made the change.
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 255 seconds]
michaelo has quit [Quit: leaving]
enok has joined #yocto
michaelo has joined #yocto
tepperson has joined #yocto
goliath has quit [Quit: SIGSEGV]
<khem>
anyone has recipes for express express-graphql node modules ?
florian_kc has joined #yocto
<tgamblin>
is there a way to enable/disable specific CONFIG_ options for busybox/kernel/etc. conditionally, based on the image you're building?
<tgamblin>
I know it's possible with a custom .bbappend or by custom image, but I'm wondering if you can do it from local.conf somehow
ablu has joined #yocto
mbulut has quit [Ping timeout: 256 seconds]
enok has quit [Ping timeout: 240 seconds]
<khem>
tgamblin: I dont think there something like that unless the option is part of .cfg file which can be added/removed from SRC_URI or packageconfig
<tgamblin>
khem: right, I'm thinking some way to basically do e.g. "SRC_URI:append:core-image-full-cmdline = my_config.cfg"
<tgamblin>
but I've only seen that done based on machine
<tgamblin>
not image
tepperson has quit [Quit: Client closed]
<khem>
images are recipes in essence
<khem>
I think it should be a separate global setting at project level,
<tgamblin>
khem: I'm thinking the best way is to define a custom image that requires the base one
ablu has quit [Ping timeout: 260 seconds]
<khem>
you need a new global config change which is at same level as distro or machine feature
<khem>
custom image can add/remove packages from original recipe it wont change recipe metadata
florian_kc has quit [Ping timeout: 255 seconds]
enok has joined #yocto
Kubu_work has quit [Quit: Leaving.]
<tgamblin>
khem: alright, thanks
<mischief>
is there a way to build with asan?
<mischief>
i tried DEPENDS += "gcc-sanitizers" CFLAGS:class-target:append = "-fsanitize=address" but there's no libasan in the sysroot
enok has quit [Ping timeout: 240 seconds]
alimon has quit [Ping timeout: 260 seconds]
Jones42_ is now known as Jones42
ablu has joined #yocto
<Jones42>
just to clarify: the [rdeptask] only applies to recipes which are in RDEPENDS, right? I'm a bit confused because I'm wondering how inter-task-dependencies and runtime-dependencies go together.
florian_kc has joined #yocto
<mischief>
khem: any idea how to make sanitizers work? you're listed as the maintainer :-D
florian_kc is now known as florian
sarahn has joined #yocto
goliath has joined #yocto
Jones42 has quit [Ping timeout: 268 seconds]
tgamblin has quit [Ping timeout: 252 seconds]
enok has joined #yocto
Kubu_work has joined #yocto
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
kevans has quit [Ping timeout: 246 seconds]
kevans has joined #yocto
enok has quit [Ping timeout: 240 seconds]
Guest13 has quit [Quit: Client closed]
leon-anavi has joined #yocto
Kubu_work has quit [Quit: Leaving.]
mattsm has quit [Quit: Client closed]
mbulut has joined #yocto
mbulut has quit [Ping timeout: 240 seconds]
<yocton>
Roughly 4% of oe-core+meta-oe recipes use http://github.com/.../releases SRC_URI. Do you think it is worth having a special case for this in the http fetcher for "devtool latest-version" (and ultimately AUH)?
CombatWombat42 has joined #yocto
<yocton>
These URLs do not allow the fetcher to look for the latest version by default and we need to add a lot of UPSTREAM_CHECK_URI = "https://github.com/.../releases"
<CombatWombat42>
I'm trying to understand the impacts of the Linux Kernel only having a 2 year LTS time, but Pocky LTS releases being 4 years. Doesn't that imply that Pocky LTS releases will have to upgrade kernels at least once? I feel like I'm missing something as this has to have been discussed before, but my googlefu is failing me.
<yocton>
CombatWombat42: yes, it is expected for the Yocto LTS to upgrade the kernel at mid-life
mvlad has quit [Remote host closed the connection]
<RP>
yocton: we probably need something like the MIRRORS handling but for upstream status...
<yocton>
Oh, good idea! A mapping SRC_URI -> UPSTREAM_CHECK_URI
<sarahn>
Has there been any discussion of swapping to civil infrastructure project supported kernels?
<sarahn>
Jookia: some vendors are better than others at upstreaming, though it's a bit immaterial to me since I don't use the poky kernel anyway
<RP>
sarahn: I don't think there is anything to stop someone providing a layer with that kernel
<Jookia>
i think yocto already ships a patched kernel, not mainline
<sarahn>
rp: agreed, just curious if it had come up already or not
<CombatWombat42>
yocton, again, Thanks!
<Jookia>
is there a way to disable git clones that don't use SRCREV?
<Jookia>
build-wide
<Jookia>
bitbake seems to let you build packages based on just a git tag without verification or warning
xmn has quit [Ping timeout: 272 seconds]
<RP>
Jookia: tags are always resolved via the network so if you disable network access you'd find them
<Jookia>
ok. i'll patch my bitbake then
<RP>
Jookia: no need to patch it, BB_NO_NETWORK iirc
<Jookia>
BB_STRICT_CHECKSUM seems closer to what i want
<RP>
Jookia: you asked if you can get errors for tag resolution. Set BB_NO_NETWORK and you'll get that
<RP>
Jookia: I've spent years arguing with people this is the correct behaviour (to hit the network)
<Jookia>
RP: yes, but i want to still download things from the network
<Jookia>
but i don't want unverified code downloaded
<RP>
whatever then. I'll just not answer questions
<Jookia>
ok
<Jookia>
RP: did you mean you were arguing with people to set BB_NO_NETWORK
<RP>
No, I meant that I'd spent a lot of time arguing the fetcher behaviour to resolve tags upstream, always, even if there is a local locally is correct
<Jookia>
why is that?
<RP>
because they can change
<Jookia>
isn't this a security hazard?
<RP>
they're certainly not ideal. If you use a tag like that you'll see that bitbake will always reparse that recipe and always check it upstream in a given build run
<RP>
so if you're not seeing recipes reparse, you can know that tags aren't being resolved
<Jookia>
no i mean, how do you know the tag is legitimate and not some kind of hijack or malicious code
<RP>
for that you'd need to check the signing key and we don't do that
<Jookia>
so the correct solution for disabling this behaviour is BB_NO_NETWORK?
<RP>
my point is that the reparse overhead naturally pushes people to use specific revisions which is our recommendation. We just do support tags whilst trying to make it obvious they have challenges
<RP>
disabling the network is one way to detect it.
<Jookia>
is there an option to disable tags?
<RP>
I'm trying to be helpful by giving you options. Instead you're trying to make be "defend" things I didn't necessarily choose :(
<RP>
no, there is not
<Jookia>
RP: i'm not asking you to defend anything
leon-anavi has quit [Remote host closed the connection]
KanjiMonster has quit [Remote host closed the connection]
florian has quit [Ping timeout: 256 seconds]
<Jookia>
did you want me to open a bug about this issue (no option to disable unverified downloads)
KanjiMonster has joined #yocto
<RP>
I guess so but opening the bug isn't going to magically fix this, there is probably quite a bit of work involved when you consider things like submodules and the other source control systems :/
<RP>
If we provide the option, it needs to work reliably/correctly
<Jookia>
i will be patching my local bitbake to try to add an option for this. that could be a start
CombatWombat42 has quit [Ping timeout: 272 seconds]