**** BEGIN LOGGING AT Fri Feb 07 02:59:57 2020 Feb 07 13:57:54 hi! How does OE decide if a recipe package is machine specific or just arch-specific? like, how does it know if the workdir should go into tmp-glibc/work//... or tmp-glibc/work//... ? Feb 07 13:58:30 PACKAGE_ARCH variable Feb 07 14:00:36 Thanks! It seems PACKAGE_ARCH gets set automatically depending on what goes into the package? I have written a recipe that is machine specific, but OE still thinks its arch-specific. Should I set the PACKAGE_ARCH specifically in this case, or should I inherit something like "allarch", or whats the best practise to make OE understand the package arch? Feb 07 14:01:29 if you know it's machine specific you need to set PACKAGE_ARCH = "${MACHINE_ARCH}" in the recipe Feb 07 14:01:50 great, thanks! i'll do that. Feb 07 14:01:55 it's set automatically in some cases (e.g. some SRC_URI element is used from the ${MACHINE} subdirectory) Feb 07 15:00:08 Good morning Feb 07 15:05:31 Neither Nor. Feb 07 16:49:35 Hello. I inherited our bitbake evnironment and I need to update a package Feb 07 16:50:10 And I have no idea where to start. I have read the yocto manual, I know what it does. I can build out currently environment Feb 07 18:36:13 JaMa: QT 5.14 is dying on cinematic experience demo on qemx86-64 and other qemu as well Feb 07 18:37:24 JaMa: if you build yoe-qt5-wayland-image and boot it run the example in /usr/share/cinematicexperience dir you can see the problem Feb 07 18:37:49 but I am on gcc10 so that might be one factor, but same gcc10 has booted it fine in past Feb 07 18:38:00 with qt 5.13 Feb 07 18:38:14 so I wonder if its just me or others can see it too Feb 07 18:39:03 I have never tried cinamaticexperience before, but with LuneOS we have this bug since 5.14 (still reproducible with 5.14.1) https://bugreports.qt.io/browse/QTBUG-81790 Feb 07 18:39:30 BlackFrog: if you need to update an existing recipe you can look into using devtool workflow https://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#using-devtool-in-your-workflow Feb 07 18:39:58 google is still sorting 2.3 above 3.0 release for docs thats shame Feb 07 18:45:15 tlwoerner: do we really need two machine confs to decide if it goes to sdcard or emmc or did I misunderstand you? Feb 07 18:45:27 I was aiming at WKS_FILE ?= "tinker-board-s-emmc.wks" Feb 07 18:45:34 i.e. ?= intead of = Feb 07 18:45:50 then if someone wanted an sd-card wks they could override it in local.conf Feb 07 18:46:09 the build is essentially the same, its only a different kernel boot args line Feb 07 18:49:36 and it would also allow someone to come up with their own partitioning if required (which is btw my use case) Feb 07 18:53:49 Jin^eLD: If the only difference is the kernel command line arguments, you can just have a separate wks file Feb 07 18:54:01 Jin^eLD: e.g. one WKS for emmc, one for SD Feb 07 18:54:59 JPEW: thats how I am setting it up now, yes, i.e. I changed the WKS line to be ?= in machine conf and I'll point the default one to the emmc version Feb 07 18:55:07 btw where do meta-rockchip patches go? Feb 07 18:55:11 regular openembedded ml? Feb 07 18:55:27 Jin^eLD: Ya, see README.md :) Feb 07 18:55:35 Jin^eLD: Err, yocto mailing list Feb 07 18:55:42 oh right there is a readme, my bad :) Feb 07 18:55:59 actually quite some info there, sorry for not noticing :) Feb 07 18:56:14 Jin^eLD: It happens :) Feb 07 19:00:50 I should probably set the image name accordingly... Feb 07 19:00:55 to indicate if its sdcard or emmc Feb 07 19:02:08 Jin^eLD: The wks file names? Yes Feb 07 19:03:31 no the actual wic image names, the binary reuslt of it Feb 07 19:04:09 and it seems I can't set it in the wks, I could only do that in machine.conf which is not so cool because then if someone wants to switch from the emmc wks to sdcard wks - the name is a separate setting Feb 07 19:05:04 https://paste.ee/p/z6EAg Feb 07 19:05:36 thats the only difference between the -s and non-s tinker so far Feb 07 19:05:57 and I wish that tinker-board-s-emmc.wks would be able to influence the iamge name, but thats not doable right? Feb 07 19:06:07 Hmm Feb 07 19:06:33 I only found WKS_FILE to influence the name, but that would have to be set in some .conf in parallel Feb 07 19:06:55 do you know what I mean? not sure if I was able to describe it properly Feb 07 19:07:26 Ya, I get it; the final image file produced doesn't seem to depend on the name of the wks file Feb 07 19:08:01 right, and the wks file itself can not influence yocto variables Feb 07 19:09:05 not really a big issue, more a nice to have thing, but given that the image won't boot if picked incorrectly it'd be a good help to see what exactly is meant for what in the image directory Feb 07 19:09:47 Jin^eLD: Ya, that is too bad. I though you could have multiple WKS files :( Feb 07 19:10:04 oh you meant multiple wks files at the same time? Feb 07 19:10:15 that's an interesting thought Feb 07 19:10:25 i.e. just generate both each time Feb 07 19:10:33 Right, e.g. WKS_FILES ?= "tinker-board-s-emmc.wks tinker-board-s-sd.wks" Feb 07 19:10:41 Just produce both all the time Feb 07 19:10:56 yes, found the variable as well in the class Feb 07 19:11:16 crap... wait, but I still need to be able to give the resulting images different names Feb 07 19:11:27 Jin^eLD: Right, but I think wks_search() only returns the first one found Feb 07 19:11:42 looks like it Feb 07 19:11:54 Jin^eLD: Yes that too Feb 07 19:11:57 doh Feb 07 19:13:00 Jin^eLD: Might be possible to extend the syntax, e.g. WKS_FILES ?= "tinker-board-s-emmc.wks;emmc "tinker-board-s-sd.wks;sd" where the suffix denotes an image suffix of some sort Feb 07 19:13:43 sounds a bit hacky hmm Feb 07 19:13:48 Maybe Feb 07 19:13:56 Might be worth seeing what rburton things Feb 07 19:13:59 *thinks Feb 07 19:14:15 if the wks syntax itself would allow to tune the image name/extention Feb 07 19:14:22 that'd be cleaner I guess Feb 07 19:14:25 (I think he did most of the wks stuff) Feb 07 19:15:19 Maybe; it might be hard to pull that back out of the file though Feb 07 19:17:59 depends who adds the name... if the wic tool would do it... Feb 07 19:18:09 mv "$build_wic/$(basename "${wks%.wks}")"*.direct "$out${IMAGE_NAME_SUFFIX}.wic" Feb 07 19:18:16 so I guess the wic tool creates a .direct file Feb 07 19:18:22 and the class moves it over to be a "wic" Feb 07 19:19:14 another way would be, well, yet another variable backed by a python function Feb 07 19:19:27 which then tunes the name and tunes which wks is being taken Feb 07 19:19:55 but that'd be a non standard solution I guess Feb 07 19:22:12 Jin^eLD: Hmm Feb 07 19:22:40 in theory it'd be possible to tune IMAGE_NAME_SUFFIX depending on what image is being generated Feb 07 19:22:45 Right Feb 07 19:22:48 not sure where the best place for that would be Feb 07 19:22:52 since its really tinker-s specific Feb 07 19:23:11 Jin^eLD: I think we can make something generic in image_types_wic.bbclass Feb 07 19:23:28 s/can/should/ Feb 07 19:23:53 but then the wic class would have to gain the knowledge of "what is this image good for", i.e. emmc, sdcard, not sure if thats not too machine specific? or is there some common ground for different boards there? Feb 07 19:24:29 Jin^eLD: That's why I was thinking it should be some option to add a generic suffix Feb 07 19:25:05 but that would not really help in this specific case? we want to add the suffix only if a specific wks file was chosen? Feb 07 19:25:46 so either this option is part of the wks and wic knows how to deal with it... or some logic for processing variables is required? or did I miss someting? Feb 07 19:25:47 Jin^eLD: It would let you produce a emmc and sd wic file at the same time Feb 07 19:26:13 ah, you mean extend the wic class to be able to spit out more than one image at once Feb 07 19:26:35 which also means it would have to deal with different image names Feb 07 19:26:44 So when you `bitbake core-image-minimal` you would get `core-image-minimal-tinker-board-s.emm.wks` and `core-image-minimal-tinker-board-s.sd.wks` Feb 07 19:26:53 Right Feb 07 19:27:16 Jin^eLD: Dang it you are nerd sniping me :) Feb 07 19:27:23 lol Feb 07 19:27:26 I'm supposed to be bringing up a dev board ;) Feb 07 19:27:33 sorry bout that hehe Feb 07 19:28:03 It's fine... I actually have been operating under the assumption this was possible and will run into the same problem eventually :) Feb 07 19:28:11 So solving it now is good :) Feb 07 19:29:21 I wonder if a better way would be to solve it in u-boot so that depending on what is being booted it tunes the kernel bootargs instead of hardcoding them during the build Feb 07 19:29:35 what is this "extlinux" thing all about btw? Feb 07 19:29:58 I am used to u-boot passing the kernel args, so wa a bit surprised about that extra partition with the -conf file Feb 07 20:24:18 JPEW: btw one more thing I noticed, wic tunes the fstab on the rootfs, at least here on the tinker board I see /dev/sda entries Feb 07 20:24:21 which of course is wrong Feb 07 20:24:53 probably the "stock" wks configs for the tinker miss the --ondisk option to set it to mmcblk0 or 1 Feb 07 21:44:48 JPEW: wks wasn't me! Feb 07 21:59:07 rburton: sorry, for some reason I thought it was **** ENDING LOGGING AT Sat Feb 08 02:59:58 2020