qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
jwillikers has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
zyga-mbp has quit [Ping timeout: 265 seconds]
zyga-mbp has joined #yocto
robbawebba has quit [Quit: WeeChat 3.2]
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
sakoman has quit [Quit: Leaving.]
FredO has quit [Quit: Leaving]
FredO has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
cocoJoe has joined #yocto
te_johan has quit [Remote host closed the connection]
paulg has quit [Ping timeout: 265 seconds]
xmn has quit [Ping timeout: 252 seconds]
r4ge has quit [Ping timeout: 260 seconds]
te_johan has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
Guest61 has joined #yocto
frieder has joined #yocto
fbre has joined #yocto
zpfvo has joined #yocto
creich_ has quit [Quit: Leaving]
creich has joined #yocto
<wCPO>
If I want a recipe executing only do_deploy, should I just add a noop do_install and "addtask deploy after do_install" or is there a smarter way?
<kanavin>
the sad truth about warnings is that they never get fixed, and people just ignore them
<kanavin>
the best course of action is to give everyone hard errors, even though this inevitably causes anger
rfuentess has joined #yocto
<kanavin>
Linus discovers what (I think) RP had known for years ;)
<RP>
kanavin: heh :)
<kanavin>
RP: but perhaps overwhelming people could have been avoided - warnings to errors could be a gradual pre-planned and clearly scheduled transition rather than a flag day
<kanavin>
(I mean in the kernel, not in yocto :)
<kanavin>
and btw rngd swelling and causing oom is potentially serious, I'll try to look time permitting
<mihai>
that's the first take after major gcc upgrade which changes warnings into errors, first commits disables errors :)
<wyre>
is ${S} by default ${WORKDIR}=
<wyre>
s/=/\?/
goliath has joined #yocto
<mihai>
wCPO: you could disable them do_task[noexec] = "1"
<mihai>
not sure if it's smarter
<mihai>
the same is done for image recipes, afaik
<qschulz>
wyre: no
<wyre>
I'm trying to make a proper do_fetch task but my gitlab repo is private and I'm not sure if deploy tokens could help me
<qschulz>
wyre: bitbake -e <anyrecipe> | less and go to the first line starting with S=, then look into the history of the variable, the first line is usually the default
<wyre>
qschulz, the problem is I'm using a docker container
<qschulz>
wyre: nothing to be done on yocto side except specify protocol to be ssh
<qschulz>
wyre: ssh-agent forwarding is the answer
<qschulz>
Pyrex does it, CROPS might be doing it, I imagine kas is doing it too
<qschulz>
-v $SSH_AUTH_SOCK:/tmp/ssh_auth_sock -e SSH_AUTH_SOCK=/tmp/ssh_auth_sock -e SSH_AGENT_PID is what I pass to custom containers (crops seems to require this from my shell history)
<qschulz>
-v ~/.ssh/known_hosts:/home/pokyuser/.ssh/known_hosts:ro also
<qschulz>
but really, you should just use whatever is already available instead of reinventing the wheel
<qschulz>
if it does not fully match your use case, you can patch/fork/contribute to it and or extend it
<qschulz>
RP: I like the argument being "the layer works with multiple poky releases without doing anything". Literally in the same sentence or the next one "I just needed to backport this class"... So are you saying it is in fact not compatible :D?
<wyre>
qschulz, you mean when you do the docker run command?
tnovotny has joined #yocto
<qschulz>
and yeah, I've circonvened that check at my previous company too.. And considering how many warnings there were when I arrived and how concerned the devs were about them, we sure don't want to turn it into a warning :D
<wyre>
qschulz, also ... where should I specify ssh as protocol for yocto?
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<qschulz>
wyre: see the link to the git fetcher
<qschulz>
wyre: yes, for CROPS i add those arguments to podman (should be more or less the same for Docker) when running the container
<qschulz>
Pyrex should be doing it for you IIRC
<RP>
kanavin: with the warnings/errors you need to get them under control over time
<RP>
kanavin: I was wondering about rngd, whether it really was using all the memory and why
prabhakarlad has joined #yocto
<kanavin>
RP: I am watching another lttng stress-test going on now. ps aux give:
<wyre>
qschulz, ok, I've set SRCREV as ${AUTOREV} but bitbake is not able to fetch the repository, despite I'm able to clone it with git:// (ssh) from the inside of the container
<wyre>
I can see a message saying "fatal: Unable to look up git@gitlab.com (port 9418) (Name or service not known)"
<wyre>
qschulz, I mean, I didn't replace git with ssh 😞 I'm not sure why bitbake is printing urls with ssh://
<qschulz>
then I guess try with / instead of : in the URL since it says it cannot resolve git@gitlab.com:whatever. After that, I'm clueless sorry
florian has joined #yocto
<wCPO>
When would I use do_<stage>[depends] over just DEPENDS ?
<kanavin>
RP: not too worrying for master branch. There's a botched upstream release of libjitterentropy in my branch, with that reverted rngd is back to normal.
<RP>
kanavin: good to at least know the cause, thanks!
Xagen has quit [Ping timeout: 252 seconds]
<kanavin>
RP: this means we may have achieved issue-free ptests for lttng - I'll run the robustness tests a few more times. They've yet to fail on arm.
<kanavin>
(I hope the x86 fail was in fact due to rngd)
<wyre>
qschulz, now it works, thank you 😀, the problem now is that python3 cannot find setup.py but I guess I can deal with it
<qschulz>
wyre: :+1:
Xagen has joined #yocto
leon-anavi has joined #yocto
<fbre>
Hi, if the .c file is located in .../build/tmp/work-shared/mymachine/kernel-source/drivers/net/ethernet/freescale, in which folder does bitbake put the .o file?
<fbre>
...on building the kernel
<RP>
kanavin: I think that lttng-relayd segfault is still out there but yes, it is good progress
<kanavin>
RP: I haven't seen that yet with 2.13.0 versions
<qschulz>
fbre: in the tmp/work/mymachine/<linux-kernel-recipe>/<linux-kernel-version>/<git probably>
<wyre>
qschulz, should S be set as the same folder where setup.py is?
<wyre>
I don't get why it says pwm/pwm.sh doesn't exist but it's there 🤔 https://bpa.st/F32Q
<qschulz>
wyre: likely yes, or set DISTUTILS_SETUP_PATH correctly
<RP>
kanavin: it is relatively rare and I think load related, you're on relatively quiet autobuilders
<qschulz>
wyre: you probably need to add ${S} or ${WORKDIR} in front of your pwm/pwm.sh path
<RP>
kanavin: are we looking better on the multiconfig change?
<kanavin>
RP: yes, I think I wrote a comment in the bug about it
<wyre>
qschulz, I'd say before I had not to add ${S} but now apparently I need it, you are right :think
<wyre>
🤔
<qschulz>
wyre: do_install runs in ${B} IIRC
<qschulz>
it's set to S by default IIRC but there is probably something changing it then
<fbre>
A while back I switched to the free version because people here recommended that to me
<fbre>
I'm not sure, but am I right meta-freescale is the alternative community version and meta-imx is the vendor version?
<fbre>
sorry for asking odd questions, I'm just trying to recall
<fbre>
...what I have forgotten
<qschulz>
that's what I said a few lines above :)
<fbre>
ok, thanx
<qschulz>
since meta-frescale is community maintained, patches are welcome, if you want 5.10 ASAP, you can add support for it and then contribute back to the layer :)
<fbre>
no, I don't want it, I just check what is available. Because I check the newer sources of all those available branches. And I compare them against my "old" dunfell version. I want to know whether a ethernet driver bug is fixed or not.
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<fbre>
I already check the branch "hardknott" of meta-freescale. But that ugly ethernet driver bug still happens after I merged those newer sources back to my old dunfell sources
<wyre>
but I'm not sure why I have not that binary in my image
<wyre>
however I have i2ctransfer 😥
<qschulz>
and the oe-pkgdata-uitil returns something for i2ctransfer?
<wyre>
qschulz, sure, busybox-ptest
<wyre>
but I've i2c-tools in my image recipe!
<wyre>
oh, just in PKG_DEBUG 😥
goliath has joined #yocto
<RP>
kanavin: that zstd compression thing looks like the number of threads is getting encoded into the rpms somehow which is bad :/
<RP>
kanavin: are the rpms the same with varying numbers of compression threads?
<kanavin>
RP: I had already fixed it, I just would like to know how poisoned items made it into reproducible builds (which are not supposed to utilize sstate)
<kanavin>
the reason it's not seen with xz is because AB hardcodes the number of threads
<RP>
kanavin: reproducible builds use sstate for half the build
<kanavin>
RP: but the other half is also saying 'zstd'
<kanavin>
from the abelloni's likn
<RP>
kanavin: both sides of the build looked to encode it in that build, yes
<RP>
kanavin: I think abelloni used the series from the mailing list
<kanavin>
RP: right, those were before I added the fix
<RP>
kanavin: that would explain things
<kanavin>
and it was marked as RFC, meaning, do not queue into builds ;)
<RP>
kanavin: abelloni and I are trying to work out how to queue the non-master patches that are still flowing in. Leaving them just ends up as a different kind of nightmare (hence the kirkstone-next brancht that appeared)
<JPEW>
Ugh, is that zstd thing specific to rpms? I didn't see that when I used the standalone utilities
<kanavin>
RP: right, but that particular RFC set shouldn't be queued - it was strictly for comments, and will be resent later when things reopen for merging
<kanavin>
JPEW, nothing is broken, there was just a mixup with not fully tested patchset
<JPEW>
Ah got it
* JPEW
needs more coffee
paulg has joined #yocto
Belsirk is now known as rfuentess
<RP>
kanavin: if the right set is ready now I'm wondering if we should queue that just so people know what is done and what isn't?
jwillikers has joined #yocto
<yates_work>
in meta/recipes-devtools/gcc, there are several recipes related to gcc, e.g., gcc_{pv}.bb, gcc-cross_{pv}.bb, gcc-cross-canadian_{pv}.bb, gcc-source_{pv}.bb, etc. is there a document describing what each of these is for?
<yates_work>
i need to modify the way crti.S is assembled for our cross-gcc, and there are multiple crti.S files and multiple recipes involved. i am confused.
<yates_work>
there is also the libgcc stuff there, which is one of the packages which contain a version of crti.S, such as libgcc_{pv}.bb and libgcc-initial_{pv}.bb. i'd really like to know what the difference of those is for.
otavio has quit [Quit: leaving]
otavio has joined #yocto
Guest4845 has quit [Ping timeout: 256 seconds]
troth has joined #yocto
tlwoerner has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
raido has joined #yocto
<raido>
Hi Yocto community! I am wondering, is it possible to run any task from `devshell`, like do_configure? When trying to just run the script from /temp/ folder from devshell, it will not work.
<raido>
This will give an error: ./run.do_fetch.4700: line 2: syntax error near unexpected token `(' ./run.do_fetch.4700: line 2: `def do_fetch(d):'
<qschulz>
raido: I assume you need to prefix this with `python` since it's probably a python taks
<raido>
it is a python task. Sorry, did not mention that yes, running as ```python run.do_fetch.4700``` will give similar error:
<raido>
Traceback (most recent call last):
<raido>
File "run.do_fetch.4700", line 6, in <module>
<raido>
do_fetch(d)
<raido>
NameError: name 'd' is not defined
<qschulz>
mmmm I think there's devpyshell too? don't know what it's for though
<raido>
May be my yocto version is too old, it doesn't have devpshell :(
<raido>
and.. I have not heard it about anyway
<raido>
sorrry...
Guest61 has quit [Ping timeout: 256 seconds]
tnovotny_ has quit [Read error: Connection reset by peer]
<Guest45>
is it possible to set partitions permissions using a wic kickstart file? "part /data --ondisk mmcblk0 --fstype=ext4 --label data --align 4096 --size=5000"
<sgw>
what am I getting blamed for now? Everyone knows I am a trouble makers!
<RP>
sgw: from 2013!
<sgw>
Just took a while for everyone to catch up to what we were doing!
vd has quit [Quit: Client closed]
fray has quit [Ping timeout: 256 seconds]
<Guest87>
ok I will use the PACKAGECONFIG_remove to get rid of libxml2 in libarchive. that works for me for now.
tnovotny has quit [Quit: Leaving]
<wyre>
I've included lmsensors in my image recipe, and I'm having a message saying "nothing provides lmsensors-isatools needed by lmsensors-3.6.0-r0.cortex7t2hf_neon"
<wyre>
why is that? should I add some extra layer? 🤔
rfuentess has quit [Remote host closed the connection]
Guest45 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
Guest45 has joined #yocto
arunss has joined #yocto
zpfvo has quit [Remote host closed the connection]
<Guest45>
does wic have a way of setting permissions on a partition?
<rburton>
partitions don't have permissions
<rburton>
the file system has permissions
<rburton>
the permissions are set by those at rootfs generation time, and will be the same as what is in the packages
<Guest45>
with wic, i am generating an ext4 filesystem like this "part /data --ondisk mmcblk0 --fstype=ext4 --label data --align 4096 --size=5000"
_whitelogger has joined #yocto
florian has quit [Quit: Ex-Chat]
arunss has quit [Remote host closed the connection]
arunss has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
cocoJoe has joined #yocto
manuel1985 has quit [Quit: Leaving]
arunss has quit [Remote host closed the connection]
arunss has joined #yocto
Guest45 has quit [Quit: Client closed]
<arunss>
I have a custom machine with 64-bit kernel and 32-bit userspace, using multilib. Target builds fine, however SDK seems to compile userspace packages for both 32 and 64-bit arch. Is there anyway I can specify SDK to build only for 32-bit?
florian_kc has joined #yocto
vd has joined #yocto
Glenn has joined #yocto
TMoore has joined #yocto
TMoore has quit [Client Quit]
Glenn has quit [Client Quit]
mfe has quit [Quit: WeeChat 3.2]
BCMM has quit [Ping timeout: 252 seconds]
TMoore has joined #yocto
elfenix|cloud has joined #yocto
<TMoore>
I am trying to dynamically modify the LIC_FILES_CHKSUM in a custom task that executes prior to the do_populate_lic task. I am able to append to the LIC_FILES_CHKSUM using `appendVar` however when the do_populate_lic (or any following task) executes it does not contain any of my appended license files. I see that if I modify LIC_FILES_CHKSUM in an
<TMoore>
anonymous python function the modification is seen in do_populate_lic. I would like to avoid an anonymous function since it is executed several times. Why are changes to the LIC_FILES_CHKSUM removed when the custom task completes? Is there any way to make these updates persist for processing in a different task (e.g. do_populate_lic)?
marc1 has joined #yocto
florian_kc is now known as florian
sakoman has quit [Quit: Leaving.]
yates_work has quit [Remote host closed the connection]
sakoman has joined #yocto
<vd>
openembedded-core has no honister branch?
<smurray>
tmoore: AIUI tasks get their own task-specific copies of the datastore, but RP would be the person who could answer definitively if he's around
<vd>
how do you guys deal with version bump? especially with this override syntax change
<vd>
I cannot bump some layers because they now use the new syntax, but there's no honister branch nowhere so I don't quite understand the expected update process here
cocoJoe has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
Guest87 has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
vd has joined #yocto
* vd
is back
frieder has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<rburton>
vd: honister isn't out yet, use master branch
yannd has quit [Remote host closed the connection]
TMoore has quit [Quit: Client closed]
<vd>
rburton ho ok, makes sense
<vd>
I'll wait
otavio has quit [Remote host closed the connection]
<RP>
smurray: I may be back, tmoore is gone though. Your right FWIW
goliath has joined #yocto
<RP>
You're...
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
lexano has quit [Ping timeout: 265 seconds]
wooosaiiii has quit [Ping timeout: 256 seconds]
wooosaiiii has joined #yocto
xmn has joined #yocto
lexano has joined #yocto
wooosaiiii has quit [Ping timeout: 265 seconds]
wooosaiiii has joined #yocto
sakoman has quit [Quit: Leaving.]
leon-anavi has quit [Quit: Leaving]
sakoman has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
gsalazar has quit [Ping timeout: 245 seconds]
wooosaiiii has quit [Ping timeout: 252 seconds]
wooosaiiii has joined #yocto
prabhakarlad has quit [Quit: Client closed]
bq has joined #yocto
<bq>
Hi all. Aside from implementing my own bbclass, is there a built-in way of banning/disallowing nobranch=1 in SRC_URI?
<bq>
I'm mostly interested in checking that nobody has specified nobranch=1 when committing code to master, since it's a common pitfall our devs fall into for introducing silly/subtle bugs