<jmd>
When I do "source oe-init-build-env" I get an error: "Please set up python v2 as your default python interpreter" But it doesn't explain how to do that.
<Xogium>
huh, python 2 ?
<jmd>
That's what it says.
<Xogium>
which yocto version is that ?
<jmd>
I'm building from git
<Xogium>
I'm a bit baffled here because the oe-init-build-env thing is just a shell script. I don't get why it would need python 2, not to mention that python 2 is dead
<jmd>
Yeah. I was surprised too.
<Xogium>
which distro do you run this on ?
<jmd>
Debian
<jmd>
12.4
<Xogium>
fwiw I'm on ubuntu here and even with python being symlinked to python3 and not python2, the oe build env thing runs
<Xogium>
I'm on kirkstone, but still
<Xogium>
I was under the impression that all this oe script does is setting up shell env variables
<jmd>
The complete message is "Bitbake is not compatible with python v3\nPlease set up python v2 as your default python interpreter"
<Xogium>
so I really don't understand the deal with python 2 vs python 3
<Xogium>
it must be something else printing this, because there is not one single error message refering to the python version in oe-build-env in itself
<Xogium>
ah
<Xogium>
what in the hell ?
<Xogium>
that also doesn't seem to make sense
<RP>
jmd: that is the latest release from master? I'd have thought we got rid of that message a long time ago
<jmd>
Xogium: I think you're mistaken. It's in line 34 of oe-buildenv-internal
<Xogium>
oh !
<Xogium>
I missed this. I was checking only the oe-init-build-env ;p
<RP>
jmd: for me, line 37 is echo >&2 "BitBake requires Python 3.8.0 or later as 'python3' (scripts/install-buildtools can be used if needed)"
<jmd>
And I'm on the "jethro" branch. Not "master" (as per the getting started in structions on https://docs.yoctoproject.org
<Xogium>
ooh boy
<RP>
jmd: Not quite sure how you got to jethro but that is a very old release :(
<Xogium>
which kind of explains why you're stuck with something that wants python 2, I guess
<jmd>
In at least 2 places.
<RP>
jmd: the 2.0 there is the issue, those are not recent docs
<jmd>
They are linked to from the main page.
<RP>
jmd: it does say at the top "This version of the project is now considered obsolete, please select and use a more recent version."
<RP>
jmd: where on the main page?
<jmd>
Okay I stand corrected it's not the main page.
<Xogium>
main page iirc always points to latest
<jmd>
It's the "Yocto Project Quick Start" page.
<jmd>
and the link says: "For the latest version of this manual associated with this Yocto Project release, see the Yocto Project Quick Start from the Yocto Project website. "
<jmd>
So that's how I found it.
<jmd>
Anyway, which instructions should I be following?
<frosteyes>
then start by source oe-init-build-env
<Saur>
sakoman, khem: Is it expected that glibc is three commits ahead on the nanbield branch compared to master?
<frosteyes>
a new build folder is created - and you should be able to run bitbake
<jmd>
frosteyes: Is it safe to do that when I've already done it? I seem to remember it causes issued.
<jmd>
s/issued/issues
<frosteyes>
we started on a fresh, when you removed the build folder and then created with source oe-init-build-env
<frosteyes>
So yes.
<jmd>
okay.
<jmd>
Then bitbake again?
<frosteyes>
Just try..
<jmd>
Yep okay so the trick is when bitbake breaks, remove build and try again.
<frosteyes>
Not exactly.. But you had a very old build setup because you had been working on 2.0
<sakoman>
Saur: I haven't merged that, just testing it in the -nut branch to see if there were any issues. It won't merge until master has the same
<jmd>
Maybe. I thought I started clean over though.
<frosteyes>
Also.. When switching from a very old release, you sometimes need to create a new terminal, when sourcing the new one..
<jmd>
Maybe that was the problem then.
<frosteyes>
E.g. source oe-init-build-env export some variables..
<frosteyes>
And they have changed over time..
<sakoman>
Saur: thanks for watching though! I always appreciate feedback -- might keep me from doing something stupid :-)
<frosteyes>
So if you first source an old one,, They are exported.. and if they are not export in newer versions, it become a mix..
<jmd>
Sometimes bitbake just blocks forever
<Saur>
sakoman: AFAICT, origin/master has SRCREV_glibc ?= "1e04dcec491bd8f48b5b74ce3e8414132578a645" and origin/nanbield has SRCREV_glibc ?= "44f757a6364a546359809d48c76b3debd26e77d4", where the latter SRCREV is three commits ahead of the former...
<jmd>
Oh and now it can't find the server again.
<frosteyes>
have you run "ctrl+c" or similar..
<khem>
Saur: usually it should not but in context we are in process to upgrade to 2.39 on master so its not bad
<frosteyes>
Will be off, good luck - jmd
<Saur>
khem: Yeah, I expected something like that. I was just a bit surprised when I noticed.
<sakoman>
Saur: Sigh, you are correct, I thought you were referring to the glibc patch I have queued in -nut
<khem>
usually devs should send patch against master and a backport
<khem>
separately
<Saur>
sakoman: No worries. And as khem says, soon it will solve itself when master upgrades to 2.39.
<khem>
RP: yes I guess, I will adapt it on top
<RP>
khem: the glibc mips patch seemed to work FWIW
<jmd>
frosteyes: Yes I've been doing that rather a lot.
<frosteyes>
jmd: then this is your problem.. Some bitbake commands take siginificant time.. When you press ctrl+c the bitbake server might not get shutdown correct. This means it can not be started for the next command. So you need to control your process - think ps and look if something hanging.. Also it might be the bitbake.lock file and bitbake.sock is still present.. Preventing the next bitbake command.
jmd` has joined #yocto
jmd`` has joined #yocto
<jmd`>
Is there a way to make bitbake run deterministicly ?
<rburton>
in bitbake's defense, it's not non-deterministic
* rburton
should stop looking at irc and finish his slides
<jmd`>
Well every time I run it, it does something different.
<rburton>
its working towards the target you specify. there's usually a huge amount of routes to that target, so it can do lots in parallel.
<rburton>
if you say what your problem is, maybe someone can help with that
rfuentess has quit [Remote host closed the connection]
<jmd`>
rburton: My (current) problem is that every time I run bitbake (with the same parameters) and without me changing anything int the filesystem, it gives different errors.
jmd`` has quit [Remote host closed the connection]
<rburton>
jmd`: its entirely possible that you just have lots of errors (maybe one root issue) and as bitbake stops when it first encounters an error and it will run tens of jobs at once, what one in particular fails first is random
<rburton>
but you've said nothing beyond "i run bitbake and it fails" so 🤷♂️
<rburton>
pick one failing recipe, bitbake just that, fix it.
<jmd`>
rburton: Right. So how can I make it run one job at a time?
<rburton>
no need to do that. just bitbake the first one that fails
<jmd`>
Also I never said "i run bitbake and it fails". You are putting words into my mouth.
<rburton>
i paraphrased "I run bitbake and it gives different errors."
<jmd`>
rburton: But the "first" one is different each run. So concentrating on the one error is difficult.
<rburton>
but if you bitbake the first one that fails then only that one will fail
<rburton>
because by definition its dependencies have succeeded
goliath has quit [Quit: SIGSEGV]
<jmd`>
That would seem not to be true. I am providing one target and I am getting 2 errors (and many warnings) from from different depdendencies.
<rburton>
so work up the dependency tree, pick an earlier recipe that is failing
<rburton>
if you bitbake foo and the recipe bar fails with errors, then bitbake bar
<jmd`>
okay. Now we're getting somewhere. So how do I find out the dependencies of foo?
<rburton>
just pick one of the recipes that actually errors, and bitbake that
<jmd`>
Yes. And how do I know which recipe is giving rise to an error?
jmd has quit [Remote host closed the connection]
<neverpanic>
jmd`: you can use bitbake -k to make it continue until it encountered all errors.
Vonter has quit [Quit: WeeChat 4.2.1]
<neverpanic>
That'll make it more deterministic, but you'll potentially see many many errors before it stops.
<rburton>
jmd`: the log tells you. "recipe foo fails in do_bar"
jmd has joined #yocto
<jmd`>
neverpanic: Yes, and it'll still come in a different order each time.
florian has quit [Quit: Ex-Chat]
<rburton>
yes, because the order isn't relevant. if foo depends on A and B then it doesn't matter if bitbake builds A or B first, or if it builds them both at the exact same time.
<neverpanic>
Yes. That's just the nature of doing things in parallel. It would take a very long time if it didn't.
<neverpanic>
You could change it to use fewer (or even just 1) job, but the order could still be different, because topological sorting doesn't have a single unique solution.
Vonter has joined #yocto
<jmd`>
rburton: I understand that. However most dependency tools, for this very reason, have an option to disable parallel builds in order to make debugging simpler.
jmd has quit [Remote host closed the connection]
<rburton>
set BB_NUMBER_THREADS=1 then, it won't help for the reason said above.
<rburton>
the answer is to build the specific recipe that failed and pick the errors off one at a time, instead of trying to do them all at once.
florian_kc has quit [Ping timeout: 252 seconds]
<rburton>
_maybe_ bitbake uses sorted sets to construct the task graph but I wouldn't rely on that. I _think_ python dicts are sorted by insertion order if you have a modern python so that would mean a bit more reliability. but this is the wrong solution to the problem.
<jmd`>
I'm not trying to do them all at once.
<jmd`>
I'm trying to do them one at a time.
<jmd`>
But that is very difficult because I can't cause the same recipe to run after I've applied a potential fix.
<neverpanic>
You can, just run bitbake $recipename
<rburton>
why can't you just bitbake that recipe?
<jmd`>
So I *think* it's fixed, only to discover 15 minutes later that my fix had not fixed the problem.
<jmd`>
rburton: Because I don't know which recipe is causing the problem.
<rburton>
but you said you just fixed a recipe
<rburton>
and every task failure says what recipe it was running in
<jmd`>
I don't see that. I just see a message like "ERROR: ParseError at Yocto/poky/meta-dmo/recipes-kernel/linux/linux-dmo.inc:46: Could not inherit file classes/fsl-vivante-kernel-driver-handler.bbclass"
<rburton>
parse errors happen before it even ran _any_ tasks
jmd has joined #yocto
<rburton>
if you've a 15 minute cycle for a bitbake parse it sounds like you're testing-via-CI, so i suggest replicating the build infra locally so you can iterate in seconds
<jmd`>
I've no idea what that means, but I will try to googleing those terms.
<Saur>
jmd`: That class comes from meta-freescale. Do you have meta-freescale in BBLAYERS in your bblayers.conf file?
<jmd`>
On a completely different note, are the mass of warnings like "SRC_URI:append += is not a recommended operator combination, please replace it." something I'm doing wrong or are they just a fact of life/
<Saur>
Or meta-fsl-arm apparently.
<jmd`>
Saur: no
jmd has quit [Remote host closed the connection]
<Saur>
Well, you need either of those layers to provide that class, or drop the recipe that inherits it, or the layer with the recipe that inherits it.
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<khem>
RP: yes, I have the final patches for glibc 2.39 on ml yesterday, the mips patch is accepted upstream it will be applied soon
<jmd`>
Saur: What if I just drop the "inherits" line?
alessioigor has quit [Quit: alessioigor]
<rburton>
jmd`: whoever wrote the recipes should fix that. :append += is a bad idiom and should be removed.
<Saur>
jmd`: The doubt the recipe would inherit the class without actually needing it...
<Saur>
I doubt*
<jmd`>
So should I file a bug? There are *many* of them.
tgamblin has quit [Remote host closed the connection]
<rburton>
jmd`: potentially you've mixed incompatible versions of things, but file a bug with whoever provided those recipes yes.
<Saur>
Are you trying to use an old layer with a new OE Core? Those warnings are fairly new.
<rburton>
that's what i'm thinking, but the compat stuff stops really old mixing.
tgamblin has joined #yocto
<jmd`>
Saur: Yes, that's what I'm doing.
<Saur>
Well, then it is not a surprise that you get those warnings. Correcting the syntax for those appends is part of updating the layer to match current the OE OCre.
<jmd`>
Isn't systemd part of the OE core?
<Saur>
It is, if you have `systemd` enabled in DISTRO_FEATURES.
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
<rburton>
if you mixing layer versions then typically you get to keep the pieces when it breaks. they're versioned for a reason.
<Saur>
jmd`: Nowadays you typically set INIT_MANAGER = "systemd" in your distro and it will take care of the rest (see meta/conf/distro/include/init-manager-systemd.inc for what it actually does).
sakman has quit [Read error: Connection reset by peer]
<jmd`>
rburton: and now I'm trying to glue the pieces back together.
<rburton>
those warnings are ignorable, it's a style thing mainly
<jmd`>
When I get "ERROR: ... inherits ... but doesn't set XXXXXX for package foo" how do I go about setting it? What's the syntax?
<rburton>
what's the actual error?
<jmd`>
mo-base-user_1.0.bb inherits useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or GROUPMEMS_PARAM for package dmo-base-user
<rburton>
if it doesn't set those variables then the class inherit is pointless, so remove it
<rburton>
that's "I was inherited but have nothing to do"
<jmd`>
Well I looks as if it does: USERADD_PARAM_${PN} = "--home ......
<jmd`>
That's what is confusing me
<Saur>
jmd`: Old syntax, neds to be corrected.
<Saur>
Should be USERADD_PARAM:${PN} now.
<rburton>
is dmo-base-user something you wrote, or something you were given?
<jmd`>
Ahh
<Saur>
There is a script to fix that...
<rburton>
because i'd have expected most vendors to have fixed this long ago
<jmd`>
Does that also apply to RDEPENDS_${PN} too?
<rburton>
yes
<rburton>
if its your code then read the migration guide for the releases you're upgrading via to understand very important things like the syntax changes and variable renames
<jmd`>
No. For the record, it's not my code.
<rburton>
then i'd ask vendor for updated code as its clearly obsolete and there should be an updated release
<jmd`>
I will ask, but I won't hold my breath.
<Saur>
jmd`: Migrating an old layer is no small task. If it is not your layer, you most likely do not want to do it yourself...
<Saur>
For the record, there are a number of scripts/contrib/convert-* scripts that will help converting old layers to new standards. However, as rburton says, you really must read and understand the migration guides for all the versions you are going through when updating...
<jmd`>
Saur: You're absolutely right. Would you like to do it for me :)
<jmd`>
I will look up the migration guides.
<Saur>
Sorry, I already have my plate full managing our own layers.
<jmd`>
Yes I thought that might be the answer.
<jmd`>
Hah! Yesterday I got a message telling me to change all instances of 'git://' to 'https://' Today I get a message telling me to change them back again!
<rburton>
you misread the message
<rburton>
if you're fetching a git repo then the protocol in the url is always git://
<rburton>
but you then have to specify what actual protocol to use in a protocol= argument
<rburton>
where as SRC_URI=https://github.com/foo/bar/ would get that url with wget, and not git
<jmd`>
Right. Thanks for the explanation.
Starfoxxes has quit [Ping timeout: 264 seconds]
<rburton>
the change was, iirc, that protocol is now mandatory
mckoan is now known as mckoan|away
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon has joined #yocto
<mischief>
for some reason after i sent a patch mail yesterday with git-send-email thru gmail, i've stopped receiving incoming messages from openembedded-core@ :-(
<jmd`>
I don't understand this message "ERROR: No recipes in default available for: <big-long-list>"
<jmd`>
<Saur>
jmd`: That means you have bbappend files with no matching bb files.
sakman has joined #yocto
goliath has joined #yocto
Thorn has quit [Quit: If you can't laugh at yourself, make fun of other people.]
florian_kc has joined #yocto
DarkestFM has joined #yocto
<jmd`>
Hmm.
<DarkestFM>
Hi im trying to patch the redis.conf in meta-openembedded/meta-oe/recipes-extended/redis/redis but there is also a redis.conf in the source, how do i get bitbake to recognize which file needs patched?
<DarkestFM>
when i use devtool it pulls the file from meta-oe into oe-local-files, modifying it and finishing devtool causes it to produce a full file instead of a patch
ablu has quit [Remote host closed the connection]
sakman1 has joined #yocto
sakman has quit [Ping timeout: 276 seconds]
sakman has joined #yocto
Saur_Home has quit [Quit: Client closed]
sakman1 has quit [Ping timeout: 252 seconds]
Saur_Home has joined #yocto
<Saur>
DarkestFM: That's because you cannot patch a file provided by one layer in another layer, you replace it whole.
<DarkestFM>
Cool. Is that documented somewhere?
<Saur>
I don't know. I think it is mostly a consequence of do_patch working in ${S}, while the files included from the layer end up in ${WORKDIR}.
<DarkestFM>
Makes sense.
<DarkestFM>
Thanks for the clarification.
sakman has quit [Ping timeout: 268 seconds]
vladest has quit [Remote host closed the connection]
sakman has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<jmd`>
So if FILES:${PN}:append += "${sysconfdir}/X11/Xsession.d/" is bad, what should it be?
<Saur>
Or in most cases for FILES:${PN}: FILES:${PN} += "${sysconfdir}/X11/Xsession.d/"
<Saur>
Note the space after the first quote in the first example.
<jmd`>
Right. So just remove :append
<JaMa>
Wrong.
<JaMa>
it will work in this case, but there might be other cases where the :append might be needed
<jmd`>
JaMa: but s/:append *+=/+=/g will be okay ??
<JaMa>
not necessary
<jmd`>
do elaborate...
<JaMa>
read the docs about various operator and their differences, there are even some presentations about this topic as it's not simple and many newcomers are confused from different behavior of :append and += and =+ or .=/=. and it's better to learn early
prabhakar has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 276 seconds]
Starfoxxes has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
jpuhlman has quit [Ping timeout: 256 seconds]
jpuhlman has joined #yocto
ptsneves has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
jmd` has quit [Remote host closed the connection]
florian_kc has joined #yocto
OnkelUlla has quit [Read error: Connection reset by peer]
OnkelUlla has joined #yocto
OnkelUlla has quit [Read error: Connection reset by peer]
OnkelUlla has joined #yocto
jmd has joined #yocto
jmd` has joined #yocto
goliath has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
ablu has joined #yocto
ablu has quit [Remote host closed the connection]
ablu has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
jmd has quit [Remote host closed the connection]
jmd` has quit [Remote host closed the connection]
ajfriesen has quit [Read error: Connection reset by peer]
ajfriesen has joined #yocto
ajfriesen has quit [Client Quit]
sakman1 has joined #yocto
ajfriesen has joined #yocto
sakman has quit [Ping timeout: 264 seconds]
sakman1 is now known as sakman
nerdboy has quit [Ping timeout: 276 seconds]
nerdboy has joined #yocto
khazakar has quit [Quit: Connection closed for inactivity]
sakman has quit [Ping timeout: 260 seconds]
jpuhlman has quit [Read error: Connection reset by peer]