**** BEGIN LOGGING AT Wed Oct 02 02:59:57 2019
Oct 02 03:31:51 <jeranio> Hello
Oct 02 03:32:24 <jeranio> Is the next Coding live Yocto on the 8th October?
Oct 02 03:32:35 <jeranio> 5pm Berlin Time ?
Oct 02 08:16:09 <LocutusOfBorg> hello, I have a simple question for imx6q mfgtool handling, is anybody out there to help?
Oct 02 08:16:36 <LocutusOfBorg> the question is: I have an imx6qsabresd, and I would like to build the mfgtools artifacts via yocto (e.g. warrior is fine)
Oct 02 08:17:05 <LetoThe2nd> LocutusOfBorg: pick your poison: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=mfgtool
Oct 02 08:19:17 <LocutusOfBorg> I fail to find documentation on the "current" mfgtool version and documentation on the build procedure, e.g.
Oct 02 08:20:07 <LocutusOfBorg> LetoThe2nd, this fails.... for some reasons, 1) meta-fsl-arm is dead, 2) fsl-image-mfgtool-initramfs is not buildable for imx6q but only for imx6s
Oct 02 08:20:43 <LocutusOfBorg> 3) imx-uuc was working really good, it contains even a patch done by me... but it relies on FSL_UTP feature, that is now dropped on the kernel side, so it seems to be not working anymore
Oct 02 08:20:59 <LocutusOfBorg> 4) new mfgtool seems to have changed the way of communicating, deprecating FSL_UTP
Oct 02 08:21:21 <LocutusOfBorg> 5) I can't find proper documentation on the current way, and I don't want to build an oooooold yocto version just to have mfgtool artifacts
Oct 02 08:22:30 <LetoThe2nd> LocutusOfBorg: well then your best chances are probably poking the layer maintainer if there's something in the making, or actually sending patches. the layerindex gives you the current publicly available state, and if that is obsolete, then... :-(
Oct 02 08:24:05 <mckoan> LocutusOfBorg: the new name of meta-fsl-arm is meta-freescale
Oct 02 08:24:29 <mckoan> LocutusOfBorg: https://freescale.github.io/
Oct 02 08:24:31 <LocutusOfBorg> mckoan, yes, since some years, but the stuff in meta-freescale is not working, as said above
Oct 02 08:24:52 <LocutusOfBorg> I was even the probably first person to complain when they moved layer without making people aware...
Oct 02 08:44:37 <yacar_>  zeddi: I worked on the bug yesterday, I've added SPDX Identifier to scc and cfg files, there's a file : cfg/debug/kgdb/debug-kgdb-serial-console.scc~ which looks like an open file by an editor, should I remove the file?
Oct 02 08:45:17 <yacar_> zeddii: I misspelled your pseudo sorry !
Oct 02 08:49:38 <prabhakarlad> Hi all, what is the correct way to append COMPATIBLE_MACHINE for a recipe
Oct 02 08:55:21 <mckoan> prabhakarlad: can you describe better your question?
Oct 02 08:55:42 <Domin1k> prabhakarlad: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#appending-and-prepending i prefere +=
Oct 02 08:56:15 <Domin1k> prabhakarlad: COMPATIBLE_MACHINE is just a variable
Oct 02 08:59:32 <prabhakarlad> Domin1k COMPATIBLE_MACHINE += doesnt work, nor does _append
Oct 02 09:03:19 <Domin1k> prabhakarlad: oh sorry im wrong. it looks like it should be made like this COMPATIBLE_MACHINE = "qemux86|qemux86-64"
Oct 02 09:05:13 <prabhakarlad> yes, but how do we append it in a bbappend file ?
Oct 02 09:09:03 <Domin1k> prabhakarlad: i would guess doing COMPATIBLE_MACHINE += "|my_new_machine". But if you say this does not work i would wait until an yocto expert answers your question. I'm just a rookie that is trying to help.
Oct 02 09:10:47 <LetoThe2nd> Domin1k: i'd guess thats pretty close, yet _append instead of +=. because append doesn't insert a blank space
Oct 02 09:12:54 <Domin1k> LetoThe2nd: (y)
Oct 02 09:13:13 <prabhakarlad> LetoThe2nd, the original bb file has COMPATIBLE_MACHINE = "(qemux86|qemux86-64)" so now when I create a bbappend file and do +=/append it doesnt work.
Oct 02 09:15:32 <Domin1k> prabhakarlad: it looks like the ) makes it unappendable
Oct 02 09:23:47 <Domin1k> Im wondering if ther is a good way handling with big rescources in bitbake? I Have a Repo with a lot of rescources like Images, Videos etc. I would like to install them to my Image directly within the bitbake process. But it looks like the bitbake duplikates these files quite often. I have the fetched resources in the workdir, a duplicate as a
Oct 02 09:23:47 <Domin1k> tar.gz inside the folder "build/download/", the rpm-package and finaly inside my wic-image. By now i need about 1.2 TB of diskspace for a build.
Oct 02 09:26:55 <LetoThe2nd> Domin1k: all which is some form opf payload isn't really meant to go into the layers. the layers, as the meta- already suggests, should not contain those images, videos, etc.
Oct 02 09:27:22 <LetoThe2nd> Domin1k: if you have already properly split them out into a payload recipe that fetches them, then i'm not aware of any redcution technique at the moment.
Oct 02 09:34:56 <Domin1k> What do you actually mean with a payload recipe? I have a recipe that builds my app within my own foo_poky/meta-foocraft/ layer inside this recipe i have seprerated the resources in a package with PACKAGES += "${PN}-resources" FILES_${PN}-resources += "/mnt/app/resources/*"
Oct 02 09:37:51 <LetoThe2nd> Domin1k: seperating means, the recipe pulls the resourced from some out-of tree location, like ftp or whatever, as does not acutally contain them as files next to the recipe.
Oct 02 09:42:08 <Domin1k> LetoThe2nd: I pull them from a clearcase-vob (VCS-repository) so that should be ok. I have to ask my boss for another diskupgrade then.
Oct 02 09:43:09 <LetoThe2nd> Domin1k: "you wann make big app boss, you gonna big disk boss""
Oct 02 09:43:16 <LetoThe2nd> +buy
Oct 02 09:44:07 <Domin1k> LetoThe2nd: for a development scenario this isn't that much relevant. I could build the image without the app resources and work with a nfs mount from my device to the resources repo on my workstation
Oct 02 09:47:56 <Domin1k> LetoThe2nd: the final size of the wic image is just 234 GB but needing 5 times that much to build this image sounds a bit crazy.
Oct 02 09:49:35 <LetoThe2nd> Domin1k: our images are usually ~40M and we need 30GB or 40GB to build them. don't you think my "why does it need a thousand times the space for the build" sounds more crazy than your 5?
Oct 02 09:53:58 <Domin1k> LetoThe2nd: My boss thinks we would do better using a ubuntu image. At the moment we are using a stripped down debian image but i'm sure yocto will help us to build a better image and solve a lot of issues that we have at the moment with our current image-build-environment.
Oct 02 09:55:45 <LetoThe2nd> Domin1k: it all depends on the use case, and using debian/ubunt can be totally valid too. it all depend.
Oct 02 09:56:53 <LetoThe2nd> Domin1k: you can of course use some evil magic and "inject" the payload through some rootfs postprocessing, but it kinda defeats the point of OE/yocto. and if thats only for the couple of bucks that some disk space costs, its a bad deal taking the maintenance effort into account.
Oct 02 11:10:56 <__angelo> hi folks :) question : i see different directory layouts when yocto-based distros are created, what should be a good directory layout to use ?
Oct 02 11:11:19 <rburton> personally i put bitbake and all the layers alongside each other
Oct 02 11:11:24 <rburton> assuming thats what you mean
Oct 02 11:11:54 <__angelo> rburton, yes. I find different layouts around, probably coming from different tutorial/how to
Oct 02 11:12:33 <__angelo> rburton, so you use kind of older oe style, right ?
Oct 02 11:12:48 <rburton> not sure i'd call it old
Oct 02 11:14:35 <__angelo> ok. so you are not using poky stuff ?
Oct 02 11:16:15 <rburton> that' a good example of bitbake and layers all in one place
Oct 02 11:16:33 <rburton> *poky is an example*
Oct 02 11:16:43 <rburton> if you want your own distro make your own distro
Oct 02 11:16:52 <rburton> otherwise you'll be upset when eg poky changes
Oct 02 11:17:07 <rburton> (which is does, often)
Oct 02 11:17:13 <__angelo> many thanks
Oct 02 11:25:27 <__angelo> about  "upset when eg poky changes", this is not totally clear. Can i fix to a revision and work on that ?
Oct 02 11:26:47 <LetoThe2nd> __angelo: for example when you update from sumo to thud, to warrior, there might be changes in poky
Oct 02 11:32:57 <__angelo> LetoThe2nd, ok
Oct 02 11:32:59 <pepone> Hey, I'm trying to track down a bug with network stack in core-image-minimal, what is the default libc build with core-image-minimal?
Oct 02 11:33:02 <__angelo> thanks
Oct 02 11:34:17 <LetoThe2nd> pepone: glibc
Oct 02 11:36:59 <pepone> I getting some issues with TCP close connection, specially sever sending TCP FIN/RST gets unoticed by client, server connection gets closed but client conn remains open
Oct 02 11:37:21 <pepone> testing with a bunch of distros and only getting this issues with Yocto Warrior
Oct 02 11:40:05 <kanavin_> pepone, are you using the latest warrior?
Oct 02 11:40:33 <pepone> 2.7.1
Oct 02 11:40:43 <rburton> pepone: what kernel though
Oct 02 11:40:47 <pepone> 38d5c8ea98cfa49825c473eba8984c12edf062be
Oct 02 11:40:55 <rburton> pepone: most BSPs provide their own kernel
Oct 02 11:41:20 <kanavin_> particularly, you probably need this fix
Oct 02 11:41:20 <kanavin_> commit f5cc3bf166c8eca58630e267cc58bdd88fbc6e95
Oct 02 11:41:22 <kanavin_> Author: Bruce Ashfield <bruce.ashfield@gmail.com>
Oct 02 11:41:22 <kanavin_> Date:   Fri Apr 26 10:52:17 2019 -0400
Oct 02 11:41:22 <kanavin_>     linux-yocto/5.0: integrate TCP timeout / hang fix
Oct 02 11:41:22 <kanavin_>     
Oct 02 11:41:31 <kanavin_> it was a bug in 5.0 kernels
Oct 02 11:41:43 <pepone> 5.0.3-yocto-standard #1 PREEMPT Mon Sep 9 17:44:34 UTC 2019 armv7l armv7l armv7l GNU/Linux
Oct 02 11:43:47 <pepone> kanavin_: Thanks I will give it a try if I manage to update the BB kernel
Oct 02 11:44:46 <rburton> that was in 2.7.1 though
Oct 02 11:47:54 <pepone> Yes I have that commit in my tree
Oct 02 13:06:37 <zeddii> RP: at least we got a bit of interest in the strace report on lkml.
Oct 02 13:07:13 <RP> zeddii: yes, I saw. Hopefully we can get them to reproduce it and then get somewhere :)
Oct 02 13:08:15 <zeddii> I had to scramble to dig up the manual build steps for it, I hope I didn't screw them up :D
Oct 02 13:11:50 <RP> zeddii: we'll see what they say and worst case we may have to come up with a simpler reprocuder
Oct 02 13:11:59 <RP> vmeson: ^^^
Oct 02 13:27:37 <kanavin_> zeddii, do you have a link?
Oct 02 13:31:00 <zeddii> kanavin_, https://lkml.org/lkml/2019/10/1/789
Oct 02 13:32:25 <kanavin_> zeddii, thanks, hope they manage to reproduce
Oct 02 13:32:43 <kanavin_> zeddii, it does not happen on opensuse's 5.2 kernel though :(
Oct 02 13:33:17 <thomasd13> When I specify a kernel feature with KERNEL_FEATURES_append , does it matter if this feature is built in the kernel or if it is provided as kernel module?
Oct 02 13:42:15 <zeddii> kanavin_: there may be some kernel config at play then. I saw it on a mainline test that I ran, but I’ll revisit that before they tell me they can’t reproduce it. I suppose I could diff the opensuse 5.2 kernel to see if they have a patch in that area.
Oct 02 13:44:39 <kanavin_> zeddii, yes, also maybe running the test on physical hardware could help narrow it down
Oct 02 13:44:54 <kanavin_> (e.g. nuc or something like that)
Oct 02 13:45:33 <zeddii> I saw it on linux-yocto-dev as well, which is pretty much a raw mainline kernel, so I know it wasn’t fixed in the 5.3 cycle. but the kernel config is very similar to the 5.2 one we use. I’m going to test 5.4-rc1 shortly to see if it is there.
Oct 02 13:46:23 <kanavin_> it might be specific to qemu
Oct 02 13:47:47 <zeddii> I don’t have any h/w test boxes handy to test on. Do we have results for 5.2 on genericx86-64 that don’t show the issue ?  or do we not run those there .. or is that not h/w ? I’m not aware of all the details there.
Oct 02 13:51:14 <kanavin_> I don't think the AB has any real HW, everything runs through qemu, maybe RP can clarify
Oct 02 14:03:14 <RP> kanavin_: all AB stuff runs on qemu. There are manual QA tests, its unclear if they'd run the ptests on the real hardware though
Oct 02 16:16:39 <Crofton> The autobuilder runs on imaginary hardware
Oct 02 16:21:25 <mckoan> Crofton: LOL
Oct 02 17:08:32 <RP> Crofton: I'm now thinking we'd have to number them with imaginary numbers
Oct 02 17:08:48 <Crofton> of course
Oct 02 17:09:05 <Crofton> A guy asked me about this email last night
Oct 02 17:09:06 <Crofton> https://lists.yoctoproject.org/pipermail/yocto/2019-June/045574.html
Oct 02 17:09:13 <Crofton> Looks like no repleis
Oct 02 17:10:33 <JPEW> I was thinking that wouldn't be hard too add an optional QA check for that case.
Oct 02 17:14:34 <Crofton> I you care about reproducible builds AUTOREV in a recipe is a serious issue
Oct 02 17:15:15 <JPEW> Right, I think they understood that the layers are poorly written(?) since AUTOREV is non-optional, but there's no tool to detect it ATM
Oct 02 17:17:06 <JPEW> The hard part is making AUTOREV a valid option (e.g. not fail QA) when it does make sense and someone does actually want it...
Oct 02 17:17:19 <JPEW> Maybe tie the QA check to the reproducibl_build.bbclass?
Oct 02 17:18:10 <JPEW> Sounds like I'm volunteering to reply to the email :)
Oct 02 17:21:58 <Crofton> RP ^^^
Oct 02 17:22:41 <RP> JPEW: sounds like the right track to me FWIW
Oct 02 17:22:46 <Crofton> ah yes, I was going there was a class that flagged the system we super care about reproducibilty
Oct 02 17:23:41 <Crofton> Stuff like this is why we need to get out and actually meet with people. He pointed the email out to us last night
Oct 02 17:24:14 <RP> Indeed. I tend to feel bad as there are a lot of emails that should get replies that don't
Oct 02 17:25:08 <Crofton> https://blog.3mdeb.com/
Oct 02 17:26:41 <Crofton> https://blog.3mdeb.com/2019/2019-08-07-qubes-os-and-3mdeb-minisummit/
Oct 02 17:28:02 <Crofton> second blog post needs review
Oct 02 17:51:34 <JPEW> RP, Crofton: Does this look OK: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13567 ?
Oct 02 17:51:35 <yocti> Bug 13567: normal, Undecided, ---, ross.burton, NEW , Add QA check for recipes that use AUTOREV by default
Oct 02 17:53:08 <Crofton> Yes, we don't want to trip people expecting a reproducible build with autorev recieps
Oct 02 18:30:15 <yocti> New news from stackoverflow: Failure while compiling apt - Yocto <https://stackoverflow.com/questions/57294288/failure-while-compiling-apt-yocto>
Oct 02 19:30:23 <yocti> New news from stackoverflow: Adding sqlite Qt5 plugin in Yocto <https://stackoverflow.com/questions/58208176/adding-sqlite-qt5-plugin-in-yocto>
Oct 02 19:36:19 <Tartarus> RP: Can you tag bitbake 1.43.2 please?
Oct 02 19:37:09 <RP> Tartarus: I can but there aren't many tags in there :/
Oct 02 19:37:34 <Tartarus> There's only 44 tags I see, yeah
Oct 02 19:37:56 <Tartarus> imho, tags for BB_MIN_VERSION values is helpful for ease of switching branches around
Oct 02 19:38:44 <RP> Tartarus: probably, I just now worry which other ones I'll be asked for
Oct 02 19:39:45 <Tartarus> sec ;)
Oct 02 19:40:13 <Tartarus> 1.39.1, which is what thud asks for
Oct 02 19:40:28 <Tartarus> older than that is no longer actively supported
Oct 02 19:40:33 <RP> already there
Oct 02 19:40:33 <Tartarus> So shrug
Oct 02 19:40:41 <Tartarus> er
Oct 02 19:40:46 <Tartarus> heh
Oct 02 19:40:50 * Tartarus kicks bitbake
Oct 02 19:40:53 * Tartarus kicks git
Oct 02 19:41:03 <RP> careful, bitbake can kick back ;-)
Oct 02 19:41:55 <Tartarus> So, yeah, I think with that, that's enough tags now
Oct 02 19:42:12 <Tartarus> and hopefully a mental note to tag bitbake when bumping BB_MIN_VERSION in the future will be 'it'.
Oct 02 19:42:55 <RP> Tartarus: I will try
Oct 02 19:43:01 <Tartarus> thanks!
Oct 02 19:49:07 <radsquirrel> is there something written down out there that helps you decide when to use = vs ?= vs ??=
Oct 02 19:49:19 <radsquirrel> and _append vs +=
Oct 02 19:49:49 <radsquirrel> from a best practices point of view.
Oct 02 19:55:19 <kroon> radsquirrel, there is always the bitbake manual
Oct 02 19:55:31 <kroon> radsquirrel, I think I've seen some bitbake cheat sheet aswell
Oct 02 20:00:42 <mischief> what is the variable ROOTFS_BOOTSTRAP_INSTALL for?
Oct 02 20:03:36 <yates> do .rpm packages provide a method to run pre- and/or post-install scripts, or are they basically just files which get copied over?
Oct 02 20:04:33 <yates> and/or does "smart" provide such a capability on top of the .rpm file installation?
Oct 02 20:07:02 <bluelightning> yates: we do intrinsically support pre/postinstall (and pre-postuninstall) scripts, and they get funnelled through into the packages (rpms in this case)
Oct 02 20:07:20 <bluelightning> yates: smart supports them in as much that it calls rpm and rpm will run them
Oct 02 20:08:01 <bluelightning> the only "special" bit is that when building the image, we try to execute them on the build host, and if they succeed then great - if not, they get deferred to first boot
Oct 02 20:08:14 <bluelightning> (which of course won't work if you are using a read-only rootfs)
Oct 02 20:09:02 <bluelightning> there is a little bit of magic to explicitly mark postinsts that are known to require running on the target in more recent versions but if you're talking about smart I suspect that won't apply in your case
Oct 02 20:09:44 <bluelightning> the best practice is to try to ensure the postinstalls *can* run during image construction
Oct 02 20:10:06 <bluelightning> what that really means is use $D in front of paths
Oct 02 20:10:15 <bluelightning> and don't assume any special hardware is there
Oct 02 20:10:36 <yates> bluelightning: the scripts are put into the .rpm file?
Oct 02 20:11:20 <yates> what do you mean by "first boot"?
Oct 02 20:11:25 <yates> deferred to first boot?
Oct 02 20:12:13 <kergoth> it means exactly what it says. they run the first time the device boots. which isn't viable on an r/o fs
Oct 02 20:14:03 <yates> why can't you run a first-boot script on a r/o fs?
Oct 02 20:14:25 <yates> because they have to be deleted after first boot?
Oct 02 20:15:24 <yates> bluelightning: so it seems there is a provision in both the .rpm format and in yocto to do this.
Oct 02 20:15:56 <bluelightning> yates: yes and yes
Oct 02 20:16:00 <yates> does the now-ancient morty support this?
Oct 02 20:16:04 <bluelightning> yes
Oct 02 20:16:14 <bluelightning> we've had it for a very long time
Oct 02 20:16:23 <yates> bluelightning: thanks for this info. Very valuable.
Oct 02 20:16:27 <bluelightning> np
Oct 02 20:53:46 <radsquirrel> kroon: I've definitely read the bitbake manual.
Oct 02 20:54:46 <radsquirrel> it describes the differences in behaviors between the different operators very well.
Oct 02 20:54:55 <radsquirrel> was looking more for the "why"
Oct 02 20:59:18 <radsquirrel> I have been thinking about starting a blog.  my first post might be called "how to choose a bitbake variable assignment operator"
Oct 02 21:00:09 <ecdhe> that's great radsquirrel
Oct 02 21:00:19 <ecdhe> I still don't know what ?= means
Oct 02 21:00:54 <ecdhe> I'm not sure how to search for it on google or what the name of the operator is
Oct 02 21:01:01 <radsquirrel> it means if the same variable has been assigned previously with = it won't take your assignment with ?=
Oct 02 21:01:39 <radsquirrel> by previously I mean in the global configuration (so something assigned by way of bitbake.conf)
Oct 02 21:02:19 <radsquirrel> or in the case of a recipe and a bbappend, previously would mean the recipe
Oct 02 21:02:33 <ecdhe> nice and contextually ambiguous -- makes debugging so much easier when you can't tell what the effect of it will be just by looking at it.
Oct 02 21:03:00 <radsquirrel> well...I'll see what I can do about the blog :-)
Oct 02 21:03:43 <radsquirrel> and if anyone wants to drop hints on why I might pick = over ?= or ??= over ?= ... feel free.
Oct 02 21:03:49 <radsquirrel> I'll include them.
Oct 02 21:10:07 <mischief> is there a way to specify some packages on a per-machine basis that are initramfs only? or should i invent a new variable?
Oct 02 22:27:33 <kergoth> ugh, the vscode bitbake extensions reliably hang my Remote - SSH workspace when opening a medium sized .inc. at least, the two extensions that work at all do
Oct 02 22:28:01 <kergoth> guess i'll do without highlighting for now..
Oct 02 22:38:32 <khem> kergoth: or switch to neovim :)
Oct 02 22:38:50 <kergoth> that's what i usually use, been playing around with vscode + Remote - SSH recently
Oct 02 22:39:40 <khem> yeah vscode is quite good IDE, I would say
Oct 02 22:40:05 <khem> I use it quite a lot myself but time and again nvim fallback is used :)
Oct 02 22:40:25 <khem> for kernel sources it works fine
**** BEGIN LOGGING AT Thu Oct 03 01:17:59 2019
Oct 03 01:33:19 <yocti> New news from stackoverflow: How to compile a NASM file in Yocto? <https://stackoverflow.com/questions/58211229/how-to-compile-a-nasm-file-in-yocto>
**** ENDING LOGGING AT Thu Oct 03 01:44:01 2019

**** BEGIN LOGGING AT Thu Oct 03 01:47:37 2019
**** ENDING LOGGING AT Thu Oct 03 02:59:57 2019