**** BEGIN LOGGING AT Tue Jan 14 03:00:09 2020 Jan 14 06:49:41 New news from stackoverflow: How to enter in root on sama5d27-som1-ek board Jan 14 07:34:01 angelo__: no, its the other way round. sumo is old, u-boot is new. so you you either need to roll back to an old u-boot, or forward to a new yocto release. Jan 14 07:53:27 LetoThe2nd, thanks Jan 14 08:17:28 how do I say to "devtool add" from what branch it should fetch? Jan 14 08:18:05 stuom1: devtool add --help :) Jan 14 08:18:10 I'm trying "--srcbranch" but it still complaind that unable to resolve master Jan 14 08:18:30 i dont have master branch and i dont want to fetch from master Jan 14 08:19:09 well if master doesn't even exist, that might be a problem then. Jan 14 08:19:23 why master has to exist? Jan 14 08:19:56 New news from stackoverflow: Yocto Linux for Banan Pi? Jan 14 08:20:55 My "master" branch is called develop, and "--scrbranch develop" says " Fetcher failure: Unable to resolve 'master' in upstream git repository" Jan 14 08:20:59 stuom1: its possible that the devtool code takes this as canonical state of a repo. if --srcbranch doesnt work for you, then you're probably either up to manual creation of the recipe or digging devtool source. Jan 14 08:21:10 or reporting a bug, or trying with recipetool Jan 14 08:22:40 if I would have branch called master, would it then fetch from correct srcbranch, or quietly fetch from master in that case? Jan 14 08:23:19 it would probably fetch master and then checkout. Jan 14 08:23:31 but thats guessing, please check the sources if you need to know for sure. Jan 14 08:29:44 using srcrev instead works luckily Jan 14 08:30:18 stuom1: care to file a bug report, anyways? the worst thing that cna happen is a "won't fix because wroks like intented, reason is XYZ" Jan 14 08:31:12 i can look into it, if it doesnt take a workday to learn how to do it ;) Jan 14 08:32:03 stuom1: https://bugzilla.yoctoproject.org/enter_bug.cgi Jan 14 08:33:11 thanks, now where did i put by bugzilla credentials... Jan 14 08:37:41 bluelightning: hello :) Asking you since you are one of the committers of meta/lib/oe/patch.py :) Jan 14 08:37:52 is patchdir *officially* supported for applying patches on top of files coming from FILEPATH? (e.g. meta-a/recipes-a/a/files/myfile and a patch meta-b/recipes-a/a/files/patch-for-myfile.patch) Jan 14 08:38:35 more specifically, what I'm describing is supported but breaks devtool modify because the relative path to the files is then incorrect when running extract_files to prepare the workspace. I could try to dig into that but if we already know it's not gonna make it upstream, i'd rather not waste time :) Jan 14 08:47:11 RP: sato-sdk/mips issue is due to prelink, if we disable prelinking it works Jan 14 08:57:26 khem: that sounds like fun to debug, good to nannow it down though! Jan 14 09:27:29 just updated "PREFERRED_VERSION_u-boot = "2016.03"" but bitbake still build the previous version. How can i refresh the version ? Jan 14 09:29:31 angelo__: did you change the u-boot recipe? Jan 14 09:29:51 angelo__: Do any of your layers have a recipe for that version of u-boot? it's a little old Jan 14 09:30:00 no, that above in in machine conf, u-boot recipe was always there Jan 14 09:30:12 yes i have Jan 14 09:30:42 You might need to use "2016.03%" if there is anything appended to that version string in the recipe Jan 14 09:30:56 mm ihave -rw-rw-r-- 1 ge ge 264 Jan 14 09:16 u-boot_2016.03.bb Jan 14 09:31:19 angelo__: bitbake-layers show-recipes u-boot? Jan 14 09:31:37 you'll see if your recipe is parsed by bitbake and thus available to you Jan 14 09:32:11 qschulz, thanks Jan 14 09:32:16 i see Jan 14 09:32:42 u-boot: Jan 14 09:32:42 meta 1:2018.07 Jan 14 09:32:42 meta-xxx-layer v2016.03+gitAUTOINC+df61a74e68 Jan 14 09:33:52 angelo__: PREFERRED_VERSION needs to match what's in PV in the recipe, in this case I'd guess to use "v2016.03%" Jan 14 09:35:12 paulbarker qschulz RP, thanks, it works now Jan 14 09:37:50 LetoThe2nd I think I found the bug in recipetool, I tried fix locally and it works. Is it easier to make a pull request somewhere or file a bug and write my findings there? Jan 14 09:38:40 stuom1: if you've already got a fix, then then best way is to send a patch to the ML Jan 14 09:45:57 BTW, I was thinking, a good tool we could add to bitbake-layers or something would be something that parses SRC_URI and FILEPATHS and tells you which files in which paths could be a match and which one is used for that particular line in SRC_URI, making it way easier to help people debug weird defconfigs or so Jan 14 09:46:46 the use-case is bbappends with same files but different layer priorities Jan 14 09:46:57 and/or OVERRIDES in paths Jan 14 09:47:11 (and the order in FILEPATHS) Jan 14 09:47:38 (i.e. PN-PV, then PN, then files) Jan 14 10:56:49 LetoThe2nd I did my best to send a patch, let's see how it went, heh Jan 14 10:57:08 for interactive dev/debug, when many changes are taking place (recipes, local patches, remote repos), it is sometimes necessary to issue "-c cleanall" for one or more recipes. Question 1: can cleanall+build be combined in a single bitbake invocation? Question 2: could bitbake theoretically be modified (may not be suitable for upstream) to retry failed tasks with cleanall? Jan 14 10:57:12 stuom1: thanks! Jan 14 10:59:07 stacktrust: 0) thou shalt use clean, not cleanall. 1) not my knowledge 2) anything is possible, its only software. but you're probably better off just using some wrapper then (also applies to 1) Jan 14 11:00:52 I also use cleanall when I want to clean something, is it bad? Jan 14 11:02:10 stuom1: the question is, what makes you use -c clean/cleanall/cleansstate? If it's just for cleaning purposes, then I'd say fine. But if it is because it's not behaving as it should or there is an error. NOT fine, you're "fixing" the consequence, not the cause. All of that = IMO Jan 14 11:03:22 it was explained lately why clean, not cleanall (by RP). it made sense, i just totally forgot again. Jan 14 11:03:32 anybody please dig up the logs, or poke him again :P Jan 14 11:05:37 LetoThe2nd: thanks :) Wrapper works for target that has a few dependencies. For a target with a large number of tasks, it would be too slow (hours) to rebuild after clean/all, hence it would be good if bb can internally re-queue the small subset of tasks which are failing (e.g. recipe edits have invalidated existing sysroots, causing FileExistsError for copy to sysroot-providers). Jan 14 11:08:31 LetoThe2nd: `cleanall` throws away downloads, sstate and the work dir. `clean` only throws away the work dir Jan 14 11:08:58 Earlier in the logs it was mentioned that bb is only aware of recipe edits, not source changes. It was also mentioned that PN/PV increments are the accepted way to force a rebuild. What do you do when PN/PV are already used by a recipe (e.g. dbus) and not suitable for modification in a bbappend? In that scenario, -c clean or -c force_rebuild (with warning message about tainted do_compile) can help. Jan 14 11:11:44 Speaking as a relatively new user of bb, the learning curve is so steep, and clean fixes so many indecipherable error messages, that -c clean is much closer to the default way of using bb. Jan 14 11:18:49 The other issue with a wrapper is that each invocation of the wrapper loses time to reparse recipes. Memory-resident bitbake is good if recipes are not changing, e.g. only making changes to source code. Jan 14 11:20:39 stacktrust: That doesn't sound like my experience with bitbake. Jan 14 11:21:19 What do you mean by "source changes"? Are you using the externalsrc bbclass or `SRCREV = "${AUTOREV}"`? Jan 14 11:21:39 mostly autorev. Jan 14 11:21:40 Or are you placing source files in your layer and using `file://` URLs? Jan 14 11:22:05 autorev should pick up new commits to a recipe without you needing to mess with PN/PV Jan 14 11:22:20 If it isn't doing then that's a bug not a feature Jan 14 11:24:38 `-c cleanall` should only be needed if there's something wrong with your downloads directory, `-c cleansstate` only if there's an issue in sstate (which is almost always a bug to report upstream as sstate shouldn't ever be reused incorrectly), `-c clean` when you just need to re-build a recipe from scratch Jan 14 11:24:38 there are some patches in the layer with file:// URLs Jan 14 11:25:17 patches in the layer and a few small source files are fine. Changes to these should be detected by bitbake and it will re-run the tasks from do_unpack for that recipe Jan 14 11:26:15 Running into a devshell gives me this error: bash: /dev/fd/62: No such file or directory (which is the probable cause for subsequent problems). What could cause this? Jan 14 11:30:04 paulbarker: -c clean also needed when sysroot changes are caused by recipe edit, e.g. separating one package into two packages (e.g decoupling header file from library builds). Before: 60 packages depended on P1. After: 30 packages depend on P1a. The other 30 depend on P1b (which depends on P1a). Jan 14 11:32:32 That shouldn't be needed, the dependency graph should rebuild the appropriate recipes. Which version of bitbake and the core layers are you using? Jan 14 11:32:46 pyro Jan 14 11:33:35 (migration to zeus in progress) Jan 14 11:34:01 pyro shouldn't be too bad. Jan 14 11:34:23 When you say you split P1 into P1a & P1b, are they separate recipes? Or packages in the same recipe? Jan 14 11:35:45 Separate recipes. Packages in the same recipe would have a common dependency on P2, which we want to break by separating P1 into P1a/P1b. Jan 14 11:36:14 After the split, only P1b depends on P2. Jan 14 11:36:59 So then did you change DEPENDS in the 60 other recipes you mentioned? Jan 14 11:37:13 is it a bad idea to copy a recipe from newer branch of meta-oe than I use? I cannot update the whole meta-oe and I'm stuck with a very old nodejs :| Jan 14 11:37:56 feel free to backport it Jan 14 11:38:03 just be aware that some things might need changing Jan 14 11:38:50 RP: so a-full does meta-intel builds now right Jan 14 11:38:50 * Crofton|road New Year resolution is to reduce the amount of work he does for old versions :) Jan 14 11:41:26 paulbarker: it was more like 30 packages depended on P3, which depended on P1. After the split, DEPENDS on P3 was changed to P1a. The other 30 packages remain dependent on P1==P1b. Jan 14 11:41:42 rburton: was this dropped intentionally based on your review comment? It seems still needed http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html Jan 14 11:42:08 JaMa: right, i was expecting a reply Jan 14 11:42:38 stacktrust: Dependency resolution in bitbake should figure out what to rebuild in that case, P3 will be rebuilt as DEPENDS changed then everything which DEPENDS on P3 will be rebuilt. If that's not happening it's a bug worth reporting Jan 14 11:42:46 I wanted to bump that thread, but no longer have it in the maildir Jan 14 11:45:23 Ok, should be easy (albeit slow) to repro. Will do that after the refactoring is done. With OpenXT moving to zeus, our bug reports will be more useful. Jan 14 11:45:39 Thanks for the analysis. Jan 14 11:50:53 Everything which DEPENDS on P3 *was* rebuilt, but they each failed with FileExistsError in staging_copyfile os.link(c, dest), e.g. copying from /build/tmp-glibc/sysroots-components/all/P1a/sysroot-providers/P1a -> /build/tmp-glibc/work/core2-64-oe-linux/libgknome-keyring/2.32.0-r3/recipe-sysroot/sysroot-providers/P1a Jan 14 11:51:23 (excuse typos from manual copy) Jan 14 11:55:08 Unless you're manually copying things into weird recipe sysroots that sounds like a bug. If libgnome-keyring is rebuilt as one of its dependencies changed, the recipe sysroot should be rebuilt Jan 14 12:10:01 likewise: is this a real hw build host? running which distro? Jan 14 12:35:12 Hi. I added the line * USERADD_PARAM_pn-systemd += "--system systemd-network" * to local.conf - and can't use root to login, why? Jan 14 12:37:04 nacknick: are you trying to replicate this? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n353 Jan 14 12:37:54 LetoThe2nd: no. It's just a local.conf someone passed to me and I don't know how to login Jan 14 12:38:24 nacknick: then what the line there for anyways? if you can't tell, get rid of it. Jan 14 12:38:43 I need to configure the environment as he did Jan 14 12:38:51 even if its wrong? Jan 14 12:39:00 why wrong? Jan 14 12:39:38 If there is no other choice, I will delete that line. Just wanted to make sure there is no way to login Jan 14 12:40:00 because let me rephrase your question. "i want to add this line to my local.conf. i have no idea why, just copying random stuff from somebody else. now something breaks. help me!" Jan 14 12:40:27 exactly Jan 14 12:43:11 rburton: right Jan 14 12:50:13 I have a function in my image recipe like: do_myfuntion(). Is it possible to include if-statements like in bash? Jan 14 12:50:43 I want to execute some commands if an environment variable is set Jan 14 12:51:38 blauskaerm: sure. lots of examples here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_243.2.bb#n218 Jan 14 12:51:51 blauskaerm: tasks and functions are running in a shell (I don't exactly how to turn that sentence so that might be *technically* wrong but whatever is inside should be shell valid Jan 14 12:52:00 blauskaerm: now the question is... what exactly are you trying to achieve Jan 14 12:53:29 blauskaerm: only remember the yocto chant: "recipe data is local, conf data is global". so if you want to set stuff in one recipe and use in another, then - nope, sorry. not a syntactical, but architectural problem that you have Jan 14 12:53:46 blauskaerm: environment variables get purged so you can't just do "FOO=bar bitbake recipe" Jan 14 12:53:58 rburton: was just about to add that Jan 14 12:54:20 a shell function is literally ran by /bin/sh though so any sh works Jan 14 12:54:27 while that can be hacked with EXTRAWHITE Jan 14 12:54:54 shush Jan 14 12:55:02 LetoThe2nd: SHUSH Jan 14 12:55:10 proper solution is to just use a variable in local.conf etc :) Jan 14 12:55:23 well it depends what they want to achieve Jan 14 12:55:56 qschulz: i'm proud, you're getting the spirit. Jan 14 12:56:00 rburton: BTW, this is kinda weird to have /bin/sh because if I'm correct, the result of the task could be different depending on which shell is the one used on the building machine right? Jan 14 12:56:15 qschulz: (it ALWAYS depends :) ) Jan 14 12:56:25 qschulz: docs say assume posix sh Jan 14 12:56:37 if you use bash code then yes expect breakage if you don't get bash Jan 14 12:56:41 LetoThe2nd: I was talking about the variables which shouldn't be named. But the local/global thing one day will be burnt in my brain Jan 14 12:57:39 hello guys! Little trouble with this recipe : http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/tree/recipes-common/ssh-keys/ssh-keys_0.1.bb?h=master, I have simply added this recipe to my Yocto env (branch zeus) I got this error but I don't understand what's appened (log: https://pastebin.com/pm61RXzF) any idea ? Thanks Jan 14 12:57:42 rburton: yup. not great, no checks are enforced at review time I think here. Is there any magic thing one of you uses to detect non-posix instructions? Jan 14 12:58:56 here = where I work eh Jan 14 13:00:37 qschulz: there's a tool to verify that you're not doing bashisms, scripts/verify-bashisms Jan 14 13:00:51 shfmt claims to check posix shell validity: https://github.com/mvdan/sh Jan 14 13:02:16 rburton: that's nice! thanks! Jan 14 13:12:21 LetoThe2nd qschulz rburton: Thank you all for your replies :) Jan 14 13:13:04 Im developing agenst a iMX6 board and want to controll when yocto hands over our kernel binaries to our crypto server for signing Jan 14 13:13:33 And environment variable is not required, it just something I came up with Jan 14 13:14:07 If I could pass something else to bitbake and check if that is set in my function would be much better but I have not found anything like that? Jan 14 13:14:21 blauskaerm: I'm not entirely sure you want to automate that actually. Jan 14 13:14:26 I mean from security PoV Jan 14 13:14:43 signing whatever is output by Yocto without human validation... Jan 14 13:14:47 We have two sets of boards. One for lab and one for production Jan 14 13:15:14 Production keys will be handled differently but we want to sign software for lab in yocto Jan 14 13:17:13 But regardless if it sound very dump, is it possible to pass "arbitrary" variables to bitbake what I can read in the function? Jan 14 13:17:29 blauskaerm: out of my head, maybe not ideal=> two recipes PROVIDES (that's the var name) the same "crypto-keys". One for lab, one for production. Then you pick the recipe with PREFERRED_PROVIDER_crypto-keys = "crypto-lab" in conf/local.conf for example? Jan 14 13:18:17 blauskaerm: sometimes when you want things to be controlled within a recipe from outside, what you want are different recipes, images, distros, machines or some lines in local.conf. Jan 14 13:21:37 That could work. Will discuss it with my colleague :) Jan 14 13:21:37 Jan 14 13:21:53 Thanks for your time Jan 14 13:28:14 blauskaerm: we use some post script in the image recipe here. So you could have two different images (slightly, just one line changed or something) and build the correct image (lab/prod) when needed. It depends on how complex the signing process is and how late it should happen Jan 14 13:47:29 I am involved in a single-source project, which also includes customization of several third party components. Now the sources are checked out x times. Is there a way around this and can the sources only be downloaded once? I assume that this is done via "work-shared", but I don't know how to do it. Does anyone have a manual for? Jan 14 13:48:26 silviof: I do not really understand the "includes customization of several third party components" part Jan 14 13:50:14 qschulz: We make changes in systemfiles, for example from "/etc/network/interfaces", but we do not track these changes in yocto but in another repository. Jan 14 13:53:56 onto my first receipe! Jan 14 13:53:58 is it possible to skip sysroot_strip function? Jan 14 13:54:48 hmm how would i source my sdk env from my receipe? should i just source the env file or is there a vetter way (does it do this by default?)? Jan 14 13:56:39 Yatekii: no no, Yocto passes a few variables to the build system of your software. If the build system (make, cmake, autotools, meson...) does not use the variables correctly, you patch the sources. If it does not have the variables you're interested in, you add them to passed variables (CFLAGS, EXTRA_OEMAKE, EXTRA_OECONF, etc...) Jan 14 13:59:14 qschulz: ok, thx, i'll try Jan 14 14:02:00 how hard can it be i mean xD Jan 14 14:02:22 Yatekii: good luck. Try as much as you can but if it feels too hacky or you rely a bit too much on Google, maybe ask a question or two here :) Jan 14 14:02:57 Yatekii: take this https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html. It's dangerous to go alone/ Jan 14 14:05:40 :D Jan 14 14:05:59 yeah I googled a lot butr most of it seems outdated (see conversationm yesterday) or just half-knowledge Jan 14 14:06:13 many irc channels are more like "google yourself, noob" Jan 14 14:06:14 :D Jan 14 14:06:16 so thanks :) Jan 14 14:07:04 Yatekii: well we know most YP stuff is very specific to one's case Jan 14 14:07:46 and the mega-manual being so mega is both a blessing and a curse. So much information. But... SO MUCH INFORMATION Jan 14 14:08:08 anyway, I should work some time :) Jan 14 14:08:42 have fun :) Jan 14 14:51:15 New news from stackoverflow: Raspberry Pi 4 yocto, rpi-basic-image.bb: Unable to determine endianness for architecture 'INVALID' Jan 14 14:57:01 silviof: downloads will be done once, cached in DL_DIR Jan 14 14:58:01 rburton: Ah thanks. probably the unpacking will take ages, because this is what takes time then. Can I use an already unpacked source tree then? Jan 14 14:58:25 work-shared isn't a built-in feature but rather something the kernel does itself Jan 14 14:58:38 its full of pain, you'll be best living with slow unpacks Jan 14 14:59:04 remember if you have two builds for different recipes inthe same source tree you *need* to be *sure* that they won't stamp on each other Jan 14 15:00:50 maybe some tricks like only unpacking the bits you need Jan 14 15:01:07 if eg you have a 1gb tarball but only need one directory, just unpack those bits Jan 14 15:02:06 rburton: Ah okay. Thanks you helped a lot. Jan 14 15:02:44 i'm presuming its a giant tarball as you said slow unpack Jan 14 15:19:15 RP: fix for gstreamer meson conversion on the way Jan 14 15:19:29 (just so you don't drop the patches from master-next) Jan 14 15:19:37 kanavin: thanks! :) Jan 14 15:19:55 kanavin: there is a -next build underway with your patches in Jan 14 15:21:21 RP: right :) btw, I will be employed by Daimler directly starting Feb 1st, which means changing equipment, setting up access, etc., so upstream work will be delayed until I'm settled Jan 14 15:21:35 kanavin: hooray! Jan 14 15:21:59 I will keep my build machine most likely, but making it work in Daimler environment may be tricky Jan 14 15:22:18 I will also try to convince them to buy me the 64 core threadripper :) Jan 14 15:24:02 kanavin: thanks for the headsup, I know what the disruption can be like! Jan 14 15:24:51 how to reset root password of yocto? I tried raspberry pi technique (init=/bin/sh) with no success Jan 14 15:29:35 nacknick: rebuild image, with settings accordingly: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-extrausers Jan 14 15:29:48 nacknick: or IMAGE_FEATURES += "DEBUG_TWEAKS" Jan 14 15:40:01 hi, want's the deal with nspr triggering compile of glibc on zeus. can't see the dependency.. Jan 14 15:45:09 mcfrisk: bitbake-diffsigs on glibc might be helpful? Jan 14 15:48:31 qschulz: blah, I trigger fingered rm -rf tmp... I'll remember that if this reproduces Jan 14 15:49:09 is it possible to set a more recent gcc version to build all (and i.e. u-boot ?) Jan 14 15:50:10 angelo__: you can try and copypasta in recipes from a newer release, but be ready for some pain Jan 14 15:50:26 angelo__: (roughly the same amount as outright upgrading the release) Jan 14 15:50:35 aaaargh :( Jan 14 15:51:20 theres a reason why there are releases which offer a consistent state :) Jan 14 15:55:24 YPTM: Armin in on Jan 14 15:56:47 mcfrisk: if you have your sstate-cache elsewhere it's still fine Jan 14 15:59:57 LetoThe2nd, have the following issue. I am in a sumo stuff, and cannot upgrade. If i build u-boot 2018, i get error that gcc must be > 6.0.0 (linaro-5.3 now), if i use an older 2016.03 u-boot i get the error "error: conflicting types for 'fdt64_t'" Jan 14 16:00:22 qschulz: yea, I did hit the bug again. have a bbappend for nspr which adds a test and that seems to be triggering this, and recompile of gcc-cross. diffsigs didn't know how to display this though.. Jan 14 16:00:42 angelo__: well then, either happy u-boot-patching, or happy upgrading. Jan 14 16:02:01 angelo__: hint: you can look at the u-boot logs to try and identify the commit that fixes your problem, then backport it. Jan 14 16:02:35 LetoThe2nd, well, will try. Thanks for now, i'll stay happy btw :) Jan 14 16:03:35 mcfrisk: interesting, it usually at least gives you one task which is the trigger Jan 14 16:05:58 JPEW: what are the requirements pyrex has for the docker image? if i wanted to change the base image, what would i have to add to it to be able to use pyrex with it? Is everything in the dockerfile mandatory, or is there a specific list of requirements? Jan 14 16:06:32 yptm: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit Jan 14 16:08:11 hmm I am trying to use the receipe in this example: https://github.com/rust-embedded/meta-rust-bin Jan 14 16:09:18 JPEW: another quick question, when using non-standard oe setup scripts, can we manually set things lke BITBAKEDIR before sourcing pyrex-init-build-env? Jan 14 16:14:51 Yatekii: "and then...ยง Jan 14 16:15:10 ? Jan 14 16:15:36 Yatekii: "i am trying to use this recipe". well if you got no further questions or remarks? Jan 14 16:17:49 well it says it cannot copy the license etc Jan 14 16:18:31 and when I ignore it it complains about a missing manifest Jan 14 16:18:36 and when I check the git dir it is empty Jan 14 16:18:46 so I wonder how I get a populated git dir Jan 14 16:20:27 the git dir? Jan 14 16:20:36 manifest path `/home/yatekii/repos/ecarup/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/1.0-r0/git/Cargo.toml` does not exist Jan 14 16:20:42 the Cargo.toml is missing Jan 14 16:20:57 but the dir it is supposed to be in is the git dir the receipe should clone from Jan 14 16:21:12 (the one in the readme) Jan 14 16:22:47 so you have a recipe that is called "raichu-core_git.bb, but which should build the gpio-utils? or what? Jan 14 16:23:09 I have a receipe that is called raichu_core.bb Jan 14 16:23:23 raichu-core.bb Jan 14 16:23:32 yes it builds the gpio-utils Jan 14 16:23:33 see, thats the problem. Jan 14 16:23:51 hmm? Jan 14 16:24:22 ${PN} and ${PV} are derived from your recipe name, unless tated otherwise. with that name, PV is unset, therefore the checkout braks. Jan 14 16:24:52 suggestion: raichu-core_0.3.0.bb :) Jan 14 16:25:34 ohhh thank you :) Jan 14 16:26:06 hmm what do I have to do so it now checks out? Jan 14 16:26:21 it's still empty (I added the tag and the PV variable requirement all together Jan 14 16:26:36 (hint: next time you just post a pointless information without context or qeustion, i'll silently ignore instead of trying and pulling it all out of nose) Jan 14 16:27:01 ? Jan 14 16:27:18 Yatekii: what did you do exactly? Jan 14 16:27:26 can't you just put the recipe as is in a pastebin? including the real file name? Jan 14 16:27:37 LetoThe2nd: sorry, got distracted debugging ^^I actually intended to pose a quetsion ... :/ Jan 14 16:30:03 LetoThe2nd: https://gist.github.com/Yatekii/45cd029ca2f6690fddcbd00aa9a4120c Jan 14 16:30:07 here you gho :) Jan 14 16:30:11 qschulz: ^ Jan 14 16:30:35 "i do not listen to what LetoThe2nd write: [X]" Jan 14 16:30:58 LetoThe2nd: I thought when I remove the PV requiremet that works Jan 14 16:31:02 ? Jan 14 16:31:26 stop thinking. start reading. this might sound like an insult, which it is not. its just the truth. Jan 14 16:32:02 LetoThe2nd: well I thought it's optional because my mate here in the office did his receipe without it Jan 14 16:32:07 so this was confusing Jan 14 16:32:14 but I now found some statements in his receipe Jan 14 16:32:16 SRC_URI[md5sum] on a git checkout is pointless too, imho Jan 14 16:32:29 -> SRCREV Jan 14 16:32:36 yes, this is what he did Jan 14 16:33:00 also added this: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" Jan 14 16:33:01 Yatekii: basically, what you did there is asking yocto to checkout master Jan 14 16:33:09 tell your "mate" that PV belongs into the recipe name. and if its a moving target, then it shall be _git Jan 14 16:33:11 Yatekii: stop stop stop. Start with small things :) Jan 14 16:33:23 *sighs* Jan 14 16:33:28 qschulz: have fun. i'm off. Jan 14 16:33:32 Yatekii: you have an example, make the example work Jan 14 16:33:39 LetoThe2nd: o/ Jan 14 16:34:11 Yatekii: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#git-fetcher Jan 14 16:34:19 well I have another example from a mate which works, so it's har dto tell which one is correct. especially since his seemed to work whilst the other didn't (not saying any of those means anything, but it's just confusing) Jan 14 16:34:23 thx LetoThe2nd :) Jan 14 16:34:34 Yatekii: your mate might not know what he's doing :) Jan 14 16:35:11 (and I say *might* because I don't know them and I haven't seen the code and I have no authority over who's doing something right or wrong :) Jan 14 16:35:21 qschulz: that's 100% the case :D Jan 14 16:35:32 Yatekii: so have a look at the link Jan 14 16:35:35 this gives all the default Jan 14 16:35:37 yup :) Jan 14 16:35:37 thx Jan 14 16:35:39 for the git fetcher Jan 14 16:36:16 mmmm Jan 14 16:36:31 it's actually not that good, it's missing the requirement on SRCREV Jan 14 16:36:32 anyway Jan 14 16:36:47 well it tells the args I can put into the url Jan 14 16:36:52 but not much more :/ Jan 14 16:37:03 TL;DR, either you use tag=mytag and you're good (except some network consequences as mentioned) Jan 14 16:37:21 or you need to pass a commit hash to SRCREV, because Yocto won't know which commit to take Jan 14 16:37:34 Remember, yocto is meant to build ina reproducible manner Jan 14 16:37:37 hmm what if I always want the newest hash? Jan 14 16:37:50 so, tag is ok because tag are meant to be fixed hashes Jan 14 16:37:50 because I am developping and not in the mood to always change it Jan 14 16:37:56 Yatekii: we'll see later Jan 14 16:38:05 let me finish that first Jan 14 16:38:08 kk :) Jan 14 16:38:29 so, either tag=something after the URL, or SRCREV Jan 14 16:38:51 the thing is, the hash in SRCREV is a hash that has to be in master Jan 14 16:39:22 or, if you add branch=mybranch, in mybranch Jan 14 16:39:27 (add to the URL) Jan 14 16:39:35 (because branch=master by default) Jan 14 16:39:43 so that's one thing Jan 14 16:39:53 so when you remove tag=${PV} Jan 14 16:40:20 It tries to get a undefined commit hash in master.. I'm actually surprised bitbake does not complain Jan 14 16:40:31 so you need either a tag or a branch + a commit hash Jan 14 16:41:06 now I hope the name of the recipe (${PN}) won't matter anywhere in the cargo class or elsewhere :) Jan 14 16:42:01 so, to answer your "but I want to develop and not update the SRCREV" => https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV Jan 14 16:42:40 and READ IT CAREFULLY, because the first line is not enough :) (bitbake will not complain but you'll have issues later on) Jan 14 16:43:03 JPEW: nevermind, just used a wrapper script to set them Jan 14 16:43:40 FILESEXTRAPATHS_prepend is for bbappends, you don't need that in a recipe (moreover, what your mate did, if they did it in a bb recipe and not in a bbappend, is actually already done, in another way, but it's done already so it's a no-op) Jan 14 16:44:13 Yatekii: also, best practice, always name your recipes my-recipe_version.bb Jan 14 16:44:31 NO underscores in my-recipe, NO uppercase letter or fancy character Jan 14 16:44:58 version can be a number, have letters or be `git` Jan 14 16:45:15 with that, PN in the recipe will be `my-recipe` and PV will be `version` Jan 14 16:45:44 ok, afk til tmrw. You can write I'll answer tomorrow if nobody's answered til then Jan 14 16:46:23 Yatekii: https://www.youtube.com/user/TheYoctoProject Jan 14 16:46:48 okii, thx :) Jan 14 16:46:52 thx so much! Jan 14 16:47:08 I will try some around, already read the sectioon you linked but not sure I fully understand Jan 14 16:47:12 have a nice evening! Jan 14 16:47:36 YPTM: is over Jan 14 16:47:38 Yatekii: i'm plugging my previous company's training (open access to materials) https://bootlin.com/training/yocto/ you can read the slides. It's a very wide introduction but not deep. Should be good for you. Jan 14 16:48:46 Yatekii: don't blindly copy paste. If you think you need to add something to your recipe or someone tell you to do it, have a look at the mega-manual and try to see if ithe variable to be modified makes sense Jan 14 16:49:26 Yatekii: btw, your personal website is returning 403 ;) Jan 14 16:49:35 kergoth: Ah, sorry missed your questions Jan 14 16:49:47 qschulz: I never blindly copy paste, I'll always try and understand the process behind it. but that does not mean it's the best way to do something ;) Jan 14 16:50:23 WPF (thank god I don't have to use it anymore) is a good example. the entire internet suggests to use it like winforms. when in fact you are not supposed to. Jan 14 16:50:42 and even tho you can understand the code and it kinda makes sense, you can't know there's a better version ;) Jan 14 16:50:46 JPEW: sorry for vomitting on the channel :) Jan 14 16:51:10 kergoth: It should be possible to set BITBAKEDIR before sourcing the environment script. We just need to make sure that BITBAKEDIR is one of the variables passed during capture Jan 14 16:51:20 qschulz: yeah, I know :/ I cba to fix it ... only had my resume, my PGP key and my email :D should fix it ... thx for the hint :) Jan 14 16:51:24 Yatekii: that was more meant for the FILESEXTRAPATH thing :) Jan 14 16:51:38 qschultz: no problem Jan 14 16:51:58 JPEW: you didn't use autocompletion for my nickname didn't you :p Jan 14 16:52:00 qschulz: yeah, that was just telling you guys what my mate used :) I didn't actually use that (lucky me :D) Jan 14 16:52:09 qschulz: https://github.com/yatekii this is more of a webpage for what I do :D Jan 14 16:52:29 qschulz: Hah, I didn't even know my client *had* autocomplete until I just tried it Jan 14 16:52:38 ok imma catch the train and continue work tomorrorw. but i'l be online on the cell to chug in all that info you gave me! Jan 14 16:54:16 Yatekii: invest your time in reading materials before coding otherwise you'll just be left with frustration. It is especially true with Yocto :) GL Jan 14 16:55:48 kergoth: I think adding "BITBAKEDIR" to run:envvars in pyrex.ini will do what you want Jan 14 16:56:10 kergoth: If you want to give that a try to make sure it works, I'll add it as the default Jan 14 16:58:11 kergoth: As far as the images are concerned, the absolute minimum requirement are the "*-base" images. From those, you could theoretically build up images for OE, Android, whatever Jan 14 16:58:42 JPEW: I think getting devtool to work would make pyrex useful for me Jan 14 16:58:53 and also running runqemu seemlessly Jan 14 16:59:14 I think those both work now Jan 14 16:59:34 khem: On the "next" branch at least Jan 14 17:00:26 runqemu works as long as you use uninative, since technically you are building qemu on a different system than you are running it :) Jan 14 17:01:24 khem: I don't use devtool extensively, but when I have used it, it's worked Jan 14 17:15:36 qschulz: yeah :) I am reading through the material you gave me :) thx! Jan 14 18:01:53 I used to be able to run bitbake -c fetchall core-image-minimal, in zeus it complains Task do_fetchall does not exist for target core-image-minimal. How can I download the sources? Jan 14 18:03:51 sveinse: That was changed Jan 14 18:03:58 https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.5-bitbake-changes Jan 14 18:04:02 thanks Jan 14 18:04:29 RP: I have a potential patch for prelink Jan 14 18:06:26 i think it needs more work but hopefully can eke it out Jan 14 18:19:59 khem: very cool :) Jan 14 18:29:56 Can you linkedin people do me a favour and share this page ? Jan 14 18:29:57 https://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ Jan 14 18:31:08 Done Jan 14 18:36:58 RP: I have one case of reproducible 'getpwuid(): uid not found: 1001' issue, but it happens only on one builder and works on other, anything you want me try there? Jan 14 18:38:19 RP: what I've found sofar is that it's triggered on all files which is unpacked from tarball in do_install() and it's not related to existing sstate-cache as I can still reproduce it on that builder after cleansstate and removing all SSTATE_MIRRORS Jan 14 18:38:52 JaMa: I was literally just looking at the python3 issue which also seems to only happen sometimes. I just replied on list about what I found there (not much) :/ Jan 14 18:39:17 JaMa: Is the ownership of those files from the tarball ever set? Jan 14 18:41:07 RP: as chown in the do_install, then not, it's this recipe: https://github.com/webOS-ports/meta-webos-ports/blob/zeus/meta-luneos/recipes-webos/luna-init/luna-init.bb#L24 Jan 14 18:41:09 JaMa: is pseudo up to date with master in that build? Jan 14 18:41:44 yes, it's oe-core b6d4150f9c74f25a4022a3fa0bd489a8e85deb77 Jan 14 18:42:50 JaMa: I think with that do_install you're at the mercy of tar and the ownership of the files is not consistent Jan 14 18:43:11 I'm logging the paths with bb.warn in "except KeyError as e" and it looks like every unpacked file triggers it (actually twice, once in package and once in packages-split directory) Jan 14 18:43:40 JaMa: there are basically two things that may happen here. Either tar never sets the ownership "correctly" or it makes a syscall pseudo doesn't capture Jan 14 18:44:01 is it using tar from host? Jan 14 18:44:06 JaMa: yes Jan 14 18:44:31 JaMa: I guess a quick cheap test is to try a different older tar binary? Jan 14 18:45:04 ok, can compare 2 builders, the failing one is tar-1.29 from Ubuntu 18.04, the other one tar-1.30 from Ubuntu 19.10 Jan 14 18:46:36 JaMa: I'd have expected the older one to work and the newer one to fail :( Jan 14 18:47:10 JaMa: still worth comparing. Are the uids of the build user different or the same? Jan 14 18:48:33 different, 3001 on failing one, 1000 on the ok, one and the error is about 1001: WARNING: luna-init-2.0.1-10+gitAUTOINC+9f0d2b6e31-r0 do_package: Cannot update hash with getpwuid or getgrgid for path ./packages-split/luna-init-fonts/usr/share/fonts/Prelude-Bold.ttf: 'getpwuid(): uid not found: 1001' Jan 14 18:52:06 New news from stackoverflow: My other imx7d pico android things start kit died, again Jan 14 18:56:52 JaMa: in the tarball what is the ownership of the files? Jan 14 18:59:27 RP: "select * from files where path like '%Prelude-Bold.ttf%'" Jan 14 18:59:38 on both builders look the same (1001 uid and gid) Jan 14 19:00:54 JaMa: I guess that is good and it means the python lookup isn't deterministic :/ Jan 14 19:00:59 RP: the gnu hash stuff is complicated, and musl does not support it either, so I think its best course for us to stay as it is Jan 14 19:01:05 JaMa: they'll be different python versions? Jan 14 19:01:11 host python Jan 14 19:01:22 khem: ok, fair enough Jan 14 19:01:29 khem: its a good one to watch/consider Jan 14 19:01:36 RP: I want to do some measurements before enabling it Jan 14 19:01:45 khem: sounds sensible Jan 14 19:01:57 since it can cause some maintainence burden, and lets not take it if its not worth it Jan 14 19:07:19 RP: 3.6.9 on failing, 3.7.5 working fine Jan 14 19:08:28 RP: roger/roger in the tarball which is 1001/1001 with --numeric-owner Jan 14 19:09:51 JaMa: Both should error, I don't know why they behave differently :/ Jan 14 19:10:38 trying with explicit chown on the failing one now Jan 14 19:11:01 JaMa: could you add debug to sstatesig.py to see that the return values of the pwd.getpwuid() call are and the input values Jan 14 19:11:11 being py it shouldn't change sigs and rebuild Jan 14 19:12:40 python docs say it shouldn't be version specific Jan 14 19:13:36 with chown -R root:root.. it works fine, pseudo db showing 0:0 now Jan 14 19:31:28 https://twitter.com/YoctoThe/status/1217166071519744000?s=20 Jan 14 19:34:00 RP: is it possible that it doesn't have include_owners set on the working one? I've added bunch of bb.warns (like I did on the failing builder) and nothing is shown, let me add it before the include_owners case Jan 14 19:36:26 damn, sorry, it might be that this build directory on the failing one doesn't have hashserv enabled at all :/ Jan 14 19:46:05 RP: now it's failing the same on both builders, I'm sorry for wasting your time Jan 14 19:48:39 JaMa: no problem, I know who hard these things can be to figure out Jan 14 19:48:54 RP: we might still improve the error message in these cases Jan 14 19:49:19 JaMa: yes, I quite like what I managed locally to improve the python 3.8 error failure Jan 14 19:49:42 I've checked last zeus build and the .ipk file really contains the files owned 1001:1001 and package-qa was fine with it (because it wasn't the same as builder's UID to trigger user-host-contamination) Jan 14 19:49:55 try: except Exception: bb.warn(str(path)) raise Jan 14 19:50:36 JaMa: we really need to improve the package-qa check to check "all unknown users" Jan 14 19:50:45 I was using https://paste.ubuntu.com/p/t2hMCZH977/ Jan 14 19:50:47 JaMa: might be worth a bug Jan 14 19:51:12 JaMa: With mine the benefit is it doesn't change behaviour, just shows more warning Jan 14 19:51:54 RP: https://twitter.com/YoctoThe/status/1217168511845519361 Jan 14 19:52:20 New news from stackoverflow: Trouble building u-boot for gumstix overo on yocto "thud" release Jan 14 19:52:32 Yes, that would be good, because now this error is triggered only with OEOuthashBasic and it might lead people to assume it's related to that Jan 14 19:53:06 I'll check the code in package-qa as I obviously have good test case for that Jan 14 19:56:58 JaMa: the hard part would be knowing which user ids are "bad". Current build user is easy, anything else is harder Jan 14 19:57:11 JaMa: I guess "exists in passwd in sysroot" is the right test? Jan 14 19:59:12 `getent passwd | cut -f1 -d: | grep -q $USER` ? Jan 14 19:59:42 JPEW: sounds like a performance nightmare Jan 14 19:59:50 RP: Ya, I could see that Jan 14 19:59:56 * RP is only half joking Jan 14 20:03:54 rburton, RP: regarding YOCTO #13733, I've noticed that sometimes the non-reproducbility is in parts of ELF files that get discarded, but this changes (only) the NT_GNU_BUILD_ID. Jan 14 20:04:24 Best solution I've found is to disable stripping of ELF files in the reproducible build test so that you ca debug it Jan 14 20:06:08 RP: interestingly, GNU_HASH/without-prelink boots faster than sysv_has/with-prelink almost 15% Jan 14 20:08:15 Hey we just ran into an sstate failure (zeus) where the filename was too long. I know this has been seen before.. has zeus been patched for this (and my zeus is just too old?) Jan 14 20:08:37 GNU_HASH w/ prelink is what I test. I'm not even sure sysv_hash + prelink actually works Jan 14 20:10:58 it works on mips Jan 14 20:11:20 filename too long is host system problem Jan 14 20:11:32 are you using something like ecryptfs Jan 14 20:11:54 no.. the sstate filename is -really- long.. Jan 14 20:12:04 it's the arch part that seems to have made it too long.. Jan 14 20:12:23 I was looking in the oe-core archives, and I see some recent patches to address it, but havn't seen if they went in (yet) Jan 14 20:12:40 longer than 255 ? Jan 14 20:12:45 yes Jan 14 20:13:08 257 Jan 14 20:14:17 perhaps we should check for NAME_MAX and bail out Jan 14 20:15:16 RP's patch fro 1/5 looks like it will fix it.. Jan 14 20:15:24 [OE-core] [PATCH 4/4] sstate: Handle sstate filenames longer than 255 characters Jan 14 20:15:56 if project have custom license, is it ok to use it like this LICENSE="${PN}" ? Jan 14 20:16:26 No, you need to define the license with a specific name. 'proprietary' is one such name you can use Jan 14 20:17:20 I have bunch of projects with custom licenses to deal with, they have custom licenses but they are all non-commercial Jan 14 20:18:11 example: https://github.com/libretro/fmsx-libretro/blob/master/LICENSE Jan 14 20:18:39 dev1990: proprietary != commercial Jan 14 20:18:52 so fray++ Jan 14 20:22:45 fray: perhaps that patch could try to deduce the limits at runtime using getconf NAME_MAX $SSTATE_DIR Jan 14 20:23:13 There is a section in the manual on settin the license field and including the license in your layer(s) Jan 14 20:23:38 http://lists.openembedded.org/pipermail/openembedded-core/2020-January/290956.html Jan 14 20:23:49 + limit = 254 Jan 14 20:24:00 + fn = spec + hash + "_" + taskname + extension Jan 14 20:24:05 + if len(fn) > limit: Jan 14 20:24:10 + avail = (254 - len(hash + "_" + taskname + extension) - len(components[0]) - len(components[1]) - len(components[5]) - len(components[6]) - 7) / 3 Jan 14 20:24:17 then max for fields 2/3/4 are 'avail' Jan 14 20:24:27 that should ensure it stays comfortably at or under 254 Jan 14 20:27:05 I'll spend some time to check that on Zeus in a bit Jan 14 20:31:31 is there a bash-completion script available for opkg? Jan 14 20:34:58 bitbake is evaluating the entire dependency tree up front right? Are there any options to alter the behaviour of the sequencing of tasks, such as early as possible vs late as possible? Jan 14 20:44:56 need to produce u-boot.bin and u-boot-spl , on deploy images i find only the main u-boot, how can i produce also the spl ? Jan 14 20:45:19 angelo__: adjust u-boot configuration accordingly Jan 14 20:45:43 u-boot will build whatever its config it says. Jan 14 20:51:21 LetoThe2nd, mm i have CONFIG_SPL in my config, but seems only one binary is generated Jan 14 20:51:54 angelo__: and if you build the config manually then it gets built? Jan 14 20:52:48 i build out of the tree with same config, it get built Jan 14 20:53:02 but i see now that the single u-boot produced is u-boot.imx Jan 14 20:53:29 so, there seems to b an issue with the make target Jan 14 20:53:48 angelo__: time to inspect the logs, then. Jan 14 20:54:29 maybe is this Jan 14 20:54:30 UBOOT_MAKE_TARGET ?= "u-boot.imx" Jan 14 20:56:58 maybe. Jan 14 20:57:06 LetoThe2nd, there will be any Yocto stand at fosdem ? Jan 14 20:57:19 angelo__: OpenEmbedded is there Jan 14 20:57:39 see also https://www.linkedin.com/posts/openembedded_fosdem-fosdem20-openembedded-activity-6622864179256705024-OTAJ Jan 14 20:58:20 angelo__: define SPL_BINARY Jan 14 21:08:17 LetoThe2nd, cool, will probably buy a ticket Jan 14 21:08:25 LetoThe2nd, you will be there ? Jan 14 21:08:40 denix, thanks, trying Jan 14 21:22:07 Hi! Im trying to find out how to remove busybox and replace it with coreutils on my build but Im failing miserably. Any hints? :) Jan 14 21:22:42 New news from stackoverflow: How do you properly build gpiod applications from Yocto? Jan 14 21:25:13 sveinse: you can change bitbake's scheduler, its plugable Jan 14 21:25:19 sveinse: rmwork enabled a different one for example Jan 14 21:33:11 autoconf-archive fails to the configuration step, because it finds python through my pyenv configuration... that is weird. Jan 14 21:52:43 JPEW: Are your slides from the San Diego devday somewhere I can link to? Jan 14 22:08:14 Rp: https://docs.google.com/presentation/d/1IzFlI8n8B49HkHiQClO6OoE_mugvK52Zoarx9BRimiY/edit?usp=sharing Jan 14 22:09:14 JPEW: can I put that on the wiki? Jan 14 22:09:22 Please do Jan 14 22:09:28 JPEW: thanks Jan 14 22:09:37 I found funny thing, please look at this Jan 14 22:09:40 https://github.com/RetroPie/RetroPie-Setup/tree/master/scriptmodules/libretrocores Jan 14 22:10:06 seems familiar? Jan 14 22:12:17 dev1990: not to me... Jan 14 22:14:47 I don't get it, they are working so hard on something that could be a Yocto from the beginning Jan 14 22:15:02 Yocto layer I mean Jan 14 22:16:33 dev1990: oh, I see. I've seen that happen before :/ Jan 14 22:17:00 RP: is there space for running another glibc run ? Jan 14 22:17:32 khem: its busy doing a build from scratch but there probably is overnight Jan 14 22:17:39 I have a fix for prelink, which I want to see if is working Jan 14 22:17:48 khem: does it only affect mips? Jan 14 22:18:00 khem: I could just run the failing mips builds if so Jan 14 22:18:14 RP: the fix is mips specific but applies to common srcs Jan 14 22:18:24 of prelink Jan 14 22:18:35 khem: so we should build everything? or just need to test mips atm ? Jan 14 22:18:40 GNU hash is pretty fast Jan 14 22:19:08 I think mips will benefit from it, I will disable it for musl/mips and enable it for glibc/mips Jan 14 22:19:17 khem: ok Jan 14 22:19:26 khem: do you have a poky branch with the change in? If so we can just run it on the AB and queue after the current build Jan 14 22:19:46 I can point it at your branch Jan 14 22:19:55 musl will eventually get it done too but they are not happy with glib's approach, so it might be a while Jan 14 22:20:13 RP: I will push this into kraj/glibc-2.31 Jan 14 22:20:19 let me do that Jan 14 22:34:35 RP: try https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/glibc-2.31 Jan 14 22:35:32 RP: perhaps just run mips/core-image-sato-sdk for starts Jan 14 22:35:51 * zeddii calls it a day of boot testing on 5.4. sato and kernel-dev tomorrow. then I'm pretty well covered Jan 14 22:36:08 zeddii: btw, I think there are fixes for meta-intel which will stop the autobuilder throwing warnings Jan 14 22:37:53 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1447 https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/206 https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1445 Jan 14 22:37:55 yah. I have most of them queued here, but they are on top of other 5.4 changes that I have, so I need to test a bit more. Jan 14 22:38:15 zeddii: ok, cool. Just keen to get rid of one of the last warnings on the AB Jan 14 22:47:27 RP: cool, I opened them in browser lets hope for green Jan 14 22:49:08 RP: I think we need https://patchwork.openembedded.org/patch/168929/ along with rest gst/meson conversion patch Jan 14 22:49:38 there are several layers which have to adopt to meson changes for gst as well Jan 14 22:49:43 khem: right, will add in the next round of testing Jan 14 22:49:47 ok Jan 14 22:52:05 RP: nfsroot with qemu is quite helpful in debugging the low level stuff like ldso Jan 14 22:52:48 khem: needs better documentation! :) Jan 14 22:54:33 RP: I think when you have prelinked rootfs and want to unprelink just one file and rootfs is not booting Jan 14 22:54:51 such situations while not common are very hard to debug otherwise Jan 14 22:55:30 khem: yes, early init can be fun... Jan 14 22:55:56 especially a borked ldso :) Jan 14 23:02:48 ya, broken ldso sucks.. REALLY a pain to debug Jan 14 23:03:14 what bugs me is the error is usually "No such file or directory".. but it doesn't tell you it's the ldso (or what the ldso was trying to load).. just a completely nebulous error. Jan 14 23:32:10 Kernighan law rightly states - debugging is twice as hard as writing the code in the first place Jan 14 23:38:09 khem: unless its bitbake hashequiv :) Jan 14 23:38:52 hmm heh Jan 14 23:39:22 RP: core-image-sato-sdk is booting here fine on qemumips now Jan 15 00:02:01 bah I don't understand how versioning of the packages works :( Jan 15 00:06:16 Yatekii: its based on debian version policy mainly https://www.debian.org/doc/debian-policy/ch-controlfields.html#version Jan 15 00:06:40 khem: I am trying to make my recipe with autorev work ... Jan 15 00:06:42 now I get WARNING: raichu-core-${SRCPV}-r0 do_unpack: raichu-core: the directory ${WORKDIR}/git (/home/yatekii/repos/raichu/build-openstlinuxtkrt-stm32mp1-raichu-cubemx/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_tkrt-linux-gnueabi/raichu-core/${SRCPV}-r0/git) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to Jan 15 00:07:25 https://gist.github.com/Yatekii/0fe441777b3a25c9cad29763e82b7fb1 is my receipe Jan 15 00:07:38 idk, all the guides and stuff are so unprecise ... Jan 15 00:08:45 remove tag= Jan 15 00:09:42 and SRC_URI should be SRC_URI = "git://github.com/rust-embedded/gpio-utils.git;protocol=https" Jan 15 00:12:43 https://gist.github.com/Yatekii/8dc9de1aa9c0a675abc192206abeda8c is what I get Jan 15 00:12:58 adding the protocol instead of the tag didn't help much :/ Jan 15 00:17:36 does SRCREV = "282ea12416d2ad29a3f4c8612fa56c14cd569c2c" work ? Jan 15 00:20:18 https://gist.github.com/Yatekii/4464ec800db6ce5e1a1ee44cc0a76dbf nah, same as in the afternoon Jan 15 00:24:14 even if I add the tag 0.3.0 and name the receipe raichu-core_0.3.0 it does not work Jan 15 00:24:40 when I look into the work dir there is a file called gpio-utils.git which contains the html of the git repo LOL and the git dir is empty Jan 15 00:24:43 .... Jan 15 00:28:58 uhm it was the http:// ... Jan 15 00:29:07 it needed to be git:// Jan 15 00:30:43 well you should read messages Jan 15 00:31:01 they don't tell Jan 15 00:31:14 and why do they do it like this in the example then lol Jan 15 00:31:15 well Jan 15 00:31:44 messages here i meant thats what i wrote above Jan 15 00:32:00 khem: ohhhhhh sorry I just saw the end Jan 15 00:32:07 thanks! Jan 15 00:32:18 why did they do it wrong in the example then? :/ Jan 15 00:32:42 to err is human :) Jan 15 00:32:46 file a bug Jan 15 00:33:23 khem: well that readme exists for many months now ... I mean somebody must have recognized ... Jan 15 00:33:25 well anyhow Jan 15 00:34:48 where did you pick the example from ? Jan 15 00:35:05 they might be using http fetcher which is fine Jan 15 00:35:13 you were trying to use git fetcher Jan 15 00:35:16 I wonder what the issue here is: bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Conflicting revisions (AUTOINC from SRCREV and git from the url) found, please specify one valid value Jan 15 00:35:17 I read the guide on AUTOREV but I still don't understand :/ Jan 15 00:35:44 khem: uhm how do I know which fetcher it's using? :/ Jan 15 00:35:46 it cant get to the repo and run git ls-remote Jan 15 00:36:59 uhm oh, so this worked wat Jan 15 00:37:06 I don't understand yet ... Jan 15 00:37:28 https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bb-fetchers Jan 15 00:38:00 yes, it says the url prefix determines the fetcher Jan 15 00:38:29 so when I am using https:// it should use that fetcher which didn't work Jan 15 00:39:11 anyhow, seems to be building the image just fine now :) Jan 15 00:40:05 hmm how is D determined? Jan 15 00:40:28 SRCPV needs a scm fetcher Jan 15 00:41:00 well I tried without that cursed variable and just use the git tag Jan 15 00:41:03 which didn't work either Jan 15 00:43:48 read about fetchers they are quite configurable Jan 15 00:44:19 one can get the syntax wrong easily Jan 15 01:11:50 hmm can I clone a private repo somehow if I have a creadential store? Jan 15 02:00:14 yes Jan 15 02:00:45 use git://user@host:......;protocol=ssh for SRC_URI Jan 15 02:01:25 you can use ~/.netrc to specify password for accessing git server **** ENDING LOGGING AT Wed Jan 15 02:59:57 2020