<mcfrisk>
should IMAGE_CLASSES be modified by distro config, build config or image recipes? I can't decide..
<mcfrisk>
or even machine config
Schlumpf has quit [Ping timeout: 260 seconds]
amelius has joined #yocto
<amelius>
hey, is there an easy why to analyse the dot output of bitbake -g?
<amelius>
way
adams[1] has quit [Quit: Client closed]
<qschulz>
amelius: with your text editor
<qschulz>
the .dot files are known to be impossible to be generated by dot
<qschulz>
it'll take an awful amount of the time (like hours) for something that isn't usable (at least that was my experience with the dot files from thud)
leon-anavi has joined #yocto
d-s-e has joined #yocto
frieder has joined #yocto
Schlumpf has joined #yocto
ptsneves has quit [Ping timeout: 240 seconds]
alessioigor has joined #yocto
amelius_ has joined #yocto
amelius has quit [Read error: Connection reset by peer]
kris has joined #yocto
Guest13 has joined #yocto
<Guest13>
hi, everyone.
<Guest13>
i created an image for coral dev board in yocto.
<Guest13>
the layers i use are freescale community(kirkstone) and meta-coral(github.com/mirzak/meta-coral/tree/wip/kirkstone-upstream)
<Guest13>
when i plug in hdmi, nothing appear. only black screen. i connected with minicom from ttyusb0 and when i look at the logs, i dontt see any output related to hdmi such as error, warning, fail. why is hdmi not working? when i plug and unplug a usb, i can see the log of it, but when i plug and unplug the hdmi, i cant see any log about that on minicom.
<Guest13>
log : pastebin.com/8pWPD3u
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
zpfvo has quit [Quit: Leaving.]
<LetoThe2nd>
Guest13: first, the log is not available. second, who do you expect on hdmi? unless you explicitly enable some form of gui, there just won't be anything. the classic way to interact with a board is the serial terminal.
<LetoThe2nd>
Guest13: ok, so you're explicitly building wayland support?
<Guest13>
xwayland, yep
<LetoThe2nd>
never used that so i can't really comment. maybe there is some form of testing utility, like filling the framebuffer?
sa7mfo has quit [Remote host closed the connection]
<Saur[m]>
amelius: It is possible to visualize task-depends.dot, at least if you filter it to the parts that are relevant for you. E.g., if you are looking for some target dependencies, you can filter out all the native tasks. The `gvpr` and `tred` tools from the graphviz package are great for this. For rendering, I use https://pypi.org/project/xdot/
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
<RP>
Saur[m]: The changes I have in mind to improve basehash debugging are going to mean more data over IPC and you have me a bit worried about that now :/
<Saur[m]>
The sample set (your and mine computer) is rather small though...
<RP>
Saur[m]: yes. I wish we knew why the difference :/
<Saur[m]>
I'll see if I can get some colleagues to test and see what it looks like for them.
<RP>
Saur[m]: thanks, more data points would be helpful
d-fens has joined #yocto
Guest13 has quit [Quit: Client closed]
Guest13 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
rfs613 has quit [Read error: Connection reset by peer]
prabhakarlad has joined #yocto
rfs613 has joined #yocto
<d-fens>
hi, build my first image and worked so good success, now i'm structuring stuff and don't want to overengineer; i added a layer 'mydistroname' with distro.conf (just name and version) and the question is: should i move BBLAYERS (meta-poky, mender , rspberrypi...) from bblayers.conf to the layer.conf? does that make sense and is that good
<d-fens>
practice?
d-fens has quit [Quit: Client closed]
d-fens has joined #yocto
<RP>
Ouch. Saving the hash data into the cache doubles parsing time :(
<LetoThe2nd>
d-fens: clearly no, its not only a bad practise, probably it even doesn't work.
<d-fens>
ok, the configuration possibilities and are just quite overwhelming for me being so new into the topic
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<rburton>
amelius_: define 'analyse'
Guest13 has quit [Quit: Client closed]
<qschulz>
d-fens: you can explicit the layer dependencies in your layer.conf
<qschulz>
and if you use bitbake-layers add-layer to add layers to your bblayers.conf, it'll refuse to include it if its dependencies aren't already added
<LetoThe2nd>
indeed but dependency != layer path
<qschulz>
d-fens: there's a new tool in langdale and master for setting the layers up, don't remember the name
<qschulz>
for before, people use other tools, such as kas for example
<qschulz>
LetoThe2nd: not sure why this is important in the context right now? what did I miss?
<d-fens>
ok makes sense, not include but define dependencies
<LetoThe2nd>
qschulz: the question was about movinb BBLAYERS. that points to actual working copies, right? the dependencies just name a kind of identifier, and its still up to you to provide the working copy.
<d-fens>
yep
amelius_ is now known as amelius
amelius is now known as amelius_
Guest86 has quit [Quit: Client closed]
<amelius_>
Saur thanks a lot, that was the answer I was looking for
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest13 has joined #yocto
<d-fens>
totally offtopic: after many years again on irc brings back memories but also when being used to discord i'm really missing the features like having a searchable chat history, emoj reactions, pasting markup code with syntax highlighting ... i see the reason of using foss and thus libera but still, feels like back in the 90ties :)
Guest86 has joined #yocto
Schlumpf has quit [Quit: Client closed]
graham_o[m] has joined #yocto
d-s-e has quit [Ping timeout: 256 seconds]
Guest13 has quit [Quit: Client closed]
<Crofton>
@d-fens no guarantee Discord remains free though. Could be bought by Elon for example
<d-fens>
Crofton, hehe what could _not_ be bought by Elon
<qschulz>
d-fens: the nice thing about old uncool techs is that they are battle-field tested and (reliably) work
<qschulz>
and we cannot satifsy every one :/
<d-fens>
i see and it all good, it's the community that matters, those ping timeouts just give me a warm feeling of nostalgia :)
<qschulz>
d-fens: the trick is to make your IRC client ignore them :)
amitk_ has quit [Ping timeout: 260 seconds]
d-fens has quit [Quit: Client closed]
vmeson has quit [Ping timeout: 240 seconds]
vmeson has joined #yocto
<hmw[m]>
can you do make commands in do_patch ?
__ad has quit [Read error: Connection reset by peer]
ad__ has joined #yocto
<qschulz>
hmw[m]: usually make commands are better located in do_configure or do_compile, why specifically in do_patch?
<hmw[m]>
u-boot build fails and calls for a make mrproper. did a google and a answer suggested to do it manually at the do_patch stage
<qschulz>
hmw[m]: mmmm did you play within WORKDIR of u-boot or are you using externalsrc?
<qschulz>
I don't think this should happen reliably
<qschulz>
(except if you committed temp/binary files)
zpfvo has quit [Ping timeout: 260 seconds]
gho has quit [Ping timeout: 268 seconds]
<qschulz>
hmw[m]: oe_runmake mrproper will probably work. Now if do_patch is a python task (I think it is by default), you can't just append to it a shell command
<hmw[m]>
qschulz: qschulz:no got it on a clean open embedded system aswel
<qschulz>
you'd need to either use do_patch[postfuncs] += ""
<qschulz>
"your-shell-function"*
<qschulz>
or prepend it to another task (e.g. do_configure)
<hmw[m]>
<qschulz> "you'd need to either use..." <- uhh on one system i get function not exist and the other one just works
<hmw[m]>
<qschulz> "you'd need to either use..." <- tnx for now
<jclsn>
JPEW: Sorry, not a prio atm. We need to provide a kirkstone dev image until the end of the week
<jclsn>
I will try again when I find the time
gho has joined #yocto
d-s-e has joined #yocto
zpfvo has joined #yocto
<JPEW>
jclsn: I understand. Sorry it's not working properly
Tokamak has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
<jclsn>
Might be my fault as well
prabhakarlad has quit [Quit: Client closed]
Guest86 has quit [Quit: Client closed]
<vvn>
hi there -- can someone test INITRAMFS_MULTICONFIG="default" so see if it fails as well or not?
prabhakarlad has joined #yocto
<Saur[m]>
RP: Ok, I figured out why I was only seeing 64 kB reads over the pipe. It was a case of PEBKAC. When I had problems with only getting 8 kB read due to having too many pipes, one of the things I had tried was to change read() to read(65536), and I had of course forgotten about it and left it in there when I later figured out that it was the number of pipes that was the real problem. So once the read() was restored, I am now seeing reads > 64 kB. :P
d-s-e has quit [Quit: Konversation terminated!]
gho has quit [Quit: Leaving.]
d-fens has joined #yocto
gho has joined #yocto
<d-fens>
i need to symlink wpa_supplicant.conf to /data/etc/wpa_supplicant.conf so connectivity stays during mender updates, so i added a wpa.bb to my layer and added a do_install() method, how can i make this receipe run only / depend when wpa_supplicant is included in the build and is do_install() the right hook to run after etc/wpa_supplicant.conf is
<d-fens>
added to the image?
<LetoThe2nd>
d-fens: you have to make it an append to the wpa-supplicant recipe. one recipe can not react on anything that another image does.
<vvn>
d-fens: I would simply edit the wpa_supplicant service to use /data/etc/wpa_supplicant.conf instead of /etc/wpa_supplicant.conf
<d-fens>
thanks will try...
florian has quit [Quit: Ex-Chat]
rob_w has quit [Remote host closed the connection]
<RP>
Saur[m]: ok, that is something of a relief! :)
<RP>
Saur[m]: so what we probably need is a check/warning somewhere if the pipesize falls too low
Guest86 has joined #yocto
<qschulz>
RP: wait, CACHE is the directory where the parsing cache is stored?
<qschulz>
wouldn't this be super convenient for faster parsing if we persist it between CI builds (thinking about my usecase of course)
Tamis has joined #yocto
tor has joined #yocto
<rburton>
qschulz: yes, assuming saving ~10 seconds is a worthwhile gain
<vvn>
Damn, 540Go sstate-cache
<rburton>
pah
<vvn>
So guys, INITRAMFS_MULTICONFIG is definitely broken, the simplest build (e.g. beaglebone-yocto/poky) with INITRAMFS_MULTICONFIG="default" results in a bitbake stack trace
<vvn>
with both kirkstone or latest master for bitbake/OE-Core(/meta-yocto)
<rburton>
bug and/or patch please :)
kscherer has joined #yocto
alessioigor has quit [Quit: alessioigor]
<vvn>
rburton: thanks I know how it works, I just reproduced it with the minimal setup...
alessioigor has joined #yocto
jlnM has joined #yocto
<vvn>
and I'm trying to understand to problem to see if I can submit a patch directly
<vvn>
s/to/the/
<d-fens>
hmm. Deeper down the rabbit hole : doing stuff in do_install:append() and also added FILES:{PN} += " \/data \/data/etc \/data/etc/wpa_supplicant.conf \" (multiline) but still get "QA Issue: wpa-supplicant: Files/directories were installed but not shipped in any package" , any hint?
<vvn>
d-fens: don't escape the FILES entries
<d-fens>
oh thats from pasting multi line as one line , they are not escaped just line breaks
<jlnM>
Hello.. i have proble
<vvn>
${PN}
<amelius_>
d-fens what directories are shown to be missing?
<rburton>
jlnM: you've run out of inotify watchers
<amelius_>
jlnM: either your disk is full or you have some BB_DISKMON_DIRS defined
<jlnM>
but on ubuntu 20.04 it dont find pylint3
<rburton>
ignore that
<rburton>
was does "sysctl fs.inotify.max_user_watches" say?
<rburton>
jlnM: ^
<jlnM>
result is fs.inotify.max_user_watches = 65536
<rburton>
set that to about ten times more
<jlnM>
then?
<rburton>
build again
<qschulz>
jlnM: you don't need pylint3, we just recently updated the docs (or soon will) to remove this dependency thanks to feedback :)
<vvn>
rburton: before submitting anything I'm trying to understand the stacktrace caused by INITRAMFS_MULTICONFIG="default": http://ix.io/4g8T
<jlnM>
i am on a virtual box VM with unbuntu 20.04
<qschulz>
jlnM: 1) why a VM 2) did you allocate enough space (Yocto needs *a lot* of it)
GillesM has joined #yocto
d-fens has quit [Quit: Client closed]
xmn has joined #yocto
<rburton>
jlnM: fwiw, if you're on a windows machine, then builds in WSL2 should work and might be faster/easier to manage. If you're on a linux machine, use a container not a whole VM.
manuel_ has quit [Ping timeout: 256 seconds]
Circuitsoft has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
Guest86 has quit [Quit: Client closed]
<jlnM>
i have deleted some files and is OK now... thanks guy....
kscherer has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
gho has quit [Quit: Leaving.]
kscherer has joined #yocto
<RP>
qschulz: yes, CACHE is where the parsing cache is stored
<RP>
qschulz: persisting it between CI runs might work, depends on what other bits of your CI do :)
gho has joined #yocto
<rfs613>
sakoman: finally posted my golang CVE fixes. Forgot to mention they are only needed in dunfell (because it uses old golang-1.14, which is outside the upstream policy of supporting only the last two releases).
<qschulz>
RP: I guess it shouldn't be accessed concurrently as opposed to SSTATE_DIR and DL_DIR?
Tokamak has joined #yocto
<RP>
qschulz: I think there are locks but it wouldn't be recommended. It also isn't relocatable like the others, it has a ton of fixed paths in to the metadata that it is the cache for
<RP>
qschulz: For the 10s parse, making it sharable seems pointless
gho has quit [Quit: Leaving.]
<rfs613>
two of the CVEs that I am suggesting be ignored are a bit interesting: per the NVD they are in "go" package... but they don't affect the go compiler itself. They could however show up in other code build using go (such as docker). The cve-checker won't flag them against other packages, so they will likely go unnoticed.
<rfs613>
I did check docker-moby, opencontainers, and runc sources, and I think those are safe (not 100% sure) but of course there are plenty more things built with go.
gsalazar has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
gsalazar has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
zpfvo has quit [Remote host closed the connection]
manuel_ has joined #yocto
gsalazar has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
<RP>
JPEW: FWIW I tried using the strings/sets as the key directly and it made no difference to the timings
Minvera has quit [Remote host closed the connection]
<RP>
JPEW: 461978 unique strings
<JPEW>
Heh, whats' the one string? "" ?
<RP>
JPEW: max string length is 22300, peak of the lengths graph looks to be about length 33, most are probably under 57
<RP>
JPEW: Frustratingly, I don't know! It could be :/
<RP>
JPEW: good guess! :)
<rburton>
it was going to be "" or "1"
* RP
has made the code exclude that
<RP>
rburton: that is probably second place at 53713 references
jjmcdn has quit [Ping timeout: 268 seconds]
jjmcdn has joined #yocto
jmiehe has joined #yocto
<RP>
JPEW: 10% speedup if I unroll the getstring function into longhand code so function overhead is playing a large part here
<RP>
well, 20% on that code
jpiat has joined #yocto
<jpiat>
Hi
<jpiat>
I'm looking for some help regarding the install of node package in a yocto build. I used devtool with my repository addresses, it created the recipe which ran fine but I don't host the built sources of my typescript on the repository. The problem is that I can't find a proper way to tell bitbake to do a npm run build on my package before copying to