**** BEGIN LOGGING AT Tue Oct 22 03:00:24 2019 Oct 22 06:34:52 noob question: Why Yocto vs say Gentoo for an embedded x86 RT Linux system? Oct 22 06:40:52 CaptHindsight: because compiling in-target is kainda meh on an embedded system? Oct 22 06:41:21 maybe have no disk, no writeable fs, litlle cpu, whatever. and what are you gonna do when things fail? Oct 22 06:41:48 ok for that hardware scenario I see Oct 22 06:42:43 any advantages where you have a full x96 PC, HD, file system, USB, serial etc Oct 22 06:42:44 and, compiling everything 1 million times if you are shipping your product 1 millin pieces is also somehow inefficient. thats at least my take on it. Oct 22 06:42:54 heh x86 Oct 22 06:43:21 CaptHindsight: you can also ship an embedded x86 product 1 million times, no problem. Oct 22 06:43:37 CaptHindsight: but generally it boils down to the use case. Oct 22 06:43:57 same for gentoo all tarballed Oct 22 06:44:38 CaptHindsight: of course you can do it. and if it suits your needs, go ahead! Oct 22 06:45:01 trying to see where Yocto fits Oct 22 06:45:35 generally it fits if you want a highly customized all-in-one binary image to deploy on a known piece of hardware. Oct 22 06:45:51 it is by no means the only way to do that. Oct 22 06:45:57 in other words "why Yocto and where?" Oct 22 06:46:12 i think i just answered that. Oct 22 06:47:11 example: think about the control panel of your coffee maker :) Oct 22 06:47:23 i haven't dug too deeply yet, how does or does it even handle kernel configs? Oct 22 06:47:46 you build a defined kernel configuration an ship it. Oct 22 06:48:17 I've been on the hardware side of embedded since the 70's Oct 22 06:48:42 well, i don't get what your actual question is unfortunately Oct 22 06:49:01 i try to avoid anything beyond 1/s and 0's or soldering as a programmer Oct 22 06:50:13 just trying to see where Yocto fits vs building Linux from scratch or gentoo for an embedded PC Oct 22 06:51:05 CaptHindsight: yocto (or more precisely, OE) is basically a highly automated LFS. Oct 22 06:51:08 I used to not mind writing firmware, boot loaders etc Oct 22 06:52:00 so there's really a lot of mind model intersection there. if LFS fits your needs, use it. if gentoo fits, use it. Oct 22 06:52:28 looking at Yoctos ins and out Oct 22 06:52:33 ups and downs Oct 22 06:52:38 its just the the OE setup is kinda more elaborate when it comes to all-in-one build time setups, whereas gentoo and lfs are more iterative. Oct 22 06:53:14 Bitbake vs portage Oct 22 06:53:20 nope Oct 22 06:53:39 bitbake is a task runner. portage is a package manager frontend. different thing. Oct 22 06:54:37 (i know they have teh same roots, but certainly evolved differently) Oct 22 06:57:36 but seriously, you are being very very nebulous. if you have a use case and requirements, one could maybe explain if yocto/or fits, or rather not. but all i can answer so far is "its related, but not the same." Oct 22 06:57:52 yes I am Oct 22 06:58:14 I'm trying to grasp what it is, what it does etc so i can see where it might fit Oct 22 07:00:20 vs have to tell me based on different hardware examples Oct 22 07:00:41 that could work to :) Oct 22 07:01:58 i have had my share of nebulousness for this morning, to be honest. fell free to have a look at the quick start, or ask me a question that actually has an answer. besides that, i'll now try and find me a coffee and do some work :) Oct 22 07:02:37 sorry, I'm only big picture at this time Oct 22 07:03:15 it tough to put into words what something is or is at times Oct 22 07:03:25 or is not Oct 22 07:06:05 an analogy might be looking at two different tools sets, both with 1001 pieces but one is mostly sockets and wrenches vs the other with mostly screw drivers and hammers Oct 22 07:06:52 having not seen so many screw drivers before one might wonder hmm I wonder what that might be good for Oct 22 07:17:00 was there some way to automatically split all shared libraries to separate binary packages? Oct 22 07:17:39 * mcfrisk looks at size increase between sumo and zeus Oct 22 07:26:52 mcfrisk: i think so. have you checked package.bbclass? Oct 22 07:26:59 and why does polkit depend on libmozjs.. Oct 22 07:27:08 LetoThe2nd: I'll check, thanks! Oct 22 07:30:47 good morning Oct 22 07:35:20 mckoan: halfways agreed. Oct 22 07:37:34 LetoThe2nd: you're going better :-D Oct 22 07:38:35 mckoan: half bad: dishwasher broke. half good: got a service appointment quickly. Oct 22 07:38:46 mckoan: how your flooding going? Oct 22 07:40:16 LetoThe2nd: thanks God today is sunny Oct 22 07:40:40 Buildroot vs Yocto: Differences for Your Daily Job https://www.youtube.com/watch?v=wCVYQWFIvBs Oct 22 07:40:47 handy comparison Oct 22 08:51:53 .me waves all Oct 22 08:52:09 How fix "SRC_URI uses unstable GitHub archives [src-uri-bad]" warning? Oct 22 08:53:23 don't use unstable GitHub archives :) Oct 22 08:53:55 hmm, buildhistory files-in-package.txt files are not re-generated if build is not needed and sstate cache is uptodate Oct 22 08:54:02 alessioigor: /archives/[tagname] URLs don't reliably return the same content Oct 22 08:54:20 alessioigor: some maintainers also upload proper tarballs to the releases page, if not use a git clone Oct 22 08:54:31 otherwise one day with no warning, fetches will fail because the tarball regenerated Oct 22 08:54:55 rburton: Ok thanks Oct 22 08:56:19 its the "Source code" links in the releases page which are bad Oct 22 08:56:58 see eg https://github.com/libarchive/libarchive/releases has also uploaded proper tarballs Oct 22 08:58:11 does yocto support the creation of an "addon" image? i.e. addon = base + extra applications - base. Like a "diff" from some defined base image? Oct 22 08:59:17 or how do I define the content/packages of an image without dragging in *any* dependencies? Oct 22 08:59:34 rburton: Unfortunately author doesn't release this way but relay on "Source code" ... :-( Oct 22 09:02:05 alessioigor: if there are no releases, you have to use git clone (so the git repo), define SRCREV to the commit you want to use, if needed, the branch in SRC_URI if it's not in a branch named master Oct 22 09:02:40 Ok I'll do that so Oct 22 09:02:48 rburton, qschulz: Thanks! Oct 22 09:12:38 New news from stackoverflow: Flashing custom Yocto image to Jetson Nano production module eMMC? Oct 22 09:24:55 or is there a way to get the content of all machine specific packages? Oct 22 09:30:20 T_UNIX: what is your problem exactly (the one that makes you think (maybe rightfully) that you need an "addon" image)? Because it's pretty vague (to me at least) Oct 22 09:36:34 alessioigor: try explaining to them that the tarballs in source code links can change and many people like having checksums, so if they could upload a tarball that would be good Oct 22 09:37:04 rburton: I''ll try. Oct 22 09:43:06 if anyone understands node/npm/etc there is a RFC on the list to rewrite the npm fetcher Oct 22 09:43:10 review and testing appreciated Oct 22 09:46:57 RP: there's a v3 of the sudo patch Oct 22 09:49:36 rburton: finally with "sudo make me a sandwich" support? Oct 22 09:50:52 * rburton curses Oct 22 09:51:23 you be a responsible citizen and inform NVD of updates to the cve database, and they can't read and update CVEs so they claim fixed releases are in fact broken Oct 22 09:51:50 whatever. Oct 22 09:51:54 where my sandwich?!? Oct 22 10:42:51 New news from stackoverflow: Linux PC not able to detect imx6 board (configured to boot mode) when using lsusb Oct 22 10:43:25 qschulz: I'd like to avoid generating entire images for each machine (brand), even though all I care for would be a few MBs owed to different DTBs, branding, etc. Oct 22 10:43:48 on the other hand I do not want to package every DTB into a single image. Oct 22 10:45:26 so currently I'd go about it by diffing some `IMAGE_ROOTFS`s and `tar`ing results via some `IMAGE_CMD_` override. Oct 22 10:47:28 an obstacle is getting the correct `IMAGE_ROOTFS` for another image than the currently build one. Oct 22 10:53:57 it would be easier though, if I could simply get *only* the content of whatever populated the `MACHINE` specific directory (`tmp/work/${MACHINE}`). Oct 22 11:11:52 Hi i have an issue building python c extensions within a bitbake build. Our app needs to build c extensions for python and use them for some postbuild stuff. It works fine using the SDK but within the bitbake build i will get a :" QA Issue: The compile log indicates that host include and/or library paths were used." Oct 22 11:12:52 The log shows that the python3 include from my hostsystem is used (/usr/include/python3.6m) Oct 22 11:12:53 New news from stackoverflow: Yocto tensorflow 2.0 Oct 22 11:13:29 Domin1k: inherit python3native Oct 22 11:13:41 I thought that a simple DEPENDS python3-native would fix it Oct 22 11:13:54 nope, the binary itself isn't in $PATH Oct 22 11:14:02 does the build use setuptools etc? Oct 22 11:14:10 there's a class for that if it does, which does the right thing. Oct 22 11:14:23 ok why do i have to inherit it i thought a DEPENDS would do the job? Oct 22 11:14:33 its a cmake project Oct 22 11:14:37 oh Oct 22 11:14:41 have fun! Oct 22 11:15:03 depending on python3-native doesn't put the new py3 on $PATH, as i said Oct 22 11:15:09 the inherit does that extra fiddle Oct 22 11:15:21 ok thaks i will give it a try Oct 22 11:15:28 you'll probably need to tell cmake explicitly where python is because cmake is dumb Oct 22 11:15:54 eg meta/recipes-sato/webkit/webkitgtk_2.26.1.bb: -DPYTHON_EXECUTABLE=`which python3` Oct 22 11:16:14 other recipes do -DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} Oct 22 11:20:38 Thank you very much for your fast reply. I will check that. Oct 22 11:32:46 T_UNIX: don't get files for an image which are from another image, tha'ts bound to fail at one point. If you anyway are going to take what's inside a tmp/work/${MACHINE}, I don't understand what you're trying to do. The sstate-cache will anyway makes everything that is not machine dependant fast. Which unfortunately does not include the kernel, bootloader, etc. Oct 22 11:38:34 T_UNIX: a hackish way would be maybe to have all those machine dependent recipes to have a PACKAGE_ARCH set to a common string (one of MACHINEOVERRIDES?). You then split the differences (e.g. DTB) in different packages and include the packages in the image depending on the machine for example? I don't know how bad of an idea that is, but I don't feel like it's great. I don't even know if that can work Oct 22 11:38:48 T_UNIX: just thinking (badly) out loud Oct 22 11:39:38 qschulz: sure, the sstate-cache makes things fast. But I'd end up with an entire image for every machine derivative. Oct 22 11:39:59 so let's ignore the `addon`-image thing. Oct 22 11:40:59 Just focus on only source whatever is diverting for a certain `MACHINE`. Oct 22 11:42:08 if I'd simply use `IMAGE_INSTALL` it would pull in all the (binary idenitcal) dependencies. Oct 22 11:43:05 so what I'm aming at is a better integration with RAUC's concept of slots (https://rauc.readthedocs.io/en/latest/basic.html#slots) Oct 22 12:03:41 LetoThe2nd: what timezone are you? Oct 22 12:07:15 unrelated question: I there a concept of `.sample` files for multiconfig files? Like there is a `local.conf.sample` in `conf` for the default `local.conf` Oct 22 12:34:48 T_UNIX: that wouldn't really make sense? **** BEGIN LOGGING AT Tue Oct 22 12:36:10 2019 Oct 22 12:39:00 hi ! I'm continuing my work on SPDX licensing, I'm doing layerindex-web and I'm wondering what to do with the html files? I'm not sure that really something that has to be licensed? Same for Dockerfile and Dockerfile.web Oct 22 12:39:15 what do you think ? Oct 22 12:39:57 LetoThe2nd: I'm sorry "sudo make me a sandwich" isn't supported yet. Though you can say "Google make me a sandwich", that works. https://www.youtube.com/watch?v=GN-pc2f-r5M Oct 22 12:58:09 Hi can i some how change the order that devices ar initilised when using a device tree ? Oct 22 13:02:15 hmw1: probe order is non deterministic. Except if you explicit the relation between devices and defer probe of device A if device B is not here already. Oct 22 13:02:23 ecdhe: europe/berlin, usually. why? Oct 22 13:02:50 hmw1: depending on what you're trying to do, it might be a very bad idea to rely on probe order Oct 22 13:14:05 LetoThe2nd: just visiting some scrollback and noticed you were either in a different timezone from me or up very late/early. Which is good to know! Oct 22 13:14:55 ecdhe: so whats yours? :) Oct 22 13:15:33 UTC -5 Oct 22 13:15:47 kay Oct 22 13:16:32 I wish I had gotten that "what is yocto/why use yocto" question you took recently Oct 22 13:17:05 I have less nuts and bolts knowledge of yocto (mostly because my vendor set it up and I haven't had to change it a whole lot) Oct 22 13:17:06 ecdhe: the asker is still around, feel free to answer Oct 22 13:19:54 CaptHindsight: if you're still around, it's instructive to consider yocto from a lifecycle perspective. Let's say I'm making an x86 rackmount NAS and I'm considering building my own image with yocto versus using a known distribution like debian. Oct 22 13:22:43 For yocto, it will be easy to develop my user-facing web-management application in a layer over a stripped down image. On debian, I'd probably package my user facing app as a .DEB and ship it. Oct 22 13:23:48 With an existing distribution like debian, you get update infrastructure. With yocto, you are actually generating your own distribution, so you'll need to provide your own. Oct 22 13:24:36 So a few months down the line, when heartbleed 2.0 appears, your debian appliance can be configured to pick up the patch automatically. Oct 22 13:27:08 If heartbleed is a concern for you in yocto, you'll have considerations like making sure you're pulling recipes from the upstream (so you can easily pull the latest security fixes and rebuild) and also have a mechanism in place for hosting updates that is accessible to your fielded appliances. Oct 22 13:29:38 Let's say your appliance has no network ports and limited storage. In yocto, you can easily taylor your custom distribution down to the essentials... in Debian it will be more tricky to pare down to a 10MB rootfs. Oct 22 13:30:17 So from a security standpoint, the more of a resource-constrained, offline-appliance you have, the more yocto makes sense. For highly connected, always on appliances, a more mainsteam distro can help offload the security economics and operations. Oct 22 13:31:19 ecdhe support vs limited storage, it's the key between custom ditro and mainstream distro like debian. Oct 22 13:35:46 I have a question about yocto and depmod. And, I'm wondering where is the best place in this irc to ask for some help? Oct 22 13:39:26 Where can I found logs with the pkg-config invocations? Oct 22 13:40:50 I have an application that doesn't found the right include dir of a library (which should provide a .pc file)... Oct 22 13:41:24 Obviously application recipes include "inherit pkgconfig". Oct 22 13:41:46 and the 'DEPENDS += "library"' Oct 22 13:43:15 initerworker: just ask Oct 22 13:47:02 alessioigor: the task configure log, presumably Oct 22 13:47:35 alessioigor: if its called cmake then speak to #cmake to find out how to get detailed logging out of it Oct 22 13:47:40 and when you find out, tell us please Oct 22 13:48:02 autoconf has a config.log which lists the commands it runs and their output, cmake doesn't appear to do that. Oct 22 13:48:55 The application provides Make and CMake support and I'm using the former... Oct 22 13:48:57 rburton: I have just tested `pkg-config --cflags library` into devshell and it is works and give the right values. Oct 22 13:54:57 hello folks Oct 22 13:55:06 is the meta-qt5 maintainer in here aswell, by any chance? Oct 22 14:18:15 litb: JaMa ^ Oct 22 14:20:13 ah, I see! I created another mkspec for win32-oe-g++ and added the OE_QMAKE_RC variable that controls the windres tool path Oct 22 15:05:30 Hello, Oct 22 15:05:30 I was watching @LetoThe2nd videos. I have small doubt. How do yocto figure out packages and their associated files for debug, dev etc? Oct 22 15:06:11 abhiarora44: look into poky/meta/classes/package.bbclass - thats where the magic happens. Oct 22 15:06:58 ecdhe: thanks, been watching some videos about Yocto to see why and where it might be useful Oct 22 15:11:01 Quite a long file. So even without you entering the FILES_ and packages, yocto does it in background? Oct 22 15:11:30 abhiarora44: thats the short version. it populates it with defaults. Oct 22 15:15:20 ecdhe: if you had to pair down a file system to 10MB with Yocto how does it trim the kernel down to 2-3 megabytes? Or is that still done using Kconfig and make? Oct 22 15:15:54 abhiarora44: also, PACKAGES and FILES_* variables are set by default in bitbake.conf http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf Oct 22 15:17:10 CaptHindsight: if you give it a kernel config, it gives you a small kernel back. no magic involved, we're shipping quite some products here with rescue systems including kernel+rootfs in 10M or less. Oct 22 15:17:27 ecdhe: my space ship just crashed here, how do i know what a recipe is vs layer etc.? Oct 22 15:18:39 the videos are filling in the blanks for the wiki Oct 22 15:19:02 CaptHindsight: watch the livecoding series, i demonstrate the standard qemux86 setup which i think ends up somewhere in that range. trim the kernel config, and you can certainly go to 6M or 7M. it won' bring many applications besides busybox, but hey, its small. Oct 22 15:21:09 in the olden days we had to fit it in 2MB of flash for Linux as BIOS (now coreboot) Oct 22 15:22:25 CaptHindsight: in the olden days we've had 2400baud and wasted all night to get a puny floppy image through the phone line. seriously, the good old days were old for sure, but not necessarily good. Oct 22 15:22:37 (my opinion) Oct 22 15:23:27 you had floppies! Oct 22 15:23:37 *shrug* whatever. Oct 22 15:23:41 kidding Oct 22 15:30:19 abhiarora44: bitbake.conf is where all the defaults are. pages of them. including PACKAGES and FILES_* Oct 22 15:37:00 floppies and butterfly, i need a doctor. emacs can you hear me. Oct 22 15:46:39 rburton, this regression in gcc8 affects Qt compilation and possibly other C++ programs, yielding to internal compiler errors: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 Oct 22 15:46:40 Bug 88568: was not found. Oct 22 15:47:04 I see it's not yet as patch in the warrior branch. may be worth it Oct 22 15:49:39 litb: feel free to send a backport Oct 22 15:50:09 rburton, they backported it. It's svn diff -c 270723 svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch Oct 22 15:51:55 CaptHindsight: was afk there. Layers can include recipes. Your custom personal layer can act actually extend/modify recipes in the base install. Oct 22 15:54:26 litb: i meant, post a oe-core patch. master then zeus first, obviously. Oct 22 15:54:48 ah, I see. thanks Oct 22 15:54:57 CaptHindsight: you NEED to put your modifications into your own layer, because you want to be able to pull updates from the included layers -- avoid making changes to the upstream stuff. However, you don't need a new layer for every little change you make. Unless you are supporting multiple products with major hardware variants or software systems, you can probably just organize your changes into a single layer of your own. Oct 22 15:57:22 https://www.youtube.com/watch?v=gswXX7b6MuI Embedded Recipes 2017 - Introduction to Yocto Project/OpenEmbedded - Mylène Josserand Oct 22 16:34:51 CaptHindsight: good stuff Oct 22 18:44:29 is there an x86 dev board or tablet (can be ARM) with a working example of Linux built with Yocto that I can purchase? Oct 22 18:45:11 I have some older ARM tablets that said they used open embedded from 7-9 years ago Oct 22 18:53:19 CaptHindsight: x86 https://www.amazon.com/MinnowBoard-Turbot-Board-64-bit-System/dp/B01N0HB0OU?SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-ffab-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=B01N0HB0OU Oct 22 18:53:35 CaptHindsight: or a beaglebone? or a raspberry pi? Oct 22 18:54:12 The SD card on the beagle/raspi might not be built with yocto, but the tutorials are excellent Oct 22 18:58:45 ecdhe: I'm looking for a fully built working example Oct 22 18:58:52 so maybe not the Rpi Oct 22 19:00:28 is there a known working ISO or image for the BBB that used Yocto? Oct 22 19:10:41 CaptHindsight: The BeagleBone Black ships with an image built with Angstrom which is Yocto-based unless that's changed lately Oct 22 19:11:19 paulbarker: thanks, I have a few of those boards Oct 22 19:11:30 You can also pick up a BBE from Sancloud, we're in the process of putting out a pre-built Yocto image for that (might end up being released after ELCE now) Oct 22 19:14:18 Raspberry Pi is also a great platform to learn Yocto Project with, you just need to pick up the meta-raspberrypi layer Oct 22 19:18:37 all the 6+ yer old ARM tablets we got used open embedded for the Linux install and they were all broken... Oct 22 19:18:51 so I don't want to use those as a reference Oct 22 19:19:38 looking for a known working image I can run a board with vs build the image using Yocto Oct 22 19:47:07 CaptHindsight: if you want we can certainly give you a working image for a raspi or bbb, that shouldn't be a problem. but the image by itself won't probably do much, unless you specify a set of applications or seomthing to be installed. and a yocto built image doesn't have a package repostiory to pull from, it all happens at build time and is poured into the image, so having that is only like half of Oct 22 19:47:13 the deal. the other half is controlling ... Oct 22 19:47:15 ... the build process. Oct 22 19:49:01 CaptHindsight: if you're interested, give me a holler tomorrow and i'll yank out a minimal rpi build for you, so you can get a feel for what we think of as "small" :) Oct 22 19:52:04 what do you want to do with your BBB or RPi @CaptHindsight ? Oct 22 19:53:15 I just got myself the BBC micro:bit. I guess it's too small to run yocto Oct 22 19:56:07 litb: at least for yoctos usual incarnation based on linux its too small, right. Oct 22 19:57:05 I hear there's meta-zephyr, but I don't know how serious they are with it Oct 22 19:57:08 litb: i know of ways to build other OS using parts of the yocto build system, like zephyr, which could totally run on it. but that usually doesn't count as "yocto" in the common meaning of the word in this context Oct 22 19:57:12 hehe Oct 22 19:58:00 litb: you just have to know that it build zephyr then which is a lot, but neither linux nor "yocto" as you know it. Oct 22 19:58:16 yeah, I wanted to experiment with zephyr. Oct 22 19:58:34 :-) Oct 22 19:59:38 yeah, because if you do that with yocto in mainstream with less 256 KB of Flash, I could like you a lot. Oct 22 20:00:49 someone with OpenWRT backporting experience on Yocto and MIPS Arch ? Oct 22 20:01:39 getting this on a clean oe bitbake core-image-minimal: https://paste.ubuntu.com/p/Ssf5XQjvnP/ Oct 22 20:01:40 initerworker: like, what? i mean, we have mips support if that is the question. Oct 22 20:01:42 any idea? Oct 22 20:01:53 with linux and mingw, there's much overlap. both share lots of packages, just target different OSes. but with zerphyr, I can't imagine much overlap. Oct 22 20:02:28 oe-core master branch * Oct 22 20:02:47 litb: no overlap at all. zephyr has no packages, it just builds a monolithic blob for a uC Oct 22 20:02:57 psrcode: any other layers? Oct 22 20:03:04 nha bare Oct 22 20:03:39 psrcode: host distro? Oct 22 20:04:15 ubuntu 18.04.2 inside a container Oct 22 20:04:27 with sanity.conf touch to bypass the root check Oct 22 20:04:48 root check? Oct 22 20:05:19 yep Oct 22 20:05:52 which root check? Oct 22 20:06:01 apparently he executes bitbake as root Oct 22 20:06:44 sounds massively stupid. Oct 22 20:07:16 mabye one of the fetcher tools like wget doesn't want to run as root Oct 22 20:07:17 well worked so far and is a "temporary" container Oct 22 20:07:37 enought for me to update the lttng recipe in the last year Oct 22 20:07:40 running as root is stupid, be it in a container or not, temporary or not. Oct 22 20:08:08 psrcode: you do know that being root in the container still means root permissions on the filesystem, right? The container could drop a suid root binary on any bind-mounted filesystem… Oct 22 20:08:22 if oe-core master doesn't properly build on ubuntu 18.04, it ought to be looked into. granted that. Oct 22 20:08:38 I never understood why running containers as root is the docker default. Oct 22 20:08:57 neverpanic: lol why do you assume this is docker Oct 22 20:09:19 psrcode: other container systems don't get this wrong as easily, in my experience. Oct 22 20:09:31 psrcode: yet, if we're talking about raw oe-core, then you 1) need to specify the bitbake revision too, and/or b) head over to #oe respectively its mailing lists. Oct 22 20:12:12 sure sorry to bother Oct 22 20:15:08 LetoThe2nd: thanks, let me see, I don't want to spin your wheels, was hoping there might already be an Rpi image out there Oct 22 20:17:11 neverpanic: its lxd/lxc by the way, not the default simply lazyness on my end Oct 22 20:17:59 Oh, OK, that's meant for system containers, so it's understandable that it defaults to root, although I'd still recommend switching the uid inside the container. Oct 22 20:18:35 CaptHindsight: the point is that those images are usually pretty much useless other than showing that they are able to boot for the described reasons. Oct 22 20:19:23 CaptHindsight: the "all at build time, no package management at runtim by default" mindset mandates that everybody makes up his own images as needed. Oct 22 20:20:22 psrcode: FYI we have containers that are set up to work out of the box without root: https://github.com/crops/poky-container Oct 22 20:20:39 docker-based though Oct 22 20:20:43 anyways. gonna call it a day, bluelightning already takes over :P Oct 22 20:20:54 LetoThe2nd: sleep well :D Oct 22 20:21:23 not my first rodeo with yocto/oe, only want to get my lttng recipe updated... Oct 22 20:21:42 sure, understood Oct 22 20:22:04 was simply surprise to get oe-core fail on me at the bitbake level Oct 22 20:22:29 i'll get around the issue one way or another Oct 22 20:22:48 it's just there are good reasons for the root check that are only half-mitigated by using a container - you still won't get any warning if a build script is writing something to a system path, so it might "work" inside the container then blow up outside of it Oct 22 20:23:21 LetoThe2nd: like, I'm trying to build a github backporting project of OpenWRT. You can look up at https://github.com/micro-iot/meta-linkit7688/issues/2. But, I have a problem with the native depmod. And, I'm looking for an advise. Oct 22 20:23:47 psrcode: Hmm, that looks like a problem. Are you on the latest oe-core & bitbake? Oct 22 20:23:47 that's likely not related to the error though Oct 22 20:24:02 bluelightning: the whole stack is trashable on our end so that's why i'm lazy here. Oct 22 20:24:27 JPEW: will first check with latest yocto, might be somthing on my end who knows Oct 22 20:25:42 JPEW: yocto master looks fine. Oct 22 20:26:11 our admin plans to use docker with yocto to build our firmware, when I'm finished with porting our firmware to yocto Oct 22 20:26:36 however I read that there's the CROPS project that has something to do with containers aswell Oct 22 20:29:29 There is also https://github.com/garmin/pyrex for building in a container (caution: shameless plug) Oct 22 20:37:48 JPEW: my version of bitbake was out of date. working fine now thank! Oct 22 20:38:12 psrcode: Good! you had me a little worried :) Oct 22 21:31:05 whats the connection between Wind River and Yocto? Oct 22 21:32:01 founding member Oct 22 21:32:36 CaptHindsight : Wind River is a strong adoptor and important contributor Oct 22 21:47:20 dreyna: thanks was just looking at WR Linux Oct 22 21:51:19 lets say I want to build an image for an x86 board with RTAI https://github.com/NTULINUX/RTAI and my custom app Oct 22 21:52:37 so I have to make a recipe for RTAI and another for my app and then use one or more board layers Oct 22 23:45:12 is it okay to send a patch as an attached .patch file? Oct 22 23:49:11 mischief: we prefer patch-in-email Oct 22 23:49:51 (which is a bit painful to set up for some environments I know) Oct 22 23:50:08 http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded if you haven't seen it Oct 22 23:52:07 bluelightning: yeah, i have. i think i set up git-email correctly just now. time to find out :-) Oct 23 00:09:36 looks like it worked, now just waiting for someone to tell me what i did wrong :) Oct 23 00:12:08 can anyone explain the cases in which PACKAGE_EXCLUDE is ignored? the reference manual for v2.6 states that the build system will halt if you use this to exclude a package and another package is dependent upon it and as far as i can tell it straight up does not work **** ENDING LOGGING AT Wed Oct 23 02:59:58 2019