**** BEGIN LOGGING AT Fri Oct 20 03:00:02 2017
Oct 20 06:18:18 <styler2go> Using a predefined wic file, how can i alter grub arguments for the mkefidisk?
Oct 20 07:22:24 <styler2go> can someone tell me what exactly this means? 2 installed and not shipped files. [installed-vs-shipped] Files/directories were installed but not shipped in any package:
Oct 20 07:22:56 <styler2go> I did a package where i replace etc/inittab using install -m 0755 ${WORKDIR}/inittab ${D}/etc/inittab
Oct 20 07:25:11 <open-nandra> styler2go: you need to add all paths to FILES_${PN}...
Oct 20 07:25:19 <open-nandra> to avoid this QA issue
Oct 20 07:25:32 <styler2go> in which receipt?
Oct 20 07:25:43 <styler2go> in my scritp which replaces the inittab?
Oct 20 07:30:04 <open-nandra> styler2go: yes
Oct 20 07:30:18 <styler2go> open-nandra, thank you
Oct 20 07:43:06 <styler2go> oh well.. actually i just forgot to add it in there
Oct 20 07:49:48 <open-nandra> Hi all
Oct 20 07:50:08 <open-nandra> I have some issues with metadata hashes: the basehash value changed from 27
Oct 20 07:50:19 <open-nandra> I have custom class which is running some scripts
Oct 20 07:50:36 <open-nandra> and I'm using date command in class
Oct 20 07:51:04 <open-nandra> I've added class[vardepsexclude] = "DATETIME"
Oct 20 07:51:10 <open-nandra> but I still see an issue
Oct 20 07:51:15 <open-nandra> any idea how to debug that?
Oct 20 07:58:12 <styler2go> Can i somehow override a file if another package already installed it?
Oct 20 07:59:03 <styler2go> check_data_file_clashes: Package recovery wants to install file /mnt/upboard/build-recovery/tmp/work/up_board-poky-linux/recovery-image/1.0-r0/rootfs/etc/inittab But that file is already provided by package  * sysvinit-inittab
Oct 20 08:05:32 <LetoThe2nd> styler2go: the correct way is to have an append to the original recipe, instead of trying to overwrite its outcome
Oct 20 08:06:06 <open-nandra> LetoThe2nd: any idea how to debug metadata hash issue?
Oct 20 08:06:38 <LetoThe2nd> open-nandra: no.
Oct 20 08:07:20 <open-nandra> LetoThe2nd: I checked it can be disabled but I'm curious why I see such issue
Oct 20 08:08:56 <LetoThe2nd> open-nandra: if i had an idea, i would've told you, don't worry. but the hashing respectively sstate altogether is basically a piece of "magic" i just use
Oct 20 08:09:19 <open-nandra> LetoThe2nd: yes sure, sorry for bothering ;)
Oct 20 08:09:40 <LetoThe2nd> open-nandra: np, good luck
Oct 20 08:42:58 <styler2go> what does the operand ?= mean?
Oct 20 08:43:20 <LetoThe2nd> styler2go: only set if not already set
Oct 20 09:00:31 <styler2go> If i add the IMAGE_FSTYPE in my local.conf, can i prevent any other script from overwriting it? i have the problem that i just want to create the wic file but for exmaple in the machine.conf there it states ext4
Oct 20 09:01:25 <nayfe> which operand you use ?
Oct 20 09:01:46 <nayfe> in local and in machine ?
Oct 20 09:01:51 <styler2go> or, at least be sure that no other script overwrites it by using IMAGE_FSTYPE =
Oct 20 09:02:03 <styler2go> the machine is a predefined, not from me. there therey used = operand
Oct 20 09:02:09 <styler2go> in my local.conf i also used =
Oct 20 09:02:31 <styler2go> now i changed the machine.conf to += and it works
Oct 20 09:12:08 <styler2go> Also, i always need to execute bitbake 2-3 times until i get my .wic file because it gets the error: cp recovery-image-1.0/hddimg/EFI/BOOT/* boot/EFI/BOOT returned '1' instead of 0
Oct 20 09:19:38 <nayfe> maybe change cp by cp -f
Oct 20 09:24:18 <styler2go> but that's somethin wic does, i do not do that in any of my scripts
Oct 20 09:28:15 <styler2go> maybe my bitbake version is too old and has bugs.. i am using 1.30.0
Oct 20 09:28:55 <LetoThe2nd> styler2go: i already told you yesterday. try to find out what in the cp fails, it can't be much. usually either the source file doesn't exist, or the destination directory.
Oct 20 09:29:40 <styler2go> LetoThe2nd, yes the source doesn't exist. but how can i possibly fix this when it's wic interal?
Oct 20 09:31:29 <LetoThe2nd> styler2go: i don't think thats "internal", but some step earlier in the process missing. have you modified the .wks file?
Oct 20 09:31:42 <styler2go> No
Oct 20 09:31:49 <styler2go> i am using mkefidisk
Oct 20 09:32:04 <LetoThe2nd> ed21: ping ^^^^^
Oct 20 09:32:57 <styler2go> ?
Oct 20 09:34:26 <LetoThe2nd> styler2go: be patient and hope the wic guy is around :)
Oct 20 09:49:44 <ed21> styler2go: Can you create bug for this issue? It looks like a bug in wic code.
Oct 20 09:51:12 <styler2go> It seems like i found the issue. It first creates the ext4 file, then it fails. When i reexecute it, it create the hddimg file but wic fails again. when i then execute it again, it works (the iso file does exist now)
Oct 20 09:51:45 <styler2go> So it seems like wic doesn't wait until all image types (especially the iso file) are created
Oct 20 09:52:32 <styler2go> https://p.styler2go.de/3897236 see the timestamps
Oct 20 09:55:11 <styler2go> in my IMAGE_FSTYPE i only have "ext4 wic". could that be a problem?
Oct 20 10:42:39 <styler2go> ed21, any idea about that behavior?
Oct 20 11:17:52 <styler2go> Does anyone else know how i can set the order in which the image types are created?
Oct 20 11:25:03 <boucman_work> styler2go: there is a variable somewhere that can specify dependencies between image types, I'm not sure what it's called
Oct 20 11:25:38 <boucman_work> styler2go: http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-IMAGE_TYPEDEP
Oct 20 11:26:21 <styler2go> sounds like an idea, will try that, thanks
Oct 20 11:36:07 <styler2go> boucman_work, did not fix it
Oct 20 11:36:14 <styler2go> I guess i'll just have to live with it
Oct 20 11:41:51 <boucman_work> styler2go: I use that feature a lot, i'm pretty sure it works; could you pastebin your type definition ?
Oct 20 11:43:02 <styler2go> https://p.styler2go.de/5698018 that's my image stuff inside local.conf
Oct 20 12:33:10 <robsta> hello
Oct 20 12:33:28 <robsta> one recipe we got from someone else is using "source"
Oct 20 12:33:41 <robsta> my suspicion is it fails for us because ubuntu/dash
Oct 20 12:33:51 <robsta> is there a way to force bitbake use bash?
Oct 20 13:08:32 <boucman_work> styler2go: that looks correct...
Oct 20 13:09:06 <styler2go> it just executed do_image_wic and do_image_hddimg simultanously and therefore wic fails..
Oct 20 13:14:16 <nayfe> robsta: you have the fail log ?
Oct 20 13:17:34 <joshuagl> robsta: can you submit a change for the recipe to use . instead of source? otherwise you might want to change the shell you use for OE builds :-/
Oct 20 13:24:29 <boucman_work> styler2go: please run "bitbake -e" and check what exactly is in the IMAGE_TYPEDEP* variables... chances are that wic has other deps that you implicitely break... so it's worth checking
Oct 20 13:28:13 <styler2go> boucman_work, https://p.styler2go.de/9302907
Oct 20 13:28:27 <styler2go> Is that enough? I tried to collect it from that huge output
Oct 20 13:28:55 <nayfe> styler2go: maybe add do_image_wic[depends] += "xxx:do_image_hddimg" in your machine conf ?
Oct 20 13:31:38 <rburton> robsta: fix it to use . as source is a bashism and you can't rely on bash
Oct 20 13:31:41 <rburton> robsta: there's verify-bashisms in scripts/contrib to run all the recipe script fragments through a bashism detection tool if you want :)
Oct 20 13:32:05 <styler2go> nayfe, i then get errors like depends upon non-existent task do_image_iso (tried hddimg too)
Oct 20 13:33:22 <nayfe> you replaced xxx with correct recipe name ?
Oct 20 13:34:22 <styler2go> yes
Oct 20 13:34:48 <styler2go> it might work now.. i did do_image
Oct 20 13:34:56 <styler2go> no error till now
Oct 20 13:36:31 <styler2go> yepp, that worked, nayfe :)
Oct 20 13:36:58 <nayfe> \o/ bitbake magic
Oct 20 13:37:21 <styler2go> now i willn clean up the folder and do one final test :D
Oct 20 13:37:23 <boucman_work> nayfe: that works but it's not "the proper way"
Oct 20 13:37:39 <boucman_work> styler2go: lool line 1..7 of your pastebin
Oct 20 13:37:41 <styler2go> it's the magic way
Oct 20 13:38:00 <boucman_work> line 2 is the line from your local.conf
Oct 20 13:38:10 <boucman_work> line 4 is the line from image-live.bbclass
Oct 20 13:38:21 <nayfe> boucman_work: why it isnt correct ?
Oct 20 13:38:23 <boucman_work> as you see, the yocto-provided class overrides your local.conf changes
Oct 20 13:38:36 <boucman_work> because both of you write the variable using "="
Oct 20 13:38:49 <boucman_work> you need to do it that way :
Oct 20 13:39:26 <boucman_work> IMAGE_FSTYPES_iso_append = "hddimage"
Oct 20 13:39:59 <boucman_work> as a general rule, learn "bitbake -e" and "bitbake -e <recipe>" it's one of the best tools to debug yocto
Oct 20 13:40:03 <styler2go> nayfe, oh well, this magic failed too :(
Oct 20 13:41:09 <styler2go> boucman_work, but that won't fix the problem i am having :/
Oct 20 13:42:20 <boucman_work> well, yes it should, IIUC
Oct 20 13:42:28 <boucman_work> right now you have the following dependencies
Oct 20 13:42:38 <boucman_work> iso after ext4
Oct 20 13:42:50 <boucman_work> wic after iso
Oct 20 13:43:00 <boucman_work> hddimage after ext4
Oct 20 13:43:13 <boucman_work> you lost iso after ext4 in the process
Oct 20 13:43:16 <boucman_work> which is what I fix
Oct 20 13:43:28 <boucman_work> and that explains your ordering problem, right ?
Oct 20 13:43:29 <styler2go> i am so confused now
Oct 20 13:43:55 <boucman_work> styler2go: do you know how to read the output of bitbake -e that I asked you to pastebin ?
Oct 20 13:44:25 <styler2go> i didn't know about -e yet, so probably no. what does the pre-expansion value mean?
Oct 20 13:44:33 <styler2go> the default value before any script?
Oct 20 13:44:52 <boucman_work> basically, for each variable it gives all the operations that were done to the variable and in what order
Oct 20 13:45:06 <boucman_work> so, for IMAGE_TYPEDEP_iso
Oct 20 13:45:13 <styler2go> so, a history of all vars?
Oct 20 13:45:20 <styler2go> that really sounds awesome
Oct 20 13:45:21 <boucman_work> yes
Oct 20 13:45:26 <boucman_work> it is :)
Oct 20 13:45:31 <styler2go> if it only would be sorted by var names :P
Oct 20 13:45:41 <boucman_work> yocto will never be the same for you, once you know that :P
Oct 20 13:46:00 <boucman_work> so in your case, for IMAGE_TYPEDEP_iso
Oct 20 13:46:12 <boucman_work> it is first set to "hddimage" by your local.conf
Oct 20 13:46:26 <boucman_work> (line 2 & 3 in your pastebin)
Oct 20 13:46:49 <boucman_work> then set to "ext4" by image-live.bbclass (thus overriding what you did)
Oct 20 13:47:38 <boucman_work> the pre-expansion part is only usefull when your variable contains some variables to expand (${..} blocks)
Oct 20 13:48:21 <boucman_work> so, we need a way to append something to the variable, without colliding with image-live.bbclass
Oct 20 13:48:28 <boucman_work> which we do using the _append mechanism
Oct 20 13:49:11 <boucman_work> ( styler2go if you read french I did a blog article about variable expansions in bitbake, not in english unfortunately)
Oct 20 13:50:26 <nayfe> ça m'intéresse :)
Oct 20 13:51:44 <styler2go> No, i'm noth french actually
Oct 20 13:52:17 <styler2go> but
Oct 20 13:52:25 <styler2go> why am i appending hddimg to iso?
Oct 20 13:52:28 <boucman_work> http://www.linuxembedded.fr/2015/12/yocto-comprendre-bitbake/
Oct 20 13:52:38 <boucman_work> http://www.linuxembedded.fr/2016/05/la-mise-au-point-des-recettes-yocto/
Oct 20 13:53:05 <boucman_work> you are appending hddimage to IMAGE_TYPEDEP_iso
Oct 20 13:53:17 <styler2go> yes
Oct 20 13:53:21 <boucman_work> oh wait
Oct 20 13:53:28 <boucman_work> I wrote something stupid earlier
Oct 20 13:53:31 <boucman_work> gimme a sec
Oct 20 13:53:45 <boucman_work> IMAGE_TYPEDEP_iso_append = "hddimage"
Oct 20 13:54:04 <boucman_work> and check that what I wrote is correct with "bitbake -e" after that :P
Oct 20 13:54:36 <styler2go> IMAGE_FSTYPES_iso_append = "hddimg"
Oct 20 13:54:36 <styler2go> IMAGE_FSTYPES_hddimg_append = "wic"
Oct 20 13:54:44 <styler2go> should i do it like that? append wic after hddimg?
Oct 20 13:55:50 <nayfe> boucman_work: merci pour les liens
Oct 20 13:57:20 <styler2go> boucman_work, now it's even crazier
Oct 20 13:57:30 <styler2go> https://p.styler2go.de/457559 why is iso now ext4?
Oct 20 13:58:28 <boucman_work> styler2go: could you pastebin the extract of your local.conf ?
Oct 20 13:59:26 <styler2go> https://p.styler2go.de/2353033
Oct 20 14:00:22 <boucman_work> styler2go: it's my fault, I told you to append to IMAGE_FSTYPES when I meant IMAGE_TYPEDEP
Oct 20 14:00:31 <boucman_work> so replace line 51 and 52 with
Oct 20 14:00:43 <boucman_work> IMAGE_TYPEDEP_iso_append = "hddimage"
Oct 20 14:00:48 <styler2go> oh wow
Oct 20 14:00:51 <styler2go> i didn't notice it
Oct 20 14:00:57 <boucman_work> IMAGE_TYPEDEP_hddimg_append = "wic"
Oct 20 14:01:17 <boucman_work> and check that the resulting variables are what you expect with bitbake -e
Oct 20 14:01:23 <styler2go> sure
Oct 20 14:01:28 <styler2go> i will use -e forever now
Oct 20 14:01:54 <styler2go> i just wish it would be a bit easier .. like grepping the results or just having a second parameter where i can say i jzst want to see IMAGE_TYPEDEP*
Oct 20 14:02:23 <styler2go> boucman_work, _append doesn't add spaces so i also need to add spaces, right?
Oct 20 14:02:32 <styler2go> IMAGE_TYPEDEP_iso="ext4hddimg" is the current result
Oct 20 14:02:42 <boucman_work> styler2go: note that when using -e bitbake will not compile, it will only print its variables
Oct 20 14:03:10 <boucman_work> styler2go: probably... I am not very clear on which call adds space... I just check what happens with -e
Oct 20 14:03:25 <styler2go> yes, -e says ext4hddimg
Oct 20 14:03:47 <boucman_work> ok, so yes add a space (or use += which adds the space for you)
Oct 20 14:03:59 <styler2go> append with spoaces would be +=
Oct 20 14:04:14 <styler2go> yeah, well, i just added the spaces manually now
Oct 20 14:04:46 <styler2go> looks good now, i will try building it
Oct 20 14:04:57 <boucman_work> styler2go: no, you need bot append and += (the explanation is a bit complicated for IRC)
Oct 20 14:05:34 <styler2go> actually i didn't notice it's that late already.. i gotta go
Oct 20 14:05:48 <styler2go> thanks for your assistance, i really appreciate <3
Oct 20 14:07:43 <boucman_work> no prob
Oct 20 14:39:13 <nathani_> updating to pyro, menuconfig gives me an error: pastebin.com/XiS88dpv
Oct 20 14:40:02 <nayfe> nathani_: why not rocko if I may ask ,
Oct 20 14:40:12 <nathani_> something to do with ncurses. using imx-linux kernel.
Oct 20 14:41:28 <nathani_> buying a SOM from a 3rd part and they haven't updated their bsp yet for rocko
Oct 20 14:42:56 <nayfe> did you have a try with linux-fslc or linux-fslc-imx
Oct 20 14:43:53 <boucman_work> nathani_: that's a pure host problem, do you know the kernel version you are using ? do you have ncurses installed on your machine ? did you clean everything when updating ?
Oct 20 14:43:55 <nayfe> you had a look on that topic ? http://lists.openembedded.org/pipermail/openembedded-core/2015-May/105363.html ?
Oct 20 14:46:14 <Adam_> Hello! I am looking for some tips on getting my Yocto SDK configured with X11 libraries. The target uses Wayland unfortunately and I can't seem to add libx11 as X11 has been removed from the DISTRO_FEATURE. Has anyone ran into this issue?
Oct 20 14:46:54 <nathani_> yeah i built from scratch. menuconfig still works on my other builds, so i assumed my host was good
Oct 20 14:48:12 <Adam_> I also am building the SDK from scratch via with -c populate_sdk
Oct 20 14:48:16 <nathani_> kernel is a linux-imx6 fork by boundary devices
Oct 20 14:48:49 <nathani_> v4.1.15
Oct 20 14:49:08 <Adam_> Nathan, sorry I am confused. Are you talking to.. me?
Oct 20 14:49:45 <nathani_> no, sorry Adam, you signed on mid convo
Oct 20 14:50:00 <Adam_> Haha sorrry apologies
Oct 20 14:57:24 <nayfe> nathani_: did you made a clean new environment after upgrading ? or still with sstate-cache or build ?
Oct 20 14:58:51 <nayfe> Adam_: maybe add libx11 in your image recipe ?
Oct 20 14:59:50 <nathani_> did $sudo apt-get install libncurses-dev, works now
Oct 20 15:00:03 <nathani_> nayfe, thanks for the help
Oct 20 15:01:04 <nathani_> FYI, i did make a clean enviro and started a new build from scratch.
Oct 20 15:01:27 <nayfe> nathani_: ok, great!
Oct 20 15:04:12 <Adam_> neyfe, adding libx11 to the image is not possible as long as Wayland is included. X11 and Wayland cannot co-exist.
Oct 20 15:04:40 <rburton> well thats not true
Oct 20 15:04:48 <rburton> you can run xwayland to have x11 apps under weston
Oct 20 15:04:51 <Adam_> I think I should still be able to build libx11-native or nativesdk-libx11 into the SDK however, regardless of X11 inclusion in the target
Oct 20 15:05:21 <Adam_> rburton, right that is true. However, I can't figure out how to include libx11 along with xwayland
Oct 20 15:05:24 <rburton> you *cant* build libx11 if the DISTRO_FEATURES have had x11 removed, but you can easily add it back
Oct 20 15:05:45 <rburton> that refusal to build is to stop things building with X if the distro disabled X
Oct 20 15:05:50 <rburton> you want X, so don't disable it
Oct 20 15:05:57 <Adam_> rburton, but I can't put X11 back in DISTRO_FEATURES as long as Wayland or XWayland is included.
Oct 20 15:06:03 <rburton> yes you can
Oct 20 15:07:15 <Adam_> Hmmm let me look at that. I am using TI's AM57xx EVM image. I believe TI's graphics driver doesn't play well with X11. It likes Wayland better. But let me check.
Oct 20 15:07:32 <rburton> if you're using xwayland then that's irrelevant
Oct 20 15:08:25 <rburton> also, bsp having bad drivers is a bsp problem, you can build wayland images with libx11 in if you want.  how else would xwayland work?
Oct 20 15:08:45 <Adam_> rburton, so you are saying I do not put x11 in the "DISTRO_FEATURES_remove" and only include xwayland in "DISTRO_FEATURES", right?
Oct 20 15:09:04 <rburton> xwayland isn't a DISTRO_FEATURE, unless your distro has added it
Oct 20 15:09:11 <rburton> don't remove x11 if you want to use x11
Oct 20 15:09:24 <Adam_> rburton, that's right - libx11 shouldn't be a prolbem to Wayland/Xwayland. I believe TI's graphics driver needs improvement
Oct 20 15:09:27 <rburton> if you want xwayland in an image, add it to the image.
Oct 20 15:10:06 <rburton> as i said we *do* have logic to abort builds of libx11 if x11 isn't in DISTRO_FEATURES but that's a sanity check to stop apps building against X when the distro said it didn't want X
Oct 20 15:11:00 <Adam_> I see. I will add xwayland to the IMAGE_FEATURES
Oct 20 15:11:06 <rburton> IMAGE_INSTALL
Oct 20 15:11:10 <Adam_> and leave wayland in DISTRO_FEATUERS
Oct 20 15:11:12 <Adam_> ah ok
Oct 20 15:11:25 <rburton> see core-image-weston
Oct 20 15:11:36 <rburton> as the package you want isn't called xwayland
Oct 20 15:13:21 <robsta> joshuagl: it's not a public recipe
Oct 20 15:13:32 <robsta> question is how to force bash for bitbake, yes
Oct 20 15:13:45 <robsta> when /bin/sh is dash
Oct 20 15:13:49 <joshuagl> you can't
Oct 20 15:14:01 <robsta> and the bitbake is running on a jenkins where you can't tweak everything to your liking
Oct 20 15:14:08 <robsta> ok
Oct 20 15:14:10 <joshuagl> either you need metadata which is POSIX sh compliant or to force /bin/sh to bash
Oct 20 15:14:15 <Adam_> rburton, ok thank you let me check on the weston image
Oct 20 15:14:30 <robsta> joshuagl: . <script> seems to work fyi
Oct 20 15:14:57 <joshuagl> robsta: yeah, that was my first suggestion. Fix it to be POSIX sh compliant by using . not source
Oct 20 15:15:01 <robsta> so we can patch the other department's recipe, which is a fix
Oct 20 15:15:16 <robsta> oh ok, just skimmed the backlog
Oct 20 15:15:19 <robsta> thanks joshuagl
Oct 20 15:15:22 <joshuagl> np
Oct 20 15:15:29 <joshuagl> robsta: it's generally advisable to use bash for /bin/sh on YP CI machines
Oct 20 15:15:40 <robsta> it's outside of our control
Oct 20 15:15:44 <joshuagl> ack
Oct 20 15:16:06 <robsta> you know the company's IT department i'm referring to
Oct 20 17:00:25 <Javier_Romero> Hi people, my name is Javier, live in Argentina and would like to know if it can be useful for Yocto Linux, to run test of it's kernel on my Raspberry PI 3 and report bugs that may appears
Oct 20 17:33:57 <lsandov> Javier_Romero: useful. which tests?
Oct 20 17:45:25 <Javier_Romero> lsandov: well I think in running tests like Sub-system Testing, CPU and Memory Stress Testing, Kernel Testing
Oct 20 17:46:31 <Javier_Romero> on Yocto running in RasPI 3
Oct 20 18:52:06 <lsandov> Javier_Romero: are those 'standard' tests? like the LSB ones?
Oct 20 19:00:40 <Javier_Romero> lsandov: They are standard test
Oct 20 19:51:56 <bodangly> is there a way, aside from looking at git branches, to tell in a yocto build what version of yocto it is a build for?
**** ENDING LOGGING AT Sat Oct 21 03:00:01 2017