**** BEGIN LOGGING AT Tue Jun 11 03:00:01 2019 Jun 11 06:02:32 mccc: heya. i should be around all day. and if you are interested, i'll be running the twitch live sessions tonight :) Jun 11 06:13:50 Link? Jun 11 06:15:42 If it's https://www.twitch.tv/yocto_project it looks like I missed you - I'll try and catch you next time :) Jun 11 06:24:17 hehe no, this night. in about 8.5 hrs Jun 11 06:26:02 mccc: so, what do you mean exactly by the clouod server topic. like, full linux systems to run inside a vm? or rather containers? Jun 11 07:04:32 Full Linux systems to run inside a VM. I have a service backend right now that uses a couple of VM types and I'm manually administering them. I was evaluating options to automate them and considered Yocto combined with an orchestrator like Terraform or Pulumi. I don't have much container experience, but a full disk image feels like a natural artifact to use to divide the configuration side Jun 11 07:04:32 from the orchestration side. I saw other recent projects taking this approach, LinuxKit and Packer. I'm using Yocto in the same project to deliver an embedded system so I wanted to consider using it here too. Jun 11 07:06:46 mccc: hmmmm ok. Jun 11 07:07:48 mccc: well the main thing about yocto or rather openembedded to be precise, is to create a custom linux distribution. so if you know beforehand what you will want in that vm image, there nothing that keeps you from creating it. Jun 11 07:10:49 mccc: it just boils down to this. pro side: total control over the generated image. (where some forms of control take littel effort, some take much). contra side: you most likely end up with a linux distribution in your container that is to at least some degree incompatible with what the rest of the word takes for granted. Jun 11 07:11:27 s/word/world/ Jun 11 07:11:56 mccc: so you'd really have to make up your mind on what the image shall bring, what the orchestration should do, etc. Jun 11 07:12:44 mccc: because if in the end you just need a drop-in for a slim ubuntu or alpine base install, then you're almost certainly better off just using those. Jun 11 07:13:21 mccc: best example: an OE-based image does by default not bring a package manager. and no package repositories too, of course. Jun 11 07:15:09 Okay. Immutable infrastructure seems to be the hot topic, but it seems like most approaches include starting with a popular distribution, running a configuration manager tool on it, capturing the image, and using it. While a configuration manager would use the distribution's package repositories during configuration time to bring down software, with the immutable infrastructure pattern you Jun 11 07:15:10 wouldn't expect to use those package managers on that image again. Instead, you would start from scratch when it comes time to upgrade. Jun 11 07:15:58 In that sense the Yocto Layer Index and community recipes end up taking the place of a distribution's package manager - it's the place where I'd bring software down when building an image. Jun 11 07:17:11 If the software I would end up needing is available in the layer index, I feel like that should be as good as if it were available in a distribution's package manager. Jun 11 07:18:13 mccc: exactly, that the thing one needs to get his head around. the recipes in the layer index are basically the equivalent of a classic package repository Jun 11 07:18:59 mccc: so, if your approach is to generate a full custom image based on that, which then only needs a handful of configuration artifacts deployed through orchestration, then you're good to go Jun 11 07:20:34 mccc: for a usecase like this, you'd probably jsut use the generic x86-64 machine, maybe core-image-minimal as the starting point, and then evolve. Jun 11 07:22:10 That seems to be the point of the immutable infrastructure pattern, but as we've talked about there isn't much online about using Yocto for this. Most guides talk about using a configuration manager like Chef or Jenkins during image build time, and then there are the LinuxKit and Packer projects. Jun 11 07:22:48 mccc: the key difference between vm and container is that the former needs the full shbang in terms of init process and all, so you can't strip it down as aggressively as a container image. there, you can literally just define the binary thats going to be run, and let OE figure out its dependencies to go into the image Jun 11 07:22:51 good morning Jun 11 07:24:08 Good morning mckoan :) Jun 11 07:24:53 good morning Jun 11 07:25:02 mccc: if you're using yocto/OE, there is little to additionally document by default in comparison to a standard embedded image. those are "immutable" too by mindset. Jun 11 07:25:36 LetoThe2nd - that makes sense. Because I don't have much Docker / container experience, I'm trying to make sure I'm not missing anything about containers in the mix here. Jun 11 07:26:25 Your point about an app designer being able to just define the binary and ignore the operating system makes sense, of course you take a dependency on the container system, but the OS can be swapped out underneith. Jun 11 07:26:56 In this scenario though as an app designer I take a dependency on Yocto when I define my recipes, Jun 11 07:27:22 and then as an image creator I do the work of defining the rest of the OS. Jun 11 07:27:30 mccc: building custom containers is where things are really different. because your run of the mill ubuntu container is, well, an ubuntu where a lot of stuff is around but never run - there is no pid 1, basically. this is where yocto/OE shines, you can totally build something that has no init, no bash, no anything Jun 11 07:29:22 I'm wondering if the extra work of 1) the Yocto learning curve and 2) being responsible for defining the rest of the OS, is what makes writing an app for a container that runs on a regular distribution the more common path. Jun 11 07:30:14 I really do like that about Yocto though, the massive configurability and the ability to start from nothing and pull in just what's needed. Jun 11 07:31:21 I'm also trying to make sure I'm not swimming too far upstream though, since I don't see much online about using Yocto for cloud VM images. Jun 11 07:36:08 It's late here so I'm going to head home, but I really appreciate your discussion about this, thank you. Jun 11 07:38:03 mccc: sorry, phone. Jun 11 07:38:58 mccc: it depends. my gut feeling is, that it only pays of if you either have super special requirements, or if you are running such a massive amount of vms/containers that the reduced resource consumption pays off. Jun 11 07:39:30 mccc: for the vast majority of cases, i'd probably say that sticking to common practises is more efficient in terms of work output Jun 11 07:40:29 That makes sense. The other consideration is I'm already using Yocto in the project for embedded so it would at least share the tool. Jun 11 07:41:10 mccc: it would only share the knowledge. Jun 11 07:45:00 :) thanks again so much for the discussion. Have a good night! Jun 11 07:45:06 mccc: you too. Jun 11 07:58:22 Does anyone know on which branch of openembedded-core I should base my patches ebfore sending them upstream? I based it on master-next but it was rejected by the build/test bot :/ Jun 11 08:09:41 qschulz: use master Jun 11 08:12:23 erbo: thx Jun 11 08:37:22 ndec: sure, i can mention that too. if i should forget, just remind me and point it out in the chat Jun 11 08:38:06 LetoThe2nd: sure! Jun 11 08:54:30 Hello everyone, I have a question about testsdk, is it possible to have the results in JUnit xml format? Jun 11 09:05:04 tprrt: we standardised on json as the output format but it should be trivial to convert to that Jun 11 09:12:44 I'm trying to inegrate nodejs in image file. IMAGE_INSTALL += "nodejs". BUt getting following error ERROR: nodejs-6.10.0-r0 do_package_qa: QA Issue: /usr/lib/node_modules/npm/scripts/dep-update contained in package nodejs requires /bin/bash, but no providers found in RDEPENDS_nodejs? [file-rdeps] Jun 11 09:12:44 ERROR: nodejs-6.10.0-r0 do_package_qa: QA Issue: /usr/lib/node_modules/npm/node_modules/node-gyp/gyp/samples/samples contained in package nodejs requires /usr/bin/python, but no providers found in RDEPENDS_nodejs? [file-rdeps]. Jun 11 09:14:49 luckywho: From the nodejs recipe, you should add bash into the RDEPENDS_${PN} to fix the first error. And for the second error, you should add the inheritance to the python bbclass. Jun 11 09:15:21 1. RDEPENDS_${PN} += "bash" Jun 11 09:17:14 RP: thanks, and where is this json file located? because I only found the file log.do_testsdk. Jun 11 09:40:33 kergoth: (reacting to your answer 4 days ago) so the problem would be a bad interaction between "${SYSROOT_DESTDIR}${base_prefix}/sysroot-providers/" in staging.bbclass and base_prefix = "${STAGING_DIR_NATIVE}" in native.class, which basically means that those 2 classes are mutually incompatible, right ? Jun 11 10:22:12 tprrt: And for the second error, you should add the inheritance to the python bbclass. why? we can add as RDEPENDS_$(PN) += "python"(image filesystem failed at do_makesystem). If i add inherit python. It will look for python.bbclass. I have following python classes. "python3-dir.bbclass python3native.bbclass python-dir.bbclass pythonnative.bbclass". Jun 11 10:41:29 Hi guys, how to configure the image correctly to use the 4G modems? f.e. I have the HUAWEI E3372 modem. By default it initializes in 'mass storage' mode and has vid/pid 12d1:if01.. So, I need the usb-modeswitch-{data} recipes. So, I have added this recipes to my image as: IMAGE_INSTALL_append = "usb-modeswitch \ usb-modeswitch-data"... But, the usb mode does not switched in a result... and my modem still detected as a 'mass storage'... Jun 11 10:42:50 I looked in /usr/share/usb_modeswitch that there are present a configuration for my modem.. in a file 12d1:1f01.. Jun 11 10:45:50 Ahh.. seems, I need to it manually, like: usb_modeswitch -v 12d1 -p 1f01 -c /usr/share/usb_modeswitch/12d1\:1f01 Jun 11 11:07:08 luckywho: Sorry, you should add ${PYTHON_PN} to RDEPENDS_${PN}. Jun 11 11:12:03 kuzulis: for this to be automatic, you may need to make a modification in a struct of the kernel: static const struct usb_device_id option_ids[] drivers/usb/serial/option.c. Jun 11 11:18:26 tprrt: Why if I try to create an udev rule instead? Is it will help? Jun 11 11:25:06 tprrt: I have added RDEPENDS_${PN} += "bash ${PYTHON_PN}". I'm getting follwoing error. error: ext4_allocate_best_fit_partial: failed to allocate 2 blocks, out of space? | fs_config_file: /home/poky/build/tmp-glibc/work/linux-gnueabi/machine-image/1.0-r0/rootfs-fsconfig.conf Jun 11 11:25:06 kuzulis: it is also a right solution, implement an udev rules calling usb_modeswitch Jun 11 11:30:13 tprrt: ok, many thanks Jun 11 11:31:46 tprrt: TMPDIR/log/oeqa/testresults.json Jun 11 11:34:17 RP: was pulling hairs trying to reproduce the gtk failure, then realized I was building gtk+ (e.g. 2.x), not gtk+3 :) Jun 11 12:02:33 kanavin: sorry, I eventually realised it was a resource issue, I think Jun 11 12:02:50 kanavin: we're getting too many hard to track down odd issues atm :( Jun 11 12:08:10 RP: Thanks for your help. Jun 11 13:31:52 removing a couple of extra defs finally leads me to a satisfactory recipe-sysroot-native being deployed to user recipes, but the fact sysroot-destdir/ contains a duplication of the whole directory tree still makes me nervous Jun 11 13:38:57 yann: if you mean for native recipes, that is necessary Jun 11 13:39:35 it looks odd, it isn't when you realise that sysroot-destdir is a sysroot, the files placed there are installed at their final end user paths, prefixed by the DESTDIR Jun 11 13:41:07 hm, but then they aren't ever going to be used at that place, since they're relocated for each recipe using them Jun 11 13:42:29 anyway, a short note in staging.class or native.class documentation would help avoid the confusion, I'd say :) Jun 11 13:43:33 yann: they might not be used at that exact path but they will be used at a location like that and other things will be at paths relative to the path. It does help a lot to install like that Jun 11 13:43:37 yann: patches welcome Jun 11 13:44:01 RP: I mean the issue that is specific to the gtk+3 version upgrade Jun 11 13:44:33 kanavin: ah, and you were building gtk+ locally, right... Jun 11 13:44:41 kanavin: sorry, my brain is fried atm :/ Jun 11 13:45:12 yes, no problem. once I sort that out, there are a few spare cycles I could use to help Jun 11 13:46:18 RP: as usual, I'm a bit wary when it comes to documenting a behaviour I just discovered :) Jun 11 13:46:54 btw, the lwn discussion under your article is a bit discouraging: people did not fail to notice that a) the failure was not picked up until a kernel developer hit the problem locally; b) the failure made it through the kernel review and testing process into stable kernele releases Jun 11 13:47:37 kanavin: there are certainly problems and things that could have happened better Jun 11 13:47:43 Is that public yet? Jun 11 13:47:57 kanavin: equally we could have been totally oblivious to it instead so I'd say we got better Jun 11 13:48:04 JPEW: yes Jun 11 13:48:25 Ah, found it Jun 11 13:48:27 JPEW: https://lwn.net/Articles/788626/ Jun 11 13:48:34 RP: thanks Jun 11 13:55:07 kanavin: I think it got the idea out there that distro testing like we're doing can help the kernel. Next time we send a bug, just maybe they may pay more attention Jun 11 13:56:25 RP: It's a good article Jun 11 13:57:54 Hrmm, perl is encoding the absolute path to miniperl in its source... this is not reproducible :( Jun 11 13:58:31 JPEW: thanks :) Jun 11 13:58:41 JPEW: no, that is bad :( Jun 11 14:03:15 yann: if native used a normal prefix like / or /usr, it’d be troublesome to do the relocation, as part of that is a sed replacement, and you can’t very well go replacing every instance of “/“. That said, we could probably just as well use a specific placeholder, I think. Wouldn’t buy us much though Jun 11 14:03:33 * kergoth yawns Jun 11 14:17:43 yann: we never used to relocate things and this code does date from then. it works well, we have other things which cause problems... Jun 11 14:18:19 kergoth: how much would we change if we started doing this from scratch today? :) Jun 11 14:59:08 ndec: no timing glitch today! Jun 11 15:00:00 FYI I'm in the twitch chat, but on a meeting.. so I might be delayed if needed... Jun 11 15:00:09 fray: noted, thanks! Jun 11 15:04:00 RP: heh, indeed. could take a little inspiration from nix's individual checksum-based prefixes, perhaps Jun 11 15:04:04 * kergoth yawns Jun 11 15:04:13 joined Jun 11 15:32:54 RP: not sure the pylint patchtest is doing the right thing Jun 11 15:34:24 rburton: it's running python3 right? Jun 11 15:35:40 no idea what the test does, but its erroring in a stupid way Jun 11 15:36:17 I found the code, trying not to look too hard ;) Jun 11 15:37:16 I think linting has grown up a bit since 2016... Jun 11 15:42:12 rburton: it probably isn't. I thought you meant the one on the autobuilder for a second Jun 11 15:57:09 unbelievable how a fly around you is when you're already trying to explain something and have a beer! Jun 11 15:57:18 *how annoying Jun 11 15:59:57 I've always wanted to make a fly tracking laser... Jun 11 16:00:20 mckoan|away: thanks for the input, BTW Jun 11 16:00:35 LetoThe2nd: sorry I was in the other meeting :( Jun 11 16:00:58 RP: no problem. was a really slow session anyways Jun 11 16:01:22 JPEW: the midges we get in the forests around here would just mob such a device :/ Jun 11 16:01:27 at least here its vacation season Jun 11 16:01:40 LetoThe2nd: what is "vacation"? Jun 11 16:02:07 I shouldn't joke, I am getting better at taking breaks Jun 11 16:02:15 RP: when you have to pay for your drinks yourself, but on the other hand do not have to code while emptying them Jun 11 16:02:30 as opposed to not paying, but having to code while.... Jun 11 16:02:46 RP: glad to hear, seriously Jun 11 16:03:10 hope i didn't talk too much nonsense, but neither you nor fray nor kergoth screamed! :) Jun 11 16:03:11 LetoThe2nd: working from home doesn't quite work like that :) Jun 11 16:03:31 LetoThe2nd: I wasn't there to scream :( Jun 11 16:03:44 hehe Jun 11 16:03:45 LetoThe2nd: sounds like you had good company though Jun 11 16:04:08 little company, i think. but well see. request #1: "make past stream sessions available" Jun 11 16:04:28 anyways, see you laters. family time now. Jun 11 16:04:54 LetoThe2nd: thanks for doing it! Jun 11 16:06:11 LetoThe2nd: we are not saying it enough ... but thank you for your work on the live sessions! today's session about packaging was good. it's a difficult thing to understand for new people... it was a good intro. Jun 11 17:26:03 RP, the opk patches for thud included a testcase. Should I bug it so we might create a OEQA test? Jun 11 17:42:28 hm, looks like I sent my doc patch to the wrong list, should have been yocto@yoctoproject.org, right ? Should I just resubmit to proper list ? Jun 11 17:46:01 armpit: could create a newcommer bug, yes Jun 11 17:46:07 k Jun 11 17:46:17 armpit: good thinking Jun 11 17:46:45 it happens once in a while ; ) Jun 11 18:30:25 ndec: no need to, its just the form of deal i can offer. we use yocto/oe in our daily work, but i don't have company money to hand out. so this is what i can do. in a nutshell: you help me in getting my work done, i help you in getting yours done. Jun 11 18:38:16 I'm working on a poky-tiny build for a firmware flash part (4MB). Following the basic steps here: https://wiki.yoctoproject.org/wiki/Poky-Tiny Jun 11 18:39:12 bsp_definition is dropping me into the bb_fatal for "Could not locate BSP definition" Jun 11 18:39:23 Did I miss a step setting up the defconfig? Jun 11 18:43:12 stephano: whoa. sorry, but that article seems to be quite outdated. Jun 11 18:44:25 stephano: for example eglibc vs. uclibc hasn't been a thing for years. Jun 11 18:45:01 LetoThe2nd: Yeah, I realize that poky-tiny needs love. It misses Darren. :) Jun 11 18:45:49 LetoThe2nd: I'm using musl. Just a vanilla poky master clone. Jun 11 18:47:15 stephano: IIRC even poky master, just switching distro to poky-tiny broke just recently, for a missing kernel (some typo thing) Jun 11 18:47:58 stephano: i'd look at your bsp if it refers to some form of DISTRO specifically. Jun 11 18:48:36 LetoThe2nd: Okay, will do. Jun 11 18:49:09 stephano: respectively, start with qemu, and only add your bsp if that builds and boots Jun 11 18:53:04 LetoThe2nd: Will do. The BSP might be meta-intel eventually, but honestly, running out of MinnowBoard flash? Who knows what will work. :) Jun 11 18:53:34 LetoThe2nd: We just recently freed up 4mb of flash on the Minnow build, so I figured I'd try to cram Yocto in there. :) Jun 11 18:53:52 You can do it Poky-Tiny!!! Jun 11 18:54:21 stephano: oh, almost nothing is impossible. but 4mb including a kernel on x86 is a very special kind of fun. on ARM, no big deal. Jun 11 18:59:57 LetoThe2nd: indeed. I will put my thinking cap on. Jun 11 19:00:34 stephano: have fun, then! Jun 11 19:12:46 LetoThe2nd: 2.7 tag worked great. :) Jun 11 19:39:21 hey stephano welcome back :) Jun 11 19:40:10 LetoThe2nd: tiny linux kernel? find tom zanussi :) Jun 11 19:40:43 erm stephano ^^^ Jun 11 19:42:03 rburton: Tom! Is he still at Intel, or does he work at VMware now... :p Jun 11 19:42:47 I never left, I was just sucked into a vortex of conferences. Jun 11 19:45:13 stephano: i think he is still at intel... Jun 11 19:45:43 but he can tell you how small a kernel can get with minimal effort, even if the knowledge is a few years stale Jun 11 19:46:15 rburton, Perfect, thanks! I'll send him an AR. :) Jun 11 19:50:01 Awww, there's even a video... https://youtu.be/rSaU091gcW8 Jun 11 19:50:19 there we go :) Jun 11 19:50:49 Queue Andrew Lloyd Webber's Memories... Jun 11 19:54:44 hi Jun 11 19:56:32 anybody Jun 11 19:56:47 yocto is the main oe distro ? Jun 11 20:01:22 what kernel does it uses ? Jun 11 20:02:17 blscoe: Linux kernel... exact version depends on a lot of factors Jun 11 20:02:54 by linux kernel Jun 11 20:03:08 you dont mean android kernel right ? Jun 11 20:04:51 Err, I'm particularly sure if I can differentiate between them :) The kernel you use is going to largely depend on what hardware you are targeting Jun 11 20:05:14 (at least in my expirence) Jun 11 20:05:29 shit Jun 11 20:05:31 ok Jun 11 20:05:51 another question Jun 11 20:06:40 whats the default root password ? I have an old password that is oelinux1 Jun 11 20:07:17 but doesnt work anymore Jun 11 20:09:45 I don't actually know... there might not be one (sometimes root is configured to not allow *any* password login) Jun 11 20:10:44 i tryed empty password but no... Jun 11 20:19:15 blscoe: default password is not set, so you can't actually login. if debug-tweaks was set, then it is empty Jun 11 20:20:03 I needoh, and how exactly are you supposed to use ther os ? Jun 11 20:20:36 oh, and how exactly are you supposed to use the os ? Jun 11 20:21:13 set a r oot password, add a user, or enable debug-tweaks. Jun 11 20:21:24 hardcoding a password out of the box is a security flaw Jun 11 20:21:51 same fore oe core ? Jun 11 20:22:02 same for oe core ? Jun 11 20:22:30 i don't understand the question. Jun 11 20:22:43 yocto's buildsystem *is* oe-core, along with a few other bits Jun 11 20:23:07 ok Jun 11 20:23:37 I need the root password for the quectel EC21 / EC25 Jun 11 20:24:05 it used to be oelinux1 , but not anymore Jun 11 20:24:16 ask quectel? Jun 11 20:24:36 oe is a tool to build distros Jun 11 20:25:03 just because the quectel ec21 has a default password of oelinux1 doesn't mean anyone else does Jun 11 20:27:40 ok. but someone here may know Jun 11 21:50:48 when using devtool to upgrade a recipe, what is the best way to handle patches that cannot be applied on the upgraded source? Jun 11 22:06:22 psrcode: it should be a typical git rebase conflict resolution operation Jun 11 22:07:03 k, I'm mostly interested in discarding part of the patches Jun 11 22:07:33 anyway found another way for now that was a bit less convuluted, will revisit devtool next time Jun 11 22:08:54 psrcode: was meaning to ask you about the lttng-modules patch sitting in -next Jun 11 22:09:17 what about them? Jun 11 22:09:50 the one for 5.1? Jun 11 22:11:47 RP: ^ Jun 11 22:13:16 psrcode: yes, those ones. I'd prefer to have a release to switch to rather than patches I guess :) Jun 11 22:13:35 psrcode: so I guess I'm asking if a release is imminent or whether adding that patch makes sense Jun 11 22:14:23 RP: hmmmm, yeah when is the next official release on your side? Jun 11 22:16:13 psrcode: we're on our interim milestone releases. M1 just built, M2 is mid july. Main release October Jun 11 22:16:36 psrcode: I just don't like adding and then removing patches. We may want to consider a git version of lttng-modules people could use instead for new kernels? Jun 11 22:16:41 we could probably cut a 2.10.10 patch level release that would include all the fixes (let me double check) Jun 11 22:17:17 If you're using bleeding edge kernels, you probably don't mind a git version of lttng-modules to go with it Jun 11 22:17:39 following the stable branch of the 2.X release would make sense Jun 11 22:17:43 master also Jun 11 22:18:02 actually master would be good Jun 11 22:18:19 is there a way to configure wich recipe to take based on the kernel? Jun 11 22:18:24 version* Jun 11 22:21:48 yeah after double checking all proposed patches are in the stable 2.10 branch, I'll check with the maintainer if we can cut a release for you Jun 11 22:22:43 but do you plane on moving to 5.2 or higher? because otherwise it is an endless chase ... Jun 11 22:22:49 plan* Jun 11 22:24:57 psrcode: This is what worries me. I think adding a git recipe for this reason may be the better answer Jun 11 22:25:22 psrcode: it wouldn't be magic but it would just be a single extra PREFERRED_VERSION setting which people can manage Jun 11 22:26:15 psrcode: I can ask the patch submitter to look at that as an alternative Jun 11 22:26:39 would be nice to be able to set a preferred version based on the kernel version chosen, anyway Mathieu is currently looking into cutting the release, should take care of the current patchset Jun 11 22:27:20 anyway I got to go, but way git recipe get my +1 Jun 11 22:27:35 way -> yeah Jun 11 22:28:00 especially for lttng-modules Jun 11 22:30:18 New news from stackoverflow: include tar.bz image in wic image Jun 11 22:39:57 I'm getting an rpm build error Jun 11 22:40:14 is there a way to debug the generated buildspec? Jun 11 22:40:29 after I run bitbake Jun 11 22:45:22 psrcode: thanks Jun 11 22:57:52 FWIW, I'm updating and testing a build of current vim now. Jun 11 23:38:33 Tartarus: cool :) **** ENDING LOGGING AT Wed Jun 12 03:00:27 2019