<JaMa>
RP: would it be terrible ideal to backport "base/bitbake.conf: Introduce UNPACKDIR" to scarthgap and kirkstone? as it's the same value it shouldn't cause any issues right? I'm thinking about forward compatibility to teach our developers to use UNPACKDIR in e.g. do_install ahead of the upgrade to styhead+ in far future
<RP>
JaMa: I've wondered about that for scarthgap. Not sure I'd want to for kirkstone
<RP>
khem: I did warn about those, they're not stable yet
Jah has quit [Quit: Client closed]
enok has quit [Ping timeout: 268 seconds]
<JaMa>
RP: I can add the weak default only locally for kirkstone, but the switch is causing quite a few rebase conflicts, so it would be easier for me (and possibly others) to be able to update the recipes in "no-op" switch in kirkstone instead of with the whole OE upgrade later, but I understand you might not want it in kirkstone
ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
Jones42 has joined #yocto
Jones42_ has quit [Quit: Leaving]
manuel1985 has joined #yocto
xmn has joined #yocto
<manuel1985>
Hi! My shlib redacted.so makes use of a few other shlibs, but yocto only complains about one. (libz.) Why? What makes libz special? https://bpa.st/WI5Q
enok has joined #yocto
<RP>
JaMa: Making it so people might not need to think about some of these things is risky :/
mihai has joined #yocto
Kubu_work has joined #yocto
Guest22 has joined #yocto
<Guest22>
hello
<ldywicki>
hi
<Guest22>
can anyone tell me if its possible to take one partition (in between two others) and make two out of it? I've got 8 partitions und want to split the 7th into 7th and 9th (8th must stay in position). that works so far but mbr write command un my uboot script destroys my newly created 9th part in so far that it says start and end sector are far out
<Guest22>
of bounds whats physically possible (and of course its not accesible afterwards)
dgriego has quit [Ping timeout: 264 seconds]
dgriego has joined #yocto
<ldywicki>
do you do it through scripts during boot or at image level with wic?
<Guest22>
the mbr write command is in my boot.scr script
<Guest22>
if it isn't called in boot.scr a reboot does not destroy the partition...so mbr write is the culprit i guess
xmn_ has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
Jones42_ has joined #yocto
jpuhlman has quit [Ping timeout: 264 seconds]
Jones42 has quit [Ping timeout: 260 seconds]
bluelightning has quit [Quit: Connection closed for inactivity]
xmn_ has quit [Ping timeout: 268 seconds]
Martin42 has joined #yocto
zpfvo has joined #yocto
<Martin42>
Hey community, I could use an extra pair of eyes ^^ I need to add "mkfs.jffs2" to my image. The mtd-utils package successfully compiles it and places it under "image/usr/sbin" inside its work directory. However, inside my image on party of the mtd-utils package arrives, "mkfs.jffs2" is missing in my image. Any ideas?
<Martin42>
Found the issue: jffs2 is an extra PACKAGE inside mtd-utils.bb, thus I have to explicitly write: "IMAGE_INSTALL:append = " mtd-utils-jffs2"", not only mtd-utils!
<qschulz>
this returns the packages that contain a file matching that glob-path
<qschulz>
manuel1985: is your shlib prebuilt or built within yocto?
<Martin42>
Thanks qschulz (y) my mistake was to not add the split package into my image >.<
<qschulz>
manuel1985: if prebuilt, you're missing libz.so in your RDEPENDS, if built, probably some compilation issue and it's linking to a different so (e.g. so.1 instead of so.1.0 or so instead of so.1.0)
<qschulz>
Martin42: yup, but sometimes it's difficult to know which package contains which file, oe-pkgdata-util is a great thing for that
<qschulz>
(note that the package needs to have been built first, so if nothing builds the recipe generating this package, it won't appear)
<manuel1985>
qschulz: It's prebuilt. Yeah I got that, but why don't I have to add the other to RDEPENDS?
Jones42__ has joined #yocto
florian has joined #yocto
<qschulz>
manuel1985: are the other NEEDED of that shlib in DEPENDS by any chance? (i.e. are they in the sysroot of the recipe of that prebuilt shlib?)
Jones42_ has quit [Ping timeout: 260 seconds]
<manuel1985>
qschulz: No, I've got DEPENDS="" in my recipe. The shlib is an unversioned shlib that a business partner gave us. I don't know what's in it. I just need to link some gstreamer element against it.
<qschulz>
manuel1985: objdump -x on the shlib to know what it needs
<manuel1985>
Things seem to work now that I added RDEPENDS:${PN} = "zlib", but I'm just wondering why this is the only one I had to add
<manuel1985>
did readelf -d /path/to/shlib | fgrep NEEDED and it listed all the ones that are listed here: https://bpa.st/WI5Q
<qschulz>
manuel1985: BTW, please really follow how to package prebuilt binaries, we have instructions on those
<qschulz>
e.g., it should probably not make it to redacted-dev package I assume
<qschulz>
manuel1985: I assume all other packages are always part of the sysroot, because well... which recipes wouldn't need the glibc?
<qschulz>
though not sure about the c++ stdlib :/
<manuel1985>
qschulz: "BTW, please really follow how to package prebuilt binaries" I do? What tells you I don't?
<qschulz>
redacted-dev complaining about missing shlibs?
<qschulz>
redacted-dev should have an .so, but it should be a symlink, so those warnings/debug messages shouldn't exist
<qschulz>
manuel1985: also, is this a pre-kirkstone Yocto? if not, we missed updating the error message to the new override syntax
<manuel1985>
"redacted-dev should have an .so, but it should be a symlink, so those warnings/debug messages shouldn't exist" ah I see. Didn't know they are caused by that. In the meantime I changed the recipe to follow the guide on unversioned shlibs, but I didn't check how that affects this log messages.
<qschulz>
manuel1985: probably changed to redacted instead of redacted-dev now :)
<manuel1985>
Need to check!
linfax has joined #yocto
<manuel1985>
btw Yocto is complaining about some installed files not being packaged, that /are/ listed in FILES:${PN}. Does that ring a bell? I'm a bit puzzled. I checked the workdir/temp and AFAIR they don't make it into packages-split.
<qschulz>
manuel1985: the error message seems to indicate you're using a pre-new-override Yocto
<qschulz>
so this would need to be FILES_${PN}
<manuel1985>
Hmmm it's dunfell so already supports the new override syntax :/
<qschulz>
manuel1985: not necessarily, the new override syntax was added in the middle of Dunfell dot releases
<qschulz>
manuel1985: I think Dunfell is now EoL BTW ;)
<qschulz>
manuel1985: you can check with bitbake-getvar/bitbake -e that your FILES:${PN} is proper
<qschulz>
can we have the content of the do_install and FILES: variables as well?
<manuel1985>
I see plenty of the new override syntax in our codebase and there were commits changing all recipes from the old to the new, so I assume this isn't it :/
<qschulz>
manuel1985: to be fair, **some** layer maintainers use GitLab/GitHub and sometimes both and sometimes both + ML, but the "core" ones (OE-core, bitbake, poky and the docs) are all ML based
<qschulz>
ML = mailing list
<manuel1985>
Can't guarantee I'll find the motivation to do that. :/ Was reading a tutorial on sending patches via ML once thought "wtf"
<Jookia>
b4 makes patch-based workflows a bit more tolerable
<qschulz>
Jookia: yes, but yocto is missing things that hooks up well into b4 for now, e.g. b4 prep --auto-to-cc, the upcoming b4 prep --check
<qschulz>
Jookia: we do have a maintainers.conf so we could somehow figure out who to notify, but we'd need to do a parse of a world build for each commit to detect which recipes are changed and notifiy their maintainers... the issue being.. what happens when you do a minimal change in one of the core bbclasses?
<qschulz>
Jookia: also, which machine(s) to use for world build parsing?
<Jookia>
oof
<qschulz>
(we could start with the mailing list to use though, before going overkill :) )
<Jookia>
the barrier to sending patches can be pretty high for projects like this
<qschulz>
"projects like this"?
<RP>
Jookia: we've had a lot of discussion on the mailing lists vs github situation. It isn't an easy answer as the mailing lists do have benefits even if occasional contributors find them hard and more unusual these days :/
<Jookia>
qschulz: low level projects seem to like mailing lists, like linux/u-boot/barebox/buildroot/yocto
<RP>
Jookia: they better enable wider peer review rather than relying on single maintainers to make a decision
<Jookia>
yeah, i can see that
<Jookia>
b4 made working in the kernel/u-boot a lot better because it puts your patch on a single branch and handles sending things off
<Jookia>
i always manage to mess up sending things
<qschulz>
Jookia: b4 really helped me manage different versions of the same patchset, that's something I really like about it. But there were other tools before as well, git-series IIRC?
<qschulz>
but github isn't going to help with how you manage your git history locally anyway
Martin42 has quit [Quit: Client closed]
<Jookia>
possibly, i can manage different versions but it's more the keeping track of cover letters, versions, to/cc, and sending things off. there's a lot of stuff that i'm bad at
<qschulz>
true, though we use GitLab (and Gerrit) at work, nobody writes a cover letter, they take the automatically generated one from the first commit, and never update it
<qschulz>
there's always some discipline you need to have, some habits to build with different tools
<qschulz>
and people usually don't like changing stuff they work with, even if they don't like the current situation
<qschulz>
it goes both ways, maintainers not improving their workflows because they don't have time, energy, willingness to do it (why change something that has worked (maybe not optimally) in the last decades?)
<qschulz>
and it always costs in the short term, so it's difficult to want to experiment
<qschulz>
especially since we don't know if it's actually going to improve anything
<qschulz>
(from maintainer PoV)
<qschulz>
(I'm no maintainer, only at my company for BSP/embedded components)
<Jookia>
i think i'd be more okay with it if mistakes were tolerated a bit better
<Jookia>
people tend to get cranky if you make mistakes
<RP>
Jookia: we do try not to get too cranky. That usually only happens if you make them time and time again
<Jookia>
my first patch to the linux kernel had someone get insulted that i didn't cc them :(
<RP>
Jookia: we're not the linux kernel and try to do some things differently
* RP
disagrees with some of the things the kernel did/does and tried to model them differently for us
<RP>
this is one of the reasons I really don't want a maintainers file like the kernel
<Jookia>
is there just one mailing list to send things to?
<qschulz>
Jookia: no, we have multiple ones, but they are documented in the README of each git repo
<qschulz>
Jookia: to be clear, (I think) we only have one mailing list per git repo
<qschulz>
(well, for patches, you can ask questions on other ones if you want for example)
<qschulz>
Jookia: the only exception is poky git repo, because it merges yocto-docs, bitbake, oe-core into one git repo. But poky is a special case in many aspects :/ for the rest, one ML per git repo if I remember correctly
<qschulz>
RP: I'm interested to know what are the complaints about this MAINTAINERS file if you have time one day (or did you write about this publicly already?).
<RP>
qschulz: There was a lot of discussion a few years ago and it will be in the mailing list archives somewhere.
<RP>
qschulz: once you have such a file it changes the dyanmics of our maintainership a lot and people don't really appreciate the impact of it. For example, people can "demand" they be copied on patches, then "demand" to reject changes, or ask things are reverted if they're not copied
<RP>
qschulz: I really don't want to get into such arguments
<RP>
I'd also note that we scale differently to the kernel, we have layers as a way of delegating responsibility
<qschulz>
RP: but if they cannot reject changes on pieces they maintain, are they maintainers?
<RP>
qschulz: I don't mean in that sense. I mean "I wasn't copied on this change, I missed it, it was merged, I now demand it be reverted instantly"
<qschulz>
RP: I'm used to U-Boot and the Linux kernel maintainership model, but don't have experience with others
Guest22 has quit [Quit: Client closed]
<qschulz>
RP: Ah yes, this is mainly because you're the only one merging stuff and there isn't a "hierarchical" model in Yocto/OE?
<qschulz>
so you cannot simply wait for others to ack patches otherwise patches just die in the archives and you cannot keep track of things to be merged/pinged (and it's not your job as a maintainer anyway :) )
<qschulz>
RP: so I'll make sure I put my idea of parsing world builds to generate a cc list for consumption by b4 :)
<qschulz>
somewhere deep in my brain*
<Jookia>
i've kind of taken up the workflow of using mailing lists as dumping grounds for patches
<qschulz>
Jookia: we do have patchwork (I don't use it as contributor (yet?) though) to mitigate some of this I believe
<Jookia>
since then people can find and use them
<Jookia>
but i don't know how i'd deal with unwnted patches. i guess just have a github fork
<qschulz>
Jookia: welcome to the world of downstream forks :)
<Jookia>
i thought the idea was layers meant you didn't have to fork
<qschulz>
Jookia: if you need to do changes to the core of OE/bitbake... there are sometimes no ways around it
<Jookia>
yeah
<qschulz>
if you don't want to spend the time contributing and making sure things are merged
<qschulz>
but then, that's your cross to bear, not ours :)
<Jookia>
yeah
<RP>
Jookia: we do have a pretty decent track record of merging a high percentage of patches
<Jookia>
i get it
<RP>
qschulz: I understand why people like the maintainers file idea, I just don't think it would do what people think
<qschulz>
RP: fair enough :) still want to do something so b4 prep --auto-to-cc adds the mailing list automatically so ones doesn't have to look it up :)
<qschulz>
s/ones/one
<RP>
qschulz: I do think that sounds reasonable
ehussain has quit [Quit: ehussain]
<RP>
as long as we don't end up with a maintainers file by stealth
* qschulz
removes his ninja clothes
Jookia has left #yocto [#yocto]
florian has quit [Ping timeout: 240 seconds]
mckoan|away has quit [Read error: Connection reset by peer]
enok has quit [Ping timeout: 268 seconds]
florian__ has quit [Ping timeout: 240 seconds]
Guest13 has quit [Quit: Client closed]
Saur_Home39 has joined #yocto
florian__ has joined #yocto
Saur_Home has quit [Ping timeout: 250 seconds]
vthor has quit [Remote host closed the connection]
enok has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
MrCryo has joined #yocto
<mbulut>
gm gents, i have some weirdness to resolve here.... full image build (with build directory deleted before) runs ok. but followed by another run without clearing the build dir gives me "This recipe does not have the LICENSE field set (linux-yocto-tiny)"
<mbulut>
second run fails in parsing recipes step, so you could replace the second one with anything
<mbulut>
e.g. bitbake image-sth ; devtool modify recipe-sth
<mbulut>
I think there's sth seriously broken in the project setup and i'm checking everything one by one but would appreciate any wisdom how to get to the bottom of this
alessioigor has joined #yocto
enok has quit [Ping timeout: 260 seconds]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
CaptainQuirk is now known as Piraty
enok has joined #yocto
Ad0 has quit [Ping timeout: 260 seconds]
Vonter_ has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
Saur_Home39 has quit [Quit: Client closed]
Saur_Home39 has joined #yocto
enok has quit [Remote host closed the connection]
enok71 has joined #yocto
dkc has quit [Remote host closed the connection]
enok71 is now known as enok
lexano has joined #yocto
Ad0 has joined #yocto
tgamblin has quit [Remote host closed the connection]
dkc has joined #yocto
yocton has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
rob_w has quit [Remote host closed the connection]
tgamblin has joined #yocto
Jones42__ has quit [Quit: Leaving]
Jones42__ has joined #yocto
manuel1985 has quit [Quit: Leaving]
Jones42__ has quit [Client Quit]
Jones42__ has joined #yocto
mvlad has joined #yocto
Jones42__ has quit [Client Quit]
Jones42 has joined #yocto
Jones42_ has joined #yocto
Jones42_ has quit [Client Quit]
<Jones42>
What's the most elegant or generic way to move the fitimage pubkey.dtb to the u-boot build directory so it can be picked up and integrated into u-boot there?
florian_kc has quit [Quit: Ex-Chat]
<qschulz>
Jones42: do_deploy in the recipe generating the pubkey.dtb, then in u-boot, do_compile[depends] += "otherrecipe:do_deploy"
MrCryo has quit [Quit: MrCryo]
<qschulz>
and you get the file from the deploy directory (there are three very close variable names, pick the correct one, I don't remember which one it is :) )
florian__ has quit [Ping timeout: 260 seconds]
MrCryo has joined #yocto
<rburton>
kanavin: does your bitbake-setup patch work against scarthgap with no other patches?
<kanavin>
rburton, yes
<rburton>
thanks
<kanavin>
not the initial release though
<kanavin>
tip of scarthgap
<Jones42>
qschulz: thanks!
<rburton>
kanavin: presumably 5.0.1 is good
MrCryo has quit [Quit: MrCryo]
<kanavin>
rburton, yes
MrCryo has joined #yocto
xmn has joined #yocto
vthor has quit [Ping timeout: 260 seconds]
enok has quit [Ping timeout: 268 seconds]
michael_e has joined #yocto
mbulut has quit [Ping timeout: 252 seconds]
Net147_ is now known as Net147
Net147 has joined #yocto
Net147 has quit [Changing host]
jpuhlman has joined #yocto
<qschulz>
RP: I have sent a basic config file for b4 for bitbake and the yocto-docs
<RP>
qschulz: cool, thanks. I was just wondering whether we should even have something in the different dirs in poky
<qschulz>
I have not sent one for OE-Core nor poky on purpose, because I think we need to play with symlinks for the .b4-config file to store the proper ML to point to depending on which repo we're in
<qschulz>
à-la README?
<qschulz>
though I don't know how this is handled :/
<RP>
this should probably be another bug to look into
<RP>
qschulz: can we not just put those files in the right subdirs for poky?
florian__ has joined #yocto
<qschulz>
RP: you would have to run b4 from that subdir then instead of the root directory
<qschulz>
RP: AND, there's a sneaky option that can only work at the moment you create the series locally (send-prefixes).. so you'd have to run the b4 binary from that directory to have it properly set
<RP>
qschulz: ah, ok, I assumed it recursed
<qschulz>
BUT I don't think we need this prefix for poky?
<qschulz>
(the --subject-prefix equivalent of git-format-patch)
<qschulz>
RP: what kind of recursion were you thinking about? .b4-config in root but calling b4 from bitbake/ or .b4-config in bitbake/ and calling b4 from root but it takes .b4-config from bitbake/ as well?
<qschulz>
not sure what you meant, sorry
<qschulz>
Konstantin (maintainer of b4 and LF sysadmin) is usually pretty open about feature requests so we could always suggest something :)
<RP>
qschulz: if b4-config wasn't at the top level, it would look in the subdirs and use from there if present. That would let us handle patches for different bits of poky, at least in theory but probably tricky in some ways as you could have a patch spanning multiple dirs (just make it an error?)
<qschulz>
RP: but if i have a .b4-config in bitbake/, in bitbake/doc (for +docs@lists.yp.org), in meta/, in meta-poky/... which one is it going to take? is it going to merge all?
<RP>
qschulz: not sure :)
<RP>
qschulz: depends where the patches are from? :)
<qschulz>
RP: ah, do you want a MAINTAINERS file :D ?
<qschulz>
mmmmm but I now understand your comment about a patch spanning multiple repos
<qschulz>
in our case.... I think we should prevent any patch from sending (thinking about poky)
<qschulz>
because bitbake/ docs/ and all oe-core directories are in different git repos so should be going individually through those
<rburton>
RP: i'm _sure_ i've seen builds rebuild overnight when nothing else changes but its not constant and assumed it was just me. My hunch at the time was distro release changing.
vthor has quit [Remote host closed the connection]
vthor has joined #yocto
<RP>
rburton: A build with no change to the hashes all built from sstate. I've now rebased master-next and am trying again
<RP>
rburton: evidence from my test builds is pretty strong :/
alessioigor has quit [Ping timeout: 250 seconds]
enok has joined #yocto
<RP>
I've never rebased a series so many times with so many conflicts as these runqueue changes
<RP>
rburton: systemd depending on os-release
<rburton>
RP: which has the version in. that would be it.
<RP>
rburton: testing a patch
* RP
has no idea why people haven;t complained about that
<rburton>
RP: its definitely not on every change though. because if i switch branch so the core sha changes, it doesn't rebuild systemd every time. at least i've not noticed it...
alessioigor has joined #yocto
<RP>
rburton: I think it might
vthor has quit [Ping timeout: 260 seconds]
<rburton>
this meson/sdk thing is a PITA btw
alessioigor has quit [Client Quit]
<rburton>
the same file being used in eSDK and meta-ide is not fun
<RP>
we could split them?
<rburton>
not _easily_, they're both just meson-native's sysroot
<RP>
rburton: ah :(
<RP>
JPEW: see what you make of the runqueue changes, particularly 6/6
<RP>
they seem to work now in testing
LocutusOfBorg has quit [Read error: Connection reset by peer]
LocutusOfBorg has joined #yocto
<rburton>
RP: FYI jonmason definitely said yesterday he'd fix the workdir problem in meta-arm
<jonmason>
I have a patch and I think the issue is being based on scarthgap versus master
<jonmason>
Won't be able to look until Monday
<rburton>
yeah, its the new workdir changes in master, which is why our CI doesn't see it
<rburton>
(we should flip CI too, feel free to do that next week too :)
<jonmason>
I was going to ask yesterday but it was a bit of a mess travelling
Kubu_work has quit [Quit: Leaving.]
zpfvo has quit [Quit: Leaving.]
enok has quit [Ping timeout: 255 seconds]
mckoan has joined #yocto
mckoan is now known as mckoan|away
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
goliath has quit [Quit: SIGSEGV]
ptsneves has joined #yocto
amitk has joined #yocto
mbulut has quit [Ping timeout: 240 seconds]
<khem>
qschulz: humanity's dilemma is that we hate change and love it at same time, what we really want is for things to remain same but get better
amitk has quit [Ping timeout: 260 seconds]
ptsneves has quit [Ping timeout: 256 seconds]
dankm has quit [Remote host closed the connection]
<qschulz>
khem: I second that. change is scary
<qschulz>
michaelo: please hold off my b4 patch for the yocto-docs, I messed up the mailing list mail address in it /me facepalms (got a case of "been a long time i haven't sent patches, how about sending many patches to many different projects the same day? things obviously go wrong then :) )
dankm has joined #yocto
vthor has quit [Ping timeout: 260 seconds]
<JaMa>
"things to remain same but get better" <- nice, I want that too
Jones42_ has joined #yocto
imx has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
<imx>
What is the best way to install a specific version of python? I found already this “PREFERRED_VERSION_python3 = "3.9.13"” but when I try to build I got the message: “
<imx>
WARNING: preferred version 3.9.13 of python3 not available (for item python3-statistics)
<imx>
WARNING: versions of python3 available: 3.10.13”
Jones42 has quit [Ping timeout: 256 seconds]
<Jones42_>
imx: I'm still pretty new myself, but you should have the matching recipe somewhere for that to work
<Jones42_>
imx: something like recipes-devtools/python/python3_3.9.13.bb in some layer (oe-core?)
<Jones42_>
imx: (at least that's my guess... I'll let Cunningham's Law do the rest)
<JaMa>
yes, you would need to revert the upgrades to roll back to 3.9.13 (if this exact version was used in oe-core before) or just provide the recipe in your own layer and it will be automatically picked if your layer has higher priority, but please think before the downgrade, do you really need older version?
Jones42__ has joined #yocto
Jones42_ has quit [Read error: Connection reset by peer]
imx has quit [Ping timeout: 250 seconds]
nwhitlock has joined #yocto
<nwhitlock>
hi. I'm trying to make a Yocto layer and I'm running into this problem with a recipe in my layer.
<nwhitlock>
I'm basically structuring my layer to have a recipe, and the code for that recipe (it's a kernel module) to exist as a submodule within the recipe folder
<nwhitlock>
I'm doing this:
<nwhitlock>
SUMMARY = "My Linux Driver"
<nwhitlock>
DESCRIPTION = "My Linux Driver"
<nwhitlock>
LICENSE = "MIT"
<nwhitlock>
SRC_URI = "file://files"
<nwhitlock>
#S = "${WORKDIR}/git"
<nwhitlock>
inherit allarch
<nwhitlock>
do_compile() {
<nwhitlock>
# make
<nwhitlock>
}
<nwhitlock>
do_install() {
<nwhitlock>
install
<nwhitlock>
}
<nwhitlock>
BBCLASSEXTEND = "native"
<nwhitlock>
It's throwing this error: "ERROR: /home/test/yocto/poky/meta-mylayer/recipes-driver/mydriver/mydriver_0.1.bb: Unable to get checksum for mydriver-native SRC_URI entry files: file could not be found"
<JaMa>
did you add "files" file there?
<JaMa>
it needs to be in FILESPATH, see bitbake-getvar FILESPATH -r mydriver
<nwhitlock>
It's a directory
<nwhitlock>
I cloned my repo as a submodule under the directory called "files" within the "mydriver" directory.
<nwhitlock>
It's just a simple makefile and some source code.
<Saur>
nwhitlock: Why use submodule? Why not let the fetcher fetch the repository?
enok has joined #yocto
Jah has joined #yocto
Jah has quit [Client Quit]
<marex>
more like, why not list the files in SRC_URI as file://file.c file://Makefile ... and that's probably all for kernel module
<marex>
also see poky.git ./meta-skeleton/recipes-kernel/hello-mod