**** BEGIN LOGGING AT Fri Aug 04 03:00:01 2017 Aug 04 07:37:32 kergoth: I tested the new gist, had to modify the d.getVar("STAMP") to d.getVar("STAMP",True) Aug 04 07:39:13 hi o/ Aug 04 07:39:17 Only a stupid question Aug 04 07:39:18 kergoth: but it fails the same way: setscenes fails under do_populate_sysroot_setscene with exit code '1' - real task will be run instead, and then massively errors under 'runtaskdeps' and do_fetch Aug 04 07:39:35 i'm trying to make the same rdepends for native and cross Aug 04 07:39:46 RDEPENDS_${PN} = XXX doesn't work Aug 04 07:40:33 Is there a way to configure a recipe to disable sstate generation it? Aug 04 07:46:24 morning all Aug 04 07:49:24 morning Aug 04 10:08:50 Now this is interesting: I get "ERROR: vsi-image-1.0-r0 do_rootfs_wicenv: Taskhash mismatch bab73ab34a1aba01309a34f5c0163815 verses c333c3682393bc0e62f2ebe32c3bb3e9 for /srv/builds/yocto-default-dev/sp/yocto/recipes-system/images/vsi-image.bb.do_rootfs_wicenv" Aug 04 10:09:21 I have finally been able to generate the sigdata for these two hashes, and they're equal! Aug 04 10:09:59 that is bitbake-diffsigs lists nothing. Doing bitbake-dumpsig and diffing the output is also equal Aug 04 10:10:17 Why then are the hashes different? Aug 04 10:47:56 Hello. How do I clean the generated SDKs I got via populate_sdk by using bitbake? Aug 04 10:49:53 you mean, delete them from tmp/deploy? Aug 04 10:49:54 use rm? Aug 04 10:55:04 rburton: tmp/deploy only contains the packaged SDK and manifest files as far as I understand... what if I need to clean in such a way so that I rebuild all of the SDK components from scratch next time? Aug 04 10:55:33 the next time I do a populate_sdk I mean Aug 04 10:58:18 Is there a way to configure recipes not to upload to the sstate cache? Aug 04 11:01:13 kanavin: packages/corei7-64-poky-linux/xserver-xorg/xserver-xorg: RDEPENDS: removed "libcrypto (['>= 1.0.2l'])", added "openssl (['>= 1.1.0f'])" Aug 04 11:01:19 kanavin: unexpected fallout from openssl1.1 Aug 04 11:02:38 hm actually it was wrong before - recipe says use openssl... Aug 04 11:03:13 really could do with a nice ui around buildhistory-diff right now Aug 04 11:04:14 aah, libcrypto != libgcrypt, i can't read. that's openssl. Aug 04 11:05:15 kanavin: is there a good reason to not continue splitting libssl and libcrypto out like 1.0 did? Aug 04 11:11:21 A taskhash mismatch A verses B. If I search for files with A and B in their filenames, I find only B and 0 of A. Where then does it get the other taskhash from? Aug 04 11:33:29 hmm, can i bake bootargs into a kernel image? Aug 04 11:35:38 rburton: I rewrote openssl 1.1 recipe from scratch, as 1.0 has astronomical amounts of old cruft. That includes not splitting those libs - how about approaching it it the other way, if there is a specific reason to do it, then it can be done :) Aug 04 11:36:29 kanavin: i guess is there a use case for linking to just libcrypto and not all the rest. xserver appears to be a usecae, it just wants the sha implementation in libcrypto and not the full stack Aug 04 11:38:33 rburton: sure, but realistically, the full stack is very likely to be pulled in anyway Aug 04 12:02:06 Is there a way to run bitbake and parse the recipes and then quit? A kind of do-nothing command Aug 04 12:02:44 bitbake -e recipename >/dev/null Aug 04 12:03:36 or even better --help tells you that --parse-only exists :) Aug 04 12:04:37 kanavin: /etc/ssl/certs/e8de2f56.0 changed symlink target from /usr/share/ca-certificates/mozilla/Buypass_Class_3_Root_CA.crt to Buypass_Class_3_Root_CA.pem Aug 04 12:04:46 kanavin: not sure if thats good, bad, or indifferent :) Aug 04 12:05:30 kanavin: also packages/corei7-64-poky-linux/gstreamer1.0-plugins-bad/gstreamer1.0-plugins-bad-dtls: RDEPENDS: removed "libssl (['>= 1.0.2l']) libcrypto (['>= 1.0.2l'])", added "openssl (['>= 1.1.0f'])" Aug 04 12:05:40 so -bad is linking to both nettle and openssl now Aug 04 12:09:22 kanavin: and does ptest pass on target? Aug 04 12:09:30 rburton: yep, because -bad has a ton of various plugins developed pretty much independently Aug 04 12:10:10 rburton: one plugin is incompatible with openssl 1.1, but can be configured to use nettle, the other is compatible with 1.1 Aug 04 12:10:23 rburton: it does, I checked :) Aug 04 12:10:40 rburton: (small print: checked when ptest support was added, which is not recent :) Aug 04 12:27:27 * rburton wonders if its time to remove oprofile Aug 04 12:34:12 It turns out that the taskhash mismatch only occurs the first time bitbake is run in an empty build (not tmp/ present). Aug 04 12:34:45 If I run another uncorrelated recipe, or even just do --parse-only, I won't run into the taskhash mismatch issue Aug 04 12:35:16 So the immediate fix for the buildserver is to run --parse-only first before starting the actual build. Aug 04 12:35:47 Isn't this very wierd thou? Aug 04 12:38:02 hm yes Aug 04 12:38:21 are you using uninative? (default in poky, not in oe-core iirc) Aug 04 12:39:02 dunno, I am using poky krogoth Aug 04 12:39:20 2.1.2 Aug 04 12:40:16 you know because you enabled it in your distro and the LSB string in bitbake startup header says universal Aug 04 12:41:32 thats very odd though. can you dump the stamps to see what it thinks the difference is now? Aug 04 12:42:00 When I dump the stamps, they are equal! Aug 04 12:42:36 sigdata I mean Aug 04 12:58:24 rburton: g-introspection with meson fixed \0/ Aug 04 12:59:21 rburton: the only issue is that the flags to enable/disable it are non-standardized, and, I suspect, it's not just json-glib that tries to be clever and disables it when cross-compiling Aug 04 13:00:09 just moaned at json-glib maintainer :) Aug 04 13:00:37 rburton: we should moan at webkit maintainers too Aug 04 13:01:15 rburton: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-sato/webkit/webkitgtk/0001-OptionsGTK.cmake-drop-the-hardcoded-introspection-gt.patch Aug 04 13:02:38 rburton: I can publish my branches perhaps? then we'll see what to do next Aug 04 13:02:46 yes, definitely Aug 04 13:09:27 khem: new glibc is much happier Aug 04 13:35:37 rburton: published in akanavin/meson, on poky-contrib (json-glib changes) and metaoe-contrib (meson changes) Aug 04 13:36:14 can you mail me those URLs so i don't forget on monday? :) Aug 04 13:36:30 rburton: yep Aug 04 13:38:09 rburton: done Aug 04 13:38:16 tnx Aug 04 13:39:19 rburton: care to take a quick look now? Aug 04 13:40:02 coffee first :) Aug 04 13:40:12 and rebooting all my stuff to make it ***** work again Aug 04 13:54:37 Hello, I am looking for some help debugging. I have a nvidia recipe that provides virtual/libgl and the mesa recipe has virtual/libgl removed. When do_rootfs is run I keep getting recipes complaining that libgl dependency isn't found Aug 04 14:03:01 It seems I have a race condition while executing a initramfs.do_rootfs. It generates the deb archives (generates the packages and release files). It dies because of "E: Could not open file ./sp-data_99.14.0+hg0-025f4d16d400-r0_armhf.deb - open (2: No such file or directory)". But when I later inspect the dir, its all there. Also note that the initramfs does not use this packages, so its only the deb repo Aug 04 14:03:07 generation which makes this die Aug 04 14:03:22 How can I serialize the execution for this? Aug 04 14:06:09 sounds like a bug in package_deb Aug 04 14:06:20 which is the least tested of all the packaging formats we support Aug 04 14:06:51 rpm is the most tested? Aug 04 14:07:38 rpm and ipkg equally i guess Aug 04 14:08:03 rpm is exercised more but ipkg is simpler :) Aug 04 14:08:16 is "DISTRO" part of the string printed by uname -a? Aug 04 14:08:43 i read the uname manpage and i see no DISTRO Aug 04 14:10:57 DISTRO is an openembedded thing, uname just prints what the kernel tells it Aug 04 14:11:08 so you won't see any mention of DISTRO in the uname man page Aug 04 14:12:55 is it documented somewhere what DISTRO is meant to signify? what should i set it to? Aug 04 14:13:49 if you're asking that then i suggest you start with the yocto documentation Aug 04 14:13:57 ah. section 5.14 Aug 04 14:14:51 yeah thats a good start Aug 04 14:15:43 ok thanks. Aug 04 14:21:52 also, isn't MACHINE a bit of a misnomer? it's not JUST the machine, i.e., the CPU/architecture (x86_64, arm7hf, etc.), more like the machine and board hosting it? Aug 04 14:22:17 and the mfr Aug 04 14:23:39 yates: machine is the board+cpu, cpu architecture is architecture :) Aug 04 14:24:41 kanavin: oh, there is a separate ARCHITECTURE specification somewhere? Aug 04 14:25:00 that helps, thanks Aug 04 14:25:44 yates: not really, architectures are defined through a set of include files in conf/machine/include Aug 04 14:28:55 Is there any documented restriction on package names? Aug 04 14:29:25 Its turns out for me if the package name start with an uppercase no postinst/postrm is generated... changing the name to lower case -> bam it works.. Aug 04 14:29:45 ...and the postinst/rm in this case was generated by systemd.. Aug 04 14:30:06 ...and I'm running pyro Aug 04 14:30:15 roric_: yes, uppercase is forbidden in some package managers Aug 04 14:30:59 rburton, thanks that explains, what about having some QA check for it..? Aug 04 14:31:39 rburton, but I think the bug might be in oe, because it was lacking in the .spec-file to (using rpm) Aug 04 14:32:04 roric_: yocto is what you make it, so you are welcome to write a patch :) Aug 04 14:32:12 rburton, thanks ;-) Aug 04 14:35:22 rburton, speaking of that (sorry for buggering you). I sent a patch fixing broken support for no_recommendations in the new dnf-code. Whats the process if I want to recommend to get that patch into some release branch like pyro? Aug 04 14:36:46 roric_: you rebase the patch on pyro, and send it with [pyro] prefixed in the subject Aug 04 14:37:04 rburton: what is holding up the gstreamer upgrade? Aug 04 14:37:12 dv__: ? Aug 04 14:42:18 . Aug 04 14:43:29 what concerns me in particular is that other patches have been pushed to oe-core, so the previous 1.12 upgrade patches now have conflicts Aug 04 14:55:59 dv_, otavio: oh meant to reply to that, sorry. it was breaking intel but i think that has been fixed and now doesn't apply. if someone can rebase... Aug 04 15:00:13 how can you tell to autotools that you want to build a library.a too ? Aug 04 15:00:58 mckoan: that happens by default but if you're using poky then you'll be passing --disable-static as poky disables static libraries Aug 04 15:01:22 note: poky is an example, only use it for real work if you've read the conf and know what it does :) Aug 04 15:01:29 Is it safe to remove package-management from IMAGE_FEATURES of poky? Aug 04 15:01:40 rburton: so it overrides the normal AC_PROG_LIBTOOL? Aug 04 15:01:51 no, it just passes --disable-static Aug 04 15:02:02 Someone once told me that without it, postinstalls that have to run on target doesn't, but I don't know if that's correct Aug 04 15:02:04 rburton: thanks, I try Aug 04 15:02:17 in general, yocto recipes tend to pass many configuration switches, to ensure deterministic builds Aug 04 15:02:35 sveinse: if you want to remove package management from the images then thats exactly what you want. Aug 04 15:02:48 @mckoan Aug 04 15:03:18 dv_: thx Aug 04 15:03:29 rburton: Not if some package I don't know of depend on some postinstall setup -- if that is indeed the case Aug 04 15:03:40 hence the question Aug 04 15:04:01 particularly my recipe worked well with fido, but I'm switching to morty Aug 04 15:04:43 sveinse: you should write a two line recipe to find out Aug 04 15:04:58 sveinse: if it does then its trivial enough to write a sanity check to abort builds in that case Aug 04 15:05:14 we already do that read only rootfs: pending postinsts and readonly rootfs are incompatible Aug 04 15:05:42 rburton: right, good. Then this statement is false. Aug 04 15:06:23 sveinse: no, i said you should find out. i'm not sure. Aug 04 15:06:36 alright, thanks Aug 04 15:07:35 I'm suspecting that yocto will install a run-once service and run those postinst scripts Aug 04 15:07:45 without any pkg mgmt system Aug 04 15:08:23 yeah i think it persists the scripts that are left behind Aug 04 15:08:28 we definitely have a first boot service to run them Aug 04 15:08:43 but the maze of code is such that its easier to test it than read the code ;) Aug 04 15:08:52 I am now Aug 04 15:19:12 rburton: EXTRA_OECONF = "--enable-static" in the recipe didn't solve Aug 04 15:19:48 mckoan: that would be because no-static-libs uses _append Aug 04 15:20:06 have a look at what poky is actualy doing and you'll see what to do Aug 04 15:20:17 (either 1) don't use poky or 2) clear DISABLE_STATIC) Aug 04 15:27:05 rburton: DISABLE_STATIC = "", it woks, thank you so much Aug 04 15:27:44 rburton: ./meta/conf/distro/include/no-static-libs.inc Aug 04 15:38:04 sveinse: looks like we already have a test for this and it does what you expect: postinsts are saved and ran on boot Aug 04 15:40:41 rburton: yes, that is what Ive found too. The run-postinst script is run by a service by the same name. This in turn calls postinst of ipk, deb or rpm if such is installed. Aug 04 15:44:21 rburton: good deal Aug 04 15:55:09 oh wait, how does the fs respond if you set commit= to a large time? Could it be that my issue with files missing from the deb repo be an error in the fs due to a large commit time? Aug 04 15:55:22 no Aug 04 15:55:41 commit just impacts when stuff actually hits disk, the kernel knows what is really happening Aug 04 15:55:43 Because that is a change we've just had Aug 04 15:56:19 commit just changes how much data you lose if you pull the power Aug 04 15:56:21 yes, I'd expect the fs to be consistent about its meta data. But I'm starting to wonder thou Aug 04 15:56:43 fwi my build machine has a two minute commit on the build disk Aug 04 15:56:58 I think ours was increased to 30 secs Aug 04 15:57:29 if the fs wasn't consistent, no one would bother using it :) Aug 04 15:57:33 would be useless Aug 04 15:57:44 kergoth: welcome back! Aug 04 15:58:47 kergoth: FYI I had to modify the gist to make it work: I had to encapsulate it in try except. Otherwise *everything* returned error code 1 and said bork bork! Aug 04 16:00:19 does fsl mean "freescale layer"? what does fslc mean? Aug 04 16:00:37 freescale linux, iirc Aug 04 16:01:06 you mean fsl == freescale linux? Aug 04 16:01:14 then what is fslc? Aug 04 16:01:15 fsl is short for freescale, yes Aug 04 16:01:21 iirc fscl is freescale community Aug 04 16:01:30 ping otavio ^^^^ Aug 04 16:03:37 i don't understand why this is failing: https://da.gd/UfAl -> https://paste.fedoraproject.org/paste/F0UJU9AQ~qya1bGwYqBFag/ Aug 04 16:04:10 Freescale has two versions, one community and one, uhm, non-community. Let me see if I can find the link Aug 04 16:05:10 ah. Aug 04 16:05:30 the file exists: https://da.gd/POuZg -> https://paste.fedoraproject.org/paste/CxEtFLlRPYaxoGOr4b~tTA/ Aug 04 16:06:27 yates, http://freescale.github.io/doc/release-notes/2.2/ see down "The differences between FSL Community BSP and Freescale Official Release" Aug 04 16:06:30 i'm not using build_x11 but a build under sources/poky Aug 04 16:06:46 sveinse: thanks! Aug 04 16:12:04 does yocto search for files under sources//blah/files/ ? Aug 04 16:12:30 no Aug 04 16:12:55 a file:// uri in SRC_URI is found by seraching FILESPATH Aug 04 16:13:00 which includes quite a few possible locations Aug 04 16:13:07 see also the bitbake user manual Aug 04 16:13:13 then why isn't it finding the file here sources/meta-variscite-fslc/recipes-connectivity/bluez5/files/imx6ul-var-dart/variscite-bt.conf Aug 04 16:14:55 kergoth: i may not have asked my question clearly. Aug 04 16:16:08 when yocto is searching for a file and it considers a path that begins with sources//blah/files/, does it only look for it under the extended path sources//blah/files/ ? Aug 04 16:16:57 no, as i just said, it searches any path in FILESPATH, which includes quite a few paths, including variants for every override listed in OVERRIDES Aug 04 16:17:02 of which MACHINE is one of many Aug 04 16:17:46 ok, i'll do some more searching / reading. Aug 04 16:18:48 assuming file://variscite-bt.conf is in SRC_URI, and assuming the recipe lives in sources/meta-variscite-fslc/recipes-connectivity/bluez5 (the recipe, not a bbappend), and assuming MACHINE is imx6ul-var-dart, then it'll pick it up from sources/meta-variscite-fslc/recipes-connectivity/bluez5/files/imx6ul-var-dart/variscite-bt.conf, yes Aug 04 16:21:50 oh. Aug 04 16:22:35 this might just be a pivotal "teachable moment" for me, then. Aug 04 16:24:48 we are defining our own machine under our own layer but want to utilize as much of the existing meta-varascite-fslc as possible. since our machine name is not imx6ul-var-dart, it is not finding the file. Aug 04 16:25:00 right. the best way to handle that is to use MACHINEOVERRIDES Aug 04 16:25:10 you can have both the original machine name and your new machine name in overrides with that Aug 04 16:25:39 that'll ensure that both variable overrides and files will still be applied an dfound, respectively Aug 04 16:25:52 best way to handle making your own variant of a machine Aug 04 16:25:55 excellent. i'll read up on MACHINEOVERRIDES. Aug 04 16:26:11 we've done that when we need to tweak an upstream machine when we have no control over the upstream layer, make our own version of the machine Aug 04 16:26:38 so your machine .conf can require the other machine .conf and adjust MACHINEOVERRIDES and should be good to go Aug 04 16:27:39 right. Aug 04 16:39:21 now https://da.gd/zcm0 -> https://paste.fedoraproject.org/paste/iE0t2bRXhsW9IS7nKnhxeg/ Aug 04 16:39:56 do i also have to create a COMPATIBLE_MACHINE line in my .conf? Aug 04 16:40:52 COMPATIBLE_MACHINE is a recipe variable used to make the recipe unparseable for machines where it won't b euseful or won't build Aug 04 16:41:06 it's not a variable for use in a machine .conf at all. doing so would affect every recipe you build, not good Aug 04 16:41:24 but no, iirc base.bbclass will check MACHINEOVERRIDES when applying COMPATIBLE_MACHINE, so you should be fine Aug 04 16:51:09 so yes, put a MACHINEOVERRIDES in machine/conf/machine/.conf ? Aug 04 16:51:20 I have to say, I think I'm a pretty smart guy, but this system is very difficult to get a handle on. Aug 04 16:51:34 yates: yes Aug 04 16:51:39 You guys are awesome for developing it. Kudos. Aug 04 16:52:53 majuk: the learning curve is fairly steep. the main issue, both positive and negative, is the flexibility, i think. there's a lot of power, but it also means there are often multiple ways of doing things, and pieces come from various places to ensure we can meet every need. once you're up to speed, it's great, though :) Aug 04 16:53:51 kergoth: Yea. I'm wading through the 300 slide presentation on free-electrons.com. Even after having used Yocto for the past couple months, I don't have much of a handle on how things are happening. Aug 04 16:54:50 majuk, magic Aug 04 16:54:59 majuk: http://www.aosabook.org/en/yocto.html might help with some background / big picture Aug 04 16:56:20 rather poky-heavy, terminology wise, given it's really describing bitbake+oe-core behavior, but good info Aug 04 16:58:20 Rudi's book is also recent Aug 04 16:58:53 https://www.amazon.com/Embedded-Systems-Project-Software-Development/dp/0133443248 Aug 04 17:01:09 I've been trying to find examples of modifying existing builds. I have a functional build for the reference board I'm working with, but transitioning that into a custom build for custom hardware is evading me because I can't seem to get a grasp on how the recipe I'm using is coming together. Aug 04 17:07:57 'recipe' probably isn't even the right term, lol Aug 04 17:08:20 'image', that's it Aug 04 17:10:49 images are built with recipes Aug 04 17:10:58 what is the existing build? Aug 04 17:11:22 Don't know how to answer that question. Aug 04 17:11:35 to clarify further, an image *is* a recipe :) just one that inherits a class that arranges to run different tasks Aug 04 17:11:40 what do you build? Aug 04 17:11:47 Linux Aug 04 17:11:56 that's so vague as to be a non-response Aug 04 17:12:09 Well it's a vague question that I don't know how to answer. Aug 04 17:12:09 So Aug 04 17:12:52 you've told us absolutely nothing about what you're building Aug 04 17:12:58 not what yocto version, what hardware, what distro, nothing Aug 04 17:13:02 You want a list of every package? The image name I invoke? The hardwre? Aug 04 17:13:11 image name Aug 04 17:13:32 core-image-x11 is the image name Aug 04 17:14:06 What do you want to change Aug 04 17:15:42 Immediately, uboot register settings for DDR. Aug 04 17:17:09 so then we need to know the bsp layer used Aug 04 17:17:12 akak hardware Aug 04 17:18:10 The Freescale Community BSP, specifically the Wandboard w/ iMx6 Solo Aug 04 17:18:50 * Crofton|work hasn't used that part Aug 04 17:18:50 does anyone know of an emacs shell that will work with yocto/bitbake? https://da.gd/bcgQ -> https://paste.fedoraproject.org/paste/dfvRMS5ljyUYaM60DpgS8w/ Aug 04 17:18:59 I could help with Xilinx :) Aug 04 17:19:22 but asking in a Freescale focused place would be better for that question Aug 04 17:19:37 Yea. No worries, thanks. Aug 04 17:19:41 also reading the u-boot recipes in the freescale BSP's might give you some ideas Aug 04 17:20:33 that is pretty intimate with the board startup, which OE handles, but the smarts for that will be in the bsp layers and can be pretty hacky at times, dpending on who did the work :) Aug 04 17:21:51 Sure. My exercise today was to try to trace from the highest level, image, down to the BSP uboot stuff Aug 04 17:22:04 and I see no reference to anything uboot in the image. So that's not going so well. :D Aug 04 17:22:45 does that layer stack on top of meta-freescale Aug 04 17:22:51 If I could build an image that just got me to a uBoot shell, that would be great. Aug 04 17:23:05 majuk: see the machine .conf Aug 04 17:23:15 it'll define the bits to pull in the bootloader to the build Aug 04 17:23:31 not the imga itself, since it's machine specific, and is independent of the image Aug 04 17:24:08 distro, machine, and image are orthogonal. any combination of the three should work, in general, so we're careful to keep changes for them in the right place Aug 04 17:24:20 That makes sense. Aug 04 17:25:01 kergoth: Ok, hearing that, the local.conf makes more sense Aug 04 17:25:29 Definitely didn't get that out of any docs I've read. :D Aug 04 17:25:33 that separation is pretty critical to the project's success, i think, along with our OVERRIDES. between the two we have the ability to share a ton of common stuff between people with widely varying use cases, hardware, and policy decisions Aug 04 17:26:29 majuk: https://www.dropbox.com/s/gxb6uxlputaupmj/OpenEmbedded%20-%20Metadata%20Structure%20-%20Distro%2C%20Machine%2C%20Image.txt?dl=0 might help in that regard. substitute references to 'task' with 'packagegroup' in most cases. haven't updated that in a while Aug 04 17:26:41 Cool, thanks. Aug 04 17:26:45 but it's about the distro/machine/image thing Aug 04 17:27:27 i think our docs could probably use a bit more coverage of high level concepts. we have some good howto-style info, and reference material, but less of the big picture, i think Aug 04 17:27:29 I'm a hard/firmware guy, the inherent hierarchy of system software is not a context I know a lot about, so this is great. Aug 04 17:28:11 of course some folks do better at drilling down from high level to low, but others do better at going the other direction, so what's helpful for one might not help the other, depending on where they are in the learning process.. Aug 04 17:32:45 Yea, I'm a low-to-high level guy for building understanding. I learn-by-doing and find it difficult to apply high-level concepts into low-level, actionable, understandable steps with anticipatable consequences. Aug 04 17:33:08 Anyway, thanks for the input, I appreciate y'alls time. Aug 04 17:33:11 np Aug 04 19:08:11 my new machine build ran for a couple of hours but eventually encountered the following error: https://da.gd/N18p -> https://paste.fedoraproject.org/paste/9SoNMpJWZhxjq7FzV7kCKg/ Aug 04 19:09:11 again this is happening because we are using a new MACHINE name Aug 04 19:11:14 the fw_env.config file for the machine we are deriving from (imx6ul-var-dart) is fine. how do we "inherit" this uboot file ? Aug 04 19:11:39 ...is fine for our machine and purposes... Aug 04 19:12:49 our machine name is imx6ul-ebtron-x5, as from this line of the error outptu: install: cannot stat '/home/yocto-project-x5-r1/sources/meta-variscite-fslc/recipes-bsp/u-boot/u-boot-fw-utils/imx6ul-ebtron-x5/fw_env.config': No such file or directory Aug 04 19:12:57 copy-paste it into "home/yocto-project-x5-r1/sources/meta-variscite-fslc/recipes-bsp/u-boot/u-boot-fw-utils/imx6ul-ebtron-x5/fw_env.config"? Aug 04 19:14:57 majuk: we are only going to change a small portion of the existing imx6ul-var-dart u-boot (and kernel) configuration. isn't there a way to inherit everything from imx6ul-var-dart except for a few special "tweaks"? Aug 04 19:19:02 yates: I imagine there is, but I don't know what it is. Sorry. Aug 04 19:23:20 kergoth: any pointers here? Aug 04 19:27:03 or rburton? Aug 04 19:27:11 everyone having a beer already? :) Aug 04 19:37:16 yeeah, finally. Build is up and running again after 2 days down. Aug 04 19:37:51 bitbake and yocto is certainly not the easiest beast when not walking on the happy path ;) Aug 04 19:46:27 bluelightning: oh hey, just the guy I'm looking for :) Aug 04 19:46:43 bluelightning: are you aware that NPM is broken-ish in YPRR 2.3 , but not in YPRR 2.2 ? Aug 04 19:46:48 Marex: hey Aug 04 19:47:02 Marex: I'm aware there are a lot of problems with it yes... Aug 04 19:47:10 in fixing one issue I created others Aug 04 19:47:29 bluelightning: surprisingly, it worked in 2.2 , but it's broken in 2.3 , does that ring a bell or shall I start bisecting ? Aug 04 19:47:52 (btw no, I didn't turn to the dark side and didn't start doing nodejs :) ) Aug 04 19:47:52 Marex: I think you will find the issues start with the commit where do_install was changed Aug 04 19:48:39 bluelightning: heh, that sounds vaguely familiar Aug 04 19:49:45 bluelightning: yeah, do_install is where it dies Aug 04 19:50:29 without that fix there are other issues unfortunately Aug 04 19:51:16 basically npm has fought us every step of the way :( Aug 04 19:51:33 I am holding out hope for npm v5 Aug 04 19:51:51 bluelightning: ... insert opinionated comment on quality of nodejs here ... Aug 04 19:52:09 bluelightning: there is no hope for nodejs Aug 04 19:53:19 bluelightning: but thanks for pointing me out to this do_install, I'll try reverting a few and see if I can track it down Aug 04 19:53:28 v5 suggests they are learning some lessons (from yarn mostly) Aug 04 19:53:52 I'm told it can be installed on top of non-bleeding-edge versions of node.js Aug 04 19:55:24 bluelightning: I'm waiting for the "but" :) Aug 04 19:57:51 Marex: well, someone I work with is sort of looking at it, but I'm not sure how much time he has to spend doing so Aug 04 19:58:11 what he's told me so far sounds very promising Aug 04 20:02:38 bluelightning: ok, reverting ebe531b38bea54bd29ed7b3d2ea6c533b9331953 helped Aug 04 20:03:02 bluelightning: I expect this will fsck something else up :) Aug 04 20:03:10 bluelightning: thanks Aug 04 20:03:26 Marex: np Aug 04 20:27:39 hello! Aug 04 20:28:09 when `bitbake-layers add-layers` produces an error like 'Parse failure with the specified layer added' how do i... debug that? Aug 04 20:29:01 even with the -d flag i don't get additional info about the failure Aug 04 20:29:09 just... that a parse failure occurred Aug 04 20:58:33 Is there a way to add a file to tmp/deploy from a bbappend? I want bios/win32/syslinux.exe accessible from the output Aug 04 21:04:36 halstead: are you around? Aug 04 21:04:59 lamego, Yes sir! Aug 04 21:06:13 halstead: Hi Michael! Please take a look at my latest emails to you when you have the time. I have a couple request there where you can help. Aug 04 21:06:39 Looking Aug 04 21:08:43 lamego, I see 2 pings that were threaded out so I missed them about patchwork. Oh this is done or very close. I see where I said I'd update you and didn't. Aug 04 21:09:14 lamego, I'm sorry. Once I get all the AB machines updated and rebooted I'll finish this. Aug 04 21:09:26 halstead: those are the ones. Please help when you have the time. Aug 04 21:09:57 halstead: Thanks, and have a nice weekend :) Aug 04 21:10:18 lamego, I will. Are you heading out soon or can I check in with you here? Aug 04 21:11:04 halstead: I'm around one more hour or so. Next Monday from 9:00 AM CST :) Aug 04 21:11:29 lamego, Reliable. :) Aug 04 22:04:19 bluelightning: https://gist.github.com/kergoth/968f4eacc8436d442f7b2a0ddf147333 any thoughts? fails to load any oe package modules from non-oe-core layers, despite the sys.path modification in base.bbclass, but only happens with devtool, not a regular parse or build Aug 04 22:17:46 can anyone explain why running bitbake on a particular image target with two different machine targets seems to cause conflicts? the tmp work directory for one machine will have empty git directories for certain packages, for example, causing their compiles to fail Aug 04 22:18:50 i'm assuming it's something relating to one of the caches but i'm having trouble determining which and how to work around this issue Aug 04 22:19:11 is in inadvisable to build for multiple machine targets using the same base yocto directory? Aug 04 22:19:29 it's the same build directory that's the issue, but even that isn't a problem as long as you wipe tmp between them Aug 04 22:19:38 that said, multi-machine builds with a single tmpdir *should* work, if it doesnt', that's a bug Aug 04 22:23:44 kergoth: i can say for certain that it doesn't seem to work without wiping tmp in between builds Aug 04 22:24:06 ideally i wouldn't need to do so since i'd like to have a copy of u-boot and a rootfs for each machine Aug 04 22:24:17 without having to manually back it up elsewhere Aug 04 22:25:47 kergoth: one fix i've found is manually running a cleanall task for each package that fails Aug 04 22:25:54 workaround, i should say Aug 04 22:28:49 kergoth: is it a specific bug? one that has been fixed in a particular version? **** ENDING LOGGING AT Sat Aug 05 03:00:00 2017