**** BEGIN LOGGING AT Fri Nov 02 02:59:58 2018
**** BEGIN LOGGING AT Fri Nov 02 04:09:59 2018
Nov 02 06:51:13 <yocti> New news from stackoverflow: How to edit the kernel files using yocto recipe <https://stackoverflow.com/questions/53113672/how-to-edit-the-kernel-files-using-yocto-recipe>
Nov 02 09:56:34 <prabhakarlad> When is exactly WORKDIR populated? For every alternative time I run my recipe I get file not found for the SRC_URI
Nov 02 09:58:29 <prabhakarlad> here is my bb file https://www.pastiebin.com/5bdc1fa2b9245
Nov 02 09:59:08 <rburton> your sd_version_inc is racing with do_unpack
Nov 02 09:59:16 <rburton> because it doesn't depend on do_unpack
Nov 02 09:59:24 <rburton> addtask sd_version_inc after do_unpack
Nov 02 10:00:59 <prabhakarlad> rburton: thank you very much for that it works now :)
Nov 02 10:25:50 <sagner> We bake a build number into os-release, which works well. However it causes systemd/udev and hence initramfs to get rebuilt. Can we somehow prevent a rebuild of those when we just update the build number?
Nov 02 10:26:13 <sagner> os-release is a RRECOMMENDS of systemd, I guess that is what is causing it...
Nov 02 11:22:03 <yocti> New news from stackoverflow: Yocto Linux installation failed <https://stackoverflow.com/questions/53117487/yocto-linux-installation-failed>
Nov 02 12:05:27 <bentech> Just wondering on this dtsi does / { mean the section is commented out? https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sunxi-h3-h5.dtsi#L51
Nov 02 12:07:43 <hireaki> Hi, I have a native recipe foo-native and another recipe bar. bar depends on foo. Foo-native is correctly placed under tmp/sysroots-components/foo-native as I expected. When they do bar or other recipes want to call foo they say foo isn't available, isn't this managed through the SYSROOT_DIRS_NATIVE variable?
Nov 02 12:10:17 <hireaki> * When bar or other recipes...
Nov 02 12:29:37 <rburton> does bar depend on foo-native?
Nov 02 12:30:15 <rburton> sysroots-components is where the sysroot components are stored but that's not where they are exectuable from.  each recipe gets it own sysroot by hardlinking pieces from the sysroot-components
Nov 02 12:33:10 <hireaki> rburton yes, so If I understood bar will have it's own sysroot composed of the necessary sysroot dependencies?
Nov 02 12:33:23 <rburton> correct
Nov 02 12:36:22 <hireaki> Thanks rburton, will do a triple check :)
Nov 02 12:51:46 <bentech> Sorry, i was having internet issues. Did anyone reply?
Nov 02 12:53:21 <hireaki> no
Nov 02 12:56:01 <sagner> How can I see the reason a particular task got executed?
Nov 02 13:17:11 <RP> sagner: "bitbake <target> -g"  will generate a task-depends.dot file which will show the tasks which depend on it
Nov 02 13:18:07 <RP> sagner: or maybe bitbake <target> -u taskexp
Nov 02 13:25:19 <sagner> RP: -g and looking at task-depends.dot definitly helps, thanks!
Nov 02 13:25:35 <sagner> Altough, now the next question arises, where do those dependencies exactly come from :-)
Nov 02 13:55:46 <sagner> Ok found the dependency chain I was looking for: my initramfs got rebuilt whenever systemd got rebuilt, altough I use no udev or systemd in my initramfs. The reason is that run-postinsts inherits systemd, so that is where the dependency came from.
Nov 02 13:56:21 <sagner> What I am now wondering why is run-postinsts even necessary in initramfs... That typically get removed fro ro rootfs...
Nov 02 13:56:32 <sagner> s/fro/for
Nov 02 13:57:01 <sagner> Hm, I guess technically initramfs is not read-only..
Nov 02 13:57:20 <sagner> Ok, kinda makes sense, but still, do we want run-postinsts in initramfs?
Nov 02 14:00:57 <ant_work> sagner, it's a whiule I don't look at this, I was aiming at a lean initramfs
Nov 02 14:01:03 <ant_work> last addition was # disable runtime dependency on run-postinsts -> update-rc.d
Nov 02 14:01:03 <ant_work> ROOTFS_BOOTSTRAP_INSTALL = ""
Nov 02 14:01:05 <ant_work> iirc
Nov 02 14:05:20 <sagner> ant_work: yeah that works.. But why is ROOTFS_BOOTSTRAP_INSTALL even part of an initramfs
Nov 02 14:05:49 <Crofton> uh oh
Nov 02 14:06:46 <ant_work> sagner, it's a long war against cruft :)
Nov 02 14:06:52 <ant_work> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-image.bb
Nov 02 14:07:42 <ant_work> I have to check today0s situation, should just have a couple of empty dirs
Nov 02 14:10:59 <sagner> ant_work: Hm, ok, I am actually not really about size, I try to figure out why I have systemd dependencies when building initramfs
Nov 02 14:22:48 <ant_work> basically my target cpio should just just have an init and a couple of binaries
Nov 02 14:27:15 <JPEW> JaMa here?
Nov 02 14:29:37 <yann> I'm struggling to find a lightweight tool to load an image into X11 root window, any hint ?
Nov 02 14:30:12 <yann> (xloadimage would require to resurect imake build support, it seems)
Nov 02 14:35:39 <yann> (hm, looks like I was looking at an old version there is autoconf support, yay)
Nov 02 14:42:14 <angelo_ts> hi, need to apply an extra CXXFLAGS -Dblabla to a recipe build
Nov 02 14:42:24 <angelo_ts> what's the proper way ?
Nov 02 14:44:25 <neverpanic> CXXFLAGS += "-Dblabla", but depends on the type of the build system
Nov 02 14:46:32 <angelo_ts> build system is gcc
Nov 02 14:46:37 <angelo_ts> ok, so seems easy
Nov 02 14:50:52 <neverpanic> GCC is not a build system, but a compiler. Build systems are autotools, cmake, meson and others.
Nov 02 14:50:59 <banach-space> hiya! do you guys whether Yocto has anything against file globbing? e.g. SRC_URI = "file://some_dir/*"?
Nov 02 14:51:07 <banach-space> *know
Nov 02 14:51:52 <banach-space> I've noticed recently that when updating files (and using file globbing), the files are not copied to the build dir. Not using file globbing fixes that, but what jsut wondering whether it's me doing sth wrong.
Nov 02 14:53:52 <angelo_ts> neverpanic, so gnu-make, simple make an no autotools
Nov 02 14:53:59 <angelo_ts> and, it doesn't work
Nov 02 14:56:55 <neverpanic> with simple make, you'll unfortunately have to check whether CXXFLAGS is exported and whether the Makefile actually uses it
Nov 02 15:44:19 <zeddii_home> RP: odd ball question. Can you fathom a way that the git fetcher could clone my upstream, checkout the right commit from the right branch, but yet leave the workingdir of the git clone invalid ?
Nov 02 15:44:55 <kergoth> what exactly does 'checkout' mean if you don't have a working workdir?
Nov 02 15:45:50 <zeddii_home> it is leaving it on the right commit, but yet the files on disk are not the same as the commit gets when you clone and set that same commit as the head
Nov 02 15:46:13 <zeddii_home> this is exactly the same as the other 100 git based recipes I have, so I’m at a loss to what is going on.
Nov 02 15:47:08 <kergoth> what's the difference between the HEAD and checkout files? if it's just that status shows a difference, but diff doesn't, it could well be that you have autocrlf enabled or something
Nov 02 15:47:19 * kergoth shrugs
Nov 02 15:47:42 <RP> zeddii_home: shallow clones or normal trees? This is after the unpack step?
Nov 02 15:48:39 <zeddii_home> RP.  I’m forcing an exit at the top of configure, and see the difference. normal clones, no subgits. it’s just an uprev of an existing recipe.
Nov 02 15:48:45 <RP> zeddii_home: any subdir= option? See unpack() in lib/bb/fetch2/git.py
Nov 02 15:48:53 <zeddii_home> the go 1.11 changes forced me into a docker/runc/container* uprev cycle
Nov 02 15:49:06 <zeddii_home> and of course, I’m on my last recipe and it is going nuts.
Nov 02 15:49:11 <zeddii_home> which is making me go nuts :P
Nov 02 15:49:38 <zeddii_home> just this: git://github.com/docker/docker-ce.git;branch=18.09;name=docker
Nov 02 15:49:46 <zeddii_home> SRCREV_docker = "ccef7c659bcb1503ba6768e3af91cdc79a4fd56d"
Nov 02 15:50:08 <zeddii_home> and yet, what you get on that commit in the build dir, is drastically different from when I clone and check that out by hand.
Nov 02 15:50:20 <zeddii_home> ow-dellw-ag [/home/bruc...src/import]> git status
Nov 02 15:50:21 <zeddii_home> On branch 18.09
Nov 02 15:50:22 <zeddii_home> Your branch is behind 'origin/18.09' by 6741 commits, and can be fast-forwarded.
Nov 02 15:50:23 <zeddii_home>   (use "git pull" to update your local branch)
Nov 02 15:50:30 <zeddii_home> if I actually do that git pull, I get what I expect
Nov 02 15:50:49 <zeddii_home> but the top commit is correct in that same directory:
Nov 02 15:50:49 <zeddii_home> commit ccef7c659bcb1503ba6768e3af91cdc79a4fd56d
Nov 02 15:50:50 <zeddii_home> Author: Anshul Pundir <anshul.pundir@docker.com>
Nov 02 15:50:51 <zeddii_home> Date:   Wed Oct 31 16:03:15 2018 -0700
Nov 02 15:51:05 <zeddii_home> I’ll go instrument the guts of the fetching a bit more
Nov 02 15:51:31 <RP> zeddii_home: I'd instrument unpack() and see where that gets you
Nov 02 15:51:52 <RP> zeddii_home: the commands should already be logged in WORKDIR/temp/log.do_unpack
Nov 02 15:51:59 <kergoth> yeah, the clone from upstream doesn't involve checkout at all, so it's not a factor, it's the clone from dl_dir that matters
Nov 02 15:52:04 <RP> zeddii_home: see if you can repoduce them?
Nov 02 15:52:36 <zeddii_home> someone else here at work, was able to see the same thing. If I clone manually from the dl_dir, it is also good. and I’ve cleanall’d about 15 times :D
Nov 02 15:52:54 * zeddii_home goes to consult the log files
Nov 02 15:54:02 <zeddii_home> this is a pretty normal use case, so there’s something stupid I’m doing. I’ll figure it out. you have bigger fish to fry. I’ll lag the thud branch of meta-virt until I get it sorted.
Nov 02 15:56:11 * RP is wondering how to automate menuconfig testing
Nov 02 15:56:41 * RP suspects it involves screen or tmux and expect 
Nov 02 15:59:19 <JaMa> JPEW: pong
Nov 02 16:03:11 <rburton_> RP: can't we assume the kernel people test menuconfig?
Nov 02 16:03:38 <RP> rburton_: we can assume lots of things and drop most of the remaining manual tests ;-)
Nov 02 16:04:19 <rburton_> hell yeah
Nov 02 16:04:33 <rburton_> i guess what i meant is menuconfig isn't really integration testing
Nov 02 16:05:12 <RP> rburton_: but it is functionality testing and we do a fair bit of that
Nov 02 20:25:23 <peniwize> msg NickServ identify 5p33d@
Nov 02 20:25:30 <peniwize> LOL
Nov 02 20:25:32 <peniwize> sorry guys
Nov 02 23:24:23 <yocti> New news from stackoverflow: Overwriting Yocto Classes through meta-layer <https://stackoverflow.com/questions/51002891/overwriting-yocto-classes-through-meta-layer>
**** ENDING LOGGING AT Sat Nov 03 02:59:58 2018