**** BEGIN LOGGING AT Tue May 12 03:00:16 2020 May 12 06:26:29 http://paste.org.ru/?m5ddx1 full log May 12 06:35:22 cronolio: despite the question lacking almost all content, i have to admit that we care mostly about building yocto and yocto-based stuff around here. (maybe thats becase why its called #yocto?) May 12 06:43:16 Letothe2nd: is this really #yocto channel ? :) May 12 06:44:00 cronolio: I cant tell if youre being sarcastic May 12 06:44:06 either way May 12 06:44:34 cronolio: I agree with Letothe2nd, but skimming through your log youre missing a header file May 12 06:44:48 cronolio: gshadow comes from glibc May 12 06:45:20 cronolio: you can literally see the compilation command so you know what directories are being searched for header files (-I flags) May 12 06:45:39 in my case libc is musl May 12 06:45:40 cronolio: you could also add -v to CFLAGS and it would tell you the specific order May 12 06:46:12 cronolio: I was just about to say you need to check where that file should be coming from and why is it not finding it May 12 06:46:16 cronolio: iÄm not being sarcastic, just referring to "21:27 < cronolio> in custom linux, not yocto" May 12 06:46:26 cronolio: but you just answered your own question May 12 06:46:29 cronolio: so i think the remark is absolutely legit. May 12 06:46:39 Letothe2nd: haha I meant him May 12 06:47:09 cronolio: plus, as systemd specifically targets glibs, you're wll like... whatever. May 12 06:47:13 cronolio: AFAIC gshadow comes from GLIBC not libc May 12 06:47:31 so, musl wouldnt have it May 12 06:48:33 cronolio: at least my musl build does not either May 12 06:49:54 so.. in yocto.. it is possible to build systemd with musl ? May 12 06:52:31 cronolio: as you can see in http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd_245.5.bb?h=master#n25 the recipe suggests that it builds for musl, but http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd_245.5.bb?h=master#n660 pretty directly says "use at your own precaution" May 12 06:52:39 it does May 12 06:53:06 cronolio: as well as it states that you need to take care about the configuration: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd_245.5.bb?h=master#n93 May 12 06:53:19 the thud branch had 0022-Use-if-instead-of-ifdef-for-ENABLE_GSHADOW.patch May 12 06:53:50 which was dropped on the 241 upgrade 4eb2b3f1503a41474d0c40ada296a9800840267c May 12 06:54:17 but youre gonna have to debug why yourself bc its late May 12 06:54:31 good night guys May 12 06:55:02 laters May 12 06:56:20 cronolio: Also, as Letothe2nd said, the simplest answer probably is build with yocto :) May 12 06:57:05 thanks. looks like configuration part is what needed to me May 12 06:58:25 cronolio: you might get it to build now, but eventually you'll realize the solution that scales is yocto/OE May 12 06:58:32 alright night May 12 07:01:27 alejandrohs: yeah, i understand that here is yocto channel :) May 12 07:31:40 there is something from lfs, musl and now from yocto. it's just for fun. quality and some scaling not required :) May 12 10:19:03 Hi, Is it possible to add extended partition on demand in wks file. I don't see such possiblity in docs May 12 10:26:40 Looks like downloads.yoctoproject.org is down. Anyone else having issues with it? May 12 10:30:53 paulbarker: same here May 12 10:33:49 Why does it always happen when it's halstead night time :) ? Are the servers european-racists? May 12 10:52:26 tolszak: I think you need to expand on that question a bit, it's a bit too vague for me to understand what you're wanting to do May 12 10:53:31 Damn, my build failed. I need to find a mirror for `opkg-0.4.2.tar.gz` or wait until downloads.yoctoproject.org gets fixed May 12 11:18:27 paulbarker: My old custom system have partition layout: May 12 11:18:38 1. boot 2. extended 3. other partitions May 12 11:19:02 I want to port it to yocto and extended partition is only created when I try to create > 4 partitions May 12 11:19:13 to have the same partition numbering as in old layout May 12 11:19:49 I need to create 2 artificial not used partitions in wks file just after boot partition May 12 11:25:53 paulbarker: http://git.yoctoproject.org/cgit/cgit.cgi/opkg/snapshot/opkg-0.4.2.tar.gz ? May 12 11:25:57 paulbarker: So I would like to do it neat. Initial option is to make custom image type recipe with parted inside it. But if wks allows to add extended partition manually it is IMHO alot better idea May 12 12:18:45 Hi is there an easy way to create a SDK which is identically with the one iam using in a build? May 12 12:20:27 Iam asking because,right now iam able to build the main application with the default sdk and with bitbake . But i want to add a dbus dependency and i want to add a shared object , so the SDK / standalone build will not work if i merge this May 12 12:21:01 tolszak: Are you talking about the old msdos primary/extended partitioning? May 12 12:21:16 You should be able to use the `--type` argument in your wks file: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/ksparser.py#n156 May 12 12:21:19 paulbarker: Yes I do May 12 12:22:03 paulbarker: Any idea why it is not in docs: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#command-part-or-partition May 12 12:22:06 paulbarker: :) May 12 12:23:07 tolszak: wic has grown lots of new options and Yocto Project is currently without a dedicated docs maintainer. Patches welcome :) May 12 12:23:57 paulbarker: Will give it a try thank you! it is highly possible I will contribute explanation for this option. Thanks May 12 12:27:23 Hi May 12 12:31:09 I would like to include an application in two differents images but the application has to be compiled with different options. It seems it is not possible to share variable between image and application recipes, is there another way? Is it possible to create two recipes that share everything (with an include) expect a variables that changes build options or is there a smarter way? May 12 12:33:49 ykrons: two distros is the proper way to do it. Depending on what the option changes, just compile everything and bundle in different packages is another proper option. Hacks involve having two recipes including the same .inc file where 99% of the logic is written except PACKAGECONFIG = "foo bar". May 12 12:35:25 ykrons: global data is global, local data is local. recipes set local data only )otherwise build or parsing order would matter which is not correct) May 12 12:36:02 I use two distributions and one machine May 12 12:48:25 qschulz, PatrickE: thanks for feedback. In my mind distos were a high level set of packages to install like X server etc. In my case, it is "just" like building a enduser application with different splashscreen image ... so distro seems to me overkill, but I'm not very familiar with distro May 12 12:49:55 ykrons i tried to copy the real world situation 1 to 1. That means i build one mainboard => one machine ... May 12 12:52:59 PatrickE, same for me mainboad <-> MACHINE, I should admit that then for me : one IMAGE <=> one product and I don't know what to do with DISTRO... May 12 12:53:32 I use debug and release distros :D May 12 12:53:43 I see several similar products using the same DISTRO customized by different IMAge May 12 12:58:05 ykrons: distros are lego vs mechano. images are boat vs car. You cna't build an image without a distro and a specific distro impacts many images. May 12 12:58:32 ykrons: https://www.youtube.com/watch?v=o-8g0TPVVGg might be better explained :) May 12 12:58:39 might explain better* May 12 13:01:24 ykrons: if it's just a splashscreen that is changed, the two recipes hack seems acceptable to me (even hackier is to change it directly in the rootfs from the image recipe but... I don't like modifying behavior of a package from the image recipe) May 12 13:05:52 qschulz: you are doing good in explaining :) May 12 13:07:36 Letothe2nd: only took your words from Yocto dev days :) May 12 13:08:42 qschulz: i know. :) May 12 13:20:03 qschulz, I will have a look to the video to clarify some concepts! Thanks. It is a bit more than a splashscreen and require different compilation, but it remains an application specific customization May 12 13:21:57 Letothe2nd, thanks for the video May 12 13:23:19 ykrons: :) May 12 13:27:29 RP: can you think of an example recipe that exports some variables from a called block of code ? My grepping has failed. My reproducibility changes are needed in a couple of places in the kernel build, and I just copied and pasted the variable exports for now .. but obviously better if it can be one place to do the exports. It can’t be anonymous python or class exports, since it needs the code to be checked out, et May 12 13:34:34 denix. jonmason: Upon further thought, I don't think that moving those python recipes to OE-core is the best idea May 12 13:36:31 JPEW: Works for me May 12 13:36:57 JPEW: I'm going to have a v2 of the TFA patch shortly. Diego fixed the part you and denix were complaining about :) May 12 13:38:42 JPEW: why? May 12 13:42:02 denix: from a maintainence perspective, I think it would be better to put TFA in oe-core instead... it seems like it would be more likely to be maintained than 2 random python recipes... I might be biased though May 12 13:43:33 Oh i just tried -c populate_sdk .... May 12 13:43:42 bitbake is really powerful May 12 13:43:42 JPEW: isn't it what I proposed back then and got shot? May 12 13:43:51 denix: Yes it is May 12 13:46:44 * JPEW looks back at that thread May 12 13:52:14 denix, jonmason: I don't really have a problem with leaving TFA in meta-arm, I just think if anything is moving to oe-core, TFA seems the most likely to be maintained, since most aarch64 users are going to need it. May 12 13:52:55 that jonmason is a slacker. he’ll let it bitrot in meta-arm :P May 12 13:52:58 JPEW: I'd prefer to keep it in meta-arm May 12 13:53:03 zeddii: ha! May 12 13:53:16 jonmason: Fair enough, but that means something has to be done with op-tee May 12 13:53:16 * zeddii ducks May 12 13:53:33 Make it dynamic on meta-python? May 12 13:54:04 JPEW: I like that better than making it's own layer May 12 13:54:16 jonmason: Sounds good. I'll make a patch May 12 13:54:58 zeddii: weren't you going to use TF-A from meta-arm.... May 12 13:55:00 ;-) May 12 13:55:02 JPEW: why do you say python modules will not be maintained in oe-core? May 12 13:55:50 JPEW: those are just python modules - how much maintenance do they require? May 12 13:56:09 jonmason: yeah, we are in this mess because of zeddii! May 12 13:56:29 denix: always zeddii fault May 12 13:57:16 truth! May 12 13:57:28 sanity build of world + dog with new tf-a recipes (with deigo's change). pushing to list upon expected successful completion May 12 13:57:32 @jonmason yes we will. May 12 13:58:01 just fighting the battle of open sourcing lopper at the moment. wheee. and fixing kernel reproducible builds, THEN fight that battle :D May 12 13:58:26 denix: Its not that they won't or can't be maintained... I just suspect it might be harder to do so? May 12 14:01:18 JPEW: python modules are low maintenance in general - just version updates, right? May 12 14:08:17 If we have the maintainers there could be a case for gently expanding oe-core a little May 12 14:12:59 denix: Ya it probably would be fine May 12 14:15:16 denix: there's also some runtime dependency work involved in maintenance, although those changes aren't usually recurring May 12 14:16:54 tgamblin: I think in this case it would be moving existing recipes from meta-python, does that make a difference? May 12 14:18:09 JPEW: depends on which ones got moved, but yeah - I've been sending fixes for module recipes here and there over the last couple of weeks, and I have 4-5 more coming May 12 14:20:47 We could also end up wanting to migrate some Python modules (e.g. python3-fastentrypoints) to address the sluggishness of https://github.com/pypa/setuptools/issues/510, if we were going to consider adding more to oe-core May 12 14:25:21 $ git log --oneline --since Jan |grep gcc-10 | wc -l May 12 14:25:21 10 May 12 14:25:37 in case anyone cares. May 12 14:25:57 a few more just added over the wknd. May 12 14:27:03 paulg: https://twitter.com/TheYoctoJester/status/1260107233477701636 May 12 14:35:02 * paulg wouldn't have associated being a gcc fanboy with "kewl kids" but whatever.... May 12 14:35:31 :) May 12 14:38:57 the above was mainline kernel, btw. Should have made that explicit. May 12 14:41:22 "Why is this build taking so long? meta-virtualizaton....dammit!" May 12 14:42:49 don’t blame the messenger. blame libvirt May 12 14:43:10 blame everything! May 12 14:59:14 jonmason: heh, I guess you don't use Qt ;) May 12 14:59:39 YPTM: Jan-Simon is on May 12 15:00:01 YPTM: Scott Murray is on May 12 15:06:15 * paulbarker misses the first 5 mins of the YPTM call May 12 15:19:53 qschulz, PatrickE : I will finally go the two recipes hack way. The video has confirmed my understanding of distro .. and we rereading the thread I see the "lego vs mecano ..." that I have missed the first time ... everything is clear now! May 12 15:20:20 thanks all May 12 15:27:12 alejandrohs: https://wiki.yoctoproject.org/wiki/LTS May 12 15:55:56 qschulz, paulbarker, downloads.yoctoproject.org recovered on its own. I've been investigating for the last hour and I haven't tracked down the problem yet. I appreciate the report. May 12 15:56:06 RP: thanks May 12 15:59:33 halstead: Thanks for looking into it May 12 16:09:53 JPEW: do we still need 32bit mingw SDK or 64bit is enough these days May 12 16:15:41 khem: I'm not sure. I don't need 32-bit so it might be worth asking on the ML. May 12 16:15:53 khem: Is something breaking? May 12 16:21:41 yes gcc10 May 12 16:21:57 drop it! May 12 16:22:23 *surely* nobody needs a 32-bit sdk now May 12 16:23:47 https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1892 May 12 16:50:06 Hello, I build linux distribution for my SAMA5D27 atmel microchip board. I want to connect my board to wifi network instead of using ethernet cable. How can I do that please ? May 12 16:53:38 khem: Is it just the i686 toolchain that failed? The x86_64 one passed? May 12 17:06:11 JPEW: I think so, yes May 12 18:31:16 RP: sent a v5 May 12 18:32:05 I carved out a fix for mingw32 as well and it was pretty much limited to mingw32 I thought it is safe to have it in gcc May 12 18:33:12 RP: the fix for valgrind/aarch64 is in glibc so I dropped the gcc patch for that and instead bumped glibc 2.31 recipe to latest on branch this particular change should be good for dunfell too May 12 18:33:28 Also merged the version mismatch for maintainer entry May 12 18:34:01 RP: hopefully this will fix all the issues we have known thus far May 12 18:34:29 JPEW: yes, so question is do we need to support 32bit windows for SDKs moving forward May 12 18:34:49 given that windows7 is EOL May 12 18:35:54 and moreover should we be spending precious AB cycles on it May 12 18:39:42 i'd say no we don't May 12 18:40:55 I vote to eliminate win 7 support.. May 12 18:50:24 well, there are the older releases if one badly needs win32 May 12 18:50:49 and there are tons of tools May 12 18:50:56 in their eco-system May 12 18:52:02 every time I see precious, I hear gollum’s voice. May 12 18:53:04 zeddii: me too! May 12 18:53:51 ant__: if someone badly needs 32-bit support they can bring it back May 12 18:53:55 its just a matter of what the priorities are May 12 19:11:47 Ya, I think dropping 32-bit is fine May 12 19:12:50 I can't think of any legitimate reason for keeping it around; it hasn't really been any more effort to maintain over the x86_64 SDK previously, but maybe that's finally shifting. May 12 19:46:33 hum there's a vote going on? May 12 19:47:14 Letothe2nd: ? May 12 19:47:27 18:40 < fray> I vote to eliminate win 7 support.. May 12 19:47:40 can I vote for beer and metal? May 12 19:48:12 beer and metal are already required to support win7, no? May 12 19:50:15 despite public expectations I hold no grudge against Microsofts software products. May 12 19:53:28 jonmason: So, how would I go about building optee for testing? May 12 19:54:00 beer in an aluminum can covers both requirements. May 12 19:55:37 paulg: i have to admit that this is technically correct. May 12 19:58:08 JPEW: I don't have a platform that is actively using it. denix might. May 12 20:02:28 jonmason: lots of talk about trusted-fw :) May 12 20:04:29 trust? https://youtu.be/VaYf0OGN68Y May 12 20:04:53 why did I just click Letothe2nd's link? May 12 20:05:03 because. May 12 20:05:04 RP: oh? May 12 20:06:55 jonmason: i have to admit that this specific link was quite "serious" in comparison, though. May 12 20:07:42 Letothe2nd: very 80's hair metal May 12 20:07:44 jonmason: Looks like it might build for qemu (TFA also)... I might add support for that in the recipes by default May 12 20:08:08 JPEW: yes, I've seen that and have it on my never-ending todo list May 12 20:08:52 JPEW: are you okay with me pulling in my TF-A v2.3 recipe? May 12 20:09:03 jonmason: the question of whether its meta-arm or core due to the number of dependencies and some of the challenges of the meta-arm dependencies May 12 20:09:03 jonmason: Ya it's fine May 12 20:09:25 jonmason: Ya I think we should reopen that disucssion also :) May 12 20:09:26 RP: We're trying to fix that now :) May 12 20:09:30 jonmason: as you know for sure how complicated customer care, i should rather suggest: https://youtu.be/WPUJG2jTw9s May 12 20:10:09 jonmason: We were talking about it on the technical call this morning (afternoon?) May 12 20:10:27 jonmason: the worry is an oe-core which requires meta-arm to build any arm platform isn't a good message for OE :/ May 12 20:10:33 dammit, I had a conflict this morning May 12 20:11:03 jonmason: as JPEW said, it came up and was discussed which is why I'm trying to make sure you know that happened! :) May 12 20:11:25 RP: i second that worry hereby. May 12 20:11:39 jonmason: I think the argument could be made that TFA is a lot like u-boot: Most (all?) aarch64 needs it to boot so maybe it belongs in oe-core instead May 12 20:11:44 RP: I completely understand. If it makes sense to move then it should move. The only issue would be when it would move (assuming it is being used in qemu) May 12 20:12:02 meta-arm should just be an architecture layer I think and mostly try to be inert May 12 20:12:11 JPEW: I'm hoping that other things needed by most aarch64 systems will be in meta-arm May 12 20:12:28 currently its leaning towards a BSP layer more May 12 20:12:28 like EDK2 and SCP May 12 20:12:38 jonmason: right, I've not formed a strong opinion on it as yet, I just have concerns May 12 20:12:39 khem: thats due to who we have working on it now May 12 20:12:59 jonmason: yeah, I missed all the morning meetings today due to conflict as well May 12 20:13:13 if we can get a new hire to start and work on it in the next month or so, maybe it can be aswesome May 12 20:13:29 * cough * May 12 20:13:35 heh May 12 20:13:54 as usual, there are coins to be inserted. May 12 20:14:35 jonmason: Ya, I know you are getting the dunfell release ready, so I think that putting the 2.3 there for now is fine, since moving it wouldn't be in the oe-core dunfell release anyway May 12 20:14:55 agreed, dunfell and what happens in master are two different things May 12 20:15:36 we're trailing the YP release due to python2 junk, which should be gone once I push my current HEAD May 12 20:15:56 But looking at what is in meta-arm right now, the only thing you *need* to boot is TFA. Coresight and optee aren't mandatory (at least for non-security applications). Granted, I don't know what the roadmap is May 12 20:15:57 and also in many cases it might make sense to bring things to oe-core to make qemuuarm better or qemuarm64 e.g. grub is not used by all arches but we still keep it in OE-Core likewise we can do that for some components that are common enough for arm platforms usually May 12 20:16:00 jonmason: right, that all looks like a good move May 12 20:17:04 * RP wasn't feeling too good earlier on so isn't entirely sure about anything he said... :/ May 12 20:17:17 to me, the next "must have" is EDK2. Which has been promised by the BSP team but are super slow to deliver (and it a huge PITA due to needing specific toolchain versions) May 12 20:18:09 I'd like for my new hire to work on that not being hot garbage May 12 20:18:29 * RP is happy to forget about edk2 May 12 20:18:55 its all that anyone cares about for aarch64 now, even though I hate it and want it to die May 12 20:19:42 jonmason: for py2 just say that meta-arm needs qtwebengine and we will accept it depend on meta-py2 :) May 12 20:20:48 JPEW: is SCP recipe interesting at all for your layers? May 12 20:21:05 or do you just use vendor binaries May 12 20:21:32 jonmason: if not edk2 then what what do you use for aarch64 as UEFI impl May 12 20:21:54 u-boot can mostly fake it out May 12 20:22:16 and u-boot is done in a sane manner May 12 20:22:51 EDK2 looks like something that was farmed out to the cheapest contracting firm and was paid by LOC May 12 20:23:32 I had to work on it once and hated life the whole time May 12 20:23:50 jonmason: I'm not actually that familiar with the lower levels of ARMv8... whats SCP? May 12 20:24:52 https://github.com/ARM-software/SCP-firmware May 12 20:26:05 each vendor decides what secret sause they don't want to share, and usually its right around the SCP/MCP level May 12 20:26:06 khem: we need chromium! May 12 20:27:06 jonmason: Is that usually where there is a pre-compiled binary that gets shoved in somewhere in ATF? May 12 20:27:46 yes May 12 20:28:15 jonmason: Not sure. I honestly haven't looked at what the ATF builds for my SoCs are doing.... they just sort of work :) May 12 20:28:54 JPEW: since ATF is BSD licensed, few vendors give it out anyway. If Rockchip does, that I'm actually highly impressed May 12 20:28:55 Except for the RK3399, I know that one has an M0 that it uses for something, but I think thats already built from source by ATF because you have to provide the arm-none-eabi-gcc for it to build May 12 20:29:33 JPEW: are you using an embedded toolchain too? May 12 20:30:34 that's next on my todo list May 12 20:30:51 jonmason: Not quite sure what you mean. For RK3399 we do: http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.3.bb#n11 and then http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-devtools/gcc-arm-none-eabi/gcc-arm-none-eabi-native_9-2019-q4-major.bb May 12 20:31:18 But thats not ideal. We'd rather build arm-none-eabi-gcc from source with either multilib or multiconfig May 12 20:31:31 Just haven't gotten there yet :) May 12 20:32:21 JPEW: this is litteraly something I'm planning on working on today. I'll talk to you about it once I educate myself, since I think we will be doing similar things May 12 20:32:47 Well, builing optee-os and TFA for qemuarm64 was surprisingly easy. No idea if they boot :) May 12 20:33:30 so why do we need binary toolchains, cant we do something like gcc --freestanding and keep using the internal toolchain May 12 20:34:13 arm is giving people bin toolchains. so I'd like to support it. ya know, with out actually supporting it May 12 20:34:32 khem: Not in the RK3399 case because the main SoC is AArch64 and the M0 is AArch32 May 12 20:35:04 I assume the m0 is running an RTOS and doing mailbox stuff May 12 20:35:06 oh so you need multiconfig May 12 20:35:21 that should work well these days May 12 20:36:08 khem: Ya, I tried a few things, but got busy and didn't have time to sort it out so the binary toolchain stuck (for now) May 12 20:36:22 Like I said, I want to figure out some way to do it May 12 20:36:29 but using binary toolchain is easier option I guess until arm officially adopts mutliconfig as way to do it in future, maybe jonmason your new hire can help with that May 12 20:36:30 JPEW: Ok, your patches do not apply now that I've thoroughly messed with tf-a recipes. Could I respectifully ask you to rebase and resubmit? May 12 20:36:48 jonmason: Sure! May 12 20:37:13 khem: my new hire has told me how much he LOVES binary toolchains. And I'm going to see if I can get him to work on them exclusively May 12 20:37:43 thats great to hear May 12 20:38:27 I think I understand from ARMs POV they just build one toolchain once and solve all sort of usecases May 12 20:39:33 jonmason: I don't see the commits in the meta-arm git tree yet for me to rebase on top of May 12 20:40:03 he said to rebase on top of his HEAD :) May 12 20:40:04 I pushed it like 10 mins ago May 12 20:40:32 jonmason: The 2.3 upgrade? May 12 20:40:43 weird, not showing up May 12 20:42:00 ok, I'm stupid. Fixed now May 12 20:46:05 jonmason: supporting binary toolchains - you mean external-arm? yeah, just don't break it - it was periodically broken at the old place... May 12 20:46:49 denix: I won't break it personally ;-) So if it works now, then we are gold May 12 20:47:26 JPEW: you need multiconfig for aarch64+armv7 builds, right? you can check meta-ti to see how I did it. may not be ideal, but works with binary toolchains like external-arm as well as building both toolcains from sources May 12 20:47:51 denix: Cool, I'll take a look May 12 20:48:56 JPEW: and as khem said, you can simply pass --freestanding parameter to linux toolchain. I was thinking adding TCLIBC=baremetal to my multiconfigs, but didn't need to May 12 20:49:29 denix: Is there an representative recipe that would be good to look at? May 12 20:52:08 JPEW: well, our u-boot builds for both cores - cortex-r5f and cortex-a72/53. you can check that single recipe. there's ti-sci-fw that's only for cortex-r5f May 12 20:55:41 JPEW: the only remaining issue I have is to package some specific pieces into main rootfs/sdk from other multiconfig targets - i.e. do_deploy works, but I also need do_install May 12 20:56:21 JPEW: we disucssed it before - i.e. I need both aarch64 and armv7 toolchains in sdk May 12 20:57:08 JPEW: I was following RP's suggestions, but so far no luck May 12 20:57:28 denix: Right. So in the u-boot recipe, is it that it can build for either machine, or uses both toolchains at once. I'm not seeing how the later is done in the recipe...? May 12 20:58:49 JPEW: either machine - different defconfigs. if you need to build both at the same time using separate toolchains, you'd need to separate them into individual steps/recipes May 12 20:59:39 denix: Ah OK! Thats the difference, the ATF for RK3399 isn't set up to build split like that; they just expect to be able to call "arm-none-eabi-gcc" May 12 20:59:59 I don't see any other way - they have separate WORKDIR. the only way to "combine" them is via DEPLOYDIR May 12 21:01:02 denix: Right May 12 21:01:15 JPEW: ^^^ by they I mean multiconfig versions of recipes, even the same recipe - one will be in aarch64 sysroot, the other is in armv7 sysroot May 12 21:02:00 hello May 12 21:04:28 I was wondering if you are seeing an strange bug I am experience. When I build an image using a wks.in file I get as a result an image does is non functional because all the files within the image have the uid/gid of the user that was used to build the image, instead of the right ones. if I copy the wks.in to a wks and remove the reference to the May 12 21:04:28 variable I am using ${IMAGE_ROOTFS}, do bitbake -c cleanall core-image-minimal and then bitbake -c build core-image-minimal the generated image has the files uid/gid correctly set and it works fine May 12 21:05:17 dggonz: wic doesn't run under pseudo, so it can't "see" the permissions assigned to files May 12 21:05:59 dggonz: At least AFAIK May 12 21:06:07 wic has its own understanding of the rootfs, you shouldn't be poking at IMAGE_ROOTFS Directly, afaik.. May 12 21:06:39 ok, let me explain what I was trying to solve, maybe there is another way around May 12 21:06:55 I have a directory which I want to place in a different partition so I am doing: May 12 21:07:20 --exclude-path=etc/certs/ on the rootfs May 12 21:07:30 and then in the partition I am trying to generate: May 12 21:07:35 part /etc/certs --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/etc/certs --ondisk mmbclk0 --fstype=ext4 --label certs --align 1024 --fixed-size 10M May 12 21:08:12 the actual files are there, but all the uid/gid are messed up on the resulting image May 12 21:08:23 not just those of the /etc/certs partition May 12 21:08:45 this is the actual rootfs partition line for reference: May 12 21:08:49 part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfsA --align 1024 --fixed-size 370M --exclude-path=etc/certs/ May 12 21:12:52 jonmason: Patches sent. Works for me on RK3399 \o/ May 12 21:16:03 JPEW: thanks. Building now, while I walk the dog May 12 21:16:53 denix: the other approach might be to build the sdks separately, then have one target in the multiconfig which merges them together. You may need to teach the SDK code to generate an intermediate output you can merge May 12 21:20:08 * JPEW kinda wishes "-9n" was the default for gzip May 12 21:31:02 RP: ok, I guess I can try merging separate sdks... May 12 22:11:35 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1895 has failures in step1b :( May 12 22:11:42 JPEW: ^^^ May 12 23:02:03 RP:these are new errors glib-2.64.2/glib/gstrfuncs.c:477:10: error: implicit declaration of function 'stpcpy' [-Werror=implicit-function-declaration] May 12 23:02:21 glib-2.64.2/glib/gslice.c:1411:9: error: implicit declaration of function 'posix_memalign' [-Werror=implicit-function-declaration] May 12 23:04:38 ../wayland-1.18.0/src/scanner.c:995:4: warning: incompatible implicit declaration of built-in function 'strndup' May 12 23:05:25 so I guess we can fix it at package level May 12 23:20:41 RP: send a backport to fix glib-2.0 issue May 12 23:20:46 looking into wayland May 12 23:25:04 all meson regressions it seems May 12 23:46:49 RP: sent one for wayland too, have fun May 13 00:58:19 khem: Ah, I thought I had that patch upstreamed, but apparently I forgot. Thanks May 13 01:09:35 Hah! Got qemu to boot ATF + optee May 13 01:10:03 Not with the linux-yocto kernel though. Must be configured differently **** ENDING LOGGING AT Wed May 13 02:59:58 2020