qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
jmiehe has quit [Quit: jmiehe]
kevinrowland has quit [Quit: Client closed]
starblue has quit [Ping timeout: 256 seconds]
dev1990 has quit [Quit: Konversation terminated!]
starblue has joined #yocto
sakoman has quit [Quit: Leaving.]
vquicksilver has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
jclsn79 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn79 is now known as jclsn7
pgowda_ has joined #yocto
yolo has joined #yocto
<yolo>
parsing is a bit slow with yocto, is it possible to write that portion in languages other than python?
davidinux has joined #yocto
kroon has joined #yocto
<Saur[m]>
Theoretically yes, practically no. Suggested workaround: get a faster computer. ;)
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
mrybczyn has joined #yocto
leon-anavi has joined #yocto
rob_w has joined #yocto
frieder has joined #yocto
lucaceresoli_ has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<barath>
good morning
xmn has quit [Ping timeout: 256 seconds]
tnovotny has joined #yocto
leon-anavi has quit [Quit: Leaving]
rob_w has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
rob_w has joined #yocto
florian has joined #yocto
florian_kc has joined #yocto
<rburton>
yolo: probably quicker/easier to rewrite the parser in python
<rburton>
(better python)
GillesMM has joined #yocto
GillesMMM has joined #yocto
GillesMM has quit [Client Quit]
florian_kc has quit [Quit: Ex-Chat]
mihai has quit [Quit: Leaving]
<RP>
the issue isn't parsing, it is processing all the dependencies between variables
vquicksilver has joined #yocto
mauro_anjo has joined #yocto
rob_w_ has joined #yocto
rob_w has quit [Read error: Connection reset by peer]
<mauro_anjo>
I'm trying to silence u-boot uart output on a raspberry, followed https://tinyurl.com/5cwhfpjn but it only stoped writing after loading env from FAT, it still prints first few lines stating u-boot version, DRAM, etc
<mauro_anjo>
my recipe appends the configs to build u-boot in silent mode, but I added "setenv silent 1" to boot.cmd.in, there is an option on u-boot CONFIG_EXTRA_ENV_SETTINGS, I should append to it, but not sure how to do it since .cfg files are just attributions if I'm not mistaken
<qschulz>
mauro_anjo: the environment is loaded pretty late in U-Boot boot process
<qschulz>
so if you don't want anything printed by U-Boot, you need to use compile time options and not use the environment
<qschulz>
note that U-Boot has been changing a lot over the last decade and variables that used to be defined in board header files are moved to KConfig options
<qschulz>
What I highly suggest is you try to manually compile and configure U-Boot until you get something you're satisfied with and then and only then do you work on integrating the required changes into Yocto
<qschulz>
and that first part can be tackled with the help of the U-Boot community on #u-boot IRC chat
leon-anavi has joined #yocto
jorschulko has joined #yocto
<mauro_anjo>
@qshulz Yeah I was struggling with board headers for now, Thanks! Will check KConfig options and test it separetely
<qschulz>
if it's incorrect (missing your option), then 2) bitbake-layers show-appends nginx
<qschulz>
if your bbappend does not appear, check that your layer is in conf/bblayers.conf
<qschulz>
if your layer is there, 3) bitbake-layers show-layers and check it's found by bitbake
<qschulz>
4) check that your layer.conf has ${LAYERDIR}/recipes-*/*/*.bbappend in BBFILES in conf/layer.conf
jmiehe has joined #yocto
<jorschulko>
qschulz: Thanks, stupidity confirmed. I accidently had my bbappend file in recipes-httpd/nginx_%.bbappend instead of recipes-httpd/nginx/nginx_%.bbappend *facepalm*
<qschulz>
jorschulko: not the first one to whom this happened, and not the last one :)
mvlad has joined #yocto
<jorschulko>
qschulz: you would think after over a year of yocto stupid stuff like this wouldn't happen :D
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
manuel1985 has joined #yocto
<RP>
michaelo: do you use a couple of different environments to send patches? One of them works well, the other corrupts the sender address :/
<RP>
some arrive as "Michael Opdenacker via lists.openembedded.org <michael.opdenacker=bootlin.com@lists.openembedded.org>" and they're annoying to handle, others come through correctly
* RP
tends just to handle it quietly else everyone will just start saying how wonderful github/lab/whatever is
<qschulz>
RP: I'm wondering if this is not sent via the WebUI of the mailing list?
lucaceresoli_ has quit [Ping timeout: 256 seconds]
<RP>
qschulz: it is usually when the mail is sent from an IP address not authed to send that email according to some of the spam protections
<jclsn[m]>
Can the sstate-cache be corrupted?
<jclsn[m]>
Me and my colleague are building the exact same build with different results
<rburton>
how are they different?
<jclsn[m]>
I am getting a kernel panic
<jclsn[m]>
All repositories and commits are the same
<rburton>
during the build, or on boot on the target?
<jclsn[m]>
I already deleted all layers and the build folder and rebuilt
<jclsn[m]>
on boot
<jclsn[m]>
I have tried two target boards and two different SD cards
<jclsn[m]>
Very unlikely that both have a defect
<rburton>
if you're using a recent release then the outputs should be identical, so you can compare the RPMs to see if they're actually the same or if there's a weird bug in a recipe you're using
<jclsn[m]>
If I delete the sstate-cache now, I will at least have to wait 5 hours
<jclsn[m]>
Well, it works for him
<jclsn[m]>
Same recipes
<jclsn[m]>
Same layers
<jclsn[m]>
Same commits
<rburton>
so the binary output should be identical, so compare it and see
<jclsn[m]>
Good call
<rburton>
(assuming a recent release, and you haven't turned off reproducible builds)
<rburton>
a shortcut would be to manually put his kernel into your image and see if that works
<jclsn[m]>
Won't there be different timestamps in the images?
<jclsn[m]>
So a diff would be pointless
<rburton>
not if you have reproducible builds enabled
<rburton>
recent release, etc etc
<rburton>
tools like diffoscope will let you ignore timestamps and drill into the files
<rburton>
point it at a known good and known bad rpm directories and it will extract them
osama1 has joined #yocto
<jclsn[m]>
We are both building with Pyrex
<jclsn[m]>
Ah okay
<jclsn[m]>
That is ineresting
lucaceresoli_ has joined #yocto
<jclsn[m]>
Will there be some overhead when activating reproducible builds?
<rburton>
no
<jclsn[m]>
Good
<jclsn[m]>
My colleague doesn't like the idea for some reason ^^
<rburton>
reproducible builds is on by default in modern poky, and is full of advantages
<jclsn[m]>
Oh my
<jclsn[m]>
Ah okay, so they should be already reproducible?
<rburton>
if you're using modern poky, yes
<jclsn[m]>
Although I don't have it set in my local.conf?
<jclsn[m]>
Ah I can check
<jclsn[m]>
Yes it is
<rburton>
so if your assertions are true: same layers at the same commit inside pyrex containers, the images should be bit-for-bit identical
<rburton>
well, we only fix reproducible failures in oe-core, so your own recipes may not be reproducible
<jclsn[m]>
So I would have to check all non oe layers for that
<jclsn[m]>
I don't think that it would be worth the hassle then
<rburton>
if its a kernel hang then its likely the kernel is the problem anyway right
<rburton>
so swap kernels
michalkotyla has joined #yocto
jorschulko has quit [Quit: leaving]
<jclsn[m]>
Sent him the whole image already
<michalkotyla>
Hi all! I see Yocto wiki says LTS releases should be maintained initially for 2 years, but Dunefell (released at 2020) will be supported until 2024. Is a chance (at this day) for future LTS (Kirkstone 3.5) to get additional 2 years of maintaince like Dunefell?
yolo has quit [Remote host closed the connection]
<rburton>
michalkotyla: its a possibility.
<rburton>
michalkotyla: can't say now what will happen in two years time
<rburton>
basically: member companies wanted to keep dunfell maintained for longer, and committed cash to pay for the maintainer. that may happen for kirkstone in two years time, it may not.
<rburton>
if you work for a company which wants to advocate for longer LTS cycles, then they should join the yocto project and say so :)
<michalkotyla>
Thanks for the answer rburton. Discussions of member companies with maintainers about extending maintenance time are available in some public space, or it is non-confidential channels and I can look only for "Release activity" table on Yocto wiki?
<rburton>
some is public, the weekly call on tuesdays discusses this sort of thing
kroon has quit [Quit: Leaving]
michalkotyla has quit [Ping timeout: 240 seconds]
BobPungartnik has joined #yocto
camus has quit [Quit: camus]
BobPungartnik has quit [Client Quit]
<jclsn[m]>
rburton: He built on his Ubuntu 20.04 host with kas and I built with Pyrex. Could this really be the cause?
<rburton>
jclsn[m]: possibly. different host tools can cause annoying problems. easily tested: get him to test in pyrex.
<jclsn[m]>
I don't see how a different build environment would break the kernel...
<rburton>
right, the usual host changes cause kernel build failures, not runtime
<jclsn[m]>
Yeah I would also assume that this would result in build failures, not runtime
<jclsn[m]>
@JPEW ?
<jclsn[m]>
JPEW: ?
<jclsn[m]>
Can you explain hat?
<JPEW>
jclsn[m]: It really just depends on what the changes are
<jclsn[m]>
I will run cleanall on the kernel and rebuild
<JPEW>
jclsn[m]: It's hard to speculate on what the problem might be
<jclsn[m]>
JPEW: Yeah, but really problematic for me as you can imagine, as I am trying to introduce tools like kas and Pyrex.
<jclsn[m]>
I need to investigate this further...
xmn has joined #yocto
jtoomey has joined #yocto
<qschulz>
jclsn[m]: check that you don't have your kernel in devtool workspace for example
<LetoThe2nd>
just ran into a recipe that uses rsync in do_install. just to confirm - this is both unsafe in terms of leaking permissions and users, as well as a hidden dependency on rsync? or is rsync in the default hosttools/-natives?
<jclsn[m]>
qschulz: Did that already
<jclsn[m]>
Besides, I already deleted the build directory and rebuilt
<rburton>
LetoThe2nd: see HOSTTOOLS in bitbake.conf. no, it's not in there.
<rburton>
LetoThe2nd: is it using rsync as a fast way to recursively copy stuff?
<LetoThe2nd>
rburton: thx. yes, close. recursively copying while maintinaing symlinks.
<qschulz>
jclsn[m]: did your colleague have a clean build directory too? etc... but good luck investigating this. And regardless if it's a pyrex/kas issue, a different build output for the same commits is bad
<qschulz>
at least it's an obvious issue with a kernel panic. Imagine if it was a small change somewhere that you wouldn't have known for months./years :)
<jclsn[m]>
qschulz: It is a galcore issue. Which package provides galcore? I need to clean that one. Else I will need to rebuild everything...
<jclsn[m]>
He built everything from scratch. If there is an issue, it is probably on my side
<jclsn[m]>
Another thing is that I keep all meta-layers checked out per board folder
<qschulz>
jclsn[m]: FWIW, I just ran into an issue with kas because it overrides the whole local.conf file instead of appending to the poky's local.conf.sample. And I had an issue with kas builds only but not local builds (because I was source'ing oe-init-buildenv and not using kas's local.conf)
<qschulz>
I mean, the issue is not with kas, it's just I didn't check carefully enough
<qschulz>
so triple check your local.conf too (don't remember if you did already?)
<qschulz>
I don't like wrappers if a simple docker/podman command can do the trick :)
<jclsn[m]>
qschulz: Thanks, but there is no way that I can introduce a third tool now
<jclsn[m]>
Seems like a wrapper around kas...
<moto-timo>
That podman trick should be more widely shared ;)
<smurray>
LetoThe2nd: I've seen rsync used like that in a couple of vendor BSPs (one of which insists on using it from the host, iirc). I believe linux-libc-headers uses it, so it's not that out there
<LetoThe2nd>
smurray: yeah, and being pulled in via DEPENDS rsync-native. well, I guess it works, but I don't particularly like it.
pgowda_ has quit [Quit: Connection closed for inactivity]
<smurray>
LetoThe2nd: it's definitely something where naive use could cause issues. I can imagine it saving some painful find+exec command shenanigans, though
<LetoThe2nd>
smurray: the cse where I ran into it is not that dynamic. well i'll see. thanks for the input.
<jclsn[m]>
I am really running into a tooling jungle here
<jclsn[m]>
Problem is I dislike the kas shell, because it doesn't work well with zsh
<rburton>
you can do kas setup or whatever to generate the build tree, and then bitbake normally
<jclsn[m]>
Pyrex is so convenient, but two tools are maybe a bit bad
<jclsn[m]>
kas doesn't provide a bitbake environment though
<jclsn[m]>
Only in the shell
<rburton>
sure it does
<jclsn[m]>
And I also want a reproducible build environment
<rburton>
"kas checkout"
<jclsn[m]>
I don't have bitbake after that
<jclsn[m]>
Just checked
<rburton>
yeah you need to oe-init-build env yourself
<rburton>
but it writes the config and checks out the layers
<jclsn[m]>
Yeah but then I am building on the host
<jclsn[m]>
We all have different Distros
<jclsn[m]>
kas-container didn't work for me
<jclsn[m]>
Seems like it expects a certain tree structure
<jclsn[m]>
Didn't find my sstate-cache etc
<rburton>
the docs tell you how to set those up
<rburton>
iirc you just set DL_DIR and SSTATE_DIR in the environment
<jclsn[m]>
There is my structure. I was also wondering if it is problematic to have the source checked out multiple times, because they contain the layers
<jclsn[m]>
* There is my structure. I was also wondering if it is problematic to have the layer checked out multiple times, which are in the sources folders
Thorn has joined #yocto
rob_w_ has quit [Quit: Leaving]
osama1 has quit [Ping timeout: 240 seconds]
osama2 has quit [Ping timeout: 256 seconds]
osama2 has joined #yocto
osama3 has joined #yocto
osama2 has quit [Read error: Connection reset by peer]
<tlwoerner>
qschulz: if you're generating bmap files with your images you can use bmaptool instead of dd and it will flash your sd cards faster
prabhakarlad has quit [Quit: Client closed]
<tlwoerner>
rburton: i'm confused why you say kas-container isn't packaged as part of kas? it's part of https://github.com/siemens/kas.git (?)
<rburton>
tlwoerner: when i last pip installed kas, it didn't install it
<tlwoerner>
rburton: ah, pip. ok
prabhakarlad has joined #yocto
Minvera has quit [Remote host closed the connection]
ecdhe has quit [Remote host closed the connection]
<tlwoerner>
(if you don't have bmaptool installed on your host, or want to use the one from oe-core)
Minvera has joined #yocto
<qschulz>
tlwoerner: I naively passed --bmap argument to bmaptool copy. is it not needed?
<tlwoerner>
i don't
<tlwoerner>
it'll find the *.bmap file if it's also in the same directory as the <image>
<qschulz>
nice :)
<tlwoerner>
and if it doesn't find it, it'll complain
<qschulz>
tlwoerner: wondering if a bmap-tools-native compiled inside a container can be used outside?
<qschulz>
(but anyway, I'm building on a server and flashing from my PC so won't help me so I'd rather not document something I don't use/maintain, but great tip!)
<tlwoerner>
qschulz: i don't know
<moto-timo>
should be able to just pass the command to the container
manuel1985 has quit [Quit: Leaving]
<qschulz>
tlwoerner: I assume all libs are from the sysroot, so I guess it should just work (provided you're flashing from a Linux system :) )
ecdhe has joined #yocto
<qschulz>
moto-timo: I would need to mount the device inside the container too, and since it's a rootless container...
<moto-timo>
Yeah, bund mount with uid:gid perms…
<moto-timo>
can’t type
<JPEW>
qschulz: Through extreme dark arts of uninative, you can usually run host tools built in the container outside of the container, as long as all the paths match
<qschulz>
JPEW: good thing I like to keep the paths the same inside the container and outside :)
<otavio>
qschulz: most distros offer bmap-tools as a package; you can install it
GNUmoon has quit [Remote host closed the connection]
<qschulz>
otavio: I was talking about the oe-run-native bmap-tools-native bmaptool copy trick. I'll document with bmaptools anyway but won't explain how to get it from Yocto :)
dev1990 has joined #yocto
lucaceresoli_ has quit [Remote host closed the connection]
lucaceresoli_ has joined #yocto
frieder has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
prabhakarlad has quit [Quit: Client closed]
mrybczyn has quit [Quit: Client closed]
florian_kc has joined #yocto
osama3 has quit [Ping timeout: 256 seconds]
xmn has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
yolo has joined #yocto
<yolo>
git clone bitbake into ubuntu 20.04, then do: bitbake -h, it shows: DeprecationWarning: Using or importing the ABCs from 'collections' and I need install python_is_python3, question: is yocto still using python2? or has it updated to python3 fully already.
<smurray>
yolo: it's been using python3 for a long time now, that warning is from a deprecation Python did something like 3.9 or 3.10. I believe some fixes went into bitbake for that, so I'm surprised you'd be seeing the warning
<smurray>
yolo: from looking in git, removing the collections.abc use happened last fall, and it was backported all the way to dunfell (last Oct), so perhaps would be good to check what version you're cloning
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<yolo>
smurray: i'm on master of bitbake
<yolo>
even yocto3.4.2 tag checkout for bitbake still give me the same warning
<vvn>
how do you guys usually update the fstab? do you rely only on the .wks file, bbappend base-files or edit ${IMAGE_ROOTFS}/etc/fstab in the image recipe?
<yolo>
default python on ubuntu 20.04 for me is: python -V 3.8.2
<yolo>
just switched to python3.10, no such warning, so it only applies to 3.8 I guess, which is ubuntu 20.04 default
vladest has quit [Quit: vladest]
<smurray>
yolo: 20.04 focal has newer 3.8 in it's updates, with the 3.8.10 in my 20.04 container image here I don't see that warning with bitbake master
<yolo>
i had it with 3.8.10 though
vladest has joined #yocto
<smurray>
yolo: I don't see it here, not sure why that would be. Note that you don't need python_is_python3, but I don't believe it'd have this effect
<yolo>
it's ok, last time with bitbake is a few years ago, as long as it's python3 all is good
<yolo>
thanks
yolo has quit [Quit: Client closed]
<jclsn[m]>
Is there a command line version of the Yocto documentation. That would be so great...
<jclsn[m]>
?
florian_kc has quit [Ping timeout: 250 seconds]
<rburton>
what's a command-line version?
<rburton>
you mean, man format?
<rburton>
sphinx can do that, patches welcome for any tweaks needed
prabhakarlad has joined #yocto
<jclsn7>
rburton: Yes exactly
<jclsn7>
Not sure how that would work though
<jclsn7>
Seems like a lot of work
sakoman has quit [Quit: Leaving.]
florian_kc has joined #yocto
<rburton>
jclsn7: without any changes, 'make man' writes a man page for the entire docs
<rburton>
so i expect its not that hard to get it to make a page-per-section
<rburton>
no, make man in the documentation directory
<rburton>
you need sphinx and the template, obviously. pip can install those.
<jclsn7>
I already created a sphinx project
<jclsn7>
So I need to downlod the Yocto docs?
<jclsn7>
How?
<rburton>
they're part of poky
<rburton>
personally the html is way easier to read and search, but <shrugs>
<jclsn7>
It is mostly lazyness
<jclsn7>
The mouse is lava
<kergoth>
yeah sphinx lets you easily map man page title to document page. not sur eif it lets you set the section, but.. the issue is just much of the docs don't fit well into a man page style structure and conventions, i think
<kergoth>
could see having proper man pages generated by sphinx for the actual cli tools
<jclsn7>
I would like something like the vim docs that I can jump through
<kergoth>
Ah, that's not really the same format, it has more explicit linking between docs afaik. It's an interesting idea though
<kergoth>
Could you not just use a console browser to browse the existing html documentation?
<neuberfran>
How to active remoteproc in harknott/yocto/technexion device imx7d-pico
<neuberfran>
?
<kergoth>
Hmm, sphinx can also output epub, which is another html based format, but in ebook style navigation, wonder if that'd be browsable in a console
<kergoth>
IHmm, bet sphinx's man page output would combine well with the sphinx argparse plugin for actual tool man pages..
<khem>
kergoth: I am impressed with mdBook project, it generates book out of markdown, rust community uses it everywhere https://github.com/rust-lang/mdBook
<kergoth>
Huh, haven't checked that one out, thanks.
<kergoth>
I know sphinx can use md instead of rst with MyST
<kergoth>
will have to read up on this one htough
<khem>
I really can write only .md 🙂
<kergoth>
I've been trying to put together a decent damn cookiecutter-style project template for my personal projects every once in a while, never got around to finishing it htough