<Ch^W>
khem: Yeah, the bind hack to build dhcp is... bad.
<Ch^W>
vmeson: I pulled the 4.4.2 recipe from dunfell. I can create a patch to support 4.4.2-P1 for dunfell if that is needed.
camus has quit [Remote host closed the connection]
camus1 has joined #yocto
camus1 is now known as camus
hpsy has joined #yocto
hpsy1 has quit [Ping timeout: 265 seconds]
Vonter has quit [Ping timeout: 258 seconds]
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
roussinm has joined #yocto
roussinm has quit [Client Quit]
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
Vonter has joined #yocto
Tokamak_ has quit [Ping timeout: 272 seconds]
paulg has quit [Ping timeout: 256 seconds]
Spooster has quit [Remote host closed the connection]
Spooster has joined #yocto
Spooster has quit [Remote host closed the connection]
rob_w has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
frieder has joined #yocto
cquast has joined #yocto
zpfvo has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
<erbo>
good morning
florian has joined #yocto
Falital has joined #yocto
argonautx has joined #yocto
zyga-mbp has joined #yocto
ilunev has joined #yocto
goliath has joined #yocto
argonautx has quit [Ping timeout: 240 seconds]
xmn has quit [Quit: ZZZzzz…]
patrick-r has quit [Quit: Client closed]
Guest79 has joined #yocto
<Guest79>
Hi, I am building a custom OS for x86-64 machine with Nvidia Tesla T4. I want to build CUDA libraries and Nvidia drivers for my OS? How do I do that?
leon-anavi has joined #yocto
<Guest79>
In CUDA installation guide, it already has a list of supported distributions for native installation, and for cross compilation it is not clear how to cross compile for another x86-64 machine but custom OS
<Guest79>
I suppose that many have done it before. So, any help here would be appreciated
eduardas has joined #yocto
tommyg has joined #yocto
<tommyg>
Folks, I'm a bit of a newbie and just looking for some advice of how to identify the source of a build error i.e. is it in the build script or the upstream repo for the project I'm trying to build
<rburton>
Guest79: typically you just follow the instructions but be sure the compiler used is ${CC}, etc
<rburton>
tommyg: pastebin the error and we'll look
<tommyg>
Trying to include mpv from meta-openembedded/recipes-multimedia
<rburton>
looks like the depends in the recipe might be a bit out of date. compare the DEPENDS in the recipe on line 14 with the list it said was missing: libxrandr isn't explicitly depended on. maybe add that to the list?
<tommyg>
I tried using the recipe from master as it's newer (0.33.1 vs 0.32.0) but same error
<tommyg>
Thanks, I'll give that a go
<rburton>
this recipe is a bit of a mess actually, that DEPENDS should be incorporated into the PACKAGECONFIG[x11]
<rburton>
patches welcome :)
<tommyg>
:-) I think that might be running, I'll walk first but when I've a bit more confidence ...
<tommyg>
Thanks rburton, adding libxrandr to dependencies did the needful
<rburton>
must have been some cleanup in the libx11 depends
<rburton>
can you send a patch?
<tommyg>
I'll give it a go, might as well learn how to some time
<rburton>
make the commit message look like the others in the repository, join the oe-devel list on lists.openembedded.org, git-send-email, done
<Guest79>
rburton u mean the cross compilation instructions?
<rburton>
Guest79: if they have cross instructions then just do what they say. if they don't then just hope that using the right compiler just works.
<rburton>
not having the source or the documentation with me, it's impossible to say
<thekappe>
hello guys
<thekappe>
I'm building rauc through the meta-rauc layer
<thekappe>
on some host machines I can compile the rauc recipe without issue
<rburton>
if you're not using master then i guess you need to backport
<thekappe>
because the host system has a kernel > 4.14
<thekappe>
i think it's 4.15 AFAIK
<rburton>
sure, but most distros don't update the libc headers in sync with the kernel
<thekappe>
and hence the issue
<rburton>
exactly
<thekappe>
btw, I'll patch it
tnovotny has joined #yocto
<thekappe>
and I'll say goodbye to it
<rburton>
file a bug to ask them to update whatever branch you;re using
<thekappe>
thanks man
<thekappe>
I'm an a custom branch cause I had to backport
<thekappe>
I'm on thud
<rburton>
you're aware that Thud is EOL and was last released in October 2019 right
Guest79 has quit [Ping timeout: 246 seconds]
<thekappe>
Yes
<thekappe>
but it seems that it's important to me only
<ejoerns[m]>
I'd also strongly suggest moving to a recent poky version, especially when it is a project under active development. At least dunfell LTS. What prevents you from moving forward?
Schlumpf has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
Falital has quit [Quit: Connection closed]
patrick-r has joined #yocto
<patrick-r>
Hello, I need to know if there is a way to display a different on-screen keyboard according to the set value of the locale in matchbox?
<rburton>
matchbox-keyboard is a bit lo-fi
<rburton>
i think it has layouts, but its been a very long time since i looked at that...
<jonesv[m]>
rburton: at cross-compilation time when I `bitbake my-package`
<jonesv[m]>
rburton: what's weird is that I have another package that I build and that also does `#include <chrono>` all over the place, and that one works
Schlumpf has quit [Quit: Client closed]
<jonesv[m]>
And this package that fails (say `my-package`) does build on my host system
Schlumpf has joined #yocto
camus1 has joined #yocto
<rburton>
well its /usr/include/c++/11.1.1/chrono in gcc-runtime
<rburton>
so maybe your makefile is hardcoding assumptions and not respecting the CC flags, so isn't using the right sysroot
camus has quit [Ping timeout: 272 seconds]
camus1 is now known as camus
Vineela has quit [Remote host closed the connection]
<moto-timo>
JPEW: I remember hearing about Zuul before... I forget what project was using it... at the time something made me say "nope" but I have zero recall of the details
<JPEW>
It's the CI for OpenStack
<moto-timo>
JPEW: for a moment, looking at the code, I was worried it was py2 but it is py3 only
<moto-timo>
JPEW: ah, I think it might have been OpenStack itself that made me say nope at the time ;)
<JPEW>
moto-timo: It's an interesting concept: Use Ansible as the CI execution engine
<moto-timo>
JPEW: agreed, and also I see they speak of Kubernetes :)
<JPEW>
But they have full K8s support suposedly. You can run the control plane on K8s and have it spin up pods as workers
<moto-timo>
that is indeed intriguing
<JPEW>
I might give it a try. It seems like its a decent out-of-the-box K8s solution for full CI
<JPEW>
moto-timo: I really like tekton, but it's missing some of the "ready to go" parts
<JPEW>
moto-timo: And I'm not sure those parts are even in the scope of the project, unfortunately
<moto-timo>
JPEW: agreed, tekton is trying to be the backend to a more full featured CI and it is missing things
<moto-timo>
JPEW: concourse is also worth looking at
manuel1985 has quit [Ping timeout: 256 seconds]
<moto-timo>
JPEW: but from your brief description of what Zuul can do with k8s it sounds worth a try
<rburton>
concourse had a serious problem that i can't remember, but i tried that for yocto CI
<rburton>
it was a blocker for what i wanted it for, wish i could recall what it was
<JPEW>
rburton: In my testing, it seems like CI systems need to be fairly mature before they can handle Yocto CI... it's just a lot different that what most people expect
<ollie>
would anyone be able to offer some insight about the following error occuring during the building of the rootfs? I am building a wayland distro based platform, dunfell release.
<ollie>
Collected errors:
<ollie>
* Solver encountered 1 problem(s):
<ollie>
* Problem 1/1:
<ollie>
* - package packagegroup-core-boot-1.0-r17.var_som_mx6 requires systemd, but none of the providers can be installed
<ollie>
*
<ollie>
* Solution 1:
<ollie>
* - do not ask to install a package providing resolvconf
<ollie>
* Solution 2:
<ollie>
* - do not ask to install a package providing packagegroup-core-boot
<ollie>
removing resolvconf for testing results in the following error
<ollie>
Collected errors:
<ollie>
* check_data_file_clashes: Package systemd wants to install file /home/build/my/build/tmp/work/var_som_mx6-fslc-linux-gnueabi/my-base-image/1.0-r0/rootfs/var/log
<ollie>
But that path is currently a directory
patrick-r has quit [Ping timeout: 246 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
bps has quit [Ping timeout: 258 seconds]
Schlumpf has quit [Quit: Client closed]
williamh89 has quit [Quit: Client closed]
<JPEW>
moto-timo: Huh ML post asking about Zuul with Yocto.... suspicious timing
<moto-timo>
Copilot?
tnovotny has quit [Quit: Leaving]
kayterina has quit [Remote host closed the connection]
patrick-r has joined #yocto
<OutBackDingo>
moto-timo: was it starlingx or airship ? both use zuul for k8s/opstack builds
<moto-timo>
OutBackDingo: this was pre-k8s-on-my-brain, so I think it was just OpenStack... but not too important to remember those details. Different era, different mindset. Lifetime ago :)
ecdhe has quit [Remote host closed the connection]
ecdhe has joined #yocto
ecdhe has quit [Changing host]
ecdhe has joined #yocto
idleroamer has joined #yocto
idleroamer has quit [Client Quit]
idleroamer has joined #yocto
idleroamer has quit [Client Quit]
yates_work has joined #yocto
<yates_work>
after getting this: http://paste.ubuntu.com/p/9pCc2YMNDM/ i created a <my-layer>/recipes-core/glibc/glibc-locale_2.32.bbappend with this one line: FILES_${PN} = "${localdir}"
<yates_work>
is this correct?
florian has joined #yocto
<yates_work>
it did not fix the issue (the QA error)
<yates_work>
is this the correct way to .bbappend the recipe?
<yates_work>
here is the bitbake output: /bin/bash: fpaste: command not found