camus has quit [Remote host closed the connection]
camus has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
rabbi[11]58 has quit [Ping timeout: 252 seconds]
rabbi[11] has quit [Ping timeout: 252 seconds]
rob_w has joined #yocto
leon-anavi has joined #yocto
leonanavi has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
mckoan|away is now known as mckoan
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
zpfvo has joined #yocto
manuel1985 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
jclsn has quit [Quit: WeeChat 3.0]
jclsn has joined #yocto
<jclsn>
JPEW: Getting expansion errors since the last Pyrex update
<jclsn>
It also says the latest Ubuntu version 22.04 is not supported
zpfvo has joined #yocto
<jclsn>
Guess Pyrex is only compatible with the latest Yocto release?
<jclsn>
No issues when building without Pyrex...
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
ederibaucourt has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
vmeson has joined #yocto
florian has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
zkrx has quit [Ping timeout: 268 seconds]
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
zkrx has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
greenwhale has joined #yocto
ptsneves has joined #yocto
odra has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
tomzy_0 has joined #yocto
fuzzybear396515 has joined #yocto
nemik has joined #yocto
<fuzzybear396515>
Is do_configure[foo] how I would define the configure task if foo is in DISTRO_FEATURES ?
<ptsneves>
fuzzybear396515: no, what lead to that assumption?
<fuzzybear396515>
ptsneves I was pretty sure it was false, that's why I asked. But, I saw examples using notation like do_configure[foo] and thought that maybe that might work with DISTRO_FEATURES in addition to other flags.
<rburton>
fuzzybear396515: as said yesterday, DISTRO_FEATURES are not overrides (or var flags). It's just a variable. If you want to do condititional things on it, then d.getVar("DISTRO_FEATURES") and poke at it (which is what bb.utils.contains does, it's getVar().strip().contains())
<rburton>
[foo] is a flag for the do_configure variable
<fuzzybear396515>
rburton and do_X[foo] means that foo is an override for the X task?
<rburton>
no
<rburton>
overrides are :like_this
<rburton>
do_configure[cleandirs] = "${B}" sets the cleandirs flag on do_configure to ${B}. this tells bitbake to ensure ${B} is an empty directory when it runs.
<ptsneves>
no. the S[X] is just notation for flag setting on a variable. By default you can do it but nothing happens.
<fuzzybear396515>
ptsneves I'm pretty confused generally. So, it's not some misunderstanding of PACKAGECONFIG that's causing my confusion.
<fuzzybear396515>
I was just searching for the example recipes in the Yocto manual where they did do_configure[noexec] () { }
<fuzzybear396515>
I couldn't find it.
<fuzzybear396515>
I was having a hard time finding the OVERRIDES documentation. Thanks rburton
<ptsneves>
then as @rburton mentioned a glance at the bitbake manual is a good idea. It is not so long and is a great way to start grasping things. That is actually how i did it a long time ago. Jumping to the general yocto docs before the bitbake ones felt extremely confusing. :)
<rburton>
fuzzybear396515: top hit for 'yocto overrides documentation' so not sure what you googled :). its all on docs.yoctoproject.org.
<fuzzybear396515>
rburton I was searching within the Yocto Project manual.
greenwhale has quit [Quit: Client closed]
<fuzzybear396515>
I think my questions are Bitbake-specific, not Yocto-specific.
<fuzzybear396515>
I think I'd benefit from reading the BitBake Manual.
<rburton>
yes
zpfvo has quit [Ping timeout: 246 seconds]
<fuzzybear396515>
I'm confused about these Bitbake-style Python functions. Our do_configure and do_install look more like POSIX shell functions than Python functions.
<fuzzybear396515>
We have case statements and install/mv/cp calls.
<fuzzybear396515>
If the tasks are truly Python functions then these should fail to parse.
<qschulz>
fuzzybear396515: python tasks are prefixed with "python", e.g. python do_compile() {}
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
<fuzzybear396515>
ptsneves with all due respect, I appreciate you linking out to the introduction, but I just read the entire introduction after your prompting and didn't see any description of how BitBake executes tasks or how recipe authors annotate tasks to indicate the language/runtime.
<fuzzybear396515>
qschulz okay, that makes sense. I saw that I could promote my own python functions to tasks. Somehow I didn't connect that all python functions need to be prefixed with the "python" keyword. I thought for tasks it was implicitly-determined.
<fuzzybear396515>
I read that > Only BitBake-style Python functions can be tasks.
<fuzzybear396515>
and thought that meant that tasks can only be written in BitBake-style Python functions.
alessioigor has quit [Quit: alessioigor]
<fuzzybear396515>
I understand now that they can also be shell functions.
alessioigor has joined #yocto
florian_kc has joined #yocto
<ptsneves>
fuzzybear396515: No problem. I meant this as the original statement "I'm confused about these Bitbake-style Python functions. Our do_configure and do_install look more like POSIX shell functions than Python functions. [...] If the tasks are truly Python functions then these should fail to parse."
<ptsneves>
In the introduction it mentions both are supported. From the link:
<ptsneves>
"Fundamentally, BitBake is a generic task execution engine that allows shell and Python tasks to be run "
<ptsneves>
That means leads to the next thing i answered, tasks, and they can be sheell and python
camus has quit [Quit: camus]
camus has joined #yocto
zpfvo has joined #yocto
<fuzzybear396515>
ptsneves Oh, yeah. My confusion about the support for shell functions arose from this in the BitBake Manual: Only BitBake-style Python functions can be tasks.
<fuzzybear396515>
The context was in comparing normal Python functions to BitBake-style Python functions, though, so out of context it sounds like only Python code can be written in tasks.
<fuzzybear396515>
The support for both (and the need to annotate with python if using a BitBake-style Python function) is clear, now.
<fuzzybear396515>
ptsneves Now it's clear that it's not saying that "tasks may only be written with BitBake-style Python functions" but, instead, that "tasks may be written in either POSIX-compliant shell functions or in Python style, but if in Python style then they must be BitBake-style Python functions (where certain imports are automatic, where the def keyword
<fuzzybear396515>
is not used, etc.)".
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
seninha has joined #yocto
<qschulz>
ptsneves: sorry, not following, what is correct/incorrect?
dmoseley has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
seninha has quit [Quit: Leaving]
zpfvo has joined #yocto
fuzzybear396515 has quit [Quit: Ping timeout (120 seconds)]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<JPEW>
jclsn: set a different version in pyrex.ini
gsalazar has joined #yocto
manuel1985 has quit [Ping timeout: 244 seconds]
manuel1985 has joined #yocto
shoragan has quit [Ping timeout: 240 seconds]
manuel1985 has quit [Ping timeout: 250 seconds]
shoragan has joined #yocto
shoragan has quit [Quit: quit]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
shoragan has joined #yocto
shoragan has quit [Client Quit]
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
shoragan has joined #yocto
manuel1985 has joined #yocto
dmoseley has joined #yocto
dmoseley has quit [Client Quit]
dmoseley has joined #yocto
dmoseley has quit [Client Quit]
shoragan has quit [Ping timeout: 268 seconds]
shoragan has joined #yocto
gsalazar has quit [Ping timeout: 265 seconds]
dmoseley has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
<JPEW>
jclsn: More specifically, we always default pyrex.ini to be the latest image, so if you're starting fresh it's going to use that. You can specify a different image in your pyrex.ini file
<ptsneves>
qschulz: In the manual there is the statement " Only BitBake-style Python functions can be tasks."
<qschulz>
ptsneves: the section is called "BitBake-Style Python Functions Versus Python Functions"
<qschulz>
and the list starts with: Following are some important differences between BitBake-style Python functions and regular Python functions
<qschulz>
so I think it's ok that we do not mention shell tasks in there?
<qschulz>
mmmm, I'm starting to work on a kirkstone brnch for our bsp layer (never too late..) and our custom kernel recipe does not fetch
<qschulz>
complains about "Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev()" but I use a fixed SRCREV and a fixed branch too
<qschulz>
ooof, found the issue
thomasd13 has quit [Ping timeout: 248 seconds]
<qschulz>
for some reason my copy-paste didn't copy the whole checksum
<qschulz>
I tested again with 39 digits instead of 40 and indeed, it triggers the error
<qschulz>
I think we can do a better job at guiding the user for this specific case
<qschulz>
mm I see JaMa have a patch in master for this one error
rob_w has quit [Remote host closed the connection]
<ptsneves>
qschulz: it still wont catch you are missing 1 character due to it considering a tag/branch name correct?
<qschulz>
ptsneves: yeah :/
<ptsneves>
:/ how would we catch that? Maybe the issue is that branches tags or hashes get all put in SRCREV.
<ptsneves>
maybe add in the message that it can also be broken hash?
<qschulz>
it's not that easy as the code that is printing this error is handling bazaar, mercurial and git fetchers
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<qschulz>
nvm, can't read
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
zpfvo has joined #yocto
Minvera has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
shoragan has quit [Quit: quit]
zpfvo has quit [Ping timeout: 252 seconds]
shoragan has joined #yocto
zpfvo has joined #yocto
gsalazar has joined #yocto
shoragan has quit [Ping timeout: 246 seconds]
shoragan has joined #yocto
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ptsneves>
qschulz: Recipe uses a floating tag/branch '%s' for repo '%s' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE). If the SRCREV was meant to be a hash check if the length is correct as well as check for typos.
<ptsneves>
would this be better? If so i will send the patch
<qschulz>
ptsneves: I think there are two cases for this message to appear
<qschulz>
1. invalid hash (not hexadecimal character or not 40-character long)
<qschulz>
2. AUTOREV but with missing SRCPV in PV?
<qschulz>
I think we should print the correct message depending on the case
<JaMa>
not only AUTOREV any non-fixed SRCREV needs SRCPV in PV IIRC
gsalazar has quit [Ping timeout: 252 seconds]
<qschulz>
JaMa: so we could have a branch name in SRCREV provided PV contains SRCPV?
leonanavi has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
<ptsneves>
qschulz: a tag name for sure
<ptsneves>
and the ambiguity remains.
<qschulz>
But.. why?
<qschulz>
we have a ;branch= and a ;tag= parameter for the fetcher
<qschulz>
so just force SRCREV to be a git commit hash or AUTOREV and nothing else
<qschulz>
no? what am I missing?
<ptsneves>
ah so i am in the wrong. You are right that we have these URL params
<qschulz>
I am not saying it's not what we currently support though :)
<ptsneves>
qschulz: and AUTOINC?
<qschulz>
ptsneves: AUTOREV is AUTOINC
<qschulz>
internally
<ptsneves>
you are right get_autorev sets it
<ptsneves>
qschulz: is the SRCREV 40 character SHA-1 in every fetcher, or just in git?
<qschulz>
ptsneves: the 40-character check is only for git
<qschulz>
so we could check if SRCREV is set to AUTOINC, then we know it's SRCPV that is missing from PV that triggers this issue (still to be confirmed though, haven't tested)
<qschulz>
and we can advise the user to add SRCPV to PV
<ptsneves>
that code check is already very late perhaps. As there ud.revisions may indeed have used the branch/tag parameters.
<qschulz>
and if it's not, we know it's an invalid sha1
<qschulz>
don't know, I have no experience in Bitbake code base :/
Guest8423 has joined #yocto
<ptsneves>
seems a bit more complicated :(
<qschulz>
ptsneves: I think it makes sense to only allow sha1 or AUTOREV in SRCREV
<qschulz>
this forces users wanting to use a branch or tag to use AUTOREV in SRCREV
mckoan is now known as mckoan|away
<qschulz>
which very much shows that it's not guaranteed to be stable
<ptsneves>
the thing is that the SRCREV is not even read in git.py. In the git.py the hash is retrieved from ud.revisions[name] which, may be set by SRCREV. I do not know yet
zpfvo has quit [Quit: Leaving.]
<Guest8423>
Hi, I'm new to Yocto and I'm getting an error while trying to build fribidi-native. Is the the right channel to ask for help?
<rburton>
sure
<rburton>
ask away
<Guest8423>
Thank you. I am using a BSP based on Yocto Thud and I added meta-ros layer that I think it pulled in fribidi native and it is causing this error: | Traceback (most recent call last):
<Guest8423>
| File "/*******/tmp-glibc/work/x86_64-linux/fribidi-native/1.0.5-r0/recipe-sysroot-native/usr/bin/meson", line 30, in <module>
<Guest8423>
| from mesonbuild import mesonmain
<Guest8423>
| ModuleNotFoundError: No module named 'mesonbuild'
<Guest8423>
| ERROR: meson failed
<rburton>
Thud has been EOL since 2019, you know that right?
<Guest8423>
Yes, I am using the BSP package from a chip vendor and this is my only option.
<rburton>
i'm assuming you're using the thud branch of meta-ros, and not master
<rburton>
your option is to shout at your vendor that thud has been EOL since 2019 and they expect you to pay for this?
<rburton>
whilst people don't get angry at them, they'll continue to release obsolete BSPs
<Guest8423>
correct, I'm using thud branch of meta-ros.
<rburton>
weird. i'd suggest removing your tmp and trying again. it has the meson wrapper but not the actual package.
<rburton>
from meta-ros: "building with thud is no longer supported as of Milestone 15 (2020-12-23)." Just saying :)
<rburton>
can you name and shame the vendor? its possible that there's an unofficial but modern bsp you can use
<Guest8423>
I have tried a clean build a few times and I keep getting the same error.
<rburton>
try "bitbake meson-native -C unpack" to force it to rebuild meson
<Guest8423>
do you think even thud branch of meta-ros os not supporting thud anymore?
<rburton>
the thud branch of meta-ros isnt supported. it supports thud, its just that they don't support it
alessioigor has quit [Quit: alessioigor]
<Guest8423>
I tried "bitbake meson-native -C unpack" which succeeded and then "bitbake fribidi-native". Still getting the same error.
<rburton>
very strange
<rburton>
an interesting test would be a clean poky with no vendor bsp and no meta-ros, just bitbake fribidi-native
<sakoman>
qschulz: So for now I can't take that. If you'd like to research the error and submit a fix I'd be happy to reconsider :-)
florian has quit [Quit: Ex-Chat]
<Guest8423>
rburton: clean poky with no vendor bsp and with vendor bsp is working. That error shows up when I add meta-ros layers. Any suggestion on how to start debugging?
<denix>
apparently, the "fix" is to disable building gdk-pixbuf tests...
<JPEW>
denix: Hmm
<JPEW>
denix: Passing `--security-opt seccomp=unconfined` to docker might fix it?
<JPEW>
You can put that in `run.args` in pyrex.ini
<denix>
yeah, disabling seccomp is mentioned there, but not sure about the consequences... I can try
vladest has quit [Ping timeout: 250 seconds]
<JPEW>
Might be able to pass a custom seccomp policy
_wmills has quit [Ping timeout: 265 seconds]
<denix>
seccomp=unconfined seems to help - it's building w/o breakage, will see if there are any other issues
<rburton>
JaMa: any thoughts on Guest8423 above?
odra has quit [Ping timeout: 260 seconds]
<JaMa>
Guest8423: whole meta-ros isn't activelly maintained anymore and I don't think it was doing anything with fribidi nor meson, I guess it's just thud being incompatible with your host OS as it's failing in -native
<JaMa>
Guest8423: try some old unsupported host OS in docker container (like ubuntu 18.04) if you want to build old unsupported junk bsp
Minvera has quit [Ping timeout: 252 seconds]
<Guest8423>
JaMa: Thank you. I am currently using Ubuntu 18.04. I used "bitbake -c devshell fribidi-native" to get some insight. When meta-ros is NOT enabled, python3 version in devshell terminal is "3.5.6" and when I enable meta-ros, python version switches to "3.7.5". Not sure if this information is useful.
dtometzki has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
dtometzki has joined #yocto
Guest3857 has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
florian_kc is now known as florian
<Guest3857>
Hi! I am currently setting up yocto for my embedded system. I have a question related to devtool: I want to split my meta-layers into "meta-bsp" and "meta-project-specific". The bsp layer should only include pure HW support whereas the project-specific layer should only contain project specific stuff. Still it might be needed to have kernel patches
<Guest3857>
in both layers some are only for HW support the others might be project specific. How can I handle that with devtool properly? When I do: "devtool update-recipe -a meta-project-specific" all my patches which are already included in meta-bsp are copied to meta-project-specific. Is it possible to only generate the patches which are not already
<Guest3857>
included in meta-bsp?
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
rabbi[11] has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
violet has quit [Quit: leaving]
sakoman has quit [Ping timeout: 252 seconds]
Guest3857 has quit [Ping timeout: 244 seconds]
Guest3827 has joined #yocto
<mcfrisk>
linux-yocto from master is very slow to fetch/download. Would switching from git to https protocol help?
Minvera has joined #yocto
Minvera2 has joined #yocto
Minvera has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
Minvera2 has quit [Remote host closed the connection]