<Guest181>
Hi, everyone, I am a new guy, and need a help now. Using bitbake poky, I have got .ipk in tmp/deploy/ipk/armv7vet2hf-neon/ , but these ipks in tmp/deploy/ipk/armv7vet2hf-neon/ don't work on my arm board. How can I get arm ipks?
<JosefHolzmayrThe>
Guest181: so what is running on the board?
<JosefHolzmayrThe>
Guest181: the generated ipks only work when used on the corresponding image, or even better, if you just rebuild the image including the things you need.
<Guest181>
"arm" "all" , and uname -m on my board is "armv7l"
tnovotny has joined #yocto
<JosefHolzmayrThe>
Guest181: no thats not what i mean. where did you get the software from that is currently running on the board?
<JosefHolzmayrThe>
your poky build has to match it
grma has joined #yocto
camus has quit [Ping timeout: 252 seconds]
<Guest181>
I just want some ipks, and all the arm ipks can work on the board well
camus has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
<Guest181>
so I dont want to rebuild the image of the board
<JosefHolzmayrThe>
well maybe you don't want to. but you have to be able to, in order to create matching ipks.
<RP>
Guest181: you'd need to configure poky to build ipks that are compatible so you need to know what the board is running
zpfvo has joined #yocto
<Guest181>
Just need some new software to work on the board
<JosefHolzmayrThe>
then set up a build that matches what is running on your board.
<RP>
Guest181: there is a bit more to configuration than just the package architecture of the ipks unfortunately
<JosefHolzmayrThe>
i would rather say "fortunately", because that is what actually gives us the configurability superpowers.
<Guest181>
Actually, any arm ipks will be ok on the board, because it not bsp software, it just some python lib like numpy
zpfvo has quit [Ping timeout: 252 seconds]
<qschulz>
tlwoerner: eh it's ok, I've a "downstream" layer for our board which we'll need to keep anyway :) https://git.theobroma-systems.com/yocto-layers/meta-theobroma-systems-bsp.git/ I'll probably push a bit more once I can send you a machine conf without too many changes (basically, TPL support in upstream U-Boot)
zpfvo has joined #yocto
<qschulz>
RP: good luck with the house, hope it didn't get worse over the week-end
<Guest181>
after "bitbake python3-numpy", the ipks are in tmp/deploy/ipk/armv7vet2hf-neon/ and armv7vet2hf-neon not match armv7l
<michalkotyla>
have set DHCP client in NetworkManager as "internal" and now it is not working for me - I get address from range 169.254...
<RP>
qschulz: I'll survive thanks. I spent a while up ladders trying to seal things up so we'll see. Going to be a pain trying to get a roofer now :/
eloi1 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
fleg has joined #yocto
thekappe has joined #yocto
rfuentess_ has joined #yocto
<thekappe>
hello guys ! I'm trying to use a yocto SDK within eclipse
<qschulz>
RP: ain't nothing that can't be fixed with duct tape :D
dev1990 has quit [Quit: Konversation terminated!]
<thekappe>
in orde to let eclipse discover "sem_t" I had to add "__LP64__" and "__arrch64__" symbols
rfuentess has quit [Read error: Connection reset by peer]
<RP>
qschulz: industrial staple gun and damp proof course membrane in this case, but yes
dev1990 has joined #yocto
<thekappe>
I'm pretty confident in __aarch64__ as I am building a 64bit distro, but I'm not so sure about __LP64__
rfuentess__ has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<thekappe>
How do I know which are the default symbols used by bitbake while building the distro ?
eloi1 has joined #yocto
rfuentess_ has quit [Ping timeout: 252 seconds]
florian has joined #yocto
tre has joined #yocto
rfuentess_ has joined #yocto
rfuentess__ has quit [Ping timeout: 268 seconds]
rfuentess__ has joined #yocto
pgowda_ has joined #yocto
rfuentess_ has quit [Ping timeout: 252 seconds]
rfuentess__ is now known as rfuentess
rzr has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
ykrons has joined #yocto
<ykrons>
Hello all
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
dacav has joined #yocto
<ykrons>
I have included nodejs 14.17.1 recipe from "honister" into a "thud" yocto version and after few small changes, it went pretty well. I have then updated the recipe to point on 14.18.1 (with intermediate jumps to 14.17.4 and 14.17.6). Up to now, everything is fine.
<JosefHolzmayrThe>
ykrons: "but"
<ykrons>
In order to do some cleaning, I have removed unused recipes for 14.17.1, 14.17.4 and 14.17.6, and since that time, "bitbake <myimage>" returns an ERROR Not manifest generated from: nodejs ...
<ykrons>
I don't understand what is the link ... restoring the deleted recipes, doesn't get build succeed again. I'm currently forcing a rebuild of nodejs to see the image
<ykrons>
Can someone explain or point a doc on that manifest stuff?
<dacav>
Hello. I'm new to Yocto. Since I'm quite confused by the build system, I'm following a bitbake tutorial ("A practical guide to BitBake" - https://a4z.gitlab.io/docs/BitBake/guide.html ). In section 6.2 the second recipe uses `inherit mybuild` (for an existing `mybuild.bbclass`). The same tutorial has a first recipe that is based on a `base.bbclass` class. I was wondering why the first recipe does not
<dacav>
need to `inherit base`. Is it implicit due to the `base.class` name?
<JosefHolzmayrThe>
dacav: for a newcomer that linked resource seems to be quite misleading - i would rather suggest to focus on the general concepts, instead of bitbake peculiarities.
<dacav>
I'd like to know my tools
<rburton>
base.bbclass is inherited before the recipes are parsed
<dacav>
Would you recommend a better starting point?
<dacav>
rburton: I see, so it is indeed a magic name!
<rburton>
no, its' not magic
<JosefHolzmayrThe>
dacav: you can always look up bitbake syntax and inner workings if needed, but as long as you don't have a good grasp on the whole thing, battling bbclass syntax on a barebones layer is probably not.... helpful.
<JosefHolzmayrThe>
dacav: 1) set up a minimal build 2) add a layer 3) add an image 4) add a recipe for a package of your choice.
<JosefHolzmayrThe>
dacav: especially for 4), which is also the main task in everyday life, there should be excellent documentation available, let me look it up
<RP>
dacav: base is just inherited by everything, always there
<dacav>
JosefHolzmayrThe: I've read this guide already, but I'd like to start small
<dacav>
small-er
<JosefHolzmayrThe>
dacav: well do so if you insist, but experience shows that it will only distract and confuse you. to use an analogy: if you're learning car mechanics, you certainly need *some* understanding of tools and parts, but you won't need to know the exact process of latex vulcanization for the tires.
<JosefHolzmayrThe>
its a tire, you get it, you use it. done.
<JosefHolzmayrThe>
RP OTOH almost certainly knows how to make his own...
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<JosefHolzmayrThe>
me for example, i have never looked into base.bbclass, in all my YP times.
<JosefHolzmayrThe>
its there, it works.
<RP>
JosefHolzmayrThe: for the record I have never made my own tyres
<JosefHolzmayrThe>
RP: just for lack of time, I'm sure.
* RP
has rebuilt the odd engine/car/motorcycle/kart :)
<RP>
JosefHolzmayrThe: not cost effective :)
<JosefHolzmayrThe>
but you also have looked at base.bbclass, so i guess thats fair game.
<dacav>
The fact is, I'm really confused by that documentation. I'm confused exactly because it skips on important details (what should a .bb contain? To what .bb will .bbappend be applied? Etc). Everyone has got a different way of understanding things, I need some bottom-up :)
zpfvo has quit [Ping timeout: 252 seconds]
<dacav>
RP: is base inherited implicitly?
zpfvo has joined #yocto
<JosefHolzmayrThe>
dacav: well, good luck then. :) if you find any specific part of the documentation wanting, then please let us know so it can be improved.
<dacav>
hehe, thanks :) - I'll be happy to help, in future, should I reach a sufficient knowledge level to be helpful :)
kroon has joined #yocto
<RP>
dacav: it is just always inherited by bitbake, I guess you could say that is implied
manuel1985 has joined #yocto
<mckoan>
dacav: I've already seen that website. Unfortunately is not updated and in some steps is broken
<qschulz>
dacav: actually... it'd be best to let us know how to improve it *before* you reach a sufficient knowledge level, because that's specifically total beginners' view on docs we're missing. Some people in the community have been working for more than a decade on Yocto/Bitbake so some things are just obvious to them and the docs sometimes reflect that by forgetting some important notions or quirks
<qschulz>
Perceval[m]: try to limit your messages to one line at a time, so old folks using IRC can still read your message without opening it in a browser :)
<qschulz>
Perceval[m]: `bitbake nodejs -e | less` and look where this "4" is coming from
<qschulz>
you have the variable history too so you'll be able to know at least in which file and line this comes from
<qschulz>
which is a huge help
kayterina has joined #yocto
<Perceval[m]>
hey qschulz, sorry for the big message :s
<Perceval[m]>
okay I will try that
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<Perceval[m]>
the variable history will be printed by bitbake -e command or stored in a file?
<Perceval[m]>
could you point me the line number please? I can't see it
<moto_timo[m]>
It’s in the url
<moto_timo[m]>
The #n46 at the end of the url is the line number
<moto_timo[m]>
Ah, the dunfell recipe has it too. Line 40. Too early and no coffee yet.
<dacav>
mckoan: Too bad, I like the idea of an entry-point tutorial. But I've to say I've already got more confidence, even if I found some differences between what the tutoral says and what the reality is.
<RP>
moto_timo[m]: why are you up? :)
<moto_timo[m]>
RP: Because I need to be up for the summit all week long ;) practice
<MauroAnjo>
Hello! I'm trying to create a recipe to build: https://github.com/raspberrypi/libcamera-apps , it DEPENDS on libcamera that is present in the build but pkg_check_modules cannot find it and fails
<dacav>
qschulz: well, so far I find the documentation well written. The confusion I've got comes from the lack of an obvious starting point: there's a lot of information, but I can hardly contextualize it. I'm not saying that anyone has the same difficulty: it might be fine for others.
<dacav>
I can hardly give any good suggestion, sorry :)
<MauroAnjo>
very recent raspberry libs to replace old MMAL stuff with raspistill, etc
<moto-timo>
Lol
zpfvo has joined #yocto
<MauroAnjo>
not libs, apps hehehe
<moto-timo>
That was me chuckling at /refs/ being a 404
<sb27>
I'm trying to cross-compile boost 1.69 with a source'd yocto SDK, and I get errors related to headers not being found (https://www.dropbox.com/s/jac3qfu1lpfc6ig/b2-cross-compile.txt?dl=0). I found in the output that the lib paths are wrong (/opt/.../usr/bin/bin, /opt/.../usr/bin/lib etc), but that doesn't explain why the headers can't be found.
<sb27>
Anyone know how to fix this or what I'm doing wrong?
<MauroAnjo>
going back to older git commits it was able to find libcamera, but now is complaining about X11 even though I stated to not use it hehehe
<MauroAnjo>
other git source on official website :P
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<moto-timo>
Ah, the url in the recipe should maybe be updated ;)
<MauroAnjo>
yeap
<moto-timo>
Hmmm. Git repo with no tags or branches. When should we consume it as stable? “Whenever”
<moto-timo>
It’s the cloud-native “trust a commit hash” model of software “releases”
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
lucaceresoli has joined #yocto
<agherzan>
Hi guys. Did anything change on the infra side of the git server? I used to have credentials to mirror to https://git.yoctoproject.org/meta-raspberrypi/ and now it I get a timeout on ssh.
<agherzan>
ssh: connect to host git.yoctoproject.org port 22: Connection timed out
dj has joined #yocto
<agherzan>
Last successful run: 23rd of Nov
<agherzan>
First fail: 26th of Nov
<dj>
What happens if you run 2 bitbakes of separate builds that share the same sstate-cache and downloads folder?
<zeddii>
yah, it needs to be push.yoctoproject.org now
<zeddii>
agherzan: ^^^^^^^
<dj>
like i want to test someone's PR and I also want to test my changes, but both share the same downloads folder and it's downloading linux-yocto
<zeddii>
dj: lock files, etc, deal with it.
<zeddii>
it is comon to share those directories.
<zeddii>
s/comon/common/
<dj>
so it won't mess things up? it's handled automatically?
<zeddii>
that's the design anyway :D
<agherzan>
I see zeddii . Is it the same port?
<dj>
hahah alright
<zeddii>
yah
<dj>
thanks zeddii
<zeddii>
agherzan: I just changed my configs from git -> push in the .configs
<zeddii>
and I was able to push, both to meta-virt and a pull request to contrib
<agherzan>
Cheers. Trying it now.
<qschulz>
dacav: oh no, it's well known that Yocto has a very steep learning curve so you're not alone. The issue is that there's a lot to teach and usually when people start using Yocto they are under pressure and just want to do something, so it's hard to find a good balance between a getting started and something complete enough to help in one very specific scenario.
<zeddii>
agherzan: if it doesn't work, it might be the mirror part is different and we'd need rp or halstead to comment.
<Perceval[m]>
qschulz: thank you very much I discovered where the 4 was coming from thanks to your command, "PARALLEL_MAKE" as set as "4" in one of the scripts of the project. It is now solved :)
<agherzan>
zeddii: It works now for the auth part of it
<agherzan>
remote: fatal: bad object 0000000000000000000000000000000000000000
<agherzan>
But I get another one: + git push --mirror git@push.yoctoproject.org:meta-raspberrypi
<agherzan>
remote: fatal: bad object 0000000000000000000000000000000000000000
<zeddii>
I was getting that as well
<dacav>
qschulz: :) Yes, I agree. one of the first things I've read has been the "what I wish I'd known about Y.", and I found it amusing.
<zeddii>
in my case, it was some sort of synchronization issue that was transient (or fixed by halstead, I wasn't sure which).
<RP>
zeddii: how did you fix it?
<dacav>
after a while, I figured I should break rule 6 and try searching something useful
<dacav>
to get started, that is
<zeddii>
I couldn't push to poky-contrib or meta-virt due to that a similar bad object message
<agherzan>
zeddii: but did you find a workaround?
<zeddii>
agherzan: no. halstead was working on the servers at the time and said something about a bad synchronization (not just the delayed one), and it went away shortly after. So I don't know if he git gc'd/prune'd the repo, or what.
<agherzan>
halstead: can you do the same magic ^ for meta-raspberrypi?
<thekappe>
hello guys, if I want to add rsyslog to my distro, is it worth removing syslogd ?
<zeddii>
and you can see there was some unspoken magic. :D
<qschulz>
Perceval[m]: awesome :)
<agherzan>
Thanks zeddii sadly it seems we have to wait for halstead to deal with this too. I can't see anything in logs that you did specifically for fixing this.
* zeddii
nods
<zeddii>
I just tried again later and it worked. so I don't know exactly what happened
<agherzan>
Some server side gc probably but we will get the confirmation for the gatekeeper
* moto-timo
now suddenly wants to talk hockey with zeddii
tre has quit [Remote host closed the connection]
<moto-timo>
michaelo: in the docs, do we use alt text for e.g. screen captures of qemu to provide hints for accessibility? I doubt we’d want to include the full text…pondering
<moto-timo>
michaelo: I should probably query some of my accessibility colleagues in Debian
<qschulz>
moto-timo: I don't think we do much currently wrt accessibility
<moto-timo>
qschulz: that’s what I suspected… always room for improvement
<qschulz>
but since we've not yet written the docs standard, it's a good time to share if there's anything specific to be done wrt accessibility so we can fix it asap and make sure it stays fixed even with new contributions
<moto-timo>
And yet, still the same 24 hours in each day.
<moto-timo>
qschulz: yes, good point
sakoman has joined #yocto
<moto-timo>
I should probably start a thread on docs mailing list
<JosefHolzmayrThe>
moto-timo: i'm envious of your macropad
<moto-timo>
JosefHolzmayrThe: it is a game changer. I'm really liking practicing with it.
<moto-timo>
you can basically program any key to type anything (and also give it a pretty RGB color of your choice)
<JosefHolzmayrThe>
moto-timo: i hadn't ever heard of it. saw it mentioned by you, and its completely sold out
<agherzan>
zeddii: halstead actually that was a red herring I think. On a second run it ran as expected and never saw that object error again.
<moto-timo>
JosefHolzmayrThe: yes, like everyone Adafruit is impacted by the supply chain woes. Getting harder and harder to get the parts you need. And if a product goes viral, like the macropad did, you run out.
<JosefHolzmayrThe>
moto-timo: i will need something stream-deckish soon too, and i mean, 50$ and tinkering fun sound much more promising than the elgato stuff
<moto-timo>
JosefHolzmayrThe: the little OLED display is also handy :)
zpfvo has quit [Ping timeout: 252 seconds]
<moto-timo>
JosefHolzmayrThe: and not obvious, but the dial lets you switch between "pages" of macros (and it is a push button as well)
<JosefHolzmayrThe>
moto-timo: wow
<JosefHolzmayrThe>
moto-timo: you're really doing the streamer thing
<moto-timo>
JosefHolzmayrThe: I use it to turn the OBS virtual camera on and off
<moto-timo>
JosefHolzmayrThe: I had to figure out a way to make the upcoming summit presentations _work_
<JosefHolzmayrThe>
hehe
<moto-timo>
still going to be an experiment, but I think it will help a lot
<moto-timo>
I'm concerned how the hands on lab will fly, but that's just me being a bit of a worry wart
<JosefHolzmayrThe>
I'll just click around wildly and break stuff. as usual.
<moto-timo>
yes
<moto-timo>
as will I
<JosefHolzmayrThe>
hi5
<JaMa>
agherzan: the link to the message from halstead saying to use push.yp.org was included in that meta-rpi issue ticket :)
<JaMa>
agherzan: but thanks for resolving it quickly
zpfvo has joined #yocto
<agherzan>
JaMa: You are right. You did reference the right email announcement but it was not loading. Oh well :)
sgw has quit [Ping timeout: 256 seconds]
sgw has joined #yocto
rob_w has quit [Remote host closed the connection]
akica has joined #yocto
<dj>
if I want to use bbclasses, is the do_install that is inherited done before or after .bb do_install?
<dj>
executed before or after*
<qschulz>
dj: if you have a do_install in your bb, only the do_install of the bb will be run
<dj>
thank you
<qschulz>
if you want to do something before or after the do_install from a bbclass, you need to use do_install:prepend or do_install:append (or old syntax, replace : with _)
<qschulz>
in your bb
<JaMa>
depends on the place where the inherit appears in the recipe, if it's after the do_install definition, then do_install from bbclass will be executed
<JaMa>
always use bitbake -e or bitbake-getvar if you're not sure (the history explains it nicely)
<qschulz>
JaMa: true, though it's best practice to do the inherit ASAP in the bb right?
<JaMa>
I have couple of bbappends which add an inherit and then you cannot easily choose
<JaMa>
especially painful if the main recipe you're bbappending to already inherits "native"
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
<moto-timo>
I’ve come across a few cases where the order of the inherit mattered. Not obvious
<moto-timo>
Hence why we all recommend bitbake -e and bitbake-getvar
<qschulz>
JaMa: was wondering if that is not a case for e.g. autotools_do_install (don't know if it exists), which is overridden in recipes if do_install is used but you can still (I think?) use it by calling it directly from the recipes' do_install
<qschulz>
moto-timo: yeah that one's a pain :)
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<moto-timo>
qschultz: also contemplating for docs... the original kernel-lab was qemux86 but now I have content for the summit that is qemuarm64... so now I want a "tab" or some menu that lets the user switch MACHINE/arch.... because why make anything simple?
<moto-timo>
ugh... I always add a t to your name :/
<qschulz>
moto-timo: use the auto-completion in your IRC client (or change the client if it does not support it :p)
<moto-timo>
indeed... sometimes I forget and just type type type type send oops
<moto-timo>
qschulz: ah yes... I'll have to think about how to do this (in a future installment)... because large portions of the chapter text would change currently
<qschulz>
moto-timo: the dependencies are very small so I don't have anything against having that plugin always in our docs
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
<moto-timo>
qschulz: yes, it would make e.g. preparing your host distro a bit fancy
<qschulz>
moto-timo: you have group tabs support already, just need to make sure the labels are identical
<moto-timo>
qschulz: I'll definitely keep that in mind when I'm ready to add to/modify the kernel-lab chapters later
<moto-timo>
need to get the existing docs done and out for review first ;)
<moto-timo>
then we can improve things
<moto-timo>
I must have compiled the kernel 1000 times in the last few weeks. lol
<qschulz>
hehehe, at least we know it works :p
xantoz has quit [Ping timeout: 256 seconds]
vd has joined #yocto
<dwagenk>
Hey There! Should BB_DISKMON_DIRS and BB_DISKMON_WARNINTERVAL be added to BB_HASHEXCLUDE_COMMON by default?
<dwagenk>
I'm investigating why my workstation is not using my build-servers sstate cache as mirror and I think the difference in BB_DISKMON_DIRS is the root cause.
xantoz has joined #yocto
fitzsim has joined #yocto
kayterina_ has joined #yocto
kayterina_ has quit [Client Quit]
eloi1 has quit [Quit: WeeChat 3.3]
michalkotyla has quit [Quit: michalkotyla]
michalkotyla has joined #yocto
michalkotyla has quit [Read error: Connection reset by peer]
<kergoth>
@dwagenk nothing should be actually referencing those vars in the metadata, so they should never be in any checksums anyway. certainly they could be excluded, but if nothing uses them for anything it's not really necessary either. bitbake uses those directly, not via other vars
mattsm has joined #yocto
<dwagenk>
Hmmm, I'll have to dive deeper into the problem then. Is there a good way to debug sstate hash comparison? bitbake -e recipes and then pay attention to the BB_HASH etc?
<rburton>
bitbake-diffsigs will show you the differences in two signatures, if you have the siginfo files to hand
<kergoth>
bitbake-dumpsig can be useful too
kayterina has quit [Read error: Connection reset by peer]
<dwagenk>
@rburton @kergoth thanks! I remember having seen those commands before, but never used them yet. I'll look into the problem.
rfuentess has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
florian has quit [Quit: Ex-Chat]
<dj>
does each yocto project need to clone yocto?
<rburton>
if you don't have it on disk already then you'll need to clone oe-core/bitbake/meta-oe/whatever
<rburton>
but you can re-use them for different projects as they're only read from, never written to, by a build
tnovotny has quit [Quit: Leaving]
zpfvo has quit [Remote host closed the connection]
<dj>
so i would have a bunch of projects in the same folder in poky or bitbake?
<rburton>
sure
<rburton>
my ~/Yocto has bitbake, poky, meta-arm, meta-oe, meta-clang, etc etc
<dj>
right those are layers, but all the projects would share the same build/ directory?
jqua[m] has left #yocto [#yocto]
jqua[m] has joined #yocto
<qschulz>
dj: oe-init-buildenv ../build-project1
<qschulz>
dj: just share sstate-cache and downloads directories between all your proejcts (SEE DL_DIR and SSTATE_DIR)
<MauroAnjo>
agherzan Hi! Do you think adding libcamera-apps and updated libcamera in meta-raspberry would be a good idea? Since raspi plans to drop userland, MMAL, for cameras...
sb27 has quit [Quit: Client closed]
<agherzan>
MauroAnjo: aren't those already in meta-multimedia?
<agherzan>
Also, do they drop userland?
<MauroAnjo>
not yet, still working, but they are going for a libcamera solution, not sure when they will drop it
<MauroAnjo>
in meta-multimedia (openembedded) you have libcamera, but an older version, had to tweak it, and create a recipe for libcamera-apps that is not present anywhere, at least I have not found it
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<agherzan>
MauroAnjo: it sounds that we should update meta-multimedia and include apps there too
<agherzan>
Thanks for raising this MauroAnjo
<agherzan>
This is most probably because of 64bit support in userland
<MauroAnjo>
yeap, not so hard to make it work, simple recipe, I can make a PR, I'm just finishing to test some features no Raspberry Pi Zero 2 W in 64bits
<MauroAnjo>
thats right!
<agherzan>
And now that they are going to provide 64images, they faced the problem too
<MauroAnjo>
It kinda works, but MMAL is messy, I did not even tried to make it work
<agherzan>
That is not an easy one
<agherzan>
I've looked into it and it's just not a happy thing to do
<MauroAnjo>
noticed 32 bits support for raspberry pi zero 2 W was dropped, I might take a look into it too
<MauroAnjo>
on the PR I mean, it would not build o rpi3-32 I believe
<agherzan>
Really?
<agherzan>
Maybe we should start cleaning up the machines in meta-raspberrypi
<MauroAnjo>
64 bit is working ok, just had trouble with RNDIS and now the imx overlays for cameras
<agherzan>
Right
qua has joined #yocto
florian has joined #yocto
<MauroAnjo>
they are still making changes to support raspberry pi zero 2 w, but have not looked why 32 bits was not so straightforward
pgowda_ has quit [Quit: Connection closed for inactivity]
Tokamak has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mattsm has joined #yocto
Tokamak has joined #yocto
<dj>
rburton, if you have all those project in the same folder how do you handle it via git? you but your build bash scripts and .git inside the layer folder?
<dj>
projects*
<dj>
you put your*
florian has quit [Ping timeout: 264 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kergoth>
how you fetch and manage multiple git repositories is really up to you, there's no official method, and there are many available tools to assist. kas, repo, submodules, etc
Tokamak has joined #yocto
Vonter has quit [Ping timeout: 265 seconds]
florian has joined #yocto
Vonter has joined #yocto
<rburton>
dj: either by hand because i'm actively fiddling, or with kas
Vonter has quit [Ping timeout: 264 seconds]
<JaMa>
zeddii: I see couple errors in world builds which include meta-virtualization, are you interested in the list/details or already aware of singularity (broken since last autotools update in oe-core, configure.ac:38: error: AM_INIT_AUTOMAKE expanded multiple times), xvisor (failing without python2 on host: xvisor/git-r0/git/tools/scripts/d2c.py: /usr/bin/python: bad interpreter: No such file or directory),
<JaMa>
uxen-guest-tools (uxen-guest-tools/4.1.8-r0/uxen-4.1.8-72a4af9/vm-support/linux/uxenhc/hypercall.c:127:24: error: too many arguments to function '__vmalloc')
<zeddii>
JaMa: I had noticed them in some logs, but was heads down on yocto summit stuff. singularity, I need to just blacklist it. the others, I was hoping the main contributors to them would notice, but will eventually look into them.
<rburton>
kanavin: the explicitly overridden PACKAGECONFIGs in libepoxy, do you agree they're redundant now we don't play games with distro features and rpaths to use the host mesa?
<kanavin>
rburton, we need x11 config for the host and sdk even if the distro feature is disabled for the target
<kanavin>
otherwise virgl in qemu won't work
<kanavin>
the games with distro features were about opengl, not x11
<rburton>
ok
<rburton>
recent epoxy doesn't abort if gl isn't present so i'm hoping we can drop the gtk/gl madness
<kanavin>
you're welcome to run experiments, but the virgl selftests need to pass if you want to make changes
<rburton>
do we have anything that exercises gtk without gl
<kanavin>
so we can run vkcube and various spiffy demos :)
<rburton>
nice!
<kanavin>
rburton, er, sato?
<rburton>
i mean in the AB
<kanavin>
ah on the host?
<kanavin>
I don't think we do, gtk frontend is only tested with qemu for the purposes of virgl I think.
<kanavin>
rburton, native gtk is also built for the various utility executables
<rburton>
i meant target, but i'll build a qemuarm64 without gl
* kanavin
is confused
<rburton>
only partly related to the original question :)
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
dj has quit [Quit: Leaving]
filipm[m] has quit [Ping timeout: 265 seconds]
alvaropg[m] has quit [Ping timeout: 265 seconds]
kmaincent has quit [Ping timeout: 265 seconds]
dwagenk has quit [Ping timeout: 265 seconds]
mcfrisk has quit [Quit: Lost terminal]
kmaincent has joined #yocto
tkoskine has quit [Quit: Lost terminal]
<khem>
poky-contrib is not accessible halstead
<halstead>
Khem: if you recently updated the remote to the push url remember you'll need you agree to the ssh hosts prompt.
alvaropg[m] has joined #yocto
filipm[m] has joined #yocto
dwagenk has joined #yocto
amitk has joined #yocto
amitk_ has quit [Ping timeout: 245 seconds]
kiran has quit [Ping timeout: 264 seconds]
<JaMa>
zeddii: only the singularity one is "new" other 2 are probably failing like this for a while, I just haven't seen them until now, because I had meta-virt included only in qemux86 build and these 2 are only for x86-64
<zeddii>
yah. looks like the kernel bump and / or libheaders got them. I'm surprised the Xen users didn't point out that failure. I'm just trying to see if there's a version bump for it now.
<JaMa>
it's definitely failing in honister already, my dunfell world is still running
<zeddii>
xvisor as well.
behanw has joined #yocto
<moto-timo>
dj: I intentionally do not build in poky. So when I setup a build it’s “. ~/Project/poky/oe-init-buildenv /srv/build-project” or I use kas as rburton said
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
Tokamak has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
fleg has quit [Remote host closed the connection]
<rburton>
hm, someone recently made a tool to process bitbake dependency files, and i've lost it
<rburton>
can anyone remember where it was?
MauroAnjo has quit [Ping timeout: 256 seconds]
florian has joined #yocto
<ziga_>
layers. I must have 2 layers that provide the same BBFILE_COLECTION and I see that it is "openembedded-core/meta/" and "poky/meta". What can be done?
<ziga_>
Hey! I want to use layer "meta-ti" which needs "meta-arm/meta-arm" and "openembedded-core/meta" layers. So I downloaded all, checked out "dunfell" (same as poky) and I added all three layers to the BBLAYERS in "local.conf". Now when I test with "bitbak-layers show-layers, I get an error: "ERROR: Found duplicated BBFILE_COLLECTIONS 'core', check bblayers.conf or layer.conf to fix it." This is all the layers that I added to the preexisting
<ziga_>
Only these two provide `core` for the variable BBFILE_COLECTIONS.
<rburton>
if you have poky you don't need oe-core
<rburton>
as poky is bitbake + oe-core glued together
<rburton>
so, remove oe-core
mvlad has quit [Remote host closed the connection]
<moto-timo>
rburton: i thought I had it open in a tab. I remember it was on GitHub, but searching is not finding it
<moto-timo>
rburton: now the question is, which day of IRC logs to search?
<ziga_>
@rburton Okay! I removed oe-core and error as it was is gone!
<ziga_>
Now I get different problem when using "bitbake-layers show-layers". This command does not return a anicely formatted layers table but this: bitbake-layers show-layers
<ziga_>
NOTE: Starting bitbake server...
<ziga_>
ret = main()
<ziga_>
File "/home/ziga/yocto/poky/bitbake/bin/bitbake-layers", line 95, in <module>
<ziga_>
Traceback (most recent call last):
<ziga_>
File "/home/ziga/yocto/poky/bitbake/bin/bitbake-layers", line 63, in main
<ziga_>
tinfoil.prepare(True)
<ziga_>
File "/home/ziga/yocto/poky/bitbake/lib/bb/tinfoil.py", line 414, in prepare
<ziga_>
self.run_command('parseConfiguration')
<ziga_>
File "/home/ziga/yocto/poky/bitbake/lib/bb/tinfoil.py", line 470, in run_command