<michalsieron>
and back then there was also no mention of MIT
<mckoan>
michalsieron: the proper LICENSE definition in the recipe is resposibility of the author. In this case 'yasm' has a complex license model as described by the COPYING file
<mckoan>
michalsieron: may be a bug or a typo or a misunderstanding. You can ask to the author
<LetoThe2nd>
michalsieron: the commit is also before the SPDX style license names. but yeah, the license structure of yasm is complex according to their document, and is definitely not appropriately represented.
LocutusOfBorg has quit [Ping timeout: 240 seconds]
<muhbay>
REGISTER
d-s-e has quit [Ping timeout: 268 seconds]
ilunev has joined #yocto
ilunev is now known as luneff
luneff has quit [Client Quit]
muhbay has quit [Quit: Client closed]
muhbay has joined #yocto
muhbay has quit [Quit: Client closed]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
Zaid has quit [Quit: Client closed]
LocutusOfBorg has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<Peter[m]123>
halstead: Thanks v much for the hashserver write-up (for some reason your message doesn't show up for me in Element but just found it in the IRC logs :-/) Going through it now and yes will update if we find any issues.
muhbay has joined #yocto
<muhbay>
i just cloned bitbake git.openembedded.org/bitbake/. set SRC_URI. But it is not downloading. Is it normal?
<muhbay>
i can download SRC_URI files using fetch. fetcher = bb.fetch2.Fetch(src_uri, d)
<muhbay>
fetcher.download()
muhbay has quit [Client Quit]
muhbay has joined #yocto
kpo has quit [Ping timeout: 240 seconds]
kpo_ has joined #yocto
<rburton>
muhbay: what are you actually trying to do?
seninha has joined #yocto
<muhbay>
i am trying to learn pure bitbake without openembedded.
<muhbay>
does SRC_URI automatically download files using poky classess?
<muhbay>
thanks. i was thinking it is a feature of bitbake.
chep has joined #yocto
<rburton>
bitbake is the task executor (and helper functions, like the fetchers). it comes with no tasks, which is why it's mostly academic to use it without something like oe-core.
<muhbay>
can we use bitbake for other purposes such as building rtos?
<rburton>
you can use _yocto_ to build rtos, there are zephyr and freertos layers
<rburton>
but you can use bitbake to build anything, just define the tasks and off you go
<yokto>
Hi, does the manual cover every possible defines (I mean RDEPENDS or something similar)? Because I think I came one that I couldn't find if I'm correct
<rburton>
yokto: it _aims_ to. If you find something missing, file a bug ideally
<yokto>
So the conclusion is that the manual should cover every define. I will do that thanks
<rburton>
git.yoctoproject.org is the official git repo of poky. a git repo is just source code, github/gitlab also doing issues is part of their value-add
<rburton>
bugs are at bugzilla.yoctoproject.org
otavio has quit [Remote host closed the connection]
<yokto>
got it thanks
yokto has quit [Quit: Client closed]
otavio has joined #yocto
d-s-e has joined #yocto
prabhakarlad has quit [Quit: Client closed]
muhbay has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
seninha has quit [Remote host closed the connection]
angman has joined #yocto
zpfvo has joined #yocto
tlwoerner has joined #yocto
angman has quit [Quit: Client closed]
angman has joined #yocto
muhbay has quit [Quit: Client closed]
<angman>
Hi! I'm learning dependency handling in yocto. I am a little confused about how to use the depends flag vs the rdepends flag.
<angman>
Could you please tell me what is the difference between these two flags?
<angman>
bitbake-user-manual said ```The [rdepends] flag works in a similar way but takes targets in the runtime namespace instead of the build-time dependency namespace.``` ,
<angman>
But unfortunately, I could not figure out what this meant.
<angman>
I created an experimental recipe, swapped the depends and rdepends flags, and observed how the output of the bitabake -g command (task-depends.dot) changed. However, the output of the bitabake -g command (task-depends.dot) does not seem to change at all when these two flags are swapped.
<LetoThe2nd>
angman: DEPENDS: needs to be available when the recipe is built. RDEPENDS: needs to also be installed on the target.
<LetoThe2nd>
angman: example: if you want to compile something written in C, then you definitely have a DEPENDS on gcc (or similar), but not an RDEPENDS. You don't need it in the resulting image. whereas a bash script that you install to /usr/bin does not need anything in DEPENDS, it can be just copied over - but it needs bash as an RDEPENDS.
<angman>
Thank you! but I understood DEPENDS and RDEPENDS variables. I want to understand depends and rdepends flags!
ptsneves has quit [Ping timeout: 268 seconds]
<LetoThe2nd>
ah! okay, sorry for the misunderstanding.
<angman>
👍
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
ptsneves has joined #yocto
<jnugen[m]>
Hi everyone! I've got a problem that I haven't been able to find an answer to.
<jnugen[m]>
I have a layer that builds an image that has a bunch of packages. I would like to make a new layer that modifies the original layer to remove some of those packages. The issue I'm having is that some sub-layers have "layer.conf" files with LAYERDEPENDS in them. I need to "edit" those files to remove some of the dependencies. Is there a good/any way to edit those "layer.conf" files?
<JPEW>
angman: IIRC DEPENDS is basically short hand for a [depends] expression (It does other things too)... I don't recall exactly off my head but maybe something similar to `do_configure[depends] = "${@' '.join(s + ':do_populate_sysroot' for s in d.getVar("DEPENDS").split())"`
prabhakarlad has joined #yocto
<JPEW>
angman: So [depends] is the more general form, and DEPENDS uses it to do a specific task
<JPEW>
I believe RDEPNDS and [rdepends] have the same relationship, but it's much less common to use [rdepends]
<angman>
I think DEPENDS and the depends flag are quite different: DEPENDS is combined with deptask to define dependencies between tasks, while the depends flag does not do that.
<angman>
In any case, I would like to know the difference between the DEPENDS and RDEPENDS flags...
<angman>
sorry, I mistype. I would like to know the difference between the depends and rdepends flags...
<angman>
I think DEPENDS variable and depends flag is not same.
<JPEW>
angman: Ya, it does use deptask, specifically `do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"`
<angman>
That's right. Let me get my questions straight for a minute.
<JPEW>
angman: Out of curosity, why the fixation on [rdepends]?
<angman>
> Out of curosity, why the fixation on [rdepends]?
<angman>
It was because it was included in an OSS recipe I was working with. I asked the question because I am concerned about descriptions that I do not understand the meaning of.
<angman>
Sorry for the long preamble, etc. My questions are as follows.
<angman>
* DEPENDS variable and depends flag are different (I think)
<angman>
* I don't know the difference between the depends flag and the rdepends flag.
<angman>
* What is the difference? Or is there no difference?
<JPEW>
angman: DEPENDS and [depends] are different but do similar things (control build time dependencies). TBH I have no idea why you would use [rdepends] over RDEPENDS in a recipe; it's a pretty rare thing to do (e.g. OE core only appears to do it for SDK recipes)
florian_kc has quit [Ping timeout: 246 seconds]
florian_kc has joined #yocto
sakoman has joined #yocto
dgriego has joined #yocto
<angman>
Hmmm... I wish there was documentation somewhere, as the code seems complicated and hard to understand.
<JPEW>
angman: [rdepends] has a little documentation.... but not a lot and it's not terribly clear
<JPEW>
If you figure it out, that would probably be worth while to clarify
<RP>
JPEW, angman: rdepends lets you use package namespace instead of build time, so you could have a [rdepends] = "bash-doc:do_packagedata" and it would resolve correctly
<RP>
it knows how to resolve bash-doc to the bash recipe
<angman>
yes, I know that..
<JPEW>
RP: Ah, that make sense, is that the only difference?
<RP>
JPEW: I think so
<JPEW>
Cool. Ya that is not like RDEPENDS at all then
<angman>
Does this mean that the depends and rdepends flags are considered the same?
<RP>
angman: they work the same way one takes a recipe namespace target and the other takes a runtime package name target
<JPEW>
IOW, they do the same thing, the difference is how the "target" (e.g. "bash-doc") is interpreted; depends is a recipe, rdepends is a package defined in a recipe (??)
<angman>
The target of depends flag is recipe file? really?
<RP>
angman: a recipe name, PN specifically
<RP>
angman: whereas rdepends uses something from PACKAGES
<angman>
Ahhh, so that's how it is! I see!
<angman>
I understood it well. Thank you so much! 😁
goliath has quit [Quit: SIGSEGV]
<angman>
jnugen[m] I'm sorry, I have pushed your post away. If anyone is able to answer the question, could you please answer it for ?
<angman>
> I have a layer that builds an image that has a bunch of packages. I would like to make a new layer that modifies the original layer to remove some of those packages. The issue I'm having is that some sub-layers have "layer.conf" files with LAYERDEPENDS in them. I need to "edit" those files to remove some of the dependencies. Is there a good/any
<angman>
way to edit those "layer.conf" files?
angman has quit [Quit: Client closed]
<rfuentess>
if I'm trying to run yocto in a docker image, is it a good idea to try to preserve the non-root rule ?
<LetoThe2nd>
rfuentess: yup
prabhakarlad has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
<rfuentess>
Okas
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<rfuentess>
but if the lifetime of the docker image is so limited, why is still a good idea ?
thomasd13 has quit [Ping timeout: 240 seconds]
<rfuentess>
but looking into the sanity.bbclass I can see all the other checks ...
<rburton>
rfuentess: some software refuses to build as root.
<rburton>
and, well, it's best practise to do as little as root as possible
<rburton>
also not sure on the impact of being root when you run pseudo, that might be prone to break
<fray>
being actual root and running pseudo will likely lead to problems (and potentially VERY unsafe behavior of the system)
<fray>
we use docker to do our builds, the build happens in a location with a long life span, but the docker part is 'short lived'. We _never_ build as root, we always limit permissions for the build
<LetoThe2nd>
rfuentess: in a nutshell, because being root in a container is essentially root on the machine.
ptsneves has quit [Ping timeout: 268 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
<frieder>
Is there a way to get the env from bitbake at the same time when running the bitbake command?
<frieder>
If I run "bitbake -e xyz" separately the env differs from the actual "bitbake xyz" due to changed timestamp in DATETIME.
<rfuentess>
rburton fray LetoThe2nd : thanks
<frieder>
The background is that I want to parse the env for variables like IMAGE_NAME to find out the filename of the resulting image. But as IMAGE_NAME includes the timestamp I never get the correct filename.
<frieder>
Hm, I guess I could just override DATETIME to a persistent value by using "bitbake --postread=override-datetime.conf".
zpfvo has joined #yocto
ptsneves has joined #yocto
<rburton>
frieder: use the non-timestamped symlinks which are basically for this reason
goliath has joined #yocto
<frieder>
rburton: hm, right. Why didn't I think of this before? Sounds so obvious. I will try that. Thanks!
bps2 has quit [Ping timeout: 246 seconds]
derinachan[m] has quit [Remote host closed the connection]
camus has quit [Ping timeout: 240 seconds]
michalsieron has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 256 seconds]
rfuentess has quit [Remote host closed the connection]
<cybergoldfish>
I'm writing a recipe for getting analysis data during final stages of a build. Is there a way to call an equivalent to tinfoil's get_recipe_file() func from within a recipe? Can't use tinfoil directly from recipe (or call out to script that uses tinfoil) since tinfoil tries to start a new bb server, which is impossible due to bitbake.lock
xmn_ has quit [Client Quit]
zpfvo has quit [Remote host closed the connection]
Thorn has quit [Ping timeout: 240 seconds]
Piraty has quit [Quit: -]
xmn has joined #yocto
Piraty has joined #yocto
mckoan is now known as mckoan|away
d-s-e has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
vladest has quit [Ping timeout: 246 seconds]
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
cybergoldfish has quit [Quit: Client closed]
cybergoldfish has joined #yocto
cybergoldfish has quit [Client Quit]
florian_kc has joined #yocto
bps2 has joined #yocto
frieder has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
<jbo>
Hey guys, I created a meta-custom/recipes-kernel/linux/<kernel>_<version>.bbappend file. upon invoking bitbake, I get:
<jbo>
WARNING: No recipes in default available for: meta-custom/recipes-kernel/linux/<kernel>_<version>.bbappend
<jbo>
what exactly does this mean & how do I resolve it?
<nerdboy>
it means it can't find linux/<kernel>_<version>.bb in any other layers
<nerdboy>
so you're trying to append to a recipe that does not exist in the build config
<jbo>
nerdboy, thanks - that is helpful. how do I figure out what i am doing wrong? I used "oe-pkgdata-util lookup-recipe kernel" to figure out which kernel I am using and I checked uname on the running device as well
<jbo>
I assume I got the wrong kernel_version.bbappend then?
Thorn has joined #yocto
<jbo>
apparently I got the version wrong. I now have xxx_%.bbappend and that seems to do the trick :)