leonanavi has quit [Remote host closed the connection]
sakoman has joined #yocto
ar__ has quit [Ping timeout: 240 seconds]
Habbie has joined #yocto
Tokamak has joined #yocto
jmiehe has joined #yocto
dtometzki has joined #yocto
dti has joined #yocto
dtometzki has quit [Ping timeout: 250 seconds]
jmiehe has quit [Quit: jmiehe]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nerdboy has quit [Ping timeout: 240 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
nerdboy has quit [Ping timeout: 268 seconds]
risca has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
prabhakarlad has quit [Quit: Client closed]
zkrx has quit [Ping timeout: 252 seconds]
kevinrowland has quit [Quit: Client closed]
zkrx has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amitk has joined #yocto
dti is now known as dtometzki
alejandrohs has quit [Ping timeout: 256 seconds]
alejandrohs has joined #yocto
sakoman has quit [Quit: Leaving.]
huseyinkozan has joined #yocto
davidinux has joined #yocto
<davidinux>
#oniroproject
davidinux has quit [Ping timeout: 250 seconds]
davidinux has joined #yocto
Thorn has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
goliath has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor 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 [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Schlumpf has joined #yocto
ardo has quit [Ping timeout: 256 seconds]
ardo has joined #yocto
GNUmoon has joined #yocto
frieder has joined #yocto
rfuentess has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
d0ku has joined #yocto
zpfvo has joined #yocto
<ziga_>
In the documentation for variable "S" I can read that by default, git:// repositories are cloned to ${WORKDIR}/git during do_fetch() step. Therefore recipe heeds to define S = "${WORKDIR}/git" so that further steps can find the source code. But! I have a recipe that uses SRC_URI = "file:///absolute/path/to/folder" (it is just a folder) but when I process this recipe with "bitbake recipe" I don't know where inside the $WORKDIR sources are
<ziga_>
copied? So I don't know what to set for "S"... Can anyone give me any advice?
<qschulz>
ziga_: because we cannot know where it fetches the files
<qschulz>
ziga_: go into $WORKDIR of your recipe and see where your files are extracted
zpfvo has joined #yocto
<qschulz>
(or copied)
<svuorela>
Hi. I might have done something wrong. When trying to build a sdk, all of my RPM's seems to be conflicting on /usr/local/oe-sdk-hardcoded-buildpath/sysroots
<qschulz>
then set S to that valu
<qschulz>
e
<qschulz>
usually when using file:// with files that aren't archives, S is ${WORKDIR}
<ziga_>
I found that if I have "SRC_URI://home/ziga/application" they are extracted to "${WORKDIR}/home/ziga/application".
<ziga_>
So I should probably set S = "${WORKDIR}/home/ziga/application"
<qschulz>
ziga_: sounds reasonable
<qschulz>
though using absolute paths is.. awful to say the least :)
<ziga_>
I try to use FILESEXTRAPATHS and then make the SRC_URI relative. But then I don't know how to use variables to set "S" so that I don't have to use absolute paths....
<qschulz>
ziga_: what are you trying to do?
<ziga_>
I just want to compile but I want to use a folder and not GIT repo. I tried setting S = "${WORKDIR}/home/ziga/application" and this folder gets created, but is not populated with sources.
vladest has quit [Remote host closed the connection]
<ziga_>
It looks like it only works well with GIT repositories. It works if I set "SRC_URI = git://whatever" and then set S = "${WORKDIR}/git". In this case do_fetch() method really fetches sources to the ${WORKDIR}/git" and during the do_compile() method sources are found because do_compile() uses "S" variable to find sources. But If I try to use folder instead of GIT repository nothing works...
<ziga_>
Sources are not transfered from my source repository (a folder) inside the workdir no matter what I do.
vladest has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<qschulz>
ziga_: and how are you going to share this folder so other people can compile it?
rfuentess has quit [Remote host closed the connection]
<ziga_>
This folder has a closed source software inside.
<qschulz>
ziga_: externalsrc is one way to do it but you still need to figure out how to share this code
<coldspark29[m]>
Hah, I should mind that this is an IRC channel and that my editing is quite pointless ^^
coldspark29 has joined #yocto
coldspark29 has quit [Client Quit]
pgowda_ has joined #yocto
<ziga_>
When I will want to share the code I will just create a GIT repository local top the company and I will use the classical method and git repositories. But... What exactly did YOU mean with sharing?
<qschulz>
ziga_: well, exactly "When I will want to share the code I will just create a GIT repository local top the company and I will use the classical method and git repositories"
<qschulz>
during heavy development phase, externalsrc is probably a good idea
<qschulz>
or git with AUTOREV, and the git fetcher is able to handle local git repositories too with the protocol=file
<qschulz>
and you might even use usehead parameter too
<ziga_>
Currently I am still learning Yocto and there is no need to put everything in GIT repositories. So using a folders is as good as it gets for now. At a later stage I will think about this as well.
<qschulz>
coldspark29[m]: can you make a minimal reproducible setup? with e.g. only poky?
<coldspark29[m]>
qschulz: I don't think that the issue occurs in just poky. It is something about our custom layer
<qschulz>
coldspark29[m]: try to find which recipe/conf/class file is triggering this
<coldspark29[m]>
I will try to see after I am finished upgrading to honister. This bug is really bugging me.
<qschulz>
coldspark29[m]: if you need to remove the whole tmpdir every two tries, it's probably worth looking into it now so you get less frustrated and lose less time :)
<coldspark29[m]>
I have to delete the tmp directory after every build attempt
<coldspark29[m]>
True
<coldspark29[m]>
Uh the kernel is compling yay
<coldspark29[m]>
Fingers crossed that it will boot as well :D
florian has joined #yocto
leon-anavi has joined #yocto
<Schlumpf>
Hi, which package do I need to get the "arp" command?
<Schlumpf>
Schlumpf: net-tools
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
olani has joined #yocto
goliath has joined #yocto
florian_kc has joined #yocto
<coldspark29[m]>
qschulz: I think the error is related to building zulu-jdk11, which my colleague added, because the openjdk wasn't compatbile with aarch64. Bitbake doesn't find the error. If I surround the whole block with try/except, only zulu related errors occur and it builds fine
<coldspark29[m]>
Any ideas about jdk? Do I really need the precompiled zulu-jdk11? Doesn't seem like a good solution
<coldspark29[m]>
meta-java seems to be very outdated
<coldspark29[m]>
Yeah I fixed the source for the zulujdk and now it doesn't happen anymore. There was a warning about that, but I didn't take it seriously. Guess I should do that in the future
<qschulz>
sometimes I wonder if we shouldn't just collectively decide to remove warning log levels and just go for errors :p
<coldspark29[m]>
The Yocto hive mind says yes
<qschulz>
coldspark29[m]: care to give the exact warning you had and what you did to fix it so that people searching for similar errors can actually find some help/hint?
<coldspark29[m]>
I then changed the SRC_URI to the remote file (and also updated the version)
<qschulz>
coldspark29[m]: wait... so the filename actually has a semi-colon in it
<qschulz>
?
<coldspark29[m]>
Aaaah probably not
zpfvo has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
I guess this was just blindly changed the the syntax override script
<coldspark29[m]>
s/the/by/
<qschulz>
ugh, colon sorry, english...
<coldspark29[m]>
Doppelpunkt
<coldspark29[m]>
point double
<qschulz>
double point :)
zpfvo has joined #yocto
<qschulz>
coldspark29[m]: but this is very likely an issue with the migration script indeed
<coldspark29[m]>
d'accord
<qschulz>
since aarch64 is definitely a known archietcture, it took _aarch64 for an overrides
<coldspark29[m]>
Yes, but should be hard to change
<qschulz>
coldspark29[m]: colon is a valid character for filenames though
<qschulz>
so it shouldn't break the cache
prabhakarlad has joined #yocto
<qschulz>
I think there needs to be some safeguard against this
<qschulz>
the issue is that we use the colon character in some places as separator
sstiller has joined #yocto
<qschulz>
this is the case for the file watcher, which splits first by space and then by colon because what's between the colon and the next space contains a boolean stating whether or not the file should be watched (IIRC)
<qschulz>
coldspark29[m]: could you please open a bug on our bugzilla.yoctoproject.org to let us know there is an issue with the files which have a colon in it and it somehow silently fails in the first try and breaks the cache on the second?
gsalazar_ has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
gsalazar has quit [Read error: Connection reset by peer]
gsalazar__ has joined #yocto
alessioigor has joined #yocto
gsalazar_ has quit [Ping timeout: 240 seconds]
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
gsalazar__ has quit [Quit: Leaving]
gsalazar has joined #yocto
alessioigor has quit [Client Quit]
camus1 has joined #yocto
camus has quit [Quit: camus]
camus1 is now known as camus
<coldspark29[m]>
<qschulz> "coldspark29: could you please..." <- Yes after the break 😁
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<RP>
qschulz: I suspect filenames with colons in aren't supported
<RP>
hmm, our sanity tests don't say that is isn't allowed
<RP>
.. + @ " " and % aren't allowed in TMPDIR/COREBASE
rber|res has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
<kayterina[m]>
if I run 'devtool create-workspace /workspace_2; devtool switches workspace. How can I go back to workspace?
manuel1985 has joined #yocto
<qschulz>
RP: i suspect this too. The question is if we want to support it or actually detect it and do a fatal error on that scenario
Schlumpf has quit [Ping timeout: 256 seconds]
<RP>
qschulz: we should error if we can't support it I guess
zpfvo has joined #yocto
<mcfrisk>
Should recipe license text names be converging towards e.g. SPDX naming of the license? E.g. PD in meta-selinux/libselinux is known better as libselinux-1.0 as in https://spdx.org/licenses/libselinux-1.0.html ?
<rburton>
if the license file is already in oe-core then yeah
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<mcfrisk>
and if not, makes sense to add to oe-core or to the layer in question, I think I'll send a patch
<RP>
mcfrisk: the plan is to converge on them, yes
likewise has joined #yocto
<rburton>
what's the variable like PNBLACKLIST but not that, that filters out recipes in a layer?
* rburton
has a brainfart
<qschulz>
BBMASK?
<rburton>
yes!
<rburton>
thanks
<coldspark29[m]>
<RP> "qschulz: I suspect filenames..." <- There were no colons originally `file://zulu11.48.21-ca-jdk11.0.11-linux_aarch64.tar.gz`
Schlumpf has joined #yocto
<qschulz>
coldspark29[m]: we know, but the : is a valid character in filenames on Unix systems
<qschulz>
and even if technically your file with the : didn't exist, it highlighted an error in Bitbake code
Guest21 has joined #yocto
<coldspark29[m]>
Okay, I requested access to bugzilla, but the admin hasn't replied yet
jmiehe has quit [Quit: jmiehe]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<Guest21>
According to WhiteSource web site, .bb file are supported Someone here use whitesource to scan recipes ?
huseyinkozan has quit [Quit: Konversation terminated!]
Schlumpf has quit [Quit: Client closed]
rber|res has quit [Ping timeout: 256 seconds]
dtometzki has quit [Remote host closed the connection]
dtometzki has joined #yocto
d0ku has quit [Ping timeout: 256 seconds]
zpfvo has quit [Quit: Leaving.]
frieder has quit [Ping timeout: 240 seconds]
<halstead>
jonmason: you're welcome. I added it a while back. I should have notified you. I saw the email about reimbursement and migration. I'll answer today.
<jonmason>
halstead: no worries
<rburton>
khem: why does meta-clang set LLVMVERSION=13.0.1?
<rburton>
there is no 13.0.1 recipe that i can see
rfuentess has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 240 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
Guest21 has quit [Ping timeout: 256 seconds]
manuel1985 has quit [Quit: Leaving]
rber|res has joined #yocto
<ziga_>
I am working on a kernel "linux-ti-staging" which is fetched to the "${WORKDIR}/git" and I have to patch a file S = "${WORKDIR}/git/arch/arm/boot/dts/am335x-boneblack.dts". How do I properly create this patch? How can I create a patch for the changes in the folder S = "${WORKDIR}/git/arch/arm/boot/dts"? I already have my own layer "meta-customm/recipes-kernel/linux" where there is a "linux-ti-staging_%.bbappend" file and a folder
<ziga_>
"meta-customm/recipes-kernel/linux/linux-ti-staging" where I already put a defect patch (it could not be applied during the build and I am sure I somehow didn't create it correctly).
<ziga_>
SORRY THERE IS A MISTAKE - please ignore "S =" at some places. :))))
<vd>
how do I generate a FIT image for the kernel?
jatedev has quit [Quit: Client closed]
<khem>
rburton: when using meta-clang we want to use llvm from there too and not from core
<rburton>
where is the llvm in meta-clang though?
<rburton>
i have meta-clang, and get warnings
<dwagenk>
<ziga_> "I am working on a kernel "linux..." <- `devtool modify linux-ti-staging`, make your modifocations in build/workspace/sources/linuc-ti-staging and commit them, `devtool finish linux-ti-staging path/to/own/layer`
<ziga_>
I will take a look at this! Thank you!
<dwagenk>
look at the devtool section in the yocto manual for details. also commit your own layer before the `devtool finish` invocation to have a safety net in place...
florian_kc has joined #yocto
rber|res has quit [Ping timeout: 250 seconds]
rber|res has joined #yocto
zyga-mbp has joined #yocto
likewise has quit [Quit: Client closed]
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
davidinux has quit [Ping timeout: 240 seconds]
<ziga_>
Does anyone know if reverse compilation of a .dtb file to .dts file with "dtc -I dtb file.dtb > file.dts" is exact? Is anything lost when this is done?
davidinux has joined #yocto
<Tartarus>
Well, dtb -> dts will not have defines and so forth, as used in a regular dts file
jatedev has joined #yocto
<ziga_>
Ah! So reverse engineering is not possible. A lot of additional work would probably have to be done on an resulting .dts file to make it really work.
<ziga_>
What about the phandles which use labels? I can't see any labels in a resulting .dts file. They are lost it seems.
<Tartarus>
Well, not lost
<Tartarus>
but compiled
<ziga_>
Yes.
<Tartarus>
the dtb -> dts will work still and should be compilable back to a dtb, but it's not something nice to work with
<Tartarus>
the kernel or u-boot or whatever works on the dtb afterall :)
<ziga_>
I compiled it back and got the same file but it does not work for some reason.
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<ziga_>
Weird... I did .dtb -> .dts and then used the .dts to patch my kernel. After this kernel was compiled by Yocto and along the way Yocto also compiled .dts -> .dtb sucessfully. The resulting .dtb has exactly the same size as the original .dtb file. But it does not work. :)
<ziga_>
Any ideas?
rber|res has quit [Remote host closed the connection]
rber|res has joined #yocto
<Tartarus>
dump and diff them both?
<Tartarus>
fdtdump that is
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prabhakarlad has quit [Quit: Client closed]
florian_kc has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
rber|res has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
rber|res has joined #yocto
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
RobertBerger has joined #yocto
rber|res has quit [Read error: Connection reset by peer]
rber__ has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
RobertBerger has quit [Ping timeout: 240 seconds]
rber__ has quit [Quit: Leaving]
jatedev has quit [Quit: Client closed]
florian_kc has joined #yocto
GNUmoon has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
jatedev has joined #yocto
mvlad has quit [Quit: Leaving]
bantu has quit [Quit: bantu]
bantu has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
ykrons has quit [Ping timeout: 256 seconds]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
codavi has quit [Ping timeout: 240 seconds]
JaMa has quit [Quit: leaving]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
leon-anavi has quit [Quit: Leaving]
Wouter0100 has quit [Read error: Connection reset by peer]