GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
xmn has joined #yocto
marc1 has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
amitk has joined #yocto
AKN has joined #yocto
<risca>
Man, do_package for ltp-ddt sure is slow on this old build. I started the build of this specific package almost 2 h ago :(
<risca>
This is not a bug report. I'm sure this has been fixed in later yocto/poky releases
warthog9 has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
warthog19 has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
warthog19 is now known as warthog9
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
thomasd13 has joined #yocto
<barath>
morning! question time. If I have a PACKAGECONFIG arg which sets a kernel module parameter, does setting that PACKAGECONFIG fit better into a machine conf or a distro conf? the module is only ever installed for for one machine
<LetoThe2nd>
barath: if the MACHINE triggers it, respectively the need for it is defined through hardware, then it goes into the machine configuration (my $.02)
<LetoThe2nd>
and yo dudX
zpfvo has joined #yocto
gho has joined #yocto
<barath>
hm, the kernel module itself is built due to the kernel config enabling it. the behavior of the kernel module is controlled by this PACKAGECONFIG which belongs to a recipe which installs a modprobe.d options config file and sets the parameter based on this PACKAGECONFIG, so in that way it seemed like policy... :D
<barath>
I guess it's dependent on the machine, ultimately, but also policy in a way
<LetoThe2nd>
barath: if it is policy, then you always have to ask what defines it. is it the ABI/API that is affected by it? then distro. does it relate to hardware? then machine.
<LetoThe2nd>
but of course there are always corner cases, and my opinion is certainly not authorative.
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
<barath>
basically, the parameter toggles some behavior of the kernel module which is hardware related. but whether the behavior should be toggled or not depends on the use case of the image/distro, so that's why I thought policy
<barath>
we'll see how it evolves :D
lamm1 has joined #yocto
leon-anavi has joined #yocto
AKN has joined #yocto
yocti has quit [Ping timeout: 252 seconds]
yocti has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
mvlad has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
yocti` has joined #yocto
yocti has quit [Killed (NickServ (GHOST command used by yocti`))]
yocti` is now known as yocti
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
danielt has quit [Quit: You have been kicked for being idle]
rocto has joined #yocto
rocto has left #yocto [#yocto]
bps has joined #yocto
bps has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
tomzy_0 has joined #yocto
<tomzy_0>
morning
olani has joined #yocto
seninha has quit [Quit: Leaving]
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
d-s-e has joined #yocto
gsalazar__ has joined #yocto
gsalazar_ has quit [Ping timeout: 265 seconds]
d-s-e has quit [Ping timeout: 265 seconds]
d-s-e has joined #yocto
seninha has joined #yocto
gsalazar__ has quit [Quit: Leaving]
gsalazar has joined #yocto
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
AKN has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
olani has quit [Remote host closed the connection]
Starfoxxes has quit [Ping timeout: 264 seconds]
olani has joined #yocto
olani has quit [Remote host closed the connection]
florian_kc has joined #yocto
lamm1 has quit [Ping timeout: 252 seconds]
olani has joined #yocto
AKN has joined #yocto
<qschulz>
does anyone remember how to create a new recipe for a pypi package?
<qschulz>
I remember there's a tool to do it, cannot find it (or cannot execute the script correctly :) )
<JaMa>
devtool?
<qschulz>
devtool add?
<JaMa>
yes, it will call recipetool in the end
<JaMa>
recipetool create <sources>
<qschulz>
and what is <sources> supposed to be?
<qschulz>
(it's a recipe for esptool)
<LetoThe2nd>
qschulz: ah having ESP32 fun too?
<qschulz>
LetoThe2nd: our latest SoM has an ESP32 for WiFi+BT on it :)
<LetoThe2nd>
qschulz: hehe
d-s-e has quit [Ping timeout: 268 seconds]
<qschulz>
i'm looking for the automagic tool to create the recipe because I know one exists
<qschulz>
but I feel like I would have been faster writing it myself by the time I find the tool to do it :D
<LetoThe2nd>
qschulz: fun fact: i am currently working on a number of content pieces / demos that showcase a simple Mender client running directly on the ESP32.
<JaMa>
qschulz: URL to tarball or git repo
<qschulz>
JaMa: get a python backstrace with malformedurl exception :/
<JaMa>
qschulz: what URL did you use?
<qschulz>
JaMa: both the github URL and the tarball in pythonhosted
<qschulz>
JaMa: the issue is in another recipe /me facepalms
<qschulz>
oh no, I'm stupid :)
<qschulz>
I have a u-boot recipe that is machine specific
<qschulz>
and I didn't make it machine specific, so the variables aren't actually set
seninha has joined #yocto
Payam has quit [Quit: Leaving]
<rburton>
PSA: if you're debugging python code, https://github.com/cool-RR/PySnooper is useful. Just pass bb.plain as the output callable and you get code breakdown on the console.
olani has quit [Remote host closed the connection]
Payam has joined #yocto
<Payam>
how faster a yocto build would be if I use a computer with 32 core in comparison on 16 cores?
<Payam>
when it comes to building and not downloading
olani has joined #yocto
demirok has quit [Ping timeout: 260 seconds]
olani has quit [Remote host closed the connection]
<smooge>
Payam, that depends on a lot of things outside of 'number of cores'. What is the memory layout of the motherboard, is there enough RAM per CPU and does the cpu cores actually handle that, what is the cache size of the chips, what is the IO and disk contention of the system (if its one disk then 32 cores only helps a little and you will be in D a lot), etc.
<JaMa>
depends on what you're building
<smooge>
Payam I have seen builds either be faster or slower depending on those and what you are building.
<Payam>
it is a c5-4xlarge runner instance on aws
olani has joined #yocto
<Payam>
same build takes 5 hours with a 8 cores
<Payam>
4x has 16
<Payam>
so I wana try 8x has 32
<smooge>
then you are most likely going to be waiting on 'disk' IO for what you are trying to build. Things which can be 'parallelized' may be faster but I would not expect it to be more than 30% faster with a lot of CPU time idle at times
<LetoThe2nd>
Payam: on average i would say maybe 20%. the sweet spot these days is somewhere in the 16-24 core area, and adding more cores does not give any real advantage. rather optimize your sstate usage, then.
<Payam>
yeah allright
demirok has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Payam has quit [Quit: Leaving]
Payam has joined #yocto
<Payam>
I use the AGL sstate mirror but I get his error : You are using a local hash equivalence server but have configured an sstate mirror.
<Payam>
should I instead use the yocto mirror?
<rburton>
if you're using a public sstate mirror then you also need to use their hashequiv server
<Payam>
how?
<rburton>
if they have a sstate mirror then they should tell you the hashequiv server url too
<mcfrisk>
LAYERSERIES_COMPAT changes to mickledore are applied in various places. should I append kirkstone to that locally when things just seem to work?
<JaMa>
mcfrisk: in most layers where I've changed it to just mickledore is separate kirkstone compatible branch, which layer are you talking about?
marc1 has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
<mcfrisk>
JaMa: meta-clang is latest, it still works with kirkstone
<mcfrisk>
for us it does work and did not hit that with Ubuntu 22.04
<JaMa>
maybe you don't build target clang?
<mcfrisk>
nope
<mcfrisk>
I would like to get us closer to master branches so I'll just overwrite the compat in our higher prio layers (seems local.conf can't do that)
<JaMa>
higher prio cannot do that as well, it needs to be in layer.conf parsed earlier (based on BBLAYERS order)
<Payam>
I used the state mirror on yoctoproject but it didn't help so much
<JaMa>
or you can volunteer to maintain kirkstone-clang15 branch (like there was dunfell-clang12 for newer clang for dunfell)
<Payam>
and I can not find the Hash server for agl
<Payam>
agl is very bad at documenting stuff
<mcfrisk>
yes, needs to be in layer.conf of some layer down in the list of BBLAYERS
<mcfrisk>
maintainer is a bit too much, but I will continue using master and will come with patches if I can fix issues seen there
<JaMa>
khem: ^^
Payam has quit [Quit: Leaving]
florian_kc has joined #yocto
seninha has quit [Quit: Leaving]
seninha has joined #yocto
sakoman has joined #yocto
<RP>
Sad to see a patch removing corgi from the linux kernel :/
goliath has joined #yocto
demirok has quit [Quit: Leaving.]
<barath>
I'm investigating whether I should replace a custom init env script with using oe-init-build-env. do people usually have their own custom init scripts? we can't use the oe-init-build-env script directly, since our checkout of poky is not in what we'd consider the "root"/"top" dir and other layers are outside of the poky dir so all paths relative to oeroot wouldnt be right
<qschulz>
barath: you can use bitbake-layers add-layer with relative/absolute paths to setup your build environment
<kanavin>
barath, I'm not sure why '. /full/path/to/poky/oe-init-build-env' wouldn't work for you
<qschulz>
we have a layer setup tool now since langdale I believe, ahven't used it yet so don't rmember the name but kanavin will be able to help
<qschulz>
some use kas also to set this all up
<kanavin>
barath, people usually do use custom init scripts, but those usually wrap . oe-init-build-env one way or another.
<JaMa>
RP: :( meta-handheld looks also a bit sad
<barath>
hm thanks for those pointers. '. /full/path/to/poky/oe-init-build-env' works, but then my own layer's bblayer.conf.sample needs to do something like ##OEROOT##/../path/to/my/layer. I guess that's okay, just feels odd somehow. our current hacky init script just sets up TOPDIR such that all layers (poky, ours) are under it
<barath>
and my TEMPLATECONF needs to set paths relative to poky as well. I guess it's all just a matter of perspective :D
<kanavin>
barath, ##OEROOT##/../path/to/my/layer is totally fine
<barath>
alrighty. I guess I'm just not used to all paths being relative to poky
<qschulz>
oooh first time I need to add a recipe for something in the public domain!
<rburton>
qschulz: call it MIT, "public domain" is meaningless in the real world
<qschulz>
rburton: "If the Public Domain is not adequate for your purpose, you can instead consider this module under the MIT License as you prefer." kinda weird :)
<rburton>
might as well make it MIT and be done, as public domain is a legal minefield
<qschulz>
rburton: they don't provide a License file with the MIT license content though
<kanavin>
rburton, that's a very sad thing to say
<qschulz>
(will take the one from COMMON_LIC_DIR instead)
<qschulz>
ah shoot, I had forgotten about python3-cryptography moving to rust... that;s going to be an expensive build only to add esptool support at runtime 😭
<rburton>
kanavin: the entire point of cc0 was to formalise 'public domain' into something actually with legal basis
<kanavin>
rburton, yeah, I just find it sad that works without copyright is a 'legal minefield'
<rburton>
there's not worldwide agreement
<rburton>
so if there's no license asserted, what is the license?
<smooge>
depending on which country in the EU you are in, there are different definitions of public domain which mean completely different things. They also only 'cover' certain articles.
<kanavin>
rburton, there isn't. it's like asking a non-religious person what is their religion.
<smooge>
sorry should stay out of licensing conversations.
<kanavin>
but what happens when copyright expires?
<rburton>
kanavin: which suddenly turns from an interesting academic exercise to an expensive legal exercise when the lawyers get involved
<rburton>
kanavin: depends on the juristiction
<kanavin>
I know disney is working hard to make it perpetual, and no significant works had their copyright expired in decades thanks to their efforts
<kanavin>
but it is still supposed to happen, so that our 'culture' can grow
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<kanavin>
RP: patch for qemu reproducibility sen
<kanavin>
t
thomasd13 has quit [Ping timeout: 268 seconds]
<rburton>
qschulz: the licence checksum is a way of validating the license, so the fragment of the readme that says "public domain, fallback to MIT" is sufficient
<qschulz>
rburton: ah, because the license file is actually matched from LICENSE variable?
<rburton>
correct
<qschulz>
thx
<rburton>
the checksum is for telling the maintainer that the license strings changed
demirok has joined #yocto
<rburton>
so if they relicened the next release to gpl, you'd get shouted at by bitbake
<qschulz>
yup, that I knew, I just had forgotten which variable "controlled" the license files to be included
<moto-timo>
qschulz: then add 'pypi' to inherit and drop the SRC_URI and the extra checksums... then begin the joys of dependencies (e.g. you need python3-reedsolo')
zpfvo has joined #yocto
<rburton>
yocton: 👋
<yocton>
Hi!
<moto-timo>
yocton: 👋
<qschulz>
moto-timo: ah I thought there was something already, or was there just someone who started the discussion and I h appened to be there at that time and took it as granted?
<qschulz>
moto-timo: yeah, that's what i've done so far
<qschulz>
moto-timo: there may be some discussion around python3-esptool recipe I made though
<qschulz>
we'll see :)
<qschulz>
python3-reedsolo has no dependency, but its setup.py scares me a bit, we'll see
<moto-timo>
qschulz: this is one case where 'esptool' might be the right name for the recipe... we should see what Debian named it (assuming it is available)
<qschulz>
(basically esptool pypi package contains three tools, and you don't necessarily need those three tools)
<moto-timo>
qschulz: the "rule" is "is it a tool or a library"
<moto-timo>
qschulz: ah, yes...
<qschulz>
(one of them requiring python3-cryptography, I'd rather split them into three different packages)
<qschulz>
(especially since I need the one that does NOT need it :) )
<moto-timo>
qschulz: that is fine... then you would want to use the PYPI_PACKAGE = "esptool" in each of the recipes so it reuses the SRC_URI (off the top of my head)
<qschulz>
moto-timo: esptool in debian
<qschulz>
moto-timo: actually, since they are runtime dependencies only, a single recipe with three different packages should be jsut fine no?
<qschulz>
been waiting for python3-cryptography and its dependencies to compile for the last 1h30
<moto-timo>
welcome to Rust!
<qschulz>
I was so happy with my small builds
<qschulz>
and then I got the request to add esptool and nmcli to our images
<qschulz>
less happy now :)
<qschulz>
(nmcli brings mesa, wayland and whatnot)
<moto-timo>
I had a probably already mangled host struggling to build rust-native, nodejs and (a broken) u-boot at the same time yesterday... it crashed the terminal twice ;)
<moto-timo>
mangled == swap was maxed
<qschulz>
(I could probably slim it down but it's just demo images we provide, so not really worth it to sink hours in it)
<qschulz>
moto-timo: my poor laptop with i7-10510U and 16gb of RAM salutes you :)
<moto-timo>
FWIW that recipe looks good... I am sure there is a way we could disable the py3-crypto build, but ... sigh
<moto-timo>
qschulz: you might want BBCLASSEXTEND = "native" ? don't know if esptool would be desireable in other recipes or not
<qschulz>
moto-timo: thanks, you said the recipe should be rather called esptool than python3-esptool?
<moto-timo>
qschulz: it's a case where it _could_ reasonably be called esptool, but IMHO python3-esptool is ok too
<qschulz>
moto-timo: I don't think so no, at least doesn't come to mind. Though... one usecase could be to build esptool so that it can be run from the host to flash the device (outside of Yocto)
<qschulz>
moto-timo: what I struggle with is that esptool is both the name of the repo/pypi package and the name of one of the scripts it contains
<moto-timo>
qschulz: yeah, I think leave it python3-esptool is fine
<moto-timo>
qschulz: as for flashing outside of Yocto that probably hints at BBCLASSEXTEND nativesdk ;)
<qschulz>
should I have a package called python3-esptool-esptool :D ?
<moto-timo>
or set PACKAGES to the three tool names?
<moto-timo>
which would mean allow empty PN
<qschulz>
yeah, I have python3-esptool, python3-esptool-espefuse python3-esptool-espsecure right now
<moto-timo>
qschulz: but Debian is on ancient 2.8 version :/
<qschulz>
moto-timo: yes, there's a reason we're not using it but pip's :)
<qschulz>
moto-timo: not related to native/nativesdk your link right?
<rburton>
ndec: yay more yocto store credit. shall i buy another very bright hoodie? :)
<moto-timo>
qschulz: right, I meant related to package split discussion
<qschulz>
moto-timo: I have files in /usr/lib/python*/site-packages/ so I believe this should be covered
<qschulz>
but now I'm curious what debian did
<ndec>
rburton: heh.. sorry about the delay.. there was a problem with getting the redeem codes.. but all speakers should have their code now!
<rburton>
i've got two messenger bags but that yocto one is pretty sweet, just not sure when i'd use it unless i can convince my son its a cool school bag
<qschulz>
ndec: rburton: shoot, i'll have to present again to get myself some swag
mvlad has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 272 seconds]
gsalazar has joined #yocto
leon-anavi has quit [Quit: Leaving]
gsalazar has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
Minvera has quit [Remote host closed the connection]
roussinm1 has quit [Ping timeout: 268 seconds]
gsalazar has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
bps has quit [Ping timeout: 252 seconds]
<RP>
JPEW: I think I've done something dangerous with bitbake and the threading. My worry is that the server/process code now has two threads and in one of the threads we do the parsing using multiprocessing.Process :/
<RP>
We're careful that we don't hold locks with the fork() would occur but I suspect there can be potential issues
gsalazar has quit [Ping timeout: 268 seconds]
<JPEW>
RP: oh ya. Didn't think about that. Threading and forks don't mix
<RP>
JPEW: I have a second issue that when we create the parser Process() processes they inherit and keep full copies of the Cooker object in memory even if it isn't referenced. We can't just start from scratch in the parser thread though as there is context we do need
<JPEW>
Why is that a problem?
<RP>
JPEW: every parser process is ending up with an RSS of 1.6GB locally. Copy on write in the kernel helps most of the time, until python gc kicks in
<JPEW>
Ooff
<JPEW>
RP: this would only be seen on the second time parsing is done with memory resident bitbake?
<JPEW>
Or is it all the time
yashraj466 has quit [Quit: Client closed]
<RP>
JPEW: even single threaded, it can be an issue with a partially valid cache from disk with parsing needed for some subset of recipes
<RP>
er, even single instance
<RP>
obviously memory resident with the new cache triggered makes things a lot worse