<Tokamak>
I struggle with understanding the workflow to update / fixup broken patches. specifically I have a patch failing 1 of 2 hunks. Considering there are many meta layers all applying patches to u-boot, what is the correct yocto way to update patches? quilt? something else?
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 268 seconds]
jmiehe1 is now known as jmiehe
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
amitk has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
goliath has joined #yocto
thomasd13 has joined #yocto
OnkelUlla has quit [Ping timeout: 240 seconds]
jpuhlman has quit [Ping timeout: 245 seconds]
thomasd123 has joined #yocto
thomasd123 has quit [Quit: Client closed]
thomasd1235 has joined #yocto
thomasd1235 has quit [Client Quit]
thomasd1235 has joined #yocto
thomasd1235 has quit [Client Quit]
Schlumpf has joined #yocto
hcg has joined #yocto
goliath has quit [Quit: SIGSEGV]
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
<LetoThe2nd>
yo dudX
mckoan|away is now known as mckoan
<mckoan>
good morning, hi LetoThe2nd
<LetoThe2nd>
yo mckoan
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
michaf has joined #yocto
<kanavin>
Tokamak, you need to describe what you are trying to do exactly
mihai has quit [Quit: Leaving]
zpfvo has joined #yocto
odra has joined #yocto
mvlad has joined #yocto
ptsneves has joined #yocto
odra has quit [Ping timeout: 252 seconds]
vermaete has joined #yocto
manuel1985 has joined #yocto
goliath has joined #yocto
prabhakarlad has joined #yocto
florian has joined #yocto
Bardon_ has joined #yocto
Bardon has quit [Ping timeout: 272 seconds]
<michaf>
rburton: I tried printing out my compile command. Apparently the PKGCONFIG part gets ignored.
starblue1 has quit [Ping timeout: 245 seconds]
SeZenker has joined #yocto
<SeZenker>
Hi, is it somehow possible to build the kernel (and uboot) using a different toolchain than for the rootfs (user space) within the same image build?
<LetoThe2nd>
SeZenker: its only software, anything is possible. but what is the usecase?
<SeZenker>
My use case is, that I have a pretty old version of uboot which doesnt work/boot with a recent version of gcc
<SeZenker>
But for the user space I like to make use of C++17/20 features
<LetoThe2nd>
SeZenker: technically you could probably do it as a multiconfig build, and inject the binaries versus a cross-dependency
<SeZenker>
ok, thanks, I will take a look into this topic
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
denisoft81 has joined #yocto
mvlad has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
vermaete has quit [Quit: Client closed]
<abelloni>
I4m trying to have a python3 module in ASSUME_PROVIDED and obviously, this doesn't work as-is because python3-natvie is not able to find the module
<abelloni>
anyone ever managed to do that?
<abelloni>
to be clear, I'm trying to add python3-cryptography-native there to avoide the dependency on rust
<rburton>
not sure how well it tracks changes in yocto though
<rburton>
ah it has its own cargo class
<rburton>
this needs to be rebuilt
odra has joined #yocto
odra_ has joined #yocto
odra has quit [Ping timeout: 244 seconds]
<abelloni>
rburton: and it doesn't handle -native
mvlad has joined #yocto
imuguruza has joined #yocto
<kriive>
Sorry folks for the noob question, how do I use openssh as SSH server in Yocto, does the debug-tweaks image feature conflict with it?
<LetoThe2nd>
kriive: it should not
paulg has quit [Ping timeout: 245 seconds]
seninha has joined #yocto
<imuguruza>
Hi there, I am trying to compile an image using kirkstone (4.0.2). rust-llvm compilation fails. I have searched around, with little success...Does my machine require the instalation of any dependency, apart from the ones that appears in the requirements sections in yocto manual?
paulg has joined #yocto
<qschulz>
imuguruza: could you give us the logs? it's a bit difficult to guess what could be going wrong
<imuguruza>
yeap one sec
Vonter has quit [Remote host closed the connection]
<qschulz>
imuguruza: if not one line or two, please use a pastebin
<RP>
JaMa: probably so if was empty the value was unchanged. I suspect it was more a convention than a requirement
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<JaMa>
ok, I'll send some RFC patch changing that (as some places use it with space already added) and it looks more strange to me now when it's almost always set to sysroot
<RP>
JaMa: I do kind of disagree though since the space is really part of the addition, not the original underlying variable :/
<imuguruza>
@khem any idea what could be the source of the problem? Thanks
denisoft81 has quit [Quit: Leaving]
<Saur[m]>
imuguruza: Based on the error messages, it looks as if the contents of the `/home/alor/yocto_ws/build/tmp/work/x86_64-linux/rust-llvm-native/1.59.0-r0/rustc-1.59.0-src/src/llvm-project/llvm/lib/Bitcode/Reader/BitcodeReader.cpp` file is not what it should be. It seems to be corrupt. Have you tried doing `bitbake rust-llvm-native -c clean`?
seninha_ has joined #yocto
seninha has quit [Ping timeout: 252 seconds]
<imuguruza>
let me try....
seninha_ has quit [Client Quit]
prabhakarlad has quit [Quit: Client closed]
mihai has joined #yocto
florian_kc has joined #yocto
odra_ is now known as odra
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
seninha has joined #yocto
<RP>
JaMa: I am a bit worried that changing that now would break external layers where there isn't a space too :/
imuguruza has quit [Quit: Client closed]
<JaMa>
RP: true, that's why it's just RFC, I've checked meta-oe OK, meta-virtualization (1 issue from 10 uses of this variable), meta-arm (1 issue), meta-raspberrypi OK, meta-clang (couple issues)
<RP>
JaMa: I think your ltp patch breaks if the RFC patch isn't present and will also conflict with a patch in master-next :/
<JaMa>
RP: it should work without RFC patch and it's based on the patch in master-next (as mentioned bellow --)
Schlumpf has quit [Quit: Client closed]
<RP>
JaMa: ah, great, thanks. Sorry, I somehow didn't see that line
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<JaMa>
no problem :) I would definitely overlook it as well
xmn has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
<vvn>
hi there -- I've set REPRODUCIBLE_TIMESTAMP_ROOTFS = "" in my distro conf, but I still end up with a weird default value of 20180309123456 instead of the content of BUILDNAME in /etc/version. Am I using it wrong?
Guest8770 has joined #yocto
hcg has quit [Quit: Client closed]
imuguruza has joined #yocto
<vvn>
Code 18 I guess. Shouldn't we default REPRODUCIBLE_TIMESTAMP_ROOTFS to "" by the way in bitbake.conf?
<imuguruza>
yes it works Saur[m]
<imuguruza>
could be something related to the compilation order?
<Guest8770>
should "devtool modify binutils-cross" work? Mine tells me unable to find any recipe file
<JaMa>
you need to append -arch, e.g. binutils-cross-arm
<Guest8770>
JaMa ah thanks
imuguruza has quit [Quit: Client closed]
prabhakarlad has joined #yocto
paulg has quit [Ping timeout: 268 seconds]
paulg has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
* RP
has just reproduced and worked out the musl llvm-config failure
<RP>
It is x86 (i.e. build arch specific) and is because llvm-config finds the target libstdc++ which isn't quite able to work with the host's glibc it was compiled for
<JPEW>
RP: Close enough to look right but not actually functional?
<rburton>
RP: always useful to experiment with a different architecture to make sure that can't happen :)
<LetoThe2nd>
rburton: like.... compiling on a ppc32?
<RP>
JPEW: right. The linker did abort but if they were all a different arch it would just skip them and work
<rburton>
LetoThe2nd: i meant machine=qemuarm64 but sure, whatever floats your boat
<RP>
rburton: other arches just work as the linker skips the,!
<rburton>
ha
<rburton>
even better
<RP>
rburton: note the AB only tests two musl x86 targets
<rburton>
we should change that
<LetoThe2nd>
rburton: hehe yeah I usually do actually recommend the same, to build for qemuarm64 or qemuriscv64 by default.
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
ferlzc has joined #yocto
florian has quit [Quit: Ex-Chat]
qzcdfn has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
nemik has quit [Ping timeout: 245 seconds]
sakoman has joined #yocto
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
paulg has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<kanavin>
RP: thanks for merging the SDK bits :)
<kanavin>
RP: I'm slowly warming up to the oe-setup idea btw
qzcdfn has quit [Quit: tiuq]
<RP>
kanavin: I haven't really had time to participate in the threads as much as I perhaps need to. It is a hard problem and one I've never had the time to focus on as much as it needs
<vvn>
Can two image recipes install two different package versions, or does this choice has to be made necessarily by the distro?
<rburton>
the image won't be able to control what version of the eg library gets built
<kanavin>
RP: I'm working on a new revision of the layer setup tooling, one which no longer will be marked as RFC (as it will have all needed selftests, and no issues that are known to me :)
<RP>
kanavin: I need to find time to properly review the patches
<rburton>
vvn: if you have parallel installable libraries then it's common to put the abi version in the filename, eg gtk3 gtk4
<vvn>
rburton: so you're saying that IMAGE_INSTALL cannot specify a version-suffixed package name, correct?
<rburton>
vvn: it won't have any impact on what version bitbake picks, no
<vvn>
I see
<kanavin>
vvn, it can, but the version needs to be in the name of the package, so you need to to have two different recipes
<vvn>
rburton: so in order to provide a dev image (using latest master from a few project), one has to tweak the distro or provide a -dev distro variant, correct?
<rburton>
yes
<rburton>
prior art, albeit very stale in poky.conf vs poky-bleeding.conf
<rburton>
see also devupstream.bbclass
<vvn>
kanavin: that's what rburton said yes, which is in fact a different package, not a different version (from bitbake's POV)
<JPEW>
As part of the SPDX build profile work, I'm attempting to the describe the various "levels" of "builds" we have as an example so that hopefully SPDX 3.0 will be able to express what we do as part of builds. I've drawn a diagram that attempts to capture all the things that are relevant to various build steps: https://drive.google.com/file/d/1SVA09CVWr9mZXMhElKC8PEIlY4hBmWea/view?usp=sharing . Any comments are appreciated
<JPEW>
^^ RP sgw rburton (and anyone else interested)
<vvn>
rburton: it will be two distros then, to have a clean way to provide the latest version to developers
paulg has joined #yocto
<vvn>
The more I use OE, the more I realize that images are more of a dev/poc thing rather that being that useful in prod. In prod you'll likely have your base image and one or more distros.
<vvn>
i.e. 1 image and 1+ distro rather than the opposite
<RP>
JPEW: at a quick look it seems reasonable to me
<kanavin>
vvn, images are collections of packages, if you can differentiate products with just different packages, you do not need different distros
<kanavin>
vvn, there's an enormous overhead in adding a distro
<kanavin>
you basically double the load on both your infra, and your QA
ferlzc has quit [Remote host closed the connection]
<vvn>
kanavin: that is right. That's why I preferred to have multiple images instead of distro. But I struggle to provide a clean dev alternative that developpers can quickly enable...
ferlzc has joined #yocto
<kanavin>
vvn, but why specifically do you need two versions?
<rburton>
if you need a 'dev image' with git HEAD builds then a dev distro is the easy solution
<vvn>
or like for gtk3/gtk4, I should duplicate the app recipe to have foo and foo-dev packages
<rburton>
just make it include the main distro so you get 99% reuse
<vvn>
rburton: true, that seems intuitive, but as kanavin correctly pointed out, this requires a bit of infra to split DEPLOY_DIR, suffix DISTRO in IMAGE_VERSION_SUFFIX or BUILDNAME and so on
<vvn>
not unfeasible though, just preventing collision when hosting the builds
<rburton>
just host them in different directories or something.
<vvn>
yep
ferlzc has quit [Ping timeout: 245 seconds]
<vvn>
something like DEPLOY_DIR .= "-${DISTRO}"
<rburton>
I presume you're not hosting *directly* from your build tree
<vvn>
rburton: I stage the content of DEPLOY_DIR internally then a subset of these files are hosted somewhere else for factory/prod/updates etc.
vladest has quit [Ping timeout: 255 seconds]
<rburton>
if you need local files to be namespaced then just set TMPDIR
Guest8770 has quit [Quit: Connection closed]
florian_kc has joined #yocto
<vvn>
rburton: you don't even bother tweaking DEPLOY_DIR then, just something like TCLIBCAPPEND = "" and TMPDIR .= "-${DISTRO}"