<ak77_>
now that's a strange error.... if I add empty (bash) do_compile() {} it's ok, but if I add empty "python do_compile() {}" it's fails due to indentation. no lines in body of do_compile
<ak77_>
(I already have "python do_conifgure() {...}" in recipe
<ak77_>
(do_configure)
<ak77_>
any idea?
<ak77_>
it fails "hard", it's IndentationError shows at closing bracket of empty python do_compile
<khem>
ak77_:if you do not need do_compile then does it matter if its shell or python
<ak77_>
but I need it. I do cargo_do_compile and npm_do_compile (this one is python so my do_compile has to be python)
<ak77_>
(currently removed, as the error is reproducible event without body)
<khem>
are you trying to add something to existing do_compile that comes from npm or cargo bbclasses ?
<ak77_>
I need to call both with different ${S}.
<ak77_>
nothing to add to those do_compile(s)
<ak77_>
but the error is strange. parsing of the recipe, I can't see anything wrong with the recipe itself, syntax wise. why would empy python do_compile() { \n } break indentation
<AdrianF>
Embedded devices with a TPM are becoming more and more state of the art. It would be nice to have a reference implementation for use cases like secure boot, encrypted data partition, mutually authenticated TLS connections. Qemu + swtpm would allow to add oe-selftests with reasonable effort and good coverage. Would this be something which could go
<AdrianF>
into oe-core?
Kubu_work has joined #yocto
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
mckoan|away is now known as mckoan
amitk_ has quit [Quit: Lost terminal]
<mcfrisk_>
AdrianF: the pieces to implement this are scattered between poky/oe-core, meta-openembedded, meta-security/meta-tpm and meta-secure-core, and vendor/BSP layers like meta-arm
<mcfrisk_>
we from Linaro are trying to add Arm SystemReady/UEFI secure boot to meta-arm, qemuarm64-secureboot/qemuarm-secureboot. Changes build UEFI compatible firmware and sign grub and kernel with matching keys.
<AdrianF>
Yes, I know that the pieces are scattered like this. I fear that this will result in many similar downstream implementations because there is no easy-to-use upstream implementation. That's exactly why I started this discussion.
<AdrianF>
Having 4...5 recipes in the core would allow to have runqemu with TPM support and related oe-selftest for the complete stack. This is almost impossible with 5 git repos and so many maintainers.
<mcfrisk_>
meta-security/meta-tpm also has tests
<mcfrisk_>
AdrianF: as an example, the systemd unified kernel image support needed python3-pefile to generate UEFI binaries. I asked khem and he kindly allowed the move from meta-oe to oe-core and keeps the maintainer status there. sbsign recipe for signing UEFI secure boot binaries needs similar move to layers which use it, possibly oe-core. efivar userspace utility could possibly be avoided if plain kernel sysfs
<mcfrisk_>
interface is used.
tnovotny has joined #yocto
<AdrianF>
Yes, but the tests from meta-security are based on 5 git repos. Probably one person on earth knows how this setup can be reproduced.
<mcfrisk_>
I think meta-security/meta-tpm need oeqa selftest to setup the build and test for a qemu machine. that requires swtpm, preferably native with also firmware side support
fray has quit [Ping timeout: 252 seconds]
fray has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
vthor has quit [Ping timeout: 252 seconds]
vthor_ has joined #yocto
<AdrianF>
Yes, the parts are available. But the beauty of a TPM is the standardization that comes with it. But this advantage is lost when many fragmented half solutions become the standard.
crazy_imp has quit [Ping timeout: 252 seconds]
crazy_imp has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
vthor_ has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
florian_kc has joined #yocto
ablu has quit [Ping timeout: 244 seconds]
ablu has joined #yocto
leon-anavi has joined #yocto
rber|res has joined #yocto
<rber|res>
Did somebody notice wrong (not root) user:group with core-image-sato-sdk-<whatever>.rootfs.tar.bz2?
<ak77>
I used devtool add <localdirectory with app, that is a subdirectory in a git repo>
<ak77>
package.json was detected, but it failed to produce .bb but left bb.parsefailed (or something similar)
<ak77>
(OTOH I read some discussions - but still don't understand why npm can't it be handled like rust -crates.inc)
<ak77>
landgraf: as RP says, it's not in filename it's in package name
<RP>
ak77: we've been hoping someone may update the npm code to be more like the crates handling
<ak77>
maybe I'll tackle this (in next weeks). together with 1) wrong presumption that nodejs is needed on target if need to build js 2) no way to do "npm run build" 3) deploy only dist of build process to target
MrTatillon has joined #yocto
<MrTatillon>
hi
<MrTatillon>
Hello, I'm looking for help to my build
<MrTatillon>
I'm trying to build an image from the Scarthgap base on Opensuse15.4
<MrTatillon>
Apparently, I have an error with `shared-mime-info_2.4.bb:do_compile`
<MrTatillon>
---
<MrTatillon>
Log data follows:
<MrTatillon>
| DEBUG: Executing shell function do_compile
<jonmason>
It's worth saying that reddit a cesspool and should be avoided
<RP>
jonmason: definitely worth saying :)
MrTatillon has quit [Ping timeout: 256 seconds]
CrazyGecko has quit [Quit: Konversation terminated!]
ablu has quit [Ping timeout: 245 seconds]
druppy has joined #yocto
ablu has joined #yocto
ablu has quit [Ping timeout: 265 seconds]
ablu has joined #yocto
mckoan is now known as mckoan|away
ablu has quit [Ping timeout: 276 seconds]
druppy has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
norvil has joined #yocto
Ad0 has quit [Ping timeout: 245 seconds]
<khem>
rburton: I dont think the problem is more c++ hdrs from libstdc++, problem seems to me the version of GCC on that host gcc 7.5 since it did not support c++17 fully,
<rburton>
ouch
<rburton>
buildtools!
<khem>
perhaps better to use buildtools yep
<khem>
or patch the source to use #include <experimental/filesystem> instead
<khem>
do we have opensuse 15.4 on AB workers ?
steelswords94 has quit [Read error: Connection reset by peer]
Ad0 has joined #yocto
<khem>
we have 15.5 which is also using gcc 7.5, I wonder if we use buildtools on it
steelswords94 has joined #yocto
<khem>
OpenSuSE wins the medal for oldest gcc on new AB :)
<khem>
title that usually centos would hold in past
<RP>
khem: we do use buildtools on it
<RP>
15.6 still needs buildtools too
<khem>
15.6 should have newer gcc no ?
<RP>
khem: gcc and python still too old
<khem>
yeah 7.5 seems to be golden gcc for gcc
<khem>
for suse
<khem>
python 3.6 hmm
<norvil>
Hi, does anyone has any suggestions on how to make work libgpiod? i added IMAGE_INSTALL:append = " libgpiod libgpiod-dev libgpiod-tools"
<norvil>
at my local.conf but it doesn't work
<khem>
usually -dev packages are not needed unless you are looking to develop on device
<khem>
just adding libgpiod-tools would have been enough to pull libgpiod3 package as well.
<khem>
I would suggest to try just using IMAGE_INSTALL:append = " libgpiod-tools"
<norvil>
okok I'll try it, because i've tried different libgpiod versions for a beagleboard-x15 and i can't even make a led turn on
<norvil>
thank you!!
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
sukbeom has quit [Quit: Ping timeout (120 seconds)]
sukbeom has joined #yocto
jmd has quit [Remote host closed the connection]
florian_kc has joined #yocto
norvil has quit [Quit: Client closed]
leon-anavi has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 260 seconds]
enok has joined #yocto
florian_kc has joined #yocto
Kubu_work has quit [Quit: Leaving.]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #yocto
enok has quit [Ping timeout: 265 seconds]
prabhakalad has quit [Ping timeout: 260 seconds]
prabhakalad has joined #yocto
guest92 has joined #yocto
guest92 has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 246 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alperak has quit [Quit: Connection closed for inactivity]
<RP>
Saur: do I remember you using the cache/clear head revisions mechanism in bitbake?
<RP>
Saur: if so there are some patches on bitbake master-next removing persist_data which could do with wider testing
<Saur>
RP: Ok, so if I cherry-pick those two commits, any thing I should look out for, or it will just work as normal? What if I remove them again later?
<RP>
Saur: the data is stored in a different file so it would be like a clean TMPDIR. Beyond that it should behave the same
<Saur>
Ok
<RP>
changing to/from it would be like cleaning the cache
<RP>
Saur: thanks, I don't use these codepaths much now so wider testing is appreciate. I'd be very happy to remove persist_data and this will make things work with python 3.13 too
<Saur>
Sounds like a win-win. :)
<RP>
Saur: right, I was wondering about "fixing" it but removing seems much nicer
<Saur>
RP: Ok, I'll give it a go.
<RP>
thanks
<Saur>
RP: On a totally unrelated note, we had a weird bug yesterday in one of our builds. It ended up in a loop trying to initialize the build over and over again: https://pastebin.com/mcVEFB6b (those are only the first three iterations). I have never seen anything like it before.
<Saur>
Since there isn't anything to go on, I tried to emulate it by injecting some exceptions around that area, but then i just reports the exception as normal and aborts the build as expected.
<RP>
Saur: I've never seen that. Was there anything useful in the cookerdaemon log?
<RP>
there would probably be a traceback there of some kind
<Saur>
I wish I had that log. Unfortunately it was a job in Jenkins which did not save any artefacts when we aborted the job after 24h. :(
<RP>
I feared that may be the case
<Saur>
For now I will just act as if it never happened...
<khem>
RP: I have clang checked out using devtool and it works ok but as soon as I delete the tmp/* and no changes in sources at all, it decides to reuild it, it does not happen when building normally
<khem>
I was expecting it to come from sstate second time around
<RP>
khem: it is very unlikely a devtool built clang would match a non-devtool one
<RP>
khem: please don't put diff's in the commit message, git am hates that