tlwoerner has quit [Read error: Connection reset by peer]
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #yocto
FO2 has joined #yocto
Tazura has quit [Read error: Connection reset by peer]
vmeson has joined #yocto
abelloni has quit [Ping timeout: 272 seconds]
abelloni has joined #yocto
vmeson has quit [Read error: Connection reset by peer]
hpsy has joined #yocto
hpsy1 has quit [Ping timeout: 252 seconds]
Fanfwe has quit [Ping timeout: 244 seconds]
Fanfwe has joined #yocto
fullstop has quit [Ping timeout: 244 seconds]
fullstop has joined #yocto
<zeddii>
RP: hmm. that's paulg's dynamic cpus list feature, it is now mainline.
<zeddii>
he can update us if it did make mainline, but it wouldn't have been in my 5.12 branches that we tested, so it can only be a potential for some of the issues.
<zeddii>
'er maybe not. I was looking at the wrong branch.
marc1 has quit [Ping timeout: 244 seconds]
marc1 has joined #yocto
<zeddii>
right. yes, those changes are from that feature. Let me grab paulg monday and we'll figure out what to try. That's a mainline destined feature, so reverting it won't buy us anything but the same issue down the road.
angolini has quit [Quit: Connection closed for inactivity]
sakoman has quit [Quit: Leaving.]
manuel1985 has quit [Quit: Leaving]
chrfle has joined #yocto
qschulz has joined #yocto
rob_w has joined #yocto
manuel1985 has joined #yocto
leon-anavi has joined #yocto
<manuel1985>
Is someone using a http SSTATE_MIRROR with http basic authentication? That is, username+password.
<manuel1985>
A collegue is trying to set this up, but it doesn't work right away.
<qschulz>
but it seems to be ok, missing the downloadfilename=PATH though, not sure it matters
<manuel1985>
qschulz: Yes that was me. We tried as suggested, but according to my collegue it didn't work. Just wanted to inquire if anyone is actually using this feature, i.e. if it's just us.
<qschulz>
manuel1985: I think you can do bitbake -DD your-recipe and look for: `Fetching your-recipe using command '` in the console
<qschulz>
this should give you the exact wget command used by bitbake
<qschulz>
run it yourself and see if it works outside of bitbake
<qschulz>
if not, there's something to be done/investigated :)
hpsy has quit [Read error: Connection reset by peer]
<qschulz>
(maybe a third -D is needed, who knows)
<barath>
would anyone happen to have a clue why allowing the inclusion of a GPL-3 recipe would work on yocto zeus but not on yocto dunfell by clearing INCOMPATIBLE_LICENSE_pn-elfutils? it fails during the image's do_rootfs task, complaining that the GPL-3 license is incompatible
ilunev has joined #yocto
BCMM has joined #yocto
Guest78 has joined #yocto
<Guest78>
Hi, I am building an AI engine on a gaming motherboard. I chose it for I need a powerful GPU. And I am using Yocto to build a custom OS for this engine. So, at first, what do you think the most appropriate motherboard to use? I already checked some ASUS and Gigabyte gaming boards but I did not find a good supporting community regarding their BSPs?
<Guest78>
So, are there any other supported boards to serve this functionality or I just start building on the already available Intel / AMD BSPs?
<pbaptista>
ls
asus_986_gpu[m] has joined #yocto
<qschulz>
Guest78: proprietary kernel/userspace driver and its blobs might be an issue on Yocto/non-vendor-supported distributions. I do not know enough on this, but I recall this was already asked a few months back
<Guest78>
Yes, I know. But I only need a roadmap guide how to address these gaming boards and even building my custom BSP on the already available intel/AMD layers
<Guest78>
Or which powerful boards available that have PCIe 3.0 support for external GPU and have a supported BSP?
<rburton>
for x86 still BSPs are less interesting, meta-intel will work on pretty much all intel hardware as they're so uniform
<rburton>
the only challenge will be writing a recipe for any closed drivers, but a lot of those already exist anyway.
RobertBerger has quit [Ping timeout: 245 seconds]
<Guest78>
ok. e.g. say I want to add Nvidia Tesla T4 driver based on meta-intel, what should I do?
rber|res has joined #yocto
<rburton>
download driver, write a recipe
<asus_986_gpu[m]>
the driver needs CUDA and CUDA needs to be compiled using some libraries. So, I should install these libraries on my OS, compile CUDA and install the driver?
<rburton>
the goal should be to not do any building on the target, have a recipe for all the libraries, and cuda, and the driver.
<asus_986_gpu[m]>
ok
pidge has quit [Remote host closed the connection]
pidge has joined #yocto
<Guest78>
do you have any reference links or docs on how to do that?
<rburton>
write a recipe? the documentation has guides.
<rburton>
docs.yoctoproject.org
<rburton>
layers.openembedded.org will let you search for existing recipes
<Guest78>
ok, but I do not understand yet how it is done without the need to build on the target!
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
Guest78: cross-compilation
<qschulz>
well, even in that case, it wouldn't be really cross-compilation I guess :) But Yocto is a build system, so you build stuff for another build system
<qschulz>
another system*
<Guest78>
hmm ok
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kanavin>
barath, check IncompatibleLicensePerImageTests in meta/lib/oeqa/selftest/cases/incompatible_lic.py for the correct way to add gpl3 exceptions
Guest7818 has joined #yocto
Guest78 has quit [Ping timeout: 250 seconds]
zyga-mbp has joined #yocto
<barath>
thx kanavin
<barath>
I think that's what I just noticed. WHITELIST_<license>_pn-<PN> is the new (at least between zeus -> dunfell) way to whitelist packages at the do_rootfs step, apparently.
<barath>
is this documented somewhere? the mega manual mentions the "WHITELIST_GPL-3.0 variable" but nothing more specific than that, AFAICT
<kanavin>
barath, also new is that do_rootfs does check that nothing prohibited is installed, which wasn't the case before
<barath>
yeah I guess that's the underlying issue that I bumped into
<kanavin>
barath, I'm not sure, you might want to open the very latest mega-manual, and search for all mentions of incompatible_license
Ileana has joined #yocto
angolini has joined #yocto
<barath>
yeah unfortunately for INCOMPATIBLE_LICENSE the documentation doesn't seem to have changed. it only mentions that in relation to "license names ... that should be excluded from the build."
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
BCMM has quit [Ping timeout: 252 seconds]
Guest78 has joined #yocto
<zeddii>
RP: the vm_file wrapping done through the aufs patches is the most suspect thing that I see. Did you want to try a standard/base branch with aufs reverted ? That would rule it out and narrow things a bit more.
<RP>
zeddii: I'm willing to try it
<zeddii>
ok. I'll do that, and send you a patch to switch to that alternate branch structure once it passes local builds.
<RP>
zeddii: sounds good, thanks
<RP>
zeddii: the builds using base instead of standard/base definitely feel much happier
<kanavin>
barath, issues are good, but patches are even better
BCMM has joined #yocto
dwagenk[m] has quit [Quit: node-irc says goodbye]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dwagenk[m] has joined #yocto
<rburton>
TIL that zsync is useful for copying images from remote build machines
zyga-mbp has joined #yocto
<barath>
kanavin: thanks, and you're right of course. do patches go into that mailinglist as well? the latest version of the dev manual just has a dead link to the poky mailinglist
<zeddii>
if that doesn't help, I'd look at the intel iommu change yet, but that wouldn't explain the multi-board behaviour.
vmeson has joined #yocto
jordemort has quit [Quit: node-irc says goodbye]
shoragan[m] has quit [Quit: node-irc says goodbye]
barath has quit [Quit: node-irc says goodbye]
Emantor[m] has quit [Quit: node-irc says goodbye]
Andrei[m] has quit [Quit: node-irc says goodbye]
khem has quit [Quit: node-irc says goodbye]
kayterina[m] has quit [Quit: node-irc says goodbye]
cody has quit [Quit: node-irc says goodbye]
ejoerns[m] has quit [Quit: node-irc says goodbye]
Jari[m] has quit [Quit: node-irc says goodbye]
Pierre-jeanTexie has quit [Quit: node-irc says goodbye]
Saur[m] has quit [Quit: node-irc says goodbye]
ndec[m] has quit [Quit: node-irc says goodbye]
janvermaete[m] has quit [Quit: node-irc says goodbye]
shoragan|m has quit [Quit: node-irc says goodbye]
alex88[m] has quit [Quit: node-irc says goodbye]
AlessandroTaglia has quit [Quit: node-irc says goodbye]
dwagenk has quit [Quit: node-irc says goodbye]
asus_986_gpu[m] has quit [Quit: node-irc says goodbye]
dlan has quit [Remote host closed the connection]
derRichard has joined #yocto
<derRichard>
hey guys! i see that syslinux shows almost no upstream activity anymore. oe-core also ships only pre release. do you still recommend syslinux?
vmeson has quit [Quit: Konversation terminated!]
<rburton>
if you dont' need it, dont use it
<rburton>
if you're doing EFI boot then you don't need it
<rburton>
we ship a pre because there hasn't been a proper release for years. we also don't ship the latest pre because it's fundamentally broken.
<derRichard>
rburton: well, i need it. on older systems we use it a lot. now i'm looking forward for alternatives. our systems boot on x86 with and without efi.
<derRichard>
pure efi would be nice. but some still use bios :(
<rburton>
syslinux is still needed then, really.
vmeson has joined #yocto
<derRichard>
sad to hear
<derRichard>
i thought maybe it is time to bite the bullet and move to grub :-D
<RP>
zeddii: thanks, put it in for testing
sakoman has joined #yocto
hpsy has joined #yocto
rob_w has quit [Remote host closed the connection]
<smurray>
RP: on dunfell, I have an image that has its do_rootfs mcdepends on a multiconfig's do_image_complete. This does trigger rebuild of the mc's image if I change something in it, but the do_rootfs does not get re-run...
<smurray>
RP: with --debug, I see that the image with the mcdepends has had its do_image_complete marked as skipped. Am I missing a dependency, or is this a symptom of what your changes in master-next try to fix?
paulg has joined #yocto
<RP>
smurray: Not sure the patch in master-next would address that but I'm not entirely sure I understand the situation you're describing fully
<RP>
zeddii: Package Version (5.10.41+gitAUTOINC+48a13749dc_73e50257ff) does not match of kernel being built (5.10.42) :/
<zeddii>
yah. I have .42 available.
<RP>
zeddii: that was with the patch above
<zeddii>
I'm juggling a #$@ tonne of hacked branches unfortunatel
<zeddii>
yah. that branch is .42, but i had to cherry pick it to another branch to push and the cherry pick was on top of a .41 base.
<smurray>
RP: so I have 2 configs, an image in one (host) has do_rootfs[mcdepends] = "mc::guest:image2:do_image_complete"
<smurray>
RP: with the host image has a post-process command that takes the guest image and copies it into the rootfs
<smurray>
err, having
<smurray>
RP: this works on a clean build, but other than that, if I trigger a rebuild of the guest image with a change, the host image do_rootfs (and my post-process command) do not run
roussinm has quit [Quit: WeeChat 3.1-dev]
roussinm has joined #yocto
<RP>
smurray: so the guest image rebuilds but the other does not? :/
<smurray>
RP: yes
<RP>
smurray: that sounds very wrong. That could I guess be related to some of the things I was trying to fix
<smurray>
RP: it seems to decide quite early on that the host image do_image_complete can be accelerated, which looks wrong/odd to my eye
<RP>
smurray: right, that is wrong and I think related to what I was looking at :(
* RP
needs to try and get back to that
<RP>
zeddii: is there a way I can tweak this to work?
<RP>
zeddii: sorry, I know there is so much going on :)
<RP>
er, :(
<smurray>
RP: I'll look at that master-next change to get an idea of where to poke around
<smurray>
moto-timo: from what kanavin said, I thought he'd heard from Collabora folks that it's unlikely to be maintained once they're finished whatever the customer project is...
<moto-timo>
smurray: but since it requires meta-gnome (gnome-desktop3 and gnome-menus3) it probably won't get to oe-core anyway
<moto-timo>
smurray: fair enough, mostly just playing with something that isn't sato
<smurray>
moto-timo: I'd not expect it to necessarily build if you just copy the recipe into oe-core, there are a couple of patches to weston in meta-agl-core it needs
<smurray>
moto-timo: or might just be one now, look at meta-agl-core/recipes-graphics/wayland in the "next" branch of meta-agl
<smurray>
moto-timo: one thing agl-compositor might help with is it's another example outside of weston itself of using libweston, which might give an idea of using libweston in a sato rework
<moto-timo>
I thought of that, but I don't know if we have the resources to do that port
<smurray>
moto-timo: I think the issue is we're lacking resources for most all that's been proposed as options :/
<vdl>
Is there a variable referencing for the include file itself? Like ${BPN}, but "foo" from within foo.inc
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
wesm has joined #yocto
moto-timo has quit [Changing host]
moto-timo has joined #yocto
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
<JPEW>
moto-timo: maynard doesn't work with stock weston; it requires some custom AGL extension
<moto-timo>
JPEW: yeah, it needs agl-compositor, which is what I was asking about
<moto-timo>
Probably not the path
<smurray>
moto-timo: one option would be to pick back through the maynard change history to before the change to use agl-compositor, but wouldn't shock me if it'd need some bits picked to work with current weston
khem has quit [Ping timeout: 244 seconds]
barath has quit [Ping timeout: 244 seconds]
shoragan[m] has quit [Ping timeout: 244 seconds]
Andrei[m] has quit [Ping timeout: 244 seconds]
kayterina[m] has quit [Ping timeout: 272 seconds]
AlessandroTaglia has quit [Ping timeout: 244 seconds]
shoragan|m has quit [Ping timeout: 244 seconds]
Saur[m] has quit [Ping timeout: 244 seconds]
janvermaete[m] has quit [Ping timeout: 244 seconds]
ejoerns[m] has quit [Ping timeout: 244 seconds]
cody has quit [Ping timeout: 244 seconds]
Emantor[m] has quit [Ping timeout: 244 seconds]
alex88[m] has quit [Ping timeout: 272 seconds]
ndec[m] has quit [Ping timeout: 272 seconds]
Jari[m] has quit [Ping timeout: 272 seconds]
Pierre-jeanTexie has quit [Ping timeout: 272 seconds]
jordemort has quit [Ping timeout: 272 seconds]
pbaptista has quit [Ping timeout: 250 seconds]
<moto-timo>
any solution that involves a fork and YP/OE maintaining it is a challenge
<moto-timo>
too bad wlroots/sway and similar tiling compositors are probably not the desired solution
<wesm>
Hi all, I'm just getting started with yocto and I haven't seen any recommendation for repository layout
<vdl>
I have to use an alias for the github.com hostname for my repo, otherwise I cannot use my deploy key. The bitbake fetcher is trying to be smart and complains about a non-int port, but I don't have any in my SRC_URI. Is there an option to use the hostname as is?
<wesm>
I have done a few builds but obviously keeping my changes in poky/build/conf/local.conf isn't going to work as I make my own layers
<wesm>
Is there a public repo that is a good example to follow?
<vdl>
wesm: it depends on your project, if you have many layers, just one, if you build in this repository, etc. I suggest you to look at the "kas" tool from Siemens and because it allows you to describes the repositories to use, it kinda gives you a better idea how to organize your code
<JPEW>
vdl: I don't know why it would complain about a non-integer port unless you had a ":" in your deploy alias
<JPEW>
Using an ssh alias like that should work just fine with the fetcher (we had to do it in when they moved the port some of our internal git server ran on)
barath has joined #yocto
Guest38 has joined #yocto
khem has joined #yocto
asus_986_gpu[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
jordemort has joined #yocto
janvermaete[m] has joined #yocto
barath has joined #yocto
ndec[m] has joined #yocto
Emantor[m] has joined #yocto
Jari[m] has joined #yocto
cody has joined #yocto
Pierre-jeanTexie has joined #yocto
khem has joined #yocto
Saur[m] has joined #yocto
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
shoragan|m has joined #yocto
AlessandroTaglia has joined #yocto
alex88[m] has joined #yocto
asus_986_gpu[m] has joined #yocto
dwagenk has joined #yocto
<vdl>
JPEW: my repo is indeed described as git://git@github.com:compagny/project.git;protocol=ssh
<vdl>
JPEW: the other problem I have is that it as a private submodule as well...
<vdl>
JPEW: in fact a few submodules (doc + lib), and only lib is necessary. I don't know how to handle that.
<vdl>
I'm currently using a manual clone in TOPDIR/../project with do_fetch[noexec] = "1" and S = "${WORKDIR}/../project", but its content is moved somehow! Is it bitbake moving sources around? Can I prevent that?
<JPEW>
vdl: You should use externalsrc if you want to use a local checkout
<JPEW>
(for temporart development purpose only)
<vdl>
JPEW: I'm trying git://git@github.com/compagny/project.git;protocol=ssh (with a '/', not a ':') and the aliases in MIRRORS
<JPEW>
vdl: Oh, right, the ":" isn't valid for bitbake
<JPEW>
vdl: I missed that. Yes what you are doing is correct (I think)
<vdl>
Is there a way to tell gitsm which submodule to fetch or ignore? (what git clone --recurse-submodules=<pathspec> does)?
<vdl>
JPEW: do_fetch: git -c core.fsyncobjectfiles=0 ls-remote ssh://git@github.com/company/project.git still fails, it doesn't look like MIRRORS is considered
<JPEW>
vdl: I doubt it, but I'm not sure
Guest38 has quit [Quit: Client closed]
<alejandrohs>
I see that we redefine MACHINEOVERRIDES= "" in the nativesdk class
<alejandrohs>
So there's no way to customize a function, like do_install_qemuX when a certain target MACHINE is being built?
<alejandrohs>
for a nativesdk package that is
<RP>
zeddii: no rcu stall or other issues with the first run of that patch FWIW
<alejandrohs>
RP: ^^ thoughts on that?, is that expected?
tprrt has quit [Quit: leaving]
leon-anavi has quit [Quit: Leaving]
tperrot has quit [Remote host closed the connection]
tprrt has joined #yocto
tprrt is now known as tperrot
tperrot is now known as tprrt
tprrt is now known as tperrot
<RP>
alejandrohs: you shouldn't really be changing nativesdk on a per machine basus
<RP>
alejandrohs: so yes, very much expected
<alejandrohs>
RP: :O
Guest48 has joined #yocto
<Guest48>
Hello, guys. Is anyone else having problems with meta-java (gatesgarth) nowadays? It fails to fetch some icedtea tarballs:
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
Guest48 has quit [Ping timeout: 250 seconds]
halstead has joined #yocto
halstead has quit [Ping timeout: 258 seconds]
BCMM has quit [Ping timeout: 252 seconds]
hpsy1 has joined #yocto
hpsy has quit [Ping timeout: 272 seconds]
<fitzsim>
regarding meta-java IcedTea tarballs, icedtea.classpath.org is under maintenance; it should should be available again soon