aleksandarsimono has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
PhoenixMage has joined #yocto
goliath has quit [Quit: SIGSEGV]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
amitk has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
sakoman has quit [Quit: Leaving.]
smurray has left #yocto [#yocto]
nemik_ has quit [Ping timeout: 268 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
amitk_ has joined #yocto
xcm has joined #yocto
|Xagen has joined #yocto
demirok has quit [Quit: Leaving.]
aardo has joined #yocto
justache- has joined #yocto
alessioigor has joined #yocto
Amynka_ has joined #yocto
risca_ has joined #yocto
__ad has joined #yocto
mckoan_ has joined #yocto
Piraty_ has joined #yocto
ardo has quit [*.net *.split]
dkl has quit [*.net *.split]
mckoan|away has quit [*.net *.split]
risca has quit [*.net *.split]
georgem has quit [*.net *.split]
xcm_ has quit [*.net *.split]
Xagen has quit [*.net *.split]
Amynka has quit [*.net *.split]
justache has quit [*.net *.split]
piraty has quit [*.net *.split]
ad__ has quit [*.net *.split]
thomasd13 has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
m4ho has quit [Quit: WeeChat 3.6]
tor has joined #yocto
rob_w_ has joined #yocto
dkl has joined #yocto
georgem has joined #yocto
Payam has joined #yocto
dreyna4529_b has quit [Ping timeout: 260 seconds]
<xcm>
moto-timo: i ended up appending to uboot-initial-env with a .bbappend, but.. it doesn't get picked up. in /boot, a uboot.env appears, but that doesn't contain my changes. worse of all, i can't find it anywhere in tmp/
nemik_ has quit [Ping timeout: 246 seconds]
nemik_ has joined #yocto
zpfvo has joined #yocto
amitk__ has joined #yocto
nemik_ has quit [Ping timeout: 268 seconds]
nemik_ has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
<Payam>
Hi, Is it possible to develop a yocto project on Windows?
<mcfrisk>
Payam: anything is possible and you can make it work, but at least I would not recommend that. Just use Linux. And don't bother with virtual machines for compiling, the performance will be poor and yocto is beast to compile...
<Payam>
mcfrisk yes. unfortunately our organization only provides Windows with VM and not even VM is configured correctly.
<frosteyes>
Payam: if you are forced to it, it can be done. Also WSL2 is pretty good. But the virtual filesystem layer is very slow.
florian has joined #yocto
<mcfrisk>
I would force the feedback to management that to develop Linux products you need to run Linux systems. Been fighting these battles for over 20 years and I would right away quit or not even join an organization which doesn't allow running Linux on developers machines.
thomasd13 has quit [Remote host closed the connection]
<LetoThe2nd>
Payam: WSL2 is your only remotely sane bet. i agree with mcfrisk - management that wants you to work without providing adequate tooling needs to either learn about it, or should be deserted.
manuel1985 has joined #yocto
manuel_ has joined #yocto
<LetoThe2nd>
... imagine being hired as a carpenter, then not getting a hammer because company police is that all work has to be done using screwdrivers. just because your manager is an electrician and the thinks that screwdrivers are like the best tool ever.
<Payam>
LetoThe2nd I am really tired of IT and tbh I dont want anything to do with them any more. Since everytime I ask for a simple thing they want a meeting with me "in 2 weeks"
<LetoThe2nd>
Payam: good time to go looking for other opportunities, then.
GNUmoon has joined #yocto
<paulbarker>
Payam: I try to phrase it in terms of how much it is costing the company. At a guess it'd be at least 3x or more work to maintain a build using Yocto Project under Windows, so they're wasting at least 2/3 of what it costs them to employ you if they make you do that
<paulbarker>
So they can either hire 2 new staff or give you a Linux build environment
<LetoThe2nd>
paulbarker: i know that this is a common technique but does not resonate always.
<paulbarker>
Honestly, if "giving me the right tools would make me more productive and save the company money, with a payback on the investment within weeks" does not resonate then you have poor management
prabhakarlad has joined #yocto
<LetoThe2nd>
paulbarker: there are many companies with poor management. especially lower, in a culture that likes processes and tries to avoid all precedence cases.
<frosteyes>
I can only second the others. I have been in a company where I was forced to virtual Linux. It can be done, but it is a PITA and it is just wrong.
<frosteyes>
And I think it is a pretty good analogy with tools. E.g. tell management that it is like forcing a carpenter to not use power tools, but only have a handsaw and hammer and some nails. Things can be build, but they take long time, and will never be as good as if you have power tools, and the correct tools for the job.
manuel1985 has quit [Ping timeout: 256 seconds]
manuel_ has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
manuel_ has joined #yocto
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
alicef has quit [Client Quit]
manuel_ has quit [Quit: Leaving]
alicef has joined #yocto
<jclsn[m]>
Has someone successfully integrated the sn65dsi83 mainline driver for the imx8mm?
<jclsn[m]>
I could use an example
mckoan_ is now known as mckoan
<jclsn[m]>
I can only find integrations for the old driver online
<mckoan>
good morning
<fnsr|2>
is there a way to make build history catch also changes to the kernel config.txt ? when setting HDMI_MODE = "4" in the local.conf it shows "No changes" while something did change
fnsr|2 is now known as d-fens_
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
d-s-e has joined #yocto
nemik_ has quit [Ping timeout: 252 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
leon-anavi has joined #yocto
<d-fens_>
hmm, seems no buildhistoey issue, the config.txt in bootfiles hasen't actually changed - what must be done to rebuild this file? rpi-config_git.bb should apply the changes
mvlad has joined #yocto
<d-fens_>
ok, works now - rm -rf to the rescue...
d-s-e has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Ping timeout: 255 seconds]
xmn has joined #yocto
d-s-e has joined #yocto
florian_kc has joined #yocto
nemik_ has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
nemik_ has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 246 seconds]
dgriego has quit [Ping timeout: 268 seconds]
dgriego has joined #yocto
dgriego has quit [Ping timeout: 260 seconds]
BobPungartnik has joined #yocto
dgriego has joined #yocto
gho has joined #yocto
BobPungartnik has quit [Client Quit]
d-s-e has quit [Ping timeout: 268 seconds]
Qorin has joined #yocto
EarnestSon has joined #yocto
fvincenzo has joined #yocto
fkuran has joined #yocto
SKaaj4 has joined #yocto
noop has joined #yocto
<noop>
any reason the kirkstone branch is not on the github mirror?
<theophile>
Hi, I'm creating a recipe which requires gengetopt software in order to build. It tried to add DEPENDS += " gengetopt" to my recipe but there is no success and the recipe building fails because it can't find gengetopt util. Could anyone help me sort that out ?
<rburton>
theophile: does it need to run it at build time? you mean gengetopt-native if so.
<theophile>
It does because I would like the file built by gengetopt to be always the most recent version
<theophile>
Therefore, they aren't included in my git repo. An easy fix could be to include them but I don't trust myself to ensure they are up to date
<ldericher>
mhhhhh, so I have "foo.bb", "files/foo_1.0_arm.tar.gz", and "files/foo_1.1_aarch64.tar.gz". Will this work and automatically install foo v1.0 on an ARM platform, and v1.1 on an AARCH64?
<theophile>
But maybe it's a bad decision
<rburton>
theophile: just DEPENDS=gengetopt-native if you want something to run at build time
<ldericher>
… btw, my SRC_URI is `file://${PN}_${PV}_${TARGET_ARCH}.tar.gz`
<theophile>
I've seen the -native with the rust compiler. Do you have any ressource to explain the difference with a normal recipe ?
<rburton>
native recipes run on the build host
<rburton>
you can't run a binary thats been built for the target at build time
<theophile>
Can it be appended to any recipe ?
<rburton>
any recipe that does BBCLASSEXTEND="native" to magically make a native version
<theophile>
Okay, that's good to know. Thanks !
<theophile>
It works like a charm :)
theophile99 has joined #yocto
theophile99 is now known as tbornon
theophile has quit [Ping timeout: 260 seconds]
<d-fens_>
is there a way to have "bitbake -c cve_check myimage" only log unpatched cves?
<d-fens_>
i want to send out daily mails if the command returns something
tbornon has quit [Ping timeout: 260 seconds]
<ldericher>
I'm stuck. I ended up with a recipe 'foo_1.0.bb' using `COMPATIBLE_MACHINE="arm"` and 'foo_1.1.bb' using `COMPATIBLE_MACHINE="aarch64"`. Still, `bitbake foo` creates a warning that `foo_1.0` doesn't have the source for my aarch64 build target.
<ldericher>
I feel like just ignoring the warning isn't the right way
theophile has joined #yocto
theophile has quit [Client Quit]
goliath has joined #yocto
mixfix41 has joined #yocto
rob_w_ has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
sakoman has joined #yocto
noop has joined #yocto
mattes-bru has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
fvincenzo has quit [Quit: Ping timeout (120 seconds)]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
fvincenzo has joined #yocto
noop has quit [Quit: Client closed]
d-s-e has quit [Ping timeout: 252 seconds]
Qorin has quit [Quit: Client closed]
leon-anavi has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe_ has joined #yocto
<gsalazar>
Hi I'm trying to get yocto to compile a binary for a secondary ARM microprocessor as a dependency for the main image. I've read the yocto manual's multiconfig documentation but I it is still not clear on how to signal that a different compiler and compiler options should be used. Anyone has used it or knows about any examples that I could check?
<LetoThe2nd>
gsalazar: its not exacly bare metal on the secondary but zephyr, but it should give you the idea: https://youtu.be/kWwzAq0x4xY
<gsalazar>
LetoThe2nd: Thank you, I'll take a look at it
<LetoThe2nd>
gsalazar: you can also look at the bare metal hello world that is already in poky, and then essential drop that in for zephyr in the example.
noop has joined #yocto
EarnestSon has quit [Quit: Client closed]
<rburton>
gsalazar: worst case (and what meta-arm currently does) is to use meta-arm-toolchain and DEPEND on the binary M compiler. have a look in meta-arm at eg the trusted-firmware-m recipe.
manuel_ has quit [Read error: Connection reset by peer]
manuel1985 has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
FredericOuellet has quit [Quit: Client closed]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<Saur[m]>
ldericher: The problem is that `COMPATIBLE_MACHINE="arm"` is not specific enough. `COMPATIBLE_MACHINE` is actually a regular expression and `arm` will match the `armv8` used for `aarch64`. If you are on Kirkstone or later you can use `bitbake-getvar --value MACHINEOVERRIDES` to get the values that `COMPATIBLE_MACHINE` is matching against. My guess is that you need to use `armv7` or something like that.
zpfvo has joined #yocto
fvincenzo has quit [Ping timeout: 260 seconds]
sgw has quit [Ping timeout: 260 seconds]
sgw has joined #yocto
prabhakarlad has quit [Quit: Client closed]
sgw has quit [Ping timeout: 260 seconds]
<qschulz>
ldericher: also, have a look at MACHINEOVERRIDES as used in FILESOVERRIDES
<qschulz>
you could have the exact same recipe but the file fetched by Bitbake would be different depending on the architecture of the target
<qschulz>
that is done by using sub directories where you'd usually directly put your files (probably files/)
<qschulz>
there have the same name for all tarballs, just in different paths: files/armv7 for arm32 (maybe, don't know exactly what wou;d be the best match) and files/aarch64 for the arm64 one
<RP>
basically to stop people abusing LAYERSERIES_COMPAT
<fray>
no objections here
<qschulz>
it becomes VERY important to keep the next releases name secret :D
<kanavin>
RP: what does the patch do exactly?
<kanavin>
what's going to happen if that phytec layer is given to it?
<RP>
kanavin: it will given an error or warning about the layer compatibility not looking right
<RP>
kanavin: basically it deletes the LAYERSERIES_COMPAT variables out the datastore as they layers are parsed so they can't be referenced by anything else
<kanavin>
RP: is it possible to simply use the value verbatim, without variable expansion?
<RP>
kanavin: I wondered about that but they'd then use := to avoid that
fvincenzo has quit [Quit: Client closed]
fvincenzo has joined #yocto
<qschulz>
RP: would this also prevent overriding another layer's LAYERSERIES_COMPAT?
<qschulz>
because we had to do this at my previous company
<qschulz>
we could also have patched the "upstream" layer instead, but that was more convenient at the time
<qschulz>
(but I didn't like it :) )
<RP>
qschulz: it might still allow that to work, not 100% sure
leon-anavi has joined #yocto
nemik_ has quit [Ping timeout: 260 seconds]
nemik_ has joined #yocto
<vmeson>
rburton: asked somewhere about removing rust-llvm and using our llvm recipe. I replied in my talk that I looked at that when we first merged rust into oe-core but not since. Has anyone else taken time to check that out?
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
aleksandarsimono has joined #yocto
<Saur[m]>
RP: I rely on being able to set `LAYERSERIES_COMPAT` for other layers. Our platform is currently based on Kirkstone. During the ~6 months of preparations for the next major Poky release I use an adaptation layer (weirdly named as `meta-axis-master` since it was originally used to build with master of Poky) where I do all changes needed to make our platform build with the next Poky release. To be able to do this, this adaptation layer uses
<Saur[m]>
`LAYERSERIES_COMPAT_axis:append = " ${LAYERSERIES_COMPAT_axis-master}"` for all our layers in the platform so that they can build with the same version of Poky as the adaptation layer is compatible with.
<RP>
Saur[m]: that will proabably break :(
PhoenixMage has quit [Ping timeout: 256 seconds]
<Saur[m]>
:( I am rather fond of this solution as it means I do not have to lie and set `LAYERSERIES_COMPAT` to include "langdale" for our platform layers before they actually do support Langdale.
PhoenixMage has joined #yocto
<qschulz>
Saur[m]: IIRC you could have LAYERSERIES_COMPAT_axis:append = "langdale" in your meta-axis-master layer.conf to lie in one place only
<qschulz>
IIRC the order in whcih the layers are parsed matter in there
leon-anavi has quit [Quit: Leaving]
<RP>
right, the append isn't the issue, the use of LAYERSERIES_COMPAT is. You could just use a different variable name?
<qschulz>
but that was like 2/3 years ago and I don't have access to the source code anymore
<aleksandarsimono>
Hello everyone.
<aleksandarsimono>
I'm having problem that I cannot solve for days. I have precompiled mcp2515-can2.dtbo file for Raspberry Pi3 (I dont have .dts) that I need to include in my root partition (/boot/overlay) on RPi3. After looking through meta-raspberrypi layer I found out that dtbo's are getting fetched through recipes-bsp/bootfiles/rpi-bootfiles.bb file, so I
<aleksandarsimono>
created rpi-bootfiles.bbappend file in my own recipe that appends to SRC_URI variable and adds my custom mcp2515-can2.dtbo file to bootfiles. Then I added RPI_KERNEL_DEVICETREE_OVERLAYS:append = " overlays/mcp2515-can2.dtbo" to my local.conf and when i run the build I get compile error: No rule to make target
<RP>
I'm really torn (again) on the change to be honest. I just really object to what people are doing in layers to subvert a core feature
<Saur[m]>
Well, it depends on if it will continue to work to set LAYERSERIES_COMPATfrom one layer for another. And we do have tight control of the order of our layers in bblayers.conf, so the adaptation layer is guaranteed to be read before any of the other layers.
<RP>
Saur[m]: I think that works with the patch
<qschulz>
aleksandarsimono: just check where RPI_KERNEL_DEVICETREE_OVERLAYS is used and add your install step without the compilation step
<Saur[m]>
RP: I'll try the patch.
florian has quit [Quit: Ex-Chat]
<aleksandarsimono>
qschulz I'm not sure how to do that
<rburton>
vmeson: rust people at work say that upstream llvm should work if you're building releases
<vmeson>
rburton: nice. That will help tighten things up. I'll give it a go, er llvm, err you know what I mean.
florian_kc has quit [Ping timeout: 260 seconds]
PhoenixMage has quit [Ping timeout: 260 seconds]
<kanavin>
vmeson, I suppose you don't want to build both llvm-native and rust-llvm-native, but llvm-native is not actually providing llvm, it only provides native llvm-config executable for the sake of building target llvm
<kanavin>
(which is very quick and doesn't affect build times)
PhoenixMage has joined #yocto
<vmeson>
kanavin: ah, so we shouldn't expect build time reduction it seems. It'll still save on largely duplicated downloads.
<Saur[m]>
RP: I can confirm that your change breaks my use case. :( `ERROR: Layer axis is not compatible with the core layer which only supports these series: langdale (layer is compatible with ${LAYERSERIES_COMPAT_axis-master} kirkstone)`
fvincenzo has quit [Quit: Client closed]
<kanavin>
vmeson, rust download itself completely dwarfs any savings
olani_ has joined #yocto
rwoaenzkt has joined #yocto
<vmeson>
kanavin: I suppose.
<RP>
Saur[m]: can you rename to a different variable name that doesn't have LAYERSERIES_COMPAT in it?
<qschulz>
aleksandarsimono: I believe you cannot use RPI_KERNEL_DEVICETREE_OVERLAYS for what you want
<qschulz>
because it's just added to KERNEL_DEVICETREE which I believe is used to tell the kernel recipe to build dtb/dtbos
<qschulz>
since you don't have the sources, it won't find it and error out
<qschulz>
without looking too much into it, I'd create a recipe just to add this dtbo into the proper directory
<Saur[m]>
RP: That seems to work, but now I realized that your change breaks what devtool does too: `ERROR: Layer workspacelayer is not compatible with the core layer which only supports these series: langdale (layer is compatible with ${LAYERSERIES_COMPAT_core})`
<RP>
Saur[m]: there is a patch for that in master-next
<Saur[m]>
Ah, ok. I just cherry-picked the bitbake change.
<aleksandarsimono>
qschulz It doesnt work that way because I need to add to boot partition and not to rootfs
<qschulz>
aleksandarsimono: I very much believe that everything is put into the image rootfs and then wic splits it by itself
<qschulz>
thanks to --source bootimg-partition
<LetoThe2nd>
qschulz: see the magic variable :-)
<qschulz>
LetoThe2nd: perfect, nice documentation on this
<Saur[m]>
RP: Ok, that solved that. However, there is a drawback with that solution: when we upgrade to the next major release, all developer's build environment will fail since their workspace layers are no longer automatically adapting to the new release name.
<vmeson>
kanavin: github.com.llvm.llvm-project.git 2.4 GB -- rustc-1.xx.src.tar.xz: 135 MB rust-std-1.64.0-x86_64-unknown-linux-gnu.tar.xz 27.4 MB -- am I missing something?
<qschulz>
LetoThe2nd: I believe IMAGE_BOOT_FILES should be modified in the image recipe or in a configuration file to be taken into account
<qschulz>
Saur[m]: I'm not sure that's an issue?
<qschulz>
that forces your devs to resync the base version
<qschulz>
otherwise your devs are debugging with devtool a version that isn't actually being used anymore
<Saur[m]>
Well, it means they will have to manually modify workspace/conf/layer.conf, a layer most of them don't even know is actually a layer...
<qschulz>
Saur[m]: they shouldn't, thats my whole point
* vmeson
wipes out his downloads and checks the data above.
<qschulz>
Saur[m]: remove your whole devtool workspace between yocto upgrade?
neil499 has joined #yocto
PhoenixMage has quit [Ping timeout: 256 seconds]
<kanavin>
vmeson, so where would the savings come from if rust is using upstream llvm? I might be missing something too :)
amitk__ has quit [Ping timeout: 256 seconds]
<Saur[m]>
That has never been needed before. At least in our case, the developers typically only use it together with devtool modify to (more or less) temporarily make the source available for a recipe or two. With the exception when someone changes the bitbake syntax ;) there is only a small bbappend per active recipe. In my case, most of the times, the workspace layer is just an empty layer.
PhoenixMage has joined #yocto
alessioigor has joined #yocto
<Saur[m]>
And when I say empty, I mean without any active bbappends. The attics directory typically contains a lot of old source directories.
<RP>
Saur[m]: Right, I'm torn on the migration issue but the patch as is is probably as close as we can get
<kanavin>
I'd much rather not see that variable become meaningless.
<RP>
kanavin: that is why I'm a bit upset about this
<Saur[m]>
RP: Yeah, I am not saying the devtool regression should block the change, I am merely mentioning it as it may cause some confusion from developers (I know it will for mine).
justache- is now known as justache
dreyna4529_b has quit [Quit: Client closed]
<kanavin>
Saur[m], it is extremely unlikely anyone else is using LAYERSERIES_COMPAT in workspace this way
<kanavin>
and you're well aware, and can mitigate ahead of time
dreyna4529_b has joined #yocto
<Saur[m]>
I was referring to the devtool case. Since my adaptation layer case works by changing to another variable name, that is fine.
tor has joined #yocto
<kanavin>
Saur[m], ah I didn't look closely at where LAYERSERIES_CORENAMES comes from
neil499 has quit [Ping timeout: 260 seconds]
PhoenixMage has quit [Ping timeout: 256 seconds]
<RP>
kanavin: I handle CORENAMES separately to stop people switching to that since I'm making that obvious in the devtool fixes for core
PhoenixMage has joined #yocto
<Saur[m]>
RP: Btw, there is a typo in the commit message for the bitbake change: "thi is mechanism" -> "this mechanism"
<RP>
Saur[m]: thanks, fixed
<Saur[m]>
There is a corresponding typo in the comment in the code: "this is mechanism" -> "this mechanism"
<kanavin>
RP: hashequiv is awesome, I fixed the x86 test fail in python, and because the fix is in the test and not in the code, the rebuild shortcuts to the image
<RP>
kanavin: it is lovely when it works :)
<RP>
Saur[m]: ah, right. Also fixed
alessioigor has quit [Quit: alessioigor]
fkuran has quit [Quit: Client closed]
<hsv>
If i had a http proxy (say squid maybe), can bitbake be told to use it?
<hsv>
after googling on this i'm a bit confused what goes on under the hood, and if git needs to be configured separately to use the proxy.
<JPEW>
RP: Dropping those two patches helped a lot! 11.5s -> 16.5s now
<JPEW>
It almost makes me think I have a bug that's preventing it from actually saving the extra parsing data.....
<JPEW>
RP: Should we make this a CookerFeature so it can be more easily toggled?
<JPEW>
And I think my name of "Siggen"RecipeInfo is not great
prabhakarlad has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
ptsneves has quit [Ping timeout: 256 seconds]
<RP>
JPEW: I was thinking we should probably not merge those two! I think making it a cooker feature might be a good move. I agree naming needs thought and is hard
<RP>
JPEW: siggen might be ok
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
<RP>
JPEW: I was interested in the shutdown patches, I wondered if a race was possible there but haven't looked into it yet
sakoman has quit [Quit: Leaving.]
Estrella has quit [Ping timeout: 265 seconds]
<JPEW>
I'll look it over again and give it a though
<JPEW>
The event one should be safe
<JPEW>
The shutdown thread might possibly race; need to think
<RP>
JPEW: I was worried syncthread needs to run after the parsers exit since only at that point have they written the code parser caches it is syncing
Estrella has joined #yocto
manuel1985 has joined #yocto
<JPEW>
IIUC, the main thread is done pulling things from the queue before that thread starts; it will "drain" the queue to keep the child processes from getting stuck, but those are just discarded and don't make it into the stack anyway
<RP>
JPEW: the syncthread doesn't care about that. It cares about the parser processes having written their code parser caches
<JPEW>
Ah, I didn't realize it was passing data out of band of the queue
<RP>
JPEW: ah, I'm getting confused again I think :/
<RP>
JPEW: I was thinking this was for bb.codeparser.parser_cache_savemerge() which calls into cache.py:save_merge() which works off a listdir()
<RP>
JPEW: we could really put that into it's own thread
<JPEW>
Ya, maybe
Estrella has quit [Ping timeout: 260 seconds]
Estrella has joined #yocto
Guest70 has joined #yocto
mattes-bru has quit [Remote host closed the connection]
<JPEW>
RP: Ok updated the branch
mattes-bru has joined #yocto
jdavid75 has joined #yocto
<jdavid75>
hi there, looking for advice debugging yocto build error, just trying to replicate my colleague's successful build
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
mattes-b_ has joined #yocto
mattes-bru has quit [Ping timeout: 268 seconds]
Estrella has quit [Ping timeout: 260 seconds]
Estrella has joined #yocto
Saur has quit [Remote host closed the connection]
<rburton>
jdavid75: give details and someone might be able to help
<jdavid75>
just nuked my yocto folder in frustration and trying from scratch, will come back here with deets if/when reoccurs
<rburton>
random build failures can be from recipes that really don't like building on an existing build tree, which is not uncommon and why you should always do out-of-tree builds
<jdavid75>
do you have a link for best-practice setup of out-of-tree builds?
mark__ has joined #yocto
mark__ is now known as mark_L
<rburton>
autotools, meson and cmake do it automatically
<rburton>
autotools-brokensep is for autotools-using recipes which don't do it
<jdavid75>
oh... failure was on a recipe that I had nothing to do with
<jdavid75>
just trying to replicate base state before starting to work
<jdavid75>
a recipe that nobody at our company had anything to do with, just came in with the NXP BSP
<rburton>
harass nxp if you paid for it :)
<mark_L>
Hi, Is there a way to list all the available/enabled DISTRO_FEATURES items? My image pulls in pulseaudio after I migrated our Yocto base to Kirkstone. Trying to see if there's a new destro feature got pulled in somewhere
<rburton>
bitbake-getvar DISTRO_FEATURES
<rburton>
worth skimming the migration guide as that talks about new features that were added
<mark_L>
Thanks rburton, I learn a new trick today!
<rburton>
also, this is why you should write your own distro configuration so you control the distro features
aleksandarsimono has joined #yocto
starblue has joined #yocto
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
sakoman has joined #yocto
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
DvorkinDmitry has joined #yocto
<DvorkinDmitry>
is it correct to write DEPEND = "mc:OTHERARCH:somerecipe" ?
mvlad has quit [Remote host closed the connection]
<hsv>
Can bitbake be told *not* to use https? (via a http proxy)
<hsv>
The problem is the proxy only caches http requests.
<JPEW>
unset http_proxy?
<hsv>
i mean still route via the proxy but use http instead of https, so the object can be cached.
manuel1985 has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Ping timeout: 260 seconds]
<RP>
hsv: you could probably put something in MIRRORS to make it do that
<RP>
there are probably servers which don't support anything but https now
<hsv>
yes i imagine that too, the server could issue a redirect and we are stuck in a loop.
<RP>
JPEW: I've separated out a couple of bits of our patches and sent them to the list. Gives us something to test on more easily I hope!
<RP>
JPEW: your event one looks good to me, not sure about sync and whether we should have a bigger rework there yet
<RP>
JPEW: our patches look to be about the same speed, 4.4s -> 8s for my test on oe-core
Starfoxxes has quit [Ping timeout: 248 seconds]
<RP>
JPEW: interestingly your on disk cache file is 96MB compared to my 60something MB file
<JPEW>
Hmm, strange. I wonder why
<JPEW>
It should be fully deduplicted afaict
<RP>
JPEW: I was a little surprised, not looked into what happened
<RP>
JPEW: oh, it is because we dropped the all in one pickle patch
<JPEW>
Ah ok.
<RP>
JPEW: my patch works around that with references in later objects
<RP>
ETOOMANYPATCHES
<JPEW>
We can do the same protocol to serialize to the file as we use between the parser tasks and cooker if we want
<RP>
JPEW: I was just wondering that
<JPEW>
The large pickle is slower?
<JPEW>
That also is sus
<RP>
JPEW: in my tests, yes
<RP>
I think it is because it allows us to interleave the IO