Closed tewarid closed 3 years ago
Suppressing alone won't work. We would need an alternative patch management, quilt based or so.
BTW, does this have more impact than just the initial printout of OE? That alone should not be a major issue, given that the log also contains what kas did right before that.
buildhistory contains the build-id.txt file of the following kind
Build Configuration:
BB_VERSION = "1.51.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-musleabi"
MACHINE = "raspberrypi0-wifi"
DISTRO = "poky"
DISTRO_VERSION = "3.3+snapshot-4d5f053e38fd951028d5267a295f285425da4c71"
TUNE_FEATURES = "arm thumb vfp arm1176jzfs callconvention-hard"
TARGET_FPU = "hard"
meta-berry = "main:e4c9945e3f899adb61e4978a04525a2f8c78ed7d"
meta-clang = "master:eb92914e31ff872c032155997c42ca8b6e6d82a3"
meta-matter = "main:e4c9945e3f899adb61e4978a04525a2f8c78ed7d"
meta-networking
meta-oe
meta-python = "patched-master:04038652399b8e8917687367cacf2477acdafa73"
meta-raspberrypi = "master:c7f4c739a3762b9a39696898876f242b17df6f59"
meta
meta-poky
meta-yocto-bsp = "patched-master:4d5f053e38fd951028d5267a295f285425da4c71"
It is easier to parse than the log.
Understood - but be warned that, when you remove patches from the log, the shown revision of the layer will not be the built revision. That can also be highly misleading!
Understood - I think I can live with committing the precise refspecs I've built by altering kas config manually.
I mean, kas patching layers is a hot-fix method, nothing that is supposed to stick (you are supposed to upstream your changes ASAP :wink:). So the ideal build is clean, refspec and, thus, patch-wise.
OTOH, if OE could be told to not only issue refspecs but possibly also git describe outputs, kas could tag the baseline in a way that makes both the base and the modification visible. Maybe this feature can be contributed to OE-core...
Thanks - I'll close this issue for now.
Unlike repo or submodules kas allows to patch locally without a need to fork a "repo", if you can not live with the "random shas" you can still fall back to forking and simply use a fork/branch where your patches are already applied. Doing so should give you stable hashes and you might still see benefits in using kas over other similar tools.
But kas itself does know the refspec it applied patches on, and it is becoming increasingly popular in the "OE/yocto" world. So we could in the long run thing about leaving a tag for a baseline. But i am afraid that might be hard considering layering, where a patching kas-yml might be based on another patching kas-yml ... and so on.
Committing patches creates a commit hash that does not exist in the source repo. Yocto buildhistory reports that hash which results in a loss of traceability. It would be interesting if kas provided an option to suppress commit of applied patches.