GillesM has quit [Remote host closed the connection]
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
otavio has quit [Remote host closed the connection]
roussinm has joined #yocto
fleg has quit [Remote host closed the connection]
NewbieinYocto has quit [Ping timeout: 256 seconds]
sakoman has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
troth has quit [Ping timeout: 268 seconds]
erbo has quit [Ping timeout: 260 seconds]
erbo has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
troth has joined #yocto
sakoman has joined #yocto
sakoman has quit [Quit: Leaving.]
camus1 has joined #yocto
troth has quit [Ping timeout: 268 seconds]
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
troth has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
troth has quit [Ping timeout: 268 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
pgowda_ has joined #yocto
troth has joined #yocto
alessioigor has joined #yocto
troth has quit [Ping timeout: 268 seconds]
alessioigor has quit [Quit: alessioigor]
engest has quit [Ping timeout: 268 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
troth has joined #yocto
fleg has joined #yocto
Guest27 has joined #yocto
Guest27 has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
rob_w has joined #yocto
<JosefHolzmayrThe>
yo dudX
zyga-mbp has joined #yocto
Schlumpf has joined #yocto
leon-anavi has joined #yocto
lucaceresoli has joined #yocto
rfuentess has joined #yocto
vladest has joined #yocto
nad has joined #yocto
tnovotny has joined #yocto
tre has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
Schlumpf has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
goliath has joined #yocto
tgamblin has quit [Remote host closed the connection]
mckoan|away is now known as mckoan
tgamblin has joined #yocto
nad15 has joined #yocto
yocton has joined #yocto
nad has quit [Ping timeout: 256 seconds]
nad15 has quit [Ping timeout: 256 seconds]
<qschulz>
o/
nad has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mihai>
yo
<mckoan>
good morning
zyga-mbp has joined #yocto
Herdinger has joined #yocto
<Herdinger>
Hi, I have a hopefully quick question. What is the way to go about setting capabilities for executables with yocto? I have added calls to setcap in the postinstall of a recipe but the capabilities do not show up under the rootfs or in the image.
qua has joined #yocto
alejandrohs has quit [Ping timeout: 260 seconds]
alejandrohs has joined #yocto
leon-anavi has quit [Quit: Leaving]
camus1 has joined #yocto
hpsy has quit [Ping timeout: 268 seconds]
chep has quit [Ping timeout: 256 seconds]
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
chep has joined #yocto
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
kanavin has quit [Remote host closed the connection]
hpsy has joined #yocto
<Herdinger>
It seems to correctly set capabilities during post install, if I log the postinstall script to a file on rootfs I can request the capabilities and see the ones that were set. But the file in the rootfs folder does not contain the capabilities. Is metadata for the rootfs set somewhere else and then applied during image creation?
kanavin has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
xmn has joined #yocto
florian has joined #yocto
Herdinger has quit [Quit: Connection closed]
<jsandman>
Hi, Is there a way I can get some header files installed in my repcipe's native sysroot? I have a very hacky component that builds host tools during compilation. The thing is it looks for thing like stdio.h to be in the recipe-sysroot-native.
<rburton>
what is it doing that the native compiler doesn't look in its own default search path?
<mckoan>
jsandman: do_install_append
<jsandman>
rburton Hold on. This Makfile is calling `gcc` directly which would mean it is not even using a native compiler from my recipe-sysroot-native. Could that be the problem of it not looking in its correct search path? What would be the recomended way for having a native gcc for host compilations in my recipe-sysroot-native?
<rburton>
native tools should be using BUILD_CC (which is gcc by default), and will search your /usr/include unless the makefile does silly things
<rburton>
we don't build a native gcc, as you must have a working compiler to build it
<rburton>
the usual problem is makefiles that don't correctly separate target from host building steps, and end up mixing compiler flags
<rburton>
if you can share the actual recipe/makefile/etc, responses can be concrete instead of vague
<rburton>
but basically, host tools should use BUILD_CC BUILD_CFLAGS BUILD_CPPFLAGS BUILD_LDFLAGS etc
<jsandman>
yes. That is exactly it. It calls to gcc directly but then gets the CFLAGS that I set for crosscompilation
<rburton>
broken makefile, fix it :)
jorschulko has joined #yocto
jorschulko has quit [Client Quit]
jorschulko has joined #yocto
<jsandman>
I am trying to inyect BUILD_CFLAGS and it seems to work but I don't know what paths I need to select so it finds headers such as stdio.h basically. Maybe I need something in my DEPENDS so that stdio.h appears in my recipe-sysroot-native but I don't know which on it is
camus1 has joined #yocto
<jsandman>
yes. This makefile is very painful. It is a proprietary component that was never ment to build in Yocto (or anywhere else really once you look inside)
camus has quit [Ping timeout: 264 seconds]
camus1 is now known as camus
<rburton>
you shouldn't need to do anything for stdio.h as gcc will know to look in /usr/include already
<rburton>
unless the makefile is turning off the system paths, in which case that's your problem
<rburton>
can you paste the compile line that is failing?
rob_w has joined #yocto
chep has quit [Ping timeout: 256 seconds]
<jorschulko>
Quick question regarding cross-project patches. I have a feature patch which affects bitbake, as well as oe-core. How do I put these on the mailinglists? Split them up? Send them all to both mailing lists?
chep has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jsandman>
Ok. Trying to get the verbose out of this massive thing so I can paste that gcc command. I'll get back. Thanks rburton
zyga-mbp has joined #yocto
chep has quit [Ping timeout: 264 seconds]
<rfuentess>
hi! I'm searching through yocto's security ML, but, I was wondering, anyone knows if the SRTool is still supported?
<rfuentess>
a simple glance on its repo shows last commit was from last year. So, not sure if the project went into zombie state. thanks in advance (And I'm going back to the ML's post )
chep has joined #yocto
<RP>
kanavin: did you find out if the pcre server are expected to return? We're also seeing svn issues in bitbake-selftest: svn://vcs.pcre.org/pcre2/code
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chep has quit [Ping timeout: 260 seconds]
zyga-mbp has joined #yocto
rob_w has quit [Quit: Leaving]
chep has joined #yocto
<mcfrisk>
RP: yea, with bitbake fetcher. git lfs could work in some cases yes
SandwichCakeExpe has joined #yocto
<SandwichCakeExpe>
Hey all
<SandwichCakeExpe>
Is it possible to set IMAGE_LINK_NAME in local.conf or will it inevitably always be overwritten?
<SandwichCakeExpe>
I'm hoping to extend it so that links have a different name irrelevant of the image name being built.
<SandwichCakeExpe>
So it shouldn't live in individual image recipes. I guess a bbappend for the base image recipe from which all of them are inheriting could be an alternative, it's just that that's git versioned I was loking for something less permanent :)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chep has quit [Ping timeout: 256 seconds]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
chep has joined #yocto
zyga-mbp has joined #yocto
<jsandman>
rburton, so these are the flags this makefile uses: https://paste.debian.net/1218315/ , That includes my CFLAGS. If I hack the makefile to not include cross compilation CFLAGS then it canot find stdio.h
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
<rburton>
you need to stop it passing --sysroot
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
<jsandman>
ack. I'll see if I can get further with this. Thanks!
SandwichCakeExpe has quit [Quit: Client closed]
jatedev has quit [Ping timeout: 256 seconds]
leon-anavi has joined #yocto
rsalveti has quit [Quit: Connection closed for inactivity]
camus has quit [Quit: camus]
jorschulko has quit [Quit: leaving]
otavio has joined #yocto
chep has quit [Ping timeout: 264 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kiran has joined #yocto
chep has joined #yocto
engest has joined #yocto
zyga-mbp has joined #yocto
vladest has joined #yocto
<JosefHolzmayrThe>
Andrei: ping - do you have any plans concerning the github url mess for meta-raspberrypi? as of today, without a hot DL_DIR it doesn't build for dunfell anymore.
sakoman has joined #yocto
<RP>
kanavin: "You can check out the PCRE2 source code via Git or Subversion" - github supports svn checkouts"!
<JosefHolzmayrThe>
RP: what was the trick/script needed to do the conversion?
<RP>
JosefHolzmayrThe: the github one?
<JosefHolzmayrThe>
RP: yup
<RP>
JosefHolzmayrThe: There is a tweak in the bitbake fetcher and a scripts/contrib/convert-srcuri.py
* JosefHolzmayrThe
is sad on a friday afternoon :(
<JosefHolzmayrThe>
yeah i think i saw the tweak on poky/dunfell, right?
<jordemort>
lol github svn support, the april fool's joke that shipped - the component that did the protocol translation there used to be called "slumlord" but i think they've rewritten it and given it a nicer name since i left
chep has quit [Ping timeout: 268 seconds]
<RP>
JosefHolzmayrThe: master?
<RP>
jordemort: I was wondering what they did to make that work!
<JosefHolzmayrThe>
RP: ah. my bad.
chep has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
<RP>
abelloni: notice it is centos8 again with make 4.2.1 which does have a pipe bug in it :/
manuel1985 has joined #yocto
* RP
dumps data to the swat list
<JosefHolzmayrThe>
RP: conversion seems to have worked, thanks.
rsalveti has joined #yocto
chep has quit [Ping timeout: 256 seconds]
<RP>
dev1990: I pushed a fix to pseudo and oe-core master for that missing fcntl64 wrapper. Would be interesting to know if that fixed your issue with findutils?
chep has joined #yocto
chep has quit [Ping timeout: 256 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chep has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
Guest2753 has joined #yocto
Guest2753 is now known as mwe
vladest has quit [Ping timeout: 256 seconds]
vladest has joined #yocto
<mwe>
Hi All,
<mwe>
I am on Dunfell top-of-tree, and when I try to build some of the recipes under recipes-kernel, bitbake hangs. This started occurring yesterday (seemingly out of no where - I have been using yocto for some time). According to the debug log, bitbake will execute up to some point when the message `DEBUG: Starting bitbake-worker` will appear in the
<mwe>
debug log. At this point, all outstanding tasks will hang forever, and I need to SIGINT bitbake.
<mwe>
What I've found is that there are certain tasks which cause the hang, such as `linux-libc-headers_5.4.bb:do_install`. during the execution of these tasks, `bitbake-worker` will be started under `pseudo`. I'm not sure how to proceed from here - I am unfamiliar how to debug this. Is there a mailing list I should direct my question to? Is there some
<mwe>
way I can configure pseudo for debug? Thanks.
tre has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
camus has joined #yocto
Tokamak has quit [Ping timeout: 264 seconds]
Tokamak has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
Guest2728 has joined #yocto
mwe has quit [Quit: Client closed]
Guest2728 is now known as mwe
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<qschulz>
tlwoerner: rock-pi-4 arm-trusted-firmware does not build on meta-rockchip dunfell branch
<qschulz>
| make[1]: arm-none-eabi-gcc: No such file or directory
<qschulz>
ah, typo in the DEPENDS I think
<qschulz>
yup
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
troth has quit [Ping timeout: 268 seconds]
florian has quit [Quit: Ex-Chat]
chep has quit [Ping timeout: 260 seconds]
tgamblin has quit [Ping timeout: 264 seconds]
tgamblin_ has joined #yocto
chep has joined #yocto
<vd>
so I do not need to prepend FILESEXTRAPATHS if I use a ${PN}/${MACHINE} directory, right?
<qschulz>
vd: you need to prepend with ${THISIDR}/${PN}
<qschulz>
from a bbappend
<qschulz>
if it's in the original recipe, no, no need
Tokamak has quit [Ping timeout: 268 seconds]
<vd>
but bitbake does look by default in ${PN}, ${PN}/${MACHINE}, ${PN}/${DISTRO}, etc. doesn't it?
<qschulz>
in the original recipe yes
<qschulz>
in the bbappend no, you need a filesextrapaths
<qschulz>
though it gets extended with each OVERRIDES (among which MACHINE and DISTRO are)
<vd>
hoo I think I understand, you ALWAYS need to prepend FILESEXTRAPATHS in a bbappend, even though you're using the standard paths bitbake looks for?
Tokamak has joined #yocto
<qschulz>
there's no such thing as standard paths from bbappends but yes
<vd>
s/standard/default/
opello has quit [Ping timeout: 260 seconds]
<vd>
hum it's a bit inconvenient as you need to specify the exact ${PN}/${DISTRO} path for example, while from the original bb recipe you don't have too.
rfuentess has quit [Remote host closed the connection]
opello has joined #yocto
<vd>
I wished you could just specify the _parent_ directory to look into, i.e. ${THISDIR}
florian has joined #yocto
hpsy has quit [Quit: Leaving.]
qua has quit [Quit: Client closed]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
nad has quit [Ping timeout: 256 seconds]
mvlad has joined #yocto
prabhakarlad has quit [Quit: Client closed]
zyga-mbp has joined #yocto
chep has quit [Ping timeout: 260 seconds]
vladest has quit [Ping timeout: 268 seconds]
chep has joined #yocto
<vd>
If you compile 2 different kernels (but the same distro and libc) you only need a different TMPDIR, correct?
akiCA has joined #yocto
vladest has joined #yocto
florian has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
mwe has quit [Quit: Client closed]
mwe has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
chep has quit [Ping timeout: 256 seconds]
lucaceresoli has quit [Quit: Leaving]
Tokamak has joined #yocto
<zeddii>
khem: I have a fix for the sdbus build issue, will send it shortly
chep has joined #yocto
nateglims has joined #yocto
vd has quit [Quit: Client closed]
kanavin has quit [Read error: Connection reset by peer]
vd has joined #yocto
kanavin has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
mwe: have to step afk but is that centos8 stream, make 4.2.1 and some process hanging in a zombie state? I'd try building a new make of a later version and try that if so.
zyga-mbp has joined #yocto
<RP>
the process tree of what is there when it hangs would help. strace is also useful, or gdb and backtrace what is hanging
<nateglims>
Is anyone taking contributions through github and also maintaining staging branches? Other than allowing only rebase merges, I'm wondering if there's any pitfalls to look out for?
mwe has quit [Quit: Client closed]
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
mwe has joined #yocto
tnovotny has quit [Quit: Leaving]
nateglims has quit [Quit: Client closed]
tgamblin_ has quit [Quit: Leaving]
Xagen has quit [Ping timeout: 268 seconds]
Xagen has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
<mwe>
RP: Upgrading to make 4.3 did not help
vladest has quit [Ping timeout: 260 seconds]
sakoman has quit [Quit: Leaving.]
florian has joined #yocto
halstead has quit [Ping timeout: 245 seconds]
NishanthMenon has quit [Ping timeout: 245 seconds]
NishanthMenon has joined #yocto
<zeddii>
khem: well, I thought I fixed it .. but meson has defeated me in thinking that the if_arp header needs to be present, even when I backported a patch. I have to step away, but will poke at it throughout the weekend and send a patch for the fixup when I finally understand what meson is doing :D
halstead has joined #yocto
vladest has joined #yocto
wCPO8 has joined #yocto
dkl_ has joined #yocto
dkl has quit [Ping timeout: 245 seconds]
wCPO has quit [Ping timeout: 268 seconds]
wCPO8 is now known as wCPO
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
mwe has quit [Quit: Client closed]
mwe has joined #yocto
<mwe>
RP: It is indeed centos8 make 4.2.1 (which I've since upgraded to 4.3), and all the pseudo bitbake-workers hang. I emailed your linux foundation email an strace log and process tree
florian has quit [Ping timeout: 260 seconds]
jmiehe has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakoman has joined #yocto
MWelchUK has quit [Quit: Ping timeout (120 seconds)]
MWelchUK has joined #yocto
ad__ has quit [Excess Flood]
ad__ has joined #yocto
<dev1990>
RP: working fine now, thanks :) I tested with updated pseudo in my poky/honister
chep has quit [Ping timeout: 260 seconds]
chep has joined #yocto
florian has joined #yocto
amitk_ has joined #yocto
nateglims has joined #yocto
nateglims has quit [Client Quit]
florian has quit [Ping timeout: 260 seconds]
amitk has quit [Ping timeout: 268 seconds]
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
chep has quit [Ping timeout: 268 seconds]
chep has joined #yocto
xmn has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
chep has quit [Ping timeout: 260 seconds]
mvlad has quit [Remote host closed the connection]
chep has joined #yocto
kiran has quit [Ping timeout: 268 seconds]
<abelloni>
mwe: RP: the BR guys are telling me that make 4.3 is segfaulting a lot
user2 has joined #yocto
saYco[m] has quit [Ping timeout: 246 seconds]
barath has quit [Ping timeout: 246 seconds]
OnkelUlla has quit [Ping timeout: 246 seconds]
RP has quit [Ping timeout: 268 seconds]
dunfell[m] has quit [Ping timeout: 268 seconds]
thekappe has quit [Ping timeout: 268 seconds]
behanw[m] has quit [Ping timeout: 268 seconds]
ericson2314 has quit [Ping timeout: 268 seconds]
moto_timo[m] has quit [Ping timeout: 246 seconds]
jwillikers[m] has quit [Ping timeout: 246 seconds]
mwe has quit [Quit: Client closed]
glembo[m] has quit [Ping timeout: 264 seconds]
Alban[m] has quit [Ping timeout: 264 seconds]
doquiros[m] has quit [Ping timeout: 264 seconds]
hjones2199[m] has quit [Ping timeout: 264 seconds]
t_unix[m] has quit [Ping timeout: 264 seconds]
florian has joined #yocto
saYco[m] has joined #yocto
barath has joined #yocto
OnkelUlla has joined #yocto
ericson2314 has joined #yocto
behanw[m] has joined #yocto
dunfell[m] has joined #yocto
moto_timo[m] has joined #yocto
roussinm has joined #yocto
Alban[m] has joined #yocto
vladest has quit [Ping timeout: 256 seconds]
glembo[m] has joined #yocto
chep has quit [Ping timeout: 260 seconds]
jwillikers[m] has joined #yocto
hjones2199[m] has joined #yocto
chep has joined #yocto
t_unix[m] has joined #yocto
doquiros[m] has joined #yocto
mwe has joined #yocto
<mwe>
abelloni: Hmm have not noticed that
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
mwe has quit [Quit: Client closed]
akiCA has quit [Ping timeout: 268 seconds]
Emantor has quit [Ping timeout: 246 seconds]
Emantor_ has joined #yocto
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #yocto
camus has quit [Quit: camus]
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<sveinse>
I'm attempting to make my own CONVERSION_CMD_spu() for an image (which in itself works fine), but I'm calling tar which throws a "Cannot change ownership to uid 0, gid 0: Operation not permitted" on me. I tried prefixing the "fakeroot CONVERSION_CMD_spu() {" but to no avail. Any suggestions on how I might run tar ops that preserves UID/GID in a conversion script?
RP has joined #yocto
<RP>
mwe: thanks, the make upgrade rules out some other weird centos8 issues I've seen today. The strace log only follows bitbake, it doesn't show what the other processes are doing unfortunately
<sveinse>
seems I cannot run tar without discarding uid/gid information in devshell either
<sveinse>
I thought pseudo/fakeroot would take care of that and allow chown. A new policy? Perhaps there is tunable somewhere?
<sveinse>
Running Hardknott
<RP>
sveinse: you should be able to do that under pseudo, I can't remember if devshell runs under pseudo by default or not