**** BEGIN LOGGING AT Mon Jun 08 02:59:58 2020 Jun 08 06:47:54 good morning Jun 08 06:49:01 mckoan: howdy Jun 08 08:00:35 I am trying to build an image for rpi3. It builds successfully but even I wrote IMAGE_FSTYPE += "squashfs" to conf/local.conf poky doesn't generate squashfs rootfs. Any idea why ? Jun 08 08:00:52 using sumo branch btw Jun 08 08:05:22 ilkmc2r: a) without a proper error, message, not really b) the variable is calles IMAGE_FSTYPES https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_FSTYPES c) sumo is beyond end of life, time to update. Jun 08 08:06:59 Letothe2nd, ty very much Jun 08 08:07:19 such a foolish mistake Jun 08 08:07:30 '=( Jun 08 08:07:56 bitbake -e is your friend Jun 08 08:17:15 hello, I am using local machine where it exists my SDK toolchain in order to cross compile applications for ARM target platform. I need to use Mono framework to cross compile C# .NET core code Jun 08 08:17:31 can I add Mono framework to the SDK ? Jun 08 08:18:02 Guest330: yes you can, and no, it will not integrate as nicely as you maybe expect. Jun 08 08:18:49 Letothe2nd what do you mean ? Jun 08 08:19:57 Guest330: I mean that you can add the mono toolchain to the SDK, and that it will not "magically" crosscompile like the C/C++ toolchain does, if your build system is properly set up. Jun 08 08:22:36 Letothe2nd it's not maintained or what ? Jun 08 08:23:24 and what is the other solution to run .NET core on ARM using yocto ? Jun 08 08:23:52 Guest330: no, its just that mono does not follow the generic build procedures as far as I know. i assume you can make it work, but its not a "hey include and be done" probably. Jun 08 08:24:25 Guest330: well isn't the sales promise of .net to be platform independent so you can "compile" anywhere? Jun 08 08:26:36 Letothe2nd than I will not find a problem when I run my code on ARM if I compile it on intel Jun 08 08:27:03 without the need to have .NET core on ARM or add it to my linux image Jun 08 08:27:30 that doesn't make sense to me. Jun 08 08:28:18 i always thought, the promise to .net/mono is that you can run it regardless of the platform, as long as the runtime is there. or am i mistaken? Jun 08 08:29:49 well I heard about " self contained " and " runtime dependent " .. Jun 08 08:30:05 isnt that just what i said? Jun 08 08:30:17 yes Jun 08 08:31:26 what i'm trying to say is this: the SDK is focused on classic cross-compilation development. hence, if used correctly, you can easily compile your packages just by sourcing the setup script that comes with it. Jun 08 08:32:14 as mono almost certainly does not care for things like CC, i just *GUESS* that it will not be that easy. but - technically you should be able to include a mono toolchain in the sdk and use it. Jun 08 08:34:57 Letothe2nd do you have an idea how to include mono toolchain in the sdk ? Jun 08 08:36:05 Guest330: https://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer Jun 08 08:36:28 Guest330: and https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-TOOLCHAIN_HOST_TASK Jun 08 08:36:52 Guest330: and https://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html#sdk-adding-individual-packages Jun 08 08:37:53 Letothe2nd thanks Jun 08 09:32:59 Looking for some help please with a failing recipe. Jun 08 09:35:05 ponzi: do you really expect helpful advice given that request? Jun 08 09:35:36 or rather with a specific package that is failing to build. Specifically libassuan-native. Even though the libgpg-error-native recipe succeeds, the config script continually fails to libgpg-error Jun 08 09:36:32 ponzi: has it ever worked? is this upstream, hopefully current? Jun 08 09:36:41 Hi guys, I am a complete newbie and was wondering about the difference between using yocto to create an image for developing a QT5 application and using raspbian. This is for a raspberry pi. Any pointers, resources or clarification would be very well received. Thanks! Jun 08 09:38:10 hey man when I'm looking for help the first thing I'm interested in is whether people are willing to help or just sass... Then we can explain the problem. Moving on... Jun 08 09:38:47 No it hasn't worked. I'm using sumo which is the distribution recommended by NXP for their imx8mm board support package. Jun 08 09:39:04 acyt2: 1) is the "open way" where you do not depend on a highly specific build. 2) is the qt-specific way 3) is the tinkerer-way where you gain interactive development, but lose reproductibiliy. Jun 08 09:39:14 If you think the question is better posed to NXP i''ll go there. Jun 08 09:40:38 the config script fails to find* libgpg-error Jun 08 09:41:42 Letothe2nd, I've been following your tutorials on Youtube to get started! They are awesome, thank you!! Jun 08 09:42:24 ponzi: so, "hey man." i take that you are not used to the IRC customs - hence a short explanation. it works like this: one shows up, and asks a question that is as concise as possible. the one by acyt2 is actually a pretty good example. then, if somebody knows, he/she can answer. people do *NOT* sit around here, waiting for somebody to first sayhello, then pull each and every bit out of the nose, until Jun 08 09:42:30 finally finding that its just not ... Jun 08 09:42:33 ... seomthing they can help with. So having said that, i will kick off a build of libassiun on master for you to check. if it does fail, i will tell you and you can file a bug. if it builds, its your job to either backport or upgrade. is that ok? Jun 08 09:42:37 acyt2: glad you like them. Jun 08 09:43:28 sounds good. Jun 08 09:44:19 ponzi: will report back, then. Jun 08 10:02:06 ponzi, Letothe2nd : we rip out gpg-config because it's fundamentally broken. the recipe that calls it needs to be changed to use pkg-config instead. Jun 08 10:03:42 but as assuan is in core already, it has already had this done Jun 08 10:03:59 Continuing on the clarifications, is there any link between yocto and bare metal programming for raspberry pi? Furthermore, is there such thing as bare metal + qt5 using either yocto or something else? Jun 08 10:04:20 ponzi: also if I can chime in. Depending on what you need from NXP's BSP layer, it might actually be worth starting your project on the latest release of Yocto and take the kernel, u-boot, etc... recipes from the NXP layer into yours. This is perfectly okay from Yocto PoV. Jun 08 10:04:51 acyt2: you could theoretically set up a bare metal build for the rpi using yocto, but other than for academic or very special industrial cases i do not see a use case. Jun 08 10:05:36 acyt2: define bare metal Jun 08 10:05:45 because qt needs a good C library and a kernel Jun 08 10:06:11 rburton: nope https://www.qt.io/product/develop-software-microcontrollers-mcu Jun 08 10:06:35 i stand corrected Jun 08 10:06:46 first time in my life! Jun 08 10:06:55 * Letothe2nd starts headbanging Jun 08 10:07:08 i'm guessing thats commercial only? Jun 08 10:07:11 doing away with a full blown os and just running the application directly on the hardware. rburton, I had doubts because of what Letothe2nd just pointed at... But looking into that, I am very confused as to whether there's any way of doing it without a commercial license from QT Jun 08 10:07:20 rburton: "very special industrial usecases" Jun 08 10:07:30 :) Jun 08 10:07:46 Hello everyone Jun 08 10:07:47 acyt2: the question you have to ask is why do i want to do bare metal. the kernel and C library provides a lot of very useful functionality :) Jun 08 10:07:54 acyt2: if you were one of those cases, you would know. seriously, just stick to linux :) Jun 08 10:08:18 thanks, rburton. I was hesitant to upgrade from sumo. I didn't want to deviate from the instructions unless I needed to. But if it's okay to use a newer version of poky I'll do that. Cheers. Jun 08 10:08:33 acyt2: might get killed for syaing that, but if all you need is one app to run... Maybe buildroot would suit you better? Even if it's baremetal, I guess you'd still need to build your own buildsystem... and that's the beginning of the nightmares :) Jun 08 10:08:34 ponzi: libassuan-native builds fine on dunfell master, just verified. so its up to you to do the backports if you want to stick to sumo. Jun 08 10:08:51 but it should work in sumo too. sounds like nxp broke something? Jun 08 10:09:39 qschulz: nah, if it fits the usecase its a perfectly fine advice :) Jun 08 10:09:41 Possibly, There's additional BSPs for the SOM I'm working with to potentially break even more things. Jun 08 10:12:27 Letothe2nd, rburton that's probably the best way, but I was curious about the alternative specially if it means I can buy cheaper hardware for the device... Atm I have a horrible prototype mixing a python daemon running the controls and a web based gui interface it's a bit too clunky and was trying to do away with as many things as I could to keep Jun 08 10:12:28 it simple, but maybe baremetal is over doing it. Thanks both! Jun 08 10:12:29 acyt2:mmmm... what I really wanted to say is that I doubt that you really need baremetal anyway since the cost of doing it the baremetal way (IMO) usually induces "harder" development, a handmade buildsystem for high size and/or performance constraints. I guess a very simple system with the bare minimum would be better. Something like core-image-minimal in yocto, or a buildroot image could be ok. I'm Jun 08 10:12:35 digressing from the original question (the difference between the two) but I've shared today's opinion :) Jun 08 10:12:47 ponzi: easy way to tesT: grab a fresh poky , don't use the nxp bsp, just build assum for qemuarm Jun 08 10:12:53 When I add IMAGE_FSTYPES += " squashfs" to my local conf build is not generating /core-image-minimal-raspberrypi3.rpi-sdimg anymore. Before I add it was generating. What should be the reason ? Jun 08 10:13:20 ilkmc2r: bitbake -e is your friend...... Jun 08 10:14:52 ilkmc2r: you'll see that you're overriding the IMAGE_FSTYPES from your machine conf file from bitbake -e :) (`bitbake -e | less` and then look for the line starting with IMAGE_FSTYPES, above that line are all the "instructions" that make up the variable Jun 08 10:15:20 Letothe2nd, qschulz thank you Jun 08 10:17:03 qschulz, it all adds, thanks for sharing the advice Jun 08 10:18:53 acyt2: also, raspbian (well now called Raspberry Pi OS) is still using 32b userspace even for 64b-able RPi IIRC Jun 08 10:19:15 qschulz: 640kB ought to be enough for everybody! Jun 08 10:20:05 Also, How do you guys manage host disk space usage? I'm at 100GB on just a qemu and rpi build! Jun 08 10:20:43 acyt2: i do not manage, just slap in a couple of TB harddrives. Jun 08 10:22:59 Right, I thought I was doing something wrong. If you don't mind me saying this, but maybe for all the complete newbies like me out there watching your videos a heads up would be appreciated ;) Jun 08 10:23:16 a heads up? Jun 08 10:23:43 acyt2: have a look at INHERIT += "rm_work" Jun 08 10:23:55 As in... Building all these images will take X amount of disk space, it's some kind of indication you're in the right direction Jun 08 10:24:14 acyt2: hm. i do not necessarily agree, to be honest. Jun 08 10:24:28 Letothe2nd fair enough Jun 08 10:25:13 acyt2: but thanks for the suggestion! i love all kinds of feedback, even if its just tellign me waht i'm doing wrong. :) Jun 08 10:28:06 Letothe2nd no, not wrong at all! Just that in my case I am running all of this on a mac on Docker and there was no indication whatsoever of how much space to give for the volume where I am writing everything... I guess it's kind of normal to have this trial an error interaction when learning, but I only mention it as something that would make it Jun 08 10:28:06 easier for complete beginners to set up their environments Jun 08 10:29:10 qschulz, thanks, will have a look! Jun 08 10:29:23 acyt2: hehe, i think i mentioned pretty early in the first session "do this on a native linux only if you don't want to lose your sanity" or something close enough, so here's your "heads up" then :) Jun 08 10:29:53 acyt2: Also... I think you could also benefit from the SSTATE_MIRRORS provided by Yocto https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#brief-building-your-image point 2 Jun 08 10:30:11 Letothe2nd '=D fair enough I did hear that advice and did not heed it so I deserve all I get Jun 08 10:31:31 acyt2: nah the point is more that its just a side effect. like "if you want to drive a car, then you need to learn ...". nobodys gonna mention that you'll need parking space. people tend to assume some side effects as jsut given. Jun 08 10:33:11 acyt2: and i gloss over many things that would have to be mentioned in a proper training - which is not what i do. for those who really want to learn stuff properly from the ground up, there are courses available. Jun 08 10:35:31 anyways. LÜNCH! Jun 08 12:51:58 Hi Jun 08 12:57:18 ykrons_: hello Jun 08 12:59:44 I'm facing weird bugs and it seems to be linked to two changes. 1. I have moved my yocto folder (layers, build, sstate etc) in a new drive (using btrfs) and in a folder that includes a dot in it and used a symboliclink to point from the old to new location. In that case, I get an opkg-make-index error at the end of SDK. 2: I have use the SDK without going through the symbolic links and I get some build errors complaining after SDK and going away after so Jun 08 12:59:44 me retries ... my questions are: Is btrfs a bad idea? Are symbolic links a bad idea? and the last is using a SDK through symlink (or moving a SDK I guess) is a very bad idea? Jun 08 13:02:43 mckoan: Hello, as you can see, I still learn a lot every day (in the case I learn from my mistakes ..) Jun 08 13:03:11 ykrons_: AFAIK Yocto/OE doesn't like symbolic links, SDK should be reinstalled Jun 08 13:03:57 ykrons_: however, just to be sure, what do you mean as SDK ? Jun 08 13:05:04 the build error in SDK is at the end of bitbake xxx -c populate_sdk Jun 08 13:05:10 ykrons_: and above all Yocto can't work if you copy the build tree in a dfferent directory. You have to reconfigure bblayers.conf and delete tmps Jun 08 13:05:59 In that case, I have moved the layers, removed build, deploy and rebuild from scratch (except download) the image and SDK Jun 08 13:06:33 annd bblayers.conf has relative in it Jun 08 13:07:09 ykrons_: it makes sense Jun 08 13:08:07 ykrons_: pastebin error log and the content of your build directory Jun 08 13:16:42 mckoan: https://pastebin.com/HHBsW5QH Jun 08 13:17:48 If everything is build from scratch there is normally no issue with using a symlink to access the yocto folder and launch the build? Jun 08 13:20:25 ykrons_: I don't know I never use symlink to access the yocto folder, and IIRC Yocto doesn't like symlinks Jun 08 13:20:40 ykrons_: if you build everything from scratch, why don't you just use the correct location and not the symlink? Jun 08 13:25:15 it is in fact a test on a build server to move the build location to a new disk with more space Jun 08 13:26:06 to do a test, the home has been copied to the new disk and a redirection is done with a symlink Jun 08 13:26:22 a rollback can be easily done with symlink Jun 08 14:01:59 what's the recommended course, when a package wants to use LD=$CROSS-ld and LDFLAGS which has all those -Wl inside ? Jun 08 14:10:47 yann: the package should get it from yocto and not redefine it (e.g. use $(LD) directly in Makefiles and not have any LD=something or LD:=something). But I'mnot sure this was your question, so could you elaborate a bit more? Jun 08 14:13:25 I'm trying to cross-build systemtap probes, and stap itself launches a kernel-module build. The build fails with https://pastebin.com/mWXzRxMH - if I override TARGET_LDFLAGS to set a value without -Wl, the build wents fine Jun 08 14:54:52 Hello, can't google if it is possible to revert inheritance in bbappend file? Jun 08 14:55:28 E.g. I want to remove gtk-icon-cache from intial recipe Jun 08 14:56:23 I don't think you can but someone might correct me. An alternative is to take the whole bb file and modify it in your layer and make sure your version is taken Jun 08 14:56:34 tolszak: in a nutshell: no. Jun 08 14:57:27 qschulz: That's the rough way Jun 08 14:57:39 Letothe2nd: Thanks! Jun 08 15:05:11 qschulz: anything additional I should detail ? Jun 08 15:18:22 yann|work: I'm not entirely sure but are you certain that it's not the host LD that is being used? Jun 08 15:18:35 yann|work: I'm surprised by aarch64-shadow-linux-ld call without a path in front of it Jun 08 15:19:15 so maybe check that your code use the LD provided by Yocto and not some hardcoded one (can be hardcoded in some fucked up ways and not obvious) Jun 08 15:19:17 at least it can't be the host ld on an x86_64 build host Jun 08 15:20:38 yann|work: you can have a cross-compiler on the host distribution :) Jun 08 15:21:12 but I admit I didn't write my sentence correctly :) Jun 08 15:21:33 there is none in this chroot Jun 08 15:22:37 my "env" call in do_compile says LD has this "aarch64-shadow-linux-ld --sysroot=..." value, no absolute path Jun 08 15:24:24 and "bitbake -e" says it comes from bitbake.conf : "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}" Jun 08 15:37:24 ld is found in $PATH as the sysroots are in $PATH Jun 08 15:48:23 yann|work: I did make cross-build work with stap back on pyro, but it was for a customer whose tree I don't have access to anymore. So it is possible, but iirc it took working out a lot of arguments to pass stap. Jun 08 15:51:08 RP: Before I squash it into my signature mcdepend commits and resubmit, does this look OK: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/mc-bbmask&id=507e14b9e962b4c6e3eea7a90aa84d872f36cbb3 Jun 08 15:52:09 RP: erg, has a small bug, but you get the general idea :) Jun 08 16:02:25 smurray: yes I think I have all of them, I'll submit patches when I have something good enough Jun 08 16:04:54 yann|work: it probably would work as a bbclass, I was toying with that idea back at the time Jun 08 16:10:33 makes sense Jun 08 17:36:59 Hi guys, I am in this very unhappy situation: my employer said that I must install an old version of TeamViewer Host Preview 12 (!!!) in my beautiful Yocto build Jun 08 17:38:25 So, first thing I created a new recipe, that DEPENDs on "dpkg-netive" and does a really nasty dpkg-deb -xv teamviewer-host_12.1.83885_amd64.deb ${D} Jun 08 17:47:28 kriive: You could try starting with `inherit bin_package` Jun 08 17:48:13 It won't handle the dependencies for you, but it should properly extract the deb and "repackage" it in Yocto for you Jun 08 18:13:10 Uh, thank you JPEW ! Does inherit bin_package also auto execute postinst scripts? Jun 08 18:19:59 kriive: I don't think so Jun 08 18:23:24 kriive: The source fetcher "handles" deb files by simply extracting their contents (maybe it puts metadata somewhere?). bin_packages.bbclass is just a small wrapper around that to make the recipe do sane things when you specify one. Jun 08 18:23:32 figured I'd ask here. I'm trying to build a piece of software with bitbake (yocto project) it's makefile is using 'curl' to get from an https:// server. curl-native is failing to verify the ssl context. It's pointing the cacerts info at the empty dir from the curl-native sysroot. I've figured out a way to massage the dir locations by writing out a ~/.curlrc before invoking `oe_runmake`. Jun 08 18:23:56 But I don't know where to point those to, or how to resolve the actual sysroot location to point to. Jun 08 18:48:45 bryanv: would adding a depends on ca-certificates-native help? Jun 08 18:49:08 no because the path is still wrong Jun 08 18:49:11 there's a bug for this Jun 08 18:49:27 depend on ca-certs-native, and then set the path to RECIPE_SYSROOT_NATIVE/sysconfdir/... Jun 08 18:49:36 bryanv: things shouldn't be fetching outside of do_fetch btw as that breaks auditing of the builds, mirroring, license handling and so on Jun 08 18:50:32 So I just hit the parts about the changes to sysroots with things from the staging class. Jun 08 18:50:55 I think i'm pretty close to figuring it out by adding dependent tasks, and not having to massage the curlrc. Jun 08 18:57:03 So I did have to use the ~/.curlrc (where ~ is of course the working dir for the recipe). Jun 08 18:57:26 I added do_compile[depends] += "ca-certificates-native:do_prepare_recipe_sysroot" Jun 08 18:57:35 and setup the curlrc with: Jun 08 18:57:41 echo "cacert=${STAGING_ETCDIR_NATIVE}/ssl/certs/ca-certificates.crt" > ~/.curlrc Jun 08 18:57:41 echo "capath=${STAGING_ETCDIR_NATIVE}/ssl/certs" >> ~/.curlrc Jun 08 18:58:00 I wonder what my next roadblock will be. Jun 08 19:29:16 /buffer 1 Jun 08 20:34:03 JPEW: can you send any changes to that bitbake series as an incremental patch which I can squash pleasE? Jun 08 20:42:50 RP: Sure, I'll just rebase on master-next quick Jun 08 20:44:52 Ah, you missed the new files Jun 08 20:45:19 Right, this has happened before because I sent the patches against poky, not bitbake and combo-layer didn't handle it Jun 08 20:45:23 sorry Jun 08 20:47:38 JPEW: its ok, I should know how to deal with it by now :/ Jun 08 20:48:07 I'll send a patch you can apply against bitbake quick Jun 08 20:50:24 RP: Oh, right the files are in bitbake, they just got missed by combo-layer Jun 08 20:55:49 JPEW: I just updated things Jun 08 20:56:12 JPEW: that patch I mean is the centos7 issue I sent email about Jun 08 21:03:27 RP: Patch sent Jun 08 21:21:47 JPEW: thanks! Jun 08 21:46:43 hi. what's the right way to access BB_ORIGENV in a recipe? Jun 08 21:47:23 if i do 'FOO = "${@d.getVar("BB_ORIGENV").getVar("FOO")}' and 'export FOO', i get a bunch of non-deterministic metadata errors and i don't understand why. **** ENDING LOGGING AT Tue Jun 09 02:59:57 2020