**** BEGIN LOGGING AT Fri Jan 17 02:59:57 2020 Jan 17 07:22:56 Any ideas why on another computer I get during do_compile "/bin/bash: ./start: cannot execute binary file: Exec format error" and on another everything works? Jan 17 07:24:41 perhaps start is a binary for different machine Jan 17 07:25:08 what does it show if you run `file ./start` cmd Jan 17 07:25:36 it is compiled by the recipe and supposedly we have same host environments and working on same code Jan 17 07:26:18 i mean it is compiled by the toolchain of that program that the recipe is baking Jan 17 07:27:16 i dont have that file, probably it gets removed when everything is done Jan 17 07:27:26 ok yocto does cross build so technically running the generated program on build host is not right and if it worked it was pure luck Jan 17 07:30:35 if it says "/bin/bash" it means it runs on host? How should it say if it was correct? Jan 17 08:00:04 how can I change autotools based recipe that it would stop searching for .so files in my host /lib and look instead from recipe sysroot Jan 17 08:00:41 stuom1: probably by looking at configure.ac and Makefile.am, there might be somthing hardcoded. Jan 17 09:07:05 "QA Issua: package contains bad RPATH" when I added -rpath to LDFLAGS, what is this? Jan 17 09:08:05 (path exists, so at least that is not bad...) Jan 17 09:08:28 probably bad means "host contaminated" in this context, but just guessing. Jan 17 09:17:04 stuom1: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#qa-issue-rpaths Jan 17 09:19:14 the build system was looking for my .so files on host, so I changed rpath to look them from sysroot, where they actually are Jan 17 09:19:23 but now that is wrong too *cries* Jan 17 09:20:06 but at least compilation succeeds now, so maybe that's something Jan 17 09:20:39 stuom1: why is it even manually looking for things, instead of relying on pkg-config respectively the known good cross compile aware build system facilites? Jan 17 09:22:56 i dont know how to answer that question, but it is using autotools and the package has not been designed to be cross-compiled, it seems Jan 17 09:25:29 *bingo* Jan 17 09:26:23 so the proper approach is actually fixing the the package instead of doing obscure dances in the recipe. Jan 17 09:27:39 I have already successfully cross-compiled it by copy-pasting the .so files to my host where it looks them from, but that's ugly Jan 17 09:28:03 now i got it too look from correct place but i get this QA error Jan 17 09:28:04 thats not ugly, thats stupid Jan 17 09:28:36 because: totally non-reproductible, you won't be able to even rebuild it yourself 3 weeks from now Jan 17 09:28:58 hence my efforts to fix it now :D Jan 17 09:29:01 go fix stuff instead of throwing bandaids. Jan 17 09:29:26 but the place to fix it is the library lookup mechanisms in the build system (you said autotools), not the recipe Jan 17 09:30:15 does it matter if i change LDFLAGS in recipe or in configure/makefile Jan 17 09:30:50 of course it does Jan 17 09:31:22 "fix" in recipe means: "this package does stupid stuff but i'd rather work around it instead of setting it straight" Jan 17 09:31:39 fix in package means: "i properly handled this" Jan 17 09:32:24 i dont have time to start developing someone else's stuff now, just need to get it work :D Jan 17 09:32:47 the only exception is if you don't have access to the package, but in this case it would still be better to carry it as patch next to the recipe, instead of doing tricks inside Jan 17 09:33:16 stuom1: i have heard that "reasoning" very often by now, here. fact: you will burn more time by "making it work" Jan 17 09:33:26 but hey, go ahead. its your project. Jan 17 09:34:26 (hint: "i can compile this here" != "it works") Jan 17 09:36:19 well the end product on target works also Jan 17 09:38:37 stuom1: "works on my machine" © is the first page of all horror tales Jan 17 09:39:00 stuom1: it is actually not uncommon to patch makefiles, autotools, etc.. Jan 17 09:39:40 By doing so, you expand your knowledge in the build system and learn a bit more about the project. In the end it's your call, but that's what we strongly advise Jan 17 09:39:59 i refuse to call anything "working" which cannot be reproduced completely by kicking off a single line on an otherwise unprepared build system. (e.g. is CI-clean) Jan 17 09:40:02 I've already patched to configure.ac and sure, I can add this LDFLAGS there too but I still the the QA issue Jan 17 09:42:37 stuom1: again, i don't think the LDFLAGS per se are the problem. its the mechanisms used to obtain them. Jan 17 09:48:28 I added --enable-new-dtags to my -rpath and now QA errors are gone Jan 17 09:49:22 I dont know, if everything works, seems clean enough solution to me :D Jan 17 09:51:16 stuom1: When fixing the consequences and not the cause, you're just setting a timer on a bomb. Or in another word, hiding the dirt under the carpet :) Jan 17 09:51:37 *shrug* go ahead. Jan 17 09:53:19 *in other words*. TGIF. Jan 17 09:54:34 * LetoThe2nd needs to prepare the next live coding session. meh. Jan 17 09:55:39 i will come to your twitch chat to give great rpath suggestions to people Kappa Jan 17 09:55:58 go ahead :) Jan 17 09:58:02 For those not around last night, I'd like to try and collect together a list of companies/products/projects using Yocto. I'm doing that on the wiki here: https://wiki.yoctoproject.org/wiki/Project_Users Jan 17 09:58:09 Any help appreciated (its a wiki!) Jan 17 09:59:20 RP: yeah you seem to have a strange rhythm these days :) Jan 17 10:00:02 LetoThe2nd: ? Jan 17 10:00:29 RP: at least for my employer speaking: its no secret that we are involved, obviously, but we do not want it publicly listed in such a form. sorry. Jan 17 10:00:50 RP: (you do stuff late at night, thats at least my impression) Jan 17 10:00:57 LetoThe2nd: ah, yes, I do :/ Jan 17 10:01:19 LetoThe2nd: np, I appreciate some can't be listed. I'd just like to list the ones we can Jan 17 10:02:39 RP: its a common problem im industry-focused OSS projects. Jan 17 10:03:53 i also cannot tell after all the hacks I've admitted using, at least LetoThe2nd would never buy from us again Jan 17 10:04:34 Remember the challenge is that if we can't show anyone using the project, it makes it hard to justify its existence or why others should support it Jan 17 10:05:29 stuom1: nah, thats not the problem. actually its a good way of showing yourself if you are selling boards with yocto support Jan 17 10:06:01 (and yes, despite my clear words here, i am very well aware of the fact that hacks are an unavoidable way of real life) Jan 17 10:06:45 RP: you can happily list me as public enthusiast, volunteer supporter, jester, whatever. :) Jan 17 10:07:54 as live coder for hire, weirdo trainer, whatever suits your politics. i just cannot allow "company x is using yocto" Jan 17 10:09:00 LetoThe2nd: I think we have that one covered :) Jan 17 10:09:23 LetoThe2nd: Anyhow, as I said, lets see if we can collect the ones we actually can as there are some Jan 17 10:09:33 RP: just making the offers i can :) Jan 17 10:17:29 RP: dumb question but isn't it a good start to grep for mails of contributors? I'm sure at least a decent amount of people use their profesionnal mail address to contribute? Jan 17 10:18:23 RP: each release of the linux kernel, there's a top 20 of companies contributing and individuals that's being created by some online media. Jan 17 10:21:09 qschulz: but usually those are asked before things being published. and for bigger contributing companies, its 1) obvious anyways 2) i'm pretty sure greg k-h has a mail from their legal somewhere saying "its ok that we're named" Jan 17 10:22:35 qschulz: Yes, I do have such a list. Its hard to tell if that does mean the company really uses it or is just experimenting Jan 17 10:22:48 qschulz: we may get to that eventually, we'll see Jan 17 10:26:22 LetoThe2nd: well, it is public anyway. Don't say it's used by this company but that company contributes to it. I actually think that might encourage company to contribute? But a mix of both lists could be nice. Jan 17 10:27:53 qschulz: the different is between "can be found out by somebody who invests some time and thought" and "is advertised on the front page" Jan 17 10:31:08 LetoThe2nd: I understand. Legally I guess it depends of the country? If I'm not mistaken, e.g. in France, it's fine to take pictures of people in the streets if they are not the main object of the picture (e.g. crowd photo, landmark photo, etc.) and publish them without explicit consent. Jan 17 10:31:14 LetoThe2nd: but lawyer stuff :) Jan 17 10:31:38 (and I'm not sure we want to scare potential contributing companies out of the project) Jan 17 10:34:45 New news from stackoverflow: Yocto Image file size reduces after adding a particular package Jan 17 12:11:36 how can I change MACHINE type in image recipe? setting MACHINE = "xxx" doesnt seem to work Jan 17 12:11:46 stuom1: you cannot. simple as is. Jan 17 12:12:14 stuom1: https://twitter.com/YoctoThe/status/1217166071519744000 Jan 17 12:12:31 alright, what would be best way to make another image for qemuarm? Jan 17 12:12:42 ? Jan 17 12:13:53 I want to make 2 same images, one for target and one for qemu Jan 17 12:14:02 then you need two builds. Jan 17 12:14:28 you can semi-automate it with a multiconfig build, but under the its just like this: 2 seperate builds. Jan 17 12:15:52 or set the buld off with 'MACHINE=xyz bitbake myimage && MACHINE=qemuarm bitbake myimage' - yet thats all just variations. Jan 17 12:17:07 ok, that seems good, thanks! Jan 17 13:10:37 Hi, I'm trying to move an old kernel to a newer yocto version, I can build it with these modifications to the recipe https://pastebin.com/iT4J5M0Z But each time i re-build it I get the following error : imx6qsabresd/kernel-source is not clean, please run 'make mrproper' (even if i run -c clean -c cleanssate) If i do what it says(run mrproper) it Jan 17 13:10:37 runs but I still think something is wrong in my configuration, thx Jan 17 13:11:57 ifan: that just looks outright wrong. Jan 17 13:12:15 yocto has built-in support for the handling of defconfigs Jan 17 13:13:19 LetoThe2nd: you mean the entire function? Jan 17 13:13:26 ifan: yup Jan 17 13:13:27 ifan: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/tree/arch/arm/configs/imx_v6_v7_defconfig there's already a defconfig in the kernel. You just have to tell the linux-yocto recipe (assuming that's what you mean with "a newer yocto version)" Jan 17 13:14:24 LetoThe2nd: both linux-imx_3.14.28.bb and linux-fslc-imx have those Jan 17 13:14:51 ifan: vendor BSP is not a good reference most of the time :) Jan 17 13:15:04 LetThe2nd: I just changed it so it could work with a newer version, I can try remove it and see what happens Jan 17 13:15:15 ifan: if you want to supply your own defconfig, it should be passed in through SRC_URI and then it can be used automagically. if you want to use an in-tree defconfig, listen to qschulz Jan 17 13:15:26 ifan: and i hope you're not actually investing time in a 3.14 kernel Jan 17 13:15:46 :LetoThe2nd its a long story :) Jan 17 13:16:14 ifan: 3.14 won't even build with anything newer than probably krogoth, unless you apply black magic Jan 17 13:16:34 and if you can do that, then you don't need our help anyways. Jan 17 13:17:51 the task is buggy anyways, as the defconfigs should be expanded, not copied. Jan 17 13:18:40 LetoThe2nd: I'm trying to move to krogoth, once I got that working I will try to apply the board specific files. If i can get that to work I will try to move it to a newer kernel Jan 17 13:19:21 ? Jan 17 13:19:27 that sounds very confused. Jan 17 13:19:59 from *where* are you coming? Jan 17 13:20:16 It's hard to explain since I dont really understand what I'm doing :) Jan 17 13:21:03 then you should maybe stop investing time to hack ancient software into ancient build systems and rather try to understand what you're doing :) Jan 17 13:21:45 The manufacturer make u-boot and kernel for 3.14.28, I want to include their stuff into Yocto and then upgrade everything Jan 17 13:22:05 if that makes sense, but first i wanted to try build the kernel for a standard machine Jan 17 13:22:07 will not work Jan 17 13:22:41 integrating or upgrading? Jan 17 13:22:47 ifan: FYI, I was HORRIFIED that we were still using krogoth a few months ago. Now we're on thud and hopefully I can push a little bit for newer releases. But upgrading or supporting krogoth now is non-sense especially with all the CVEs being patched since then. Jan 17 13:23:20 ifan: wait a second, on which SoC is your board based? Jan 17 13:23:36 because imx SoC are very well supported upstream Jan 17 13:23:47 ifan: u-boot, kernel and gcc and somewhat tied together. so once you got all building in krogoth, you can feel proud for 10 minutes, and then throw way everything just to start anew on a recent release. Jan 17 13:23:50 imx6 Jan 17 13:24:44 ifan: the imx6 support in upstream is extremely good, so chances are that (unless you vendor gave you the utmost crappy hw), you will be able to boot surrent mainly with no more than just a custom device tree. Jan 17 13:25:08 and for just getting booted, probably not even a custom dt is needed. Jan 17 13:26:36 imx sabre support seems to be absolutely up to date: http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine Jan 17 13:27:16 ifan: even more so: http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine/imx6qdlsabresd.conf#n7 Jan 17 13:27:19 So I should drop everything I'm doing and get on a newer branch Jan 17 13:28:08 ifan: imx6 is really well supported since a a few releases (I had to bootstrap one on 4.14 like two years ago, didn't ask much more than that) Jan 17 13:28:24 ifan: if i'm not totally mistaken, the file i just linked to says basically that imx6qsabresd is officially supported in the current meta-freescale layer. no ancient crap involved. Jan 17 13:29:14 I am SO thankful for this information guys Jan 17 13:29:17 ifan: so, many hours did we just save you? where can we send our invoice? Jan 17 13:29:34 qschulz: 50/50, mkay? Jan 17 13:29:35 no more looking in mail threads from 2014 :] Jan 17 13:29:45 LetoThe2nd: HALF A BEER? Jan 17 13:29:59 qschulz: depends on the size of the beer. Jan 17 13:30:23 probably a few months Jan 17 13:30:46 ifan: what's your board? custom? Jan 17 13:33:01 Its from a company named Avalue, ACP-IMX6 Jan 17 13:33:50 ACP-IMX6POS* Jan 17 13:35:00 RP: I just finished all my local testing on 5.4, if I sent some builds to the AB, would that cause issues with higher priority builds ? Jan 17 13:35:12 sweet, "Cash Drawer interface (RJ11)" Jan 17 13:35:13 New news from stackoverflow: Debug symbols not stripped from resulting binaries in Yocto Jan 17 13:35:36 ifan: seriously, their manual is popcorn gold. Jan 17 13:35:42 also, "OS Information: Yocto 1.5.1" Jan 17 13:36:04 we support building on 12.04. do: git clone guest@202.55.227.57:freescale/imx6/Android.git -b 4.4.2-pos Jan 17 13:36:16 I do like the DAC, though, I love Wolfson stuff. Jan 17 13:36:37 anyways, probably just a classic sabre with minor dt adjustments. Jan 17 13:36:38 not sure I understand what popcorn gold means Jan 17 13:36:47 but don you guys trashtalk my board :< Jan 17 13:37:01 zeddii: no problem with other builds, we're quiet atm. We do have the maintenance window in around 5 hours though Jan 17 13:37:37 ifan: why not? :P Jan 17 13:38:07 she is a beauty ;) Jan 17 13:38:25 "git checkout from this magic ip, pw right next to it in the pdf" is not exactly confidence inspiring :) Jan 17 13:38:48 RP: ok. cool. Will try one before that, and then some after. I have to get a bit organized on the branch to push and do some version overrides (since I'm doing them in local.conf here). Jan 17 13:38:50 anyways, happy weekend everybody! Jan 17 13:39:10 u2! Jan 17 13:39:14 and thanks again Jan 17 13:39:24 Yeah, she's a worthy POS....system. ;-) Point of Sale being abbreviated POS always amused me, though. Jan 17 13:39:25 But I did extra testing on this one. All arches + two c-libraries for all of sato,minimal and kernel-dev. I *know* that systemtap won't get me this time :D Jan 17 13:39:40 zeddii: :D Jan 17 13:39:48 Have a good weekend, LetoThe2nd. Jan 17 13:40:30 LetoThe2nd: o/ Jan 17 13:42:55 ifan: yeah it shouldn't be too hard, try to find something based on imx6qdl.dtsi or imx6q.dtsi. Apparently ift's a Micrel KSZ9031 for the Ethernet PHY, that's supported upstream. You even have upstream support for the GPU. Honestly, it might be even worth spending a few weeks/months or consulting bucks on using upstream kernel directly. Jan 17 13:43:42 ifan: I would follow LetoThe2nd 's advice by starting from a board which isn't toofar in specs. Then most likely some different pinmuxing, clocks, etc. But nothing unfixable Jan 17 13:45:55 (and by upstream support for the GPU I mean actual OSS driver) Jan 17 13:49:06 qshulz: I will try that, thank you very much for all the info :> Jan 17 13:56:42 LetoThe2nd informed me it's possible to build another image by "MACHINE="qemuarm" bitbake myimage". This works, but I also want to add DISTRO= variable there but that doesnt work anymore. It only takes one variable and disregards the second Jan 17 13:57:45 Is there some special way to do it with bitbake? Normally (outside bitbaking) you can put as many environment variables as you want Jan 17 14:00:44 stuom1: that should work actually I think Jan 17 14:00:51 Can you give use the line your using? Jan 17 14:01:31 MACHINE="qemuarm" DISTRO="tdx-xwayland" bitbake myimage Jan 17 14:01:48 but distro doesnt change. If I put just DISTRO, it works Jan 17 14:05:16 stuom1: interesting for sure. Well usually the DISTRO ?= is set in conf/local.conf. Jan 17 14:05:59 yes i probably need to setup some multiconfig as Leto suggested but this was just for trying now fast Jan 17 14:06:00 stuom1: you can try do debug this thing by running MACHINE="qemuarm" DISTRO="tdx-xwayland" bitbake myimage -e | less and check for a line starting with DISTRO=. Then you look up and you'll see what's overriding what or setting the variable to some value Jan 17 14:09:21 ok, future me will handle all this on Monday Jan 17 14:10:25 bitbake is now busy and doesnt let me try anything :P Jan 17 14:12:07 stuom1: you can have two instances running if you copy paste your dev environment somewhere else :) Jan 17 14:15:30 *hmmm* Jan 17 14:16:14 Is it common to use yocto-check-layer? Jan 17 14:16:17 I need to consider that but I rarely bake something that takes so long I cannot wait Jan 17 14:17:27 stuom1: $ ls -d build-*|wc -l Jan 17 14:17:27 13 Jan 17 14:17:54 just remember to set tmpdir to something different :) Jan 17 14:21:05 you have 13 build environments? Jan 17 14:21:18 indeed Jan 17 14:21:22 quite a collector Jan 17 14:22:00 some are just alternative configurations like "with musl" or "with mingw sdk", others are just identical configurations for parallel builds Jan 17 14:23:36 the reason I ask is that meta-virtualization, which I guess is a pretty common layer, is returning som issues. (Nothing provide ostree for cri-o_git.bb) Jan 17 14:24:44 And when running on arm64 - nothing provide syslinux for ipxe_git.bb. Jan 17 14:25:45 frosteyes: former sounds like a missing layer dependency. ostree is in meta-oe Jan 17 14:27:01 Still running in 2.6, so it might be an old issue. Jan 17 14:27:25 the syslinux thing is fair: syslinux only works on IA, so a dependency should be conditional on architecture Jan 17 14:27:41 I think so to. Jan 17 14:28:59 So it was more of a "hey, yes yocto-check-layer should be used, and it is just a matter of being better to use it" or more of. It is not very used, so don't expect it to work.. Jan 17 14:29:48 a mainstream layer that doesn't pass check-layer should be fixed, yes Jan 17 15:05:28 halstead: hi, just here to report two things https://wiki.yoctoproject.org uses weak encryption according to FF: Broken Encryption (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 256 bit keys, TLS 1.0) Jan 17 15:06:26 halstead: I don't know if it's your "job" or not but https://wiki.yoctoproject.org/wiki/Special:RequestAccount: "Also, your password will be e-mailed to you when your account is created. " I hope not :) I guess we are talking about a temporary password and that we are not being sent our password plaintext :) Jan 17 15:07:33 BTW, I registered with my personal mail and not company one on the wiki, so no worries if the name is noit matching the email address you usually receive mails from on the ML :) (to anyone accepting/refusing wiki users) Jan 17 15:16:35 Hi everyone! Should I put every custom configuration (e.g. nginx site configuration) in a separate layer? Jan 17 15:16:52 kriive: separate from what? Jan 17 15:19:00 In case of nginx I can't put the conf in the same layer (because I don't control the repo), but in case of a package (or a number of them) of mine that requires a configuration, should I put configs in a separate layer (i.e. different from the layers containing the recipi that compiles and installs the actual binary)? Jan 17 15:21:16 Sorry for not being too clear, I'm still learning it and many concepts are a little foggy Jan 17 15:23:47 kriive: if it's related to some distro configuration, then I'd say a layer for the distro maybe? Otherwise, I'd say it's fine to put the conf in your layer I guess. It's foggy to me as well. One layer for the BSP support and one for everything else is usually what I see/think Jan 17 16:10:27 anyone is experiencing an extremely high memory consumption when building with zeus, particularly the meta-toolchain? Jan 17 16:12:29 that never happened before, so I was wondering why Jan 17 16:13:25 * mckoan tries reducing BB_NUMBER_THREADS Jan 17 16:30:09 mckoan: what is using the memory? Jan 17 16:31:37 RP: mainly xz Jan 17 16:32:04 mckoan: right, we're kind of aware it can do this :/ Jan 17 16:32:58 RP: I have 'only' 16GB Jan 17 16:34:44 mckoan: have a look at XZ_DEFAULTS in bitbake.conf Jan 17 16:34:54 RP: and nativesdk-clang Jan 17 16:35:21 mckoan: it depends which xz it is mind, the one in rpm is probably passed parameters through rpmbuild Jan 17 17:13:19 khem: finally binutils doing what we need Jan 17 17:13:23 moto-timo: ^^^ Jan 17 17:17:01 RP: cool what fix did you choose Jan 17 17:18:13 mckoan: XZ_DEFAULTS = "--threads=n" will limit it Jan 17 17:18:33 where n is a number according to your CPU muscle Jan 17 17:18:34 khem: thanks, I'll give it a try Jan 17 17:19:06 mckoan: and also install pigz Jan 17 17:19:34 clang packaging gets a lot of help with pigz Jan 17 17:20:17 khem: pigz is already the newest version (2.4-1) Jan 17 17:20:38 k Jan 17 17:26:31 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/pyro Jan 17 17:26:45 khem: doesn't work yet but its progress, failures are later Jan 17 17:31:14 Hi all, I created a Yocto Image for Raspberry PI 3 with RT Linux kernel and created a base image. Everything is fine till I wish to expand the SD Card. When I delete the 2nd partition and create a new one I get a `resource is busy IOCTL` warning and there is no `resize2fs` binary in the image. What is it that I am doing wrong here? Jan 17 17:37:09 khem: now we have buildtools and uninative clashing head on :/ Jan 17 17:38:55 khem: I'll disable uninative since it shouldn't be needed here Jan 17 18:00:52 khem: far better, completed! Thanks! Jan 17 18:03:03 khem, moto-timo: mail on the list about what I managed Jan 17 18:03:50 khem: is the glibc ready to go if it passes? Jan 17 18:04:36 have a nice weekend Jan 17 18:05:58 RP: yes and I will send a SRCREV bump once the final 2.31 is released Jan 17 18:06:12 New news from stackoverflow: Manually building a Kernel source from Yocto build Jan 17 18:06:14 RP: I want to figure out wider issues Jan 17 18:06:19 if any Jan 17 18:06:23 earlier Jan 17 18:06:29 rather than later Jan 17 18:14:27 khem: sounds wise :) Jan 17 18:14:55 khem: I don't think my binutils hack is too bad, no worse than our gcc patching really... Jan 17 18:15:11 * RP -> food Jan 17 18:41:47 RP: I think it does address a problem where people are using a distro for wide range of yocto releases Jan 17 18:42:03 but agains containers are cooler :) Jan 17 18:43:09 RP: oe-core does not use PIE/PIC by default that unveiled the issue in prelink that happened yesterday Jan 17 18:43:43 I am glad that there was a test on AB to catch it Jan 17 18:54:11 khem: containers are cooler, this fixes the autobuilder challenge though Jan 17 18:54:32 khem: we should probably create a specific test case for that Jan 17 18:58:51 Agreed Jan 17 19:02:40 Containers are the shiney new thing! Jan 17 19:06:01 Crofton|road: actually crates are even shinier :) Jan 17 19:07:05 oh this python2 removal needs to be in meta-py2 before its gone from core, Jan 17 19:08:43 * khem rebases it out of yoe/mut Jan 17 19:17:34 khem: ha, yes, i haven't sent the addition yet Jan 17 20:00:08 what about the python-* removals which were merged before zeus was released? should they be added to meta-python2? Jan 17 20:18:46 JaMa: they should have been added to meta-python, so will already be in meta-python2 Jan 17 20:30:48 ooh, removing python2 from oe-core sounds awesome Jan 17 20:36:44 New news from stackoverflow: Use a yocto layer's recipe or class without inheriting all bbappends Jan 17 20:36:49 kergoth: yeah it will be a good PR for 3.1 release as well Jan 17 21:10:38 Can I do something like file://*.patch;patch=1 as part of a SRC_URI in order for bitbake to pull in all of the patch files (which may be different based on machine) and apply them? Jan 17 21:11:24 fullstop: nope Jan 17 21:11:43 Hey! You're supposed to be enjoying your weekend! Jan 17 21:13:08 okay.. can I reference SRC_URI as a variable when using overrides? Jan 17 21:14:13 something like SRC_URI_jetson-nano = "${SRC_URI} file://blabblah" Jan 17 21:16:07 nope, recursion death Jan 17 21:17:17 SRC_URI_append_jetson-nano will do the same without death Jan 17 21:17:41 That's what I was looking for.. _append_ Jan 17 21:17:46 thanks, JaMa Jan 17 21:19:30 That worked perfectly. Jan 17 22:22:49 zeddii: I replied to mail, sorry, it is AB config Jan 17 22:25:23 zeddii, for $20 he will fix it ; ) Jan 17 22:38:36 armpit: er, I'd pay $20 for someone to fix this one! :) Jan 17 22:38:46 armpit: long standing AB issue :/ Jan 17 23:05:46 ahah. thanks Jan 17 23:06:01 I see some other similar error, but most everything seems to be building. Jan 17 23:06:05 fingers crossed :D Jan 17 23:13:33 zeddii: I have created a defconfig for ppc64le, is it possible for you to add it to linux-yocto Jan 17 23:14:51 I can use it to create a BSP fragment. sure. Jan 17 23:30:23 zeddii: the other similar errors may be real. Its only step2d of quick itself (or full) that show this Jan 17 23:37:17 zeddii: the clue btw is in its configuration Jan 17 23:37:17 zeddii: ok. I need to first make OpenFirmware understand it and load it properly Jan 17 23:39:30 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/882/steps/10/logs/stdio - it sets PREMIRRORS = "" but I don't remember how upstream gets disabled there :/ Jan 17 23:40:06 zeddii: oh, its running oe-selftest -r buildoptions.SourceMirroring.test_yocto_source_mirror' Jan 17 23:40:25 zeddii: so not a normal build... Jan 17 23:40:40 * RP -> Zzz **** ENDING LOGGING AT Sat Jan 18 02:59:59 2020