**** BEGIN LOGGING AT Tue Mar 07 03:00:03 2017
Mar 07 03:11:48 <nerdboy> anybody else get a linker fail with nss on morty?
Mar 07 03:12:15 <nerdboy> the infamous hardened build host has gold as default
Mar 07 03:12:55 <nerdboy> nss fails with/without ld-is-gold in distro_features...
Mar 07 03:15:15 * nerdboy just trying to build boundary-eval-image with vanilla (upstream) manifest
Mar 07 04:01:04 <Marex> khem: I'll only have a usable build machine on Thursday ... will do it later
Mar 07 05:51:52 <khem> ok np
Mar 07 07:50:55 <apelete> hello
Mar 07 07:54:04 <apelete> I'm trying to build "perf" profiling tool using poky 1.7.3
Mar 07 07:54:37 <apelete> the build fails, complaining about missing headers
Mar 07 07:54:52 <apelete> http://paste.debian.net/918522/
Mar 07 07:56:15 <apelete> I'm obviously missing something, could someone help please ?
Mar 07 08:05:49 <yourfate> hi, when I enable dev-pkgs the task "do_rootfs" fails with the error error: "argp-standalone-dev-1.3-r0 conflicts with argp-standalone = 1.3-r0"
Mar 07 08:06:41 <yourfate> image is core-image-full-cmdline, i use musl, target is the zybo board from meta-xilinx
Mar 07 08:10:20 <yourfate> now I disabled the dev-pkgs, then the image bitbake ran fine, but populate_sdk failed with the same old error
Mar 07 08:18:33 <sandsmark> has anyone looked into f2fs rootfs support?
Mar 07 08:21:21 <sandsmark> hmm, looks fairly straightforward to do
Mar 07 08:21:38 <yourfate> I switched back to default libc (glibc I assume) and am trying again.
Mar 07 08:22:05 <yourfate> also, why does it build mesa and gstreamer when I don't think I have a package that uses X...
Mar 07 08:26:53 <sandsmark> yourfate: try bitbake -g core-image-full-cmdline
Mar 07 08:27:29 <yourfate> sec, the bitbake with glibc intead of musl is still running
Mar 07 08:27:35 <sandsmark> and then `grep gstreamer pn-depends.dot`
Mar 07 08:27:37 <khem> what are contents of argp-standalone-dev and argp-standalone ipks
Mar 07 08:27:38 <sandsmark> oki
Mar 07 08:28:17 <khem> glibc based systems dont use argp-standalone so you wont run into this error with glibc but the problem still remains
Mar 07 08:28:18 <yourfate> ah, -g builds graphic dependency treee, nice
Mar 07 08:28:28 <sandsmark> yup
Mar 07 08:28:33 <yourfate> khem: where do I find those
Mar 07 08:28:39 <sandsmark> but looking at the generated graphs is pain, so I usually just grep
Mar 07 08:28:45 <yourfate> :D
Mar 07 08:28:47 <yourfate> brb
Mar 07 08:28:49 <khem> in the builddir for argp-standalone
Mar 07 08:29:05 <khem> go under packages-split
Mar 07 08:29:17 <khem> and it will have directories corresponding to each ipk
Mar 07 08:29:21 <khem> inspect the content
Mar 07 08:29:47 <khem> a conflict would mean there is some duplication probably
Mar 07 08:38:31 <yourfate> so I assume under build/tmp/work ? there are toons of packages-split folders in there somewhere according to find . :D
Mar 07 08:39:22 <khem> yourfate: go into argp-standalone dir
Mar 07 08:39:46 <khem> under build/tmp/work/<target>/ dir
Mar 07 08:42:11 <yourfate> hmm, that directory is empty
Mar 07 08:42:37 <khem> bitbake -ccleansstate argp-standalone && bitbake argp-standalone
Mar 07 08:42:54 <khem> it could be that it was used from sstate
Mar 07 08:44:21 <yourfate> ok, after the current bitbake finishes. this will take quite a while I suppose as It probably has to rebuild everything right now, after switching from musl to glibc
Mar 07 08:45:24 <yourfate> thanks so far tought :)
Mar 07 08:45:30 <yourfate> +h
Mar 07 09:12:36 <apelete> any clue for this "perf" build issue ? http://paste.debian.net/918522/
Mar 07 09:23:37 <RP> apelete: it looks like there is something wrong with the kernel headers but I don't know what specifically
Mar 07 09:29:33 <ant_work> RP: another hint about menuconfig/ncurses. Only kernel is failing do_menuconfig: for busybox is ok.
Mar 07 10:48:06 <rburton> maxin: there?
Mar 07 10:48:58 <Grynium> Hi guys, anyone knows which is the package that causes the installation of the file "/etc/locale.conf"?
Mar 07 10:50:10 <rburton> try oe-pkgdata-util find-path /etc/locale.conf
Mar 07 11:08:25 <Grynium> ERROR: Unable to find any package producing path /etc/locale.conf
Mar 07 11:09:40 <Grynium> I've executed the command from my build dir
Mar 07 11:10:04 <Grynium> after the execution of the "source oe-init-build-env build_imx6qsabresd" command
Mar 07 11:10:10 <Grynium> correct?
Mar 07 11:11:17 <robsta> hello
Mar 07 11:11:54 <robsta> what is the correct way to run bitbake-layers if you want to peek into the yocto project? invoke with path or set PATH env to include its dir?
Mar 07 11:12:51 <rburton> robsta: run oe-init-build-env first to get the paths all set up right
Mar 07 11:12:58 <rburton> source it, that is
Mar 07 11:13:51 <maxin> rburton: ping
Mar 07 11:14:14 <robsta> rburton: someone here insists on wrapping oe-init-build-env so maybe that's where things go belly up
Mar 07 11:14:36 <kanavin> rburton: where do patches for yocto-autobuilder tree go?
Mar 07 11:14:43 <rburton> kanavin: yocto@
Mar 07 11:15:06 <rburton> maxin: would http://errors.yoctoproject.org/Errors/Details/134742/ be something caused by the useradd fixes you sent?
Mar 07 11:15:57 <kanavin> rburton: thanks :) I'm going to disable lib64-core-image-sato-sdk as it was working more by accident than anything
Mar 07 11:16:09 <maxin> rburton: checking
Mar 07 11:18:20 <maxin> rburton: possibly. I will test it with lib32-dbus
Mar 07 11:33:44 <RP> maxin: I think its the removal of the PSEUDO piece in that patch you sent
Mar 07 11:34:28 <RP> kanavin: you're worrying me a little ;-)
Mar 07 11:35:10 <maxin> RP: for some strange reasons, it didn't fail with rpm (failing now with ipk)
Mar 07 11:35:56 <maxin> RP: didn't fail with deb either
Mar 07 11:36:20 <maxin> RP: will look into the PSEUDO part, thanks
Mar 07 11:36:29 <RP> maxin: we're lacking good tests for a lot of the useradd pieces :(
Mar 07 11:37:09 <maxin> RP: true, documentation as well
Mar 07 11:38:20 <rburton> maxin: please add comments liberally whilst you fix :)
Mar 07 11:39:09 <maxin> rburton: will do :)
Mar 07 11:40:21 <rburton> cheers
Mar 07 11:41:53 <kanavin> RP: the issue is that noarch packages pull in 32 bit dependencies, while the bulk of the system is made of lib64- stuff, then clashes happen
Mar 07 11:42:54 <kanavin> RP: it worked with rpm5 because it does some very convoluted remapping of package names and architectures at package creation time, and then again at package install time, which  I do not want to repeat
Mar 07 11:43:39 <RP> kanavin: well, simply dropping that case really isn't going to work
Mar 07 11:44:21 <RP> kanavin: when you say convoluted remapping, you mean dropping the multilib prefix and using the elf colours or flavours or whatever they were?
Mar 07 11:45:01 <kanavin> moving the multilib prefix into the package architecture
Mar 07 11:45:25 <kanavin> and then doing it again when installing packages into an image
Mar 07 11:46:18 <RP> kanavin: well, there are two points you have to map OE names to rpm names, yes
Mar 07 11:55:01 <kanavin> RP: why remap though? Fedora and opensuse don't do it, and we should follow that
Mar 07 11:55:39 <kanavin> (I mean that multilib prefix/suffix stays in the package name)
Mar 07 12:03:49 <RP> kanavin: I'm not saying we should remap, we do need core-image-sato-sdk to work though
Mar 07 12:04:27 <RP> kanavin: in the rpm5 world this was the way multilibs were designed to work. I don't know enough about the differences with rpm4 to know how it should work there
Mar 07 12:05:19 <kanavin> RP: core-image-sato-sdk does work, what does not work is lib64-core-image-sato-sdk
Mar 07 12:09:52 <kanavin> it does not work because dnf tries to install a mixture of lib32 and lib64 packages into it, and they clash
Mar 07 12:11:56 <kanavin> I guess I should try to fix it though
Mar 07 12:16:13 <maxin> kanavin: is there any similarities between rpm and deb here ? In this case,  just ipk seems to fail.
Mar 07 12:17:49 <kanavin> maxin: I don't know to be honest - deb isn't tested with multilib at all, and ipk gets only minimal testing
Mar 07 12:19:40 <maxin> kanavin: thanks, just wanted to know if it was a known bug ..
Mar 07 12:24:23 <RP> kanavin: sorry, I meant that we need to find a way to make lib64-core-image-sato-sdk work
Mar 07 12:25:13 <kanavin> RP: yes, I've already reverted my attempt to simplify things :)
Mar 07 12:25:23 <kanavin> the remaping is back :)
Mar 07 12:25:29 <CTtpollard> is 'BB_STRICT_CHECKSUM = 0' still a thing for overriding the md5/sha256 checking in specific recipes?
Mar 07 12:26:33 <RP> kanavin: I'm not keen on the remapping fwiw, its the fact those images to work currently that we need to retain
Mar 07 12:28:21 <kanavin> RP: yeah, I'd need to figure out how to translate lib64-stuff into stuff.lib64_somearch (and then give it to dnf), that isn't too convoluted
Mar 07 12:28:43 <kanavin> RP: the code that's there for smart I did not like, at all :) hence the attempt to drop the remapping
Mar 07 12:33:28 <filt3r> hello, what would be the best way to have a different kernel config for different images
Mar 07 12:33:29 <filt3r> ?
Mar 07 12:33:38 <filt3r> but same machine
Mar 07 13:54:57 <deva> Has anybody had any luck with using qbs (next generation qmake) buildsystem in a recipe?
Mar 07 13:56:50 <deva> I have gotten as far as to verify that there is no qbs.bbclass in the qt5-meta/class directory...
Mar 07 13:57:03 <rburton> patches welcome!
Mar 07 13:57:15 <deva> So I would gladly help in making such... but I am not sure how to get started
Mar 07 13:58:06 <rburton> just implement do_configure do_compile do_install in a class
Mar 07 13:58:32 <rburton> waf.bbclass is about a minimal as it gets, with a few bits to eg transform PARALLEL_MAKE into the right syntax for waf
Mar 07 13:59:14 <deva> Cool, thanks.
Mar 07 14:02:43 <rburton> maxin, kanavin: is jku around?
Mar 07 14:03:38 <kanavin> rburton: no idea, I am at home today
Mar 07 14:09:21 <sandsmark> anyone know why only libf2fs.* is picked up when building f2fs, and not e. g. mkfs.f2fs?
Mar 07 14:10:41 <sandsmark> it should be a plain autotools recipe
Mar 07 14:22:34 <sandsmark> seems like it doesn't like /sbin
Mar 07 15:16:45 <mjourdan> Hello!
Mar 07 15:16:48 <mjourdan> Can Yocto export its toolchain without including the whole SDK ?
Mar 07 15:16:53 <mjourdan> The dream goal is to export something with the same structure as something like gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz
Mar 07 15:17:14 <RP> mjourdan: "bitbake meta-toolchain" is probably similarish
Mar 07 15:18:16 <mjourdan> Alright thanks I'll try that
Mar 07 15:28:13 <lpapp> hi, why does the kernel package not remove the uImage belonging to the previously installed kernel-image package?
Mar 07 15:36:47 <lpapp> is there any feature added for cleanup? I understand that it may help to leave the old kernel around should the new one not boot, but the uImage is 2 MBs, and it is quite a critical size on our very limited board.
Mar 07 15:37:08 <wesam> I wanted to ask, for infotainment development, what do you think will be the most used programming language
Mar 07 15:37:16 <wesam> and are there any third party apps developed for infotainment
Mar 07 15:56:13 <sjolley> YPTM:   Ready-Access Number:    8007302996  Access Code:    2705751
Mar 07 15:56:22 <sjolley> YPTM: Stephen joined
Mar 07 15:58:20 <joshuagl> YPTM: Joshua joined
Mar 07 15:58:52 <armpit> YPTM - armin is on
Mar 07 16:00:00 <stephano> YPTM - stephano is on
Mar 07 16:00:35 <Sona> YPTM: Sona is on
Mar 07 16:01:26 <rburton> YPTM ross on
Mar 07 16:01:59 <RP> YPTM: Richard joined
Mar 07 16:03:56 <sgw_> YPTM: Saul joined
Mar 07 16:05:14 <Sona> I am trying to get CII badge for Yocto Project. I have started to fill the application, I haven’t submitted yet: https://bestpractices.coreinfrastructure.org/projects/765
Mar 07 16:14:30 <RP> armpit: are you trying to say something?
Mar 07 16:17:45 <Crofton|work> lol, I realized you must be referring to a telecon
Mar 07 16:21:06 <Sona> meta-spdxscanner
Mar 07 16:24:52 * armpit dropped to head to other meeting
Mar 07 16:26:49 <sjolley> YPTM is over.
Mar 07 16:29:10 <ali1234> i just built a poky image with bitbake. where is it?
Mar 07 16:29:39 <joshuagl> tmp/deploy/images
Mar 07 16:29:53 <ali1234> where is tmp?
Mar 07 16:29:56 <joshuagl> relatively to cwd of the completed command invocation
Mar 07 16:30:05 <joshuagl> please read the docs
Mar 07 16:30:08 <ali1234> there is no tmp directory in the cwd
Mar 07 16:31:00 <ali1234> do you mean TMPDIR?
Mar 07 16:31:28 <ali1234> yes, you do
Mar 07 16:33:14 <ali1234> by the way, i did read the docs. specifically the quickstart guide
Mar 07 16:33:32 <ali1234> it doesn't tell you where "tmp" is, or how to change it with TMPDIR
Mar 07 16:33:45 <ali1234> it just tells me the same (incorrect) thing you just did
Mar 07 16:34:58 <joshuagl> sure, the quickstart doesn't assume you've changed TMPDIR
Mar 07 16:37:46 <ali1234> and why on earth is the build result in tmp anyway? rather than somewhere sensible like the build directory, where one might expect it?
Mar 07 16:38:28 <rburton> the vague rationale from a decade ago was "this is generated, so in tmp"
Mar 07 16:38:37 <ali1234> it isn't really correct to say the quickstart assumes i haven't changed TMPDIR
Mar 07 16:38:48 <ali1234> tmp is going to be TMPDIR whether i changed it or not
Mar 07 16:39:12 <rburton> change DEPLOY_DIR if you really want it somewhere else
Mar 07 16:39:18 <CTtpollard> it is by default a subdir of the buldir, I don't think that's strange
Mar 07 16:39:28 <CTtpollard> it's not /tmp on your host...
Mar 07 16:40:10 <CTtpollard> That would be slightly un-sensible :)
Mar 07 16:40:15 <ali1234> why?
Mar 07 16:40:36 <CTtpollard> Because you'd lose everything on reboot
Mar 07 16:40:43 <rburton> because tmp may be far too small, and on many modern systems you can't execute from /tmp which would make putting a compiler in there tricky
Mar 07 16:40:43 <ali1234> so? it's temporary
Mar 07 16:41:03 <ali1234> any directory named tmp must be able to gracefully handle arbitrary deletion of files at any time
Mar 07 16:41:24 <ali1234> which is why it is strange the put the final build result in there
Mar 07 16:41:30 <rburton> rename it then.
Mar 07 16:41:34 <rburton> change DEPLOY_DIR
Mar 07 16:41:35 <rburton> whatever
Mar 07 16:41:39 <ali1234> okay
Mar 07 16:41:49 <CTtpollard> I'm really not sure what the issue is
Mar 07 16:43:05 <ali1234> the issue is that the way TMP_DIR is used a) violates the dictionary definition of the word "temporary" and b) this unexpected violation is not adequately documented in the quickstart guide
Mar 07 16:44:08 <rburton> the contents are temporary in the sense that they can be re-generated.  patches welcome for the quickstart though: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/yocto-project-qs
Mar 07 16:46:58 <yohboy> Hi, someone already work with zynq7 (xilinx) and yocto ? I don't really understand how to link vivado (xilinx tools) and yocto. The goal is to generate my own hdf file. I use the conf machine zybo-linux-bd-zynq7, and I think (not sure), the layers meta-xilinx give us a template project to be able to create a core-image-minimal then boot on zybo. It works very well, but I don't really understand how to include my own vivado project ?
Mar 07 16:49:12 <ali1234> rburton: does it build any files that can't be re-generated?
Mar 07 16:49:36 <ali1234> also, why is there a directory named "cache" in the build directory?
Mar 07 16:51:58 <kergoth> i doubt its possible to move deploy_dir anymore now that its tracked with sstate, given sstate operates relative to tmpdir, no?
Mar 07 16:53:16 <rburton> ali1234: tmp/cache is the bitbaek cache
Mar 07 16:53:24 <rburton> kergoth: hmm
Mar 07 16:53:33 * kergoth shrugs
Mar 07 16:53:36 <ali1234> no, not tmp/cache
Mar 07 16:53:43 <nrossi> yohboy: the meta-xilinx layer doesn't deal with vivado tooling, the zybo-linux-bd-zynq7 only uses the hdf as a means of getting the bitstream and ps7_init files.
Mar 07 16:53:44 <ali1234> $cwd/cache
Mar 07 16:53:51 <rburton> ali1234: *everything* in tmp/ can be regenerated, in fact my TMPDIR is a tmpfs
Mar 07 16:54:01 <rburton> ali1234: sorry.  that's the bitbake cache
Mar 07 16:54:18 <ali1234> can it not be regenerated?
Mar 07 16:55:02 <rburton> its not going to be moved to under tmp/ because its the bitbake cache and tmp/ is OE
Mar 07 16:55:19 <ernstp> ali1234: do you have a specific problem?
Mar 07 16:55:21 <ali1234> is $cwd used for anything at all?
Mar 07 16:55:54 <kergoth> yes, its where conf, cache, and tmp go
Mar 07 16:56:04 <ali1234> ernstp: no, it's just a general inability to understand how any of this works
Mar 07 16:56:20 <ali1234> kergoth: not tmp, that goes in TMPDIR
Mar 07 16:56:28 <ernstp> ali1234: I had conf/local.conf and conf/bblayers.conf in version control in one project
Mar 07 16:56:38 <kergoth> ali1234: huh?
Mar 07 16:56:44 <kergoth> no, TMPDIR *itself* lives in BUILDDIR
Mar 07 16:56:47 <kergoth> read bitbake.conf
Mar 07 16:57:06 <yohboy> nrossi: ok I understand, what is the hdf used by default ? can we change it by our own hdf ? or something else ?
Mar 07 16:57:32 <ali1234> where is bitbake.conf?
Mar 07 16:57:34 <ernstp> ali1234: those are the only two files that you may not want to delete depending on your setup
Mar 07 16:58:18 <kergoth> meta/conf/bitbake.conf is what defines tmpdir, among nearly every other important var / path
Mar 07 16:58:26 <nrossi> rburton: btw looking into the gettext - libintl, i don't think its worth getting that change into oe/meta since nothing else even uses its version of libintl except mingw (i thought uclibc was used/available somewhere, but its not). So you can ignore that patch
Mar 07 16:59:10 <kergoth> what does musl use for intl?
Mar 07 16:59:11 <ali1234> kergoth: and then my local.conf overrides it
Mar 07 16:59:25 <kergoth> ali1234: it can, yes, bitbake.conf is what includes local.conf in the first place
Mar 07 16:59:25 <nrossi> kergoth: provides a version now
Mar 07 16:59:38 <kergoth> ah, nice
Mar 07 16:59:54 <ali1234> in fact it overrides TMPDIR, but none of the other dirs
Mar 07 17:00:06 <ali1234> oh wait it also overrides DL_DIR and SSTATE_DIR
Mar 07 17:00:11 <kergoth> are we supposed to care whether you override tmpdir or not?
Mar 07 17:00:18 <kergoth> i don't see the problem
Mar 07 17:00:46 <rburton> nrossi: thanks
Mar 07 17:00:54 <ali1234> the problem is that you keep incorrectly stating that tmp is in BUILDDIR
Mar 07 17:00:59 <ali1234> this is incorrect, it is in TMPDIR
Mar 07 17:01:00 <kergoth> by default it is
Mar 07 17:01:11 <ali1234> the fact that TMPDIR sometimes = BUILDDIR is 100% irrelevant to anyone
Mar 07 17:01:20 <kergoth> you're the one who asked what lived in $PWD
Mar 07 17:01:23 <kergoth> by defualt tmp is
Mar 07 17:01:25 <nrossi> yohboy: you can provide your own hdf, but you should be doing that with a custom recipe. Use the zybo-linux-bd one as a reference, http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-bsp/reference-design/zybo-linux-bd.bb
Mar 07 17:01:33 <kergoth> are you really this dense?
Mar 07 17:01:39 <ali1234> what lives in PWD and cannot be overriden?
Mar 07 17:02:29 <kergoth> that's quite a different question. nearly everything can be overridden somewhere, that's a key driving force of the project, flexibility
Mar 07 17:03:25 <ernstp> ali1234: do you know how ?= works? https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#setting-a-default-value
Mar 07 17:03:40 <yohboy> nrossi: thank you very much for help, i'll try it ! i'll come back soon, nice irc :)
Mar 07 17:07:54 <khem> rburton: my local builds of go are building successfully for musl based systems
Mar 07 17:08:12 <khem> rburton: do you have a handy link into erros log where we see errors ?
Mar 07 17:08:13 <rburton> khem: ok.  i'll back out the musl disable and see what happens
Mar 07 17:08:18 <rburton> shall try to find it
Mar 07 17:08:22 <khem> rburton: ok
Mar 07 17:08:37 <khem> rburton: I remember to have an issue with clang+musl+x86_64
Mar 07 17:08:44 <khem> but with gcc it works ok
Mar 07 17:08:59 <khem> go 1.7 did not support mips
Mar 07 17:09:09 <khem> go 1.8 does
Mar 07 17:09:28 <khem> which we will send update once we have used 1.7
Mar 07 17:09:32 <khem> for some time
Mar 07 17:09:55 <khem> rburton: binutils 2.28 world builds for my targets appears to be all green as well.
Mar 07 17:10:45 <ali1234> there sure are a lot of DIR variables
Mar 07 17:10:47 <ant_work> khem, I'll test 2.28 this evening for armv4
Mar 07 17:11:11 <rburton> khem: unfortunately errors.yp is being veeery sloooowww
Mar 07 17:13:12 <ant_work> rburton, pray that RP or khem do reproduce the menuconfig/ncurses issue or you'll be my next target (git blame)
Mar 07 17:13:17 <ant_work> going home now...
Mar 07 17:13:25 <khem> rburton: I noticed that and I stopped sending logs to it
Mar 07 17:13:31 <khem> ant_work: thanks,
Mar 07 17:13:51 <khem> ant_work: on your rpi kernel question I havent tried to reproduce it myslelf
Mar 07 17:14:02 <khem> ant_work: but I guess we are missing a dep on ncurses-native
Mar 07 17:14:19 <ant_work> it is in sysroot but not found
Mar 07 17:14:52 <ant_work> because of kernel dirs split
Mar 07 17:15:18 <khem> ant_work: it should be in path isnt it
Mar 07 17:15:21 <ant_work> proof is, menuconfigs is ok with busybox
Mar 07 17:15:38 <ant_work> work-shared?
Mar 07 17:15:42 <rburton> khem: https://autobuilder.yoctoproject.org/main/tgrid <— ross/go will appear shortly, that's master + go and go-helloworld in core-image-sato
Mar 07 17:15:44 <khem> ant_work: even for busybox S != B
Mar 07 17:16:39 <ant_work> I tried STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR with no luck
Mar 07 17:16:45 <ant_work> (no target to build)
Mar 07 17:18:52 <ant_work> bbl
Mar 07 17:20:14 <ali1234> kergoth: how can overriding things be a "driving force" if you don't care whether people do it?
Mar 07 17:27:20 <khem> ali1234: its a strong feature of OE build system
Mar 07 17:27:47 <khem> your use may be more or less depends on your projects
Mar 07 17:34:47 <kanavin> RP: so the code that handles multilb packages at do_rootfs time is not actually too awful, I thought it's subverting the package manager's dependency resolution entirely and produces a gigantic list of packages to install from recursive RDEPENDS run, but it's not the case.
Mar 07 18:02:24 <kergoth> ali1234: sorry if i was a bit harsh. let me try again. when you run bitbake, it sets TOPDIR to $PWD, then searches upward from $PWD to / to find a 'conf/bblayers.conf' file. if it finds it, it's parsed, and conf/layer.conf in each layer in BBLAYERS is parsed. then layer priorities are calculated, etc. then it parses conf/bitbake.conf. both bitbake and oe use TOPDIR and define everything relative to it. there are cases where bitbake has to write to
Mar 07 18:02:24 <kergoth>  TOPDIR before bitbake.conf is parsed, so obviously it can't write into TMPDIR at that point. bitbake.lock, for example. but everything beyond that is defined via bitbake.conf and the files bitbake.conf includes. if you want to know what files/dirs will end up in TOPDIR, other than conf/bblayers.conf, look for all variables in bitbake.conf defined using that variable. conf/local.conf is usually next to bblayers.conf, but that's a convention, to keep the
Mar 07 18:02:24 <kergoth>  local build configuration next to its output. the "yocto" chapter of the freely available Architecture of Open Source Systems book (http://www.aosabook.org/en/yocto.html) may also be of interest for general background on how bitbake works
Mar 07 18:38:32 <ali1234> kergoth: thanks, that's useful. is there a list somewhere of all the different *DIR variables and what they are used for?
Mar 07 18:38:53 <kergoth> the yocto project reference manual might mention some, but bitbake.conf is likely definitive
Mar 07 18:39:38 <ali1234> bitbake.conf lists them all sure, but it doesn't tell me what they are used for, and if i guess based on the name, in the case of TMPDIR at least, my assumptions are probably wrong
Mar 07 18:40:26 <fray> did you look at conf/documentation.conf  ?  most are defined in there
Mar 07 18:40:30 <ali1234> there seems to be a section with variable cross reference at the end of the docs
Mar 07 18:41:50 <ali1234> fray: TMPDIR[doc] = "The temporary directory the OpenEmbedded build system uses when it does its work building images. By default, the TMPDIR variable is named tmp within the Build Directory."
Mar 07 18:42:12 <ali1234> iow, it doesn't mention that build products also go there
Mar 07 18:42:23 <ali1234> although i suppose they dont
Mar 07 18:42:25 <fray> anything you build is disposable
Mar 07 18:42:29 <ali1234> they go to DEPLOY_DIR
Mar 07 18:42:41 <fray> correct
Mar 07 18:43:54 <ali1234> bitbake -e will probably help me too
Mar 07 18:44:15 <fray> yes, this is why it is documented the way it is.. so bitbake -e will provide the info
Mar 07 18:44:35 <ali1234> it produces quite a lot of output though
Mar 07 18:47:54 <ali1234> does it matter whether i clone external meta-* stuff inside or outside the main poky dir?
Mar 07 18:48:11 <ali1234> like meta-qt5 for example
Mar 07 18:48:27 <ali1234> does it have to go along side meta? or can is that just convention?
Mar 07 20:00:52 <rburton> khem: https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/1076/steps/BuildImages/logs/stdio <— go doesn't like x32
Mar 07 20:01:03 <rburton> damn that error for not being clear
Mar 07 20:01:26 <fray> I'm not surprised by that.. :|
Mar 07 20:03:36 <rburton> khem: https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/1097/steps/BuildImages/logs/stdio <— goarch explodes on ppc
Mar 07 20:04:01 <rburton> khem: https://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/1086/steps/BuildImages/logs/stdio <— and mips the same way
Mar 07 20:04:14 <rburton> if it just doesn't work on those arches then we need some compatible machine statements
Mar 07 20:05:18 <rburton> oh there's a skippackage in goarch
Mar 07 20:05:30 <rburton> but that doesn't really give neat errors
Mar 07 20:05:58 <rburton> can we also have COMPATIBLE_* statements in the core recipe to make it clearer?
Mar 07 20:53:04 <ali1234> i'm reading this: http://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#changing-the-configuration
Mar 07 20:53:44 <ali1234> "If you have a final Linux kernel .config file you want to use, copy it to a directory named files, which must be in your layer's recipes-kernel/linux"
Mar 07 20:54:23 <ali1234> the layer i am looking at doesn't have that directory, but it still has "file://defconfig" in the .bbappend
Mar 07 20:54:30 <ali1234> so what is that about?
Mar 07 20:55:35 <ali1234> it actually specifies it a bit different, but it still doesn't exist
Mar 07 20:55:43 <ali1234> see https://github.com/jumpnow/meta-rpi/blob/morty/recipes-kernel/linux/linux-raspberrypi_4.9.bbappend
Mar 07 20:55:57 <ali1234> and https://github.com/jumpnow/meta-rpi/tree/morty/recipes-kernel/linux/linux-raspberrypi-4.9
Mar 07 21:03:21 <bluelightning> ali1234: that's actually a very good question
Mar 07 21:03:27 <bluelightning> it ought to be there...
Mar 07 21:04:17 <ali1234> i want to use 100% my own custom kernel config
Mar 07 21:04:27 <ali1234> but i don't understand where  i am supposed to put it
Mar 07 21:06:27 <bluelightning> ali1234: if you have your own bbappend with FILESEXTRAPATHS_prepend... in your own layer, which has a higher priority, and you put your defconfig in the directory you specify in the value, then it will be used in preference to any other
Mar 07 21:07:01 <ali1234> meta-rpi is someone elses "own layer" which works on top or meta-raspberrypi
Mar 07 21:07:09 <ali1234> so they've already done that, or something similar to that
Mar 07 21:07:15 <ali1234> but i don't understand how it works
Mar 07 21:08:08 <ant_home> khem, ouch..testing master with binutils 2.28
Mar 07 21:08:11 <ant_home> ERROR: Task (/oe/oe-core/meta/recipes-devtools/cmake/cmake-native_3.7.2.bb:do_compile) failed with exit code '1'
Mar 07 21:08:44 <ali1234> or rather i dont understand WHY it works.. because it does appear to work
Mar 07 21:18:11 <ant_home> khem, parsing errors
Mar 07 21:18:13 <ant_home> | g++: internal compiler error: Killed (program cc1plus)
Mar 07 21:18:14 <ant_home> | Please submit a full bug report,
Mar 07 21:19:04 <bluelightning> ali1234: ah, now I understand
Mar 07 21:19:15 <bluelightning> ali1234: the defconfig is in the original meta-raspberrypi layer
Mar 07 21:19:33 <ali1234> there is one, yes
Mar 07 21:19:53 <ali1234> but in a different directory
Mar 07 21:19:57 <ali1234> and i dont think it is used
Mar 07 21:20:01 <bluelightning> ali1234: that's already in the default search path
Mar 07 21:20:55 <ali1234> so what actually happens?
Mar 07 21:21:19 <bluelightning> ali1234: the bbappend needs to include file://defconfig in its SRC_URI value because it's setting it outright, so the previous addition of that in linux-raspberrypi.inc won't be applicable
Mar 07 21:21:45 <ali1234> linux-raspberrypi.inc doesn't use it, it runs "make whatever_defconfig" manually
Mar 07 21:21:50 <bluelightning> what actually happens is that defconfig will be used, assuming there is no other in the search path
Mar 07 21:21:53 <ali1234> ie using the in source config
Mar 07 21:22:16 <bluelightning> well, shoot the layer maintainer for setting it up confusingly ;)
Mar 07 21:22:25 <ali1234> which layer tho?
Mar 07 21:23:22 <ali1234> the defconfig file in meta-raspberrypi is empty except a comment that says "this is only here to get past initial kernel config and we wipe it later"
Mar 07 21:23:25 <bluelightning> meta-raspberrypi, that's where what you are describing is being done
Mar 07 21:23:28 <ali1234> or something like that
Mar 07 21:23:34 <bluelightning> ok, then that explains that
Mar 07 21:25:04 <bluelightning> this is a real mess looking over these files :(
Mar 07 21:25:27 <ali1234> it makes me feel better about my own hand-rolled image building scripts that i'm trying to get rid of because they are a mess
Mar 07 21:25:29 <bluelightning> two inc files, multiple config handling pieces
Mar 07 21:25:39 <bluelightning> and a class as well
Mar 07 21:25:56 <bluelightning> khem: paulbarker: ^
Mar 07 21:42:46 <ant_home> khem: the log is here https://filebin.net/f9nxz2lnljp70vpj
Mar 07 22:06:26 <ant_home> khem, somehow cmake-native did compile now after cleaning tmpdir. It failed on first run from scratch. Doh
Mar 07 22:54:42 <mattsm> bluelightning: for https://bugzilla.yoctoproject.org/show_bug.cgi?id=7733
Mar 07 22:54:43 <yocti> Bug 7733: enhancement, Low, Future, paul.eggleton, NEW , Add an option to execute task for target and all of its dependent targets
Mar 07 22:54:56 <mattsm> bluelightning: how do you envision invoking bitbake?
Mar 07 22:55:53 <bluelightning> mattsm: I guess something like bitbake --runall do_patch core-image-minimal
Mar 07 22:56:39 <ant_home> khem, sorry for the noise, I was just OOM :/
Mar 07 23:00:53 <bluelightning> mattsm: just replied to RP's comment
Mar 07 23:02:04 <mattsm> bluelightning another one or the one from 28 min ago?
Mar 07 23:03:02 <RP> bluelightning: also replied :)
Mar 07 23:03:45 <bluelightning> ok
Mar 07 23:04:26 <bluelightning> I'm also not saying this is the way it has to work, just the way I'd thought about it in the fairly short time I have spent thinking about it ;)
Mar 07 23:04:51 <RP> bluelightning: having spent a lot more time in the past on this, I think it probably does ;-)
Mar 07 23:21:26 <mattsm> bluelightning i didn't see any new comments, just the emails you sent
Mar 07 23:22:18 <bluelightning> mattsm: we're up to comment 3 on https://bugzilla.yoctoproject.org/show_bug.cgi?id=7733 - is that not what you are seeing?
Mar 07 23:22:19 <yocti> Bug 7733: enhancement, Low, Future, paul.eggleton, NEW , Add an option to execute task for target and all of its dependent targets
Mar 07 23:22:25 <mattsm> Oh, ok
Mar 07 23:22:27 <mattsm> on the bug itself
Mar 07 23:22:33 <mattsm> was looking for emails
Mar 07 23:22:47 <bluelightning> mattsm: ah right, sorry for the confusion, so many different communication mediums :D
Mar 07 23:23:31 <mattsm> good info there
Mar 07 23:23:49 <mattsm> make sense why the BB_DEFAULT_TASK was there now
Mar 08 02:58:35 <mattsm> RP bluelightning sent a patch to bitbake devel for the issue earlier
**** ENDING LOGGING AT Wed Mar 08 03:00:01 2017