**** BEGIN LOGGING AT Fri Sep 21 03:00:02 2018
Sep 21 08:00:46 <boucman_work> Hey all
Sep 21 08:01:09 <boucman_work> I am trying to build a minimalistic image for inside a light-container, and bash gets pulled in as a dependency...
Sep 21 08:01:31 <boucman_work> from what I can tell, my main program has a dependency on /bin/sh and bash is chosen as the provider.
Sep 21 08:01:39 <boucman_work> I have two questions about that...
Sep 21 08:01:52 <boucman_work> (runtime dependencies, I didn't find any DEPENDS about that)
Sep 21 08:03:16 <boucman_work> * Why does yocto think he needs /bin/sh ? my image only has lightttpd and its dependencies, but yocto decided it needed a shell... does something, somewhere scan the header of scripts looking for #!/bin/sh ? if yes, is there a way to influence that ?
Sep 21 08:04:22 <boucman_work> * why did yocto decide that bash was the right provider for /bin/sh, and can I change it ? I guess the fact that bash provides /bin/sh is somewhere in the dnf database, but I don't understand how yocto figured out that it had to compile that recipe in the first place...
Sep 21 08:04:50 <boucman_work> (afaik PREFERRED_PROVIDER only works for packages, not for files provided by packages)
Sep 21 08:42:29 <mcfrisk> The build failure madness I've seen with some seems to have been caused by cmake modules including absolute paths to a sysroot of the recipe build environment. In our sources this seems to be a bit epidemic. Any hints or examples how to write a QA check for this? I should propably also check pkg-config .pc files too.
Sep 21 08:42:41 <mcfrisk> /some/sumo/
Sep 21 08:55:30 <mcfrisk> wouldn't buildpaths QA check already find these? why isn't it enabled in poky by default?
Sep 21 08:56:12 <boucman_work> Hmm, my question seems to boil down to how to influence providers of update-alternatives
Sep 21 08:56:17 <boucman_work> but I can't find that in the doc...
Sep 21 09:09:30 <Andrus997> Hello guys
Sep 21 09:10:22 <Andrus997> I have problem to set up limits in my poky, ulimit and /etc/limits doesn't work
Sep 21 09:10:39 <Andrus997> only prlimit works without problem....
Sep 21 09:11:02 <Andrus997> do you have an idea how change default limits?
Sep 21 09:53:20 <kuzulis> Hi all. How I can remove some packages from the output image?
Sep 21 09:53:36 <kuzulis> e.g. I want to remove the 'sudo' package..
Sep 21 09:53:48 <LetoThe2nd> kuzulis: do not install them in the first place :)
Sep 21 09:54:38 <kuzulis> I have added this: IMAGE_INSTALL_remove = 'sudo' && DISTRO_FEATURES_remove = 'sudo' ...
Sep 21 09:54:49 <kuzulis> but this does not help
Sep 21 09:54:55 <LetoThe2nd> kuzulis: better find out why it is even installed.
Sep 21 09:55:43 <kuzulis> LetoThe2nd: How I can find it? I did not see any mention of 'sudo' in my layer
Sep 21 09:56:42 <LetoThe2nd> kuzulis: are you using some premade image or distribution?
Sep 21 09:58:09 <kuzulis> LetoThe2nd: Ho, I have created an own yocto layer (based on boot2qt)
Sep 21 09:58:19 <kuzulis> LetoThe2nd: s/Ho/No
Sep 21 09:58:42 <LetoThe2nd> then you are probably pulling in something that has a dependency on it, i guess
Sep 21 10:00:39 <LetoThe2nd> i'd say, start with bitbake -g $YOURIMAGENAME && less task-depends.dot
Sep 21 10:00:43 <LetoThe2nd> there, look for sudo
Sep 21 10:02:59 <zagor> or just bitbake -g sudo ?
Sep 21 10:04:43 <LetoThe2nd> zagor: that should tell you on what sudo depends, but not what depends on sudo :)
Sep 21 10:04:54 <zagor> ahh, right
Sep 21 10:05:06 <LetoThe2nd> but, looking at package-depends is probably less spammy.
Sep 21 10:05:30 <kuzulis> I got:
Sep 21 10:05:31 <kuzulis> "sudo" -> "quilt-native"
Sep 21 10:05:31 <kuzulis> "sudo" -> "libtool-cross"
Sep 21 10:05:31 <kuzulis> "sudo" -> "libtool-native"
Sep 21 10:05:31 <kuzulis> "sudo" -> "linux-libc-headers"
Sep 21 10:05:31 <kuzulis> "sudo" -> "autoconf-native"
Sep 21 10:05:32 <kuzulis> "sudo" -> "binutils-cross-arm"
Sep 21 10:05:34 <kuzulis> "sudo" -> "gcc-cross-arm"
Sep 21 10:05:36 <kuzulis> "sudo" -> "pseudo-native"
Sep 21 10:05:38 <kuzulis> "sudo" -> "glibc"
Sep 21 10:05:40 <kuzulis> "sudo" -> "gcc-runtime"
Sep 21 10:05:42 <kuzulis> "sudo" -> "rpm-native"
Sep 21 10:05:45 <LetoThe2nd> please, no mass pasting in here
Sep 21 10:05:46 <kuzulis> "sudo" -> "automake-native"
Sep 21 10:05:48 <kuzulis> "sudo" -> "opkg-utils-native"
Sep 21 10:05:50 <kuzulis> "sudo" -> "gnu-config-native"
Sep 21 10:05:52 <kuzulis> "sudo" -> "libgcc"
Sep 21 10:05:54 <kuzulis> "sudo" -> "prelink-native"
Sep 21 10:05:56 <kuzulis> at -g sudo
Sep 21 10:05:58 <kuzulis> ok
Sep 21 10:06:09 <LetoThe2nd> like i said, it only told you what sudo depends on.
Sep 21 10:06:28 <kuzulis> So, do I need 'bitbake -g $YOURIMAGENAME && less task-depends.dot' instead?
Sep 21 10:07:05 <LetoThe2nd> bitbake -g $YOURIMAGENAME && less package-depends.dot
Sep 21 10:08:28 <kuzulis> But then 'package-depends.dot' is not exists
Sep 21 10:08:55 <kuzulis> I have only recipe-depends.dot  task-depends.dot
Sep 21 10:09:02 <Andrus997> #/j oe
Sep 21 10:09:22 <LetoThe2nd> kuzulis: then start by inspecting those? (i assume that you properly replaced the image name, right?)
Sep 21 10:10:52 <kuzulis> LetoThe2nd: I got this: https://pastebin.com/WJSdJt77
Sep 21 10:11:33 <LetoThe2nd> kuzulis: so did you inspect the resulting files?
Sep 21 10:12:52 <kuzulis> LetoThe2nd: What of file I need to inspect? task-depends.dot or recipe-depends.dot?
Sep 21 10:13:06 <LetoThe2nd> kuzulis: why not go ahead and find out?
Sep 21 10:16:23 <kuzulis> LetoThe2nd: When this command 'bitbake -g $YOURIMAGENAME && less package-depends.dot' finishes, then I see two files: task-ls
Sep 21 10:17:02 <kuzulis> Sorry, I see one file task-depends.dot
Sep 21 10:18:52 <LetoThe2nd> kuzulis: and what does it tell you about sudo?
Sep 21 10:19:04 <kuzulis> Oops... I see two files: recipe-depends.dot  task-depends.dot.
Sep 21 10:20:10 <kuzulis> LetoThe2nd: The 'recipe-depends.dot' has this: https://pastebin.com/fgqSHPpQ
Sep 21 10:20:55 <LetoThe2nd> kuzulis: well then, there you are.
Sep 21 10:21:10 <kuzulis> LetoThe2nd: And task-recipe.dot this: https://pastebin.com/qJ0kH6T6
Sep 21 10:21:11 <alexlarsson> rburton: hey, i'm having some weird issues
Sep 21 10:21:21 <rburton> hey alexlarsson
Sep 21 10:21:26 <LetoThe2nd> kuzulis: the first 3 lines are totally self-explaining, don't you agree?
Sep 21 10:21:38 <alexlarsson> I'm sure they are partly my fault, but I don't know where to start
Sep 21 10:21:57 <alexlarsson> So, i'm building the freedesktop sdk base, which is yocto based
Sep 21 10:22:08 <alexlarsson> And, i'm building on a x86-64 machine
Sep 21 10:22:34 <kuzulis> LetoThe2nd: Do you mean, lines from task-depends.dot?
Sep 21 10:22:47 <LetoThe2nd> kuzulis: recipe-depends
Sep 21 10:22:51 <alexlarsson> And, i'm building in a x86-64 flatpak (i.e. /usr/bin/gcc is a x86-64 -> x86-64 and we're setarch x86-64)
Sep 21 10:22:59 <rburton> alexlarsson: didn't you move to buildstream already?
Sep 21 10:23:07 <alexlarsson> But, i'm building an i386 runtime
Sep 21 10:23:21 <alexlarsson> rburton: this is just changing the build env for the old runtime
Sep 21 10:23:35 <kuzulis> LetoThe2nd: And, how I can break dependency from: "packagegroup-core-x11-base" -> "sudo" and "mini-x-session" -> "sudo" ?
Sep 21 10:23:49 <alexlarsson> rburton: anyway, i get a bunch of failures, see e.g. https://flathub.org/builds/#/builders/21/builds/477/steps/5/logs/stdio
Sep 21 10:24:01 <alexlarsson> rburton: but, fundamentally, it seems confused about the host arch
Sep 21 10:24:19 <LetoThe2nd> kuzulis: i guess the dependency is there for a reason. so, construct an image without mini-x-session. or without packagegroup-x11 altogethere. or just live with sudo.
Sep 21 10:24:38 <alexlarsson> rburton: i.e. gmp-native fails to build, because configure fails when it decides sizeof(long) != 4
Sep 21 10:24:47 <alexlarsson> which is true, it is 8
Sep 21 10:24:59 <alexlarsson> And the reason seems to be, from config.log:
Sep 21 10:25:13 <alexlarsson>  $ ../gmp-6.1.1/configure --build=i386-linux --host=i386-linux --target=i386-linux --prefix=
Sep 21 10:25:26 <alexlarsson> rburton: surely some of those i386 should be x86-64? no?
Sep 21 10:25:32 <kuzulis> LetoThe2nd: Ok, many thanks.. Seems I understand a main idea.. :)
Sep 21 10:25:40 <LetoThe2nd> kuzulis: have fun
Sep 21 10:26:41 <alexlarsson> rburton: But, i have no idea how/why bitbake chose those options?
Sep 21 10:27:16 <rburton> BUILD_ARCH := "${@os.uname()[4]}"
Sep 21 10:27:34 <alexlarsson> rburton: i'm guessing something about the gcc in the runtime gets this wrong?
Sep 21 10:29:12 <rburton> where is your layer again?
Sep 21 10:30:16 <alexlarsson> $ flatpak run --command=python org.flatpak.Builder -c "import os; print os.uname()"
Sep 21 10:30:16 <alexlarsson> ('Linux', 'localhost.localdomain', '4.17.14-202.fc28.x86_64', '#1 SMP Wed Aug 15 12:29:25 UTC 2018', 'x86_64')
Sep 21 10:30:41 <alexlarsson> https://github.com/flatpak/freedesktop-sdk-base (branch 1.6)
Sep 21 10:31:45 <rburton> your job is passing i386 to build.sh so ARCH=i386 to flatpak run
Sep 21 10:33:08 <alexlarsson> yeah
Sep 21 10:33:40 <alexlarsson> in fact, i'm manually running: flatpak run --command=make org.flatpak.Builder all ARCH="i386"
Sep 21 10:33:53 <alexlarsson> and i only have the x86-64 org.flatpak.Builder installed
Sep 21 10:34:01 <alexlarsson> I tried to run the i386 one
Sep 21 10:34:11 <alexlarsson> but bitbake hanged on startup with some deadlock
Sep 21 10:34:17 <rburton> fun
Sep 21 10:34:35 <rburton> why does freedesktop-sdk-build-yocto set BUILD_ARCH = "${architecture}"?
Sep 21 10:34:55 <alexlarsson> Is that not how you set the target arch?
Sep 21 10:35:34 <alexlarsson> the weird thing is that all this works on the x86-64 buildmachine (running some centos base)
Sep 21 10:35:38 <rburton> just MACHINE should be suffient
Sep 21 10:35:48 <rburton> setting BUILD_ARCH overrides the uname
Sep 21 10:35:55 <alexlarsson> hmm
Sep 21 10:35:56 <rburton> the value *from* uname
Sep 21 10:36:26 <kuzulis> LetoThe2nd: But, what about wayland? https://pastebin.com/r1UK3ESi
Sep 21 10:36:32 <alexlarsson> ok, so if i drop BUILD_ARCH it might work?
Sep 21 10:36:34 * alexlarsson tries
Sep 21 10:36:37 <rburton> alexlarsson: worth a go
Sep 21 10:37:31 <alexlarsson> HERE WE GO!
Sep 21 10:37:43 <alexlarsson> rburton: the level of indirection here is amazing tho
Sep 21 10:38:14 <alexlarsson> x86-64 fedora => x86-64 fd.o runtime -> yocto cross builds to i386
Sep 21 10:38:33 <rburton> quick put it all inside a docker
Sep 21 10:38:58 <alexlarsson> rburton: i wonder if it worked before is because i previously built first built a 64bit, then a 32bit
Sep 21 10:39:05 <alexlarsson> so maybe it reused the -native rpms?
Sep 21 10:39:18 <rburton> yeah native stuff is target-agnostic
Sep 21 10:39:20 <alexlarsson> would it do that?
Sep 21 10:39:40 <rburton> apart from the bits which care like gcc, obviously
Sep 21 10:40:09 <alexlarsson> woa
Sep 21 10:40:14 <alexlarsson> it seems like it goes
Sep 21 10:42:54 <alexlarsson> rburton: we'll get to that when we make the buildbot workers run in docker containers on a kubernetes cluster!
Sep 21 10:43:28 <rburton> the future!
Sep 21 10:44:10 <LetoThe2nd> kuzulis: um, what is the actual question?
Sep 21 10:47:01 <kuzulis> LetoThe2nd: Sorry, please skip..
Sep 21 10:52:36 <alexlarsson> rburton: new try: https://flathub.org/builds/#/builders/2/builds/4650
Sep 21 10:52:43 <alexlarsson> lets hope this one works :)
Sep 21 10:54:06 <rburton> fingers crossed
Sep 21 10:54:25 <rburton> you have post-build checks to eg sanity check the binaries are the expected architecture?
Sep 21 10:54:50 <alexlarsson> NOTE: recipe gmp-native-6.1.1-r0: task do_configure: Succeeded
Sep 21 10:54:53 <alexlarsson> woho
Sep 21 10:55:25 <alexlarsson> nah
Sep 21 10:55:31 <alexlarsson> no sanity checks
Sep 21 10:55:34 <alexlarsson> :)
Sep 21 10:56:02 <rburton> qa is for wimps without confidence
Sep 21 10:56:15 <alexlarsson> yeah
Sep 21 10:58:50 <rburton> why is everyone dumping their new arch enabling patches on the list the *day* that we hope to roll our feature freeze build
Sep 21 10:59:17 <nrossi> rburton: for me, it was just co-incidence... :|
Sep 21 11:00:17 <LetoThe2nd> rburton: *BECAUSE*!
Sep 21 11:00:32 <rburton> nrossi: yours might be good for post-m3 because they're so isolated
Sep 21 11:02:49 <nrossi> rburton: sounds good to me, I was just posting them to get included "at some point" :)
Sep 21 11:04:39 <rburton> nrossi: what's being built with that target?
Sep 21 11:06:34 <nrossi> rburton: embedded programs, I was just playing with it. But mithro was after support for his litex/migen use
Sep 21 11:06:54 <mcfrisk> sigh, "ERROR: Unable to start bitbake server" isn't really helpful..
Sep 21 11:10:19 <mithro> Hey nrossi!
Sep 21 11:10:45 <mithro> nrossi: Thanks for working on lm32 support!
Sep 21 11:12:00 <nrossi> mithro: hi, no problem the fact that it is all upstream in gnu made it a easy :)
Sep 21 11:12:34 <mithro> nrossi: Do you know if or1k is supported? Stafford Horne just got or1k into upstream gcc....
Sep 21 11:13:13 <nrossi> mithro: I saw those hit gcc, not sure what state all the pieces are in though
Sep 21 11:19:02 <nrossi> mithro: does not look like they have been applied to gcc just yet
Sep 21 11:19:22 <mithro> nrossi: Stafford is going to give a talk on the topic in a couple of hours
Sep 21 11:20:04 <nrossi> mithro: there is another one to add to the list of topics to watch from orconf :)
Sep 21 11:20:23 <mithro> nrossi: I'll be talking about SymbiFlow tomorrow!
Sep 21 11:20:45 <mithro> nrossi: Won't be talking about TimVideos / LiteX stuff...
Sep 21 11:21:01 <nrossi> mithro: the symbiflow one is already on my list :)
Sep 21 11:51:41 <rburton> alexlarsson: well your build didn't explode into fire
Sep 21 11:51:54 <rburton> alexlarsson: i wonder if the output is right :)
Sep 21 11:53:20 <alexlarsson> rburton: yeah...
Sep 21 11:54:07 <kinsifous> Hi, Im trying to understand how the DL_DIR and the SOURCE_MIRROR_URL work. I understand that the SOURCE_MIRRROR_URL copies all the specified folder to the build-dir and in DL_DIR it just specifies which folder to use. But while reading for the DL_DIR, i saw that it says it doesnt use the git repositories. Can someone elaborate that?
Sep 21 11:55:11 <kinsifous> Also, when you are builing on a ci-cd server and your cache is NFS-mounted. Would that complicate things in any way? Depending on if you use the DL_DIR or the SOURCE_MIRROR_ULR?
Sep 21 11:55:15 <alexlarsson> rburton: a local build seems to work
Sep 21 12:00:40 <kinsifous> This is where im reading
Sep 21 12:00:40 <kinsifous> https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-DL_DIR
Sep 21 12:07:13 <mithro> nrossi: The more people help with my other projects, the more time I can dedicate to SymbiFlow :-P
Sep 21 12:07:24 <mithro> nrossi: So your helping SymbiFlow right now!
Sep 21 12:21:08 <mcfrisk> rabbit holes are nice, turns out libcrypto.pc generated by openssl has libdir=${exec_prefix}//lib which somehow ends up fully expanded to build sysroot path in a project which generates a cmake module using it
Sep 21 12:22:36 <mcfrisk> and linker commands using the cmake module end up having -L$${libdir} with an absolute path to recipe sysroot of the recipe which generated the cmake module
Sep 21 12:23:45 <mcfrisk> question is, should yocto/bitbake be replacing those pkg-config paths with something else and is the extra slash / causing this problem..
Sep 21 12:29:48 <mithro> nrossi: Would it help for me to ack or some otherway confirm the lm32 stuff would be useful for me?
Sep 21 12:33:19 <nrossi> mithro: unless rburton wants some info? although i think he was mostly just curious
Sep 21 12:41:15 <rburton> mcfrisk: the pkgconfig file should have paths not including the sysroot, so -L/usr/lib etc
Sep 21 12:41:23 <rburton> and then pkgconfig appends the sysroot as required
Sep 21 12:43:37 <kanavin> rburton: I've been thinking about teaching make and ninja to watch RAM and load average (and avoid spawning new compilers when either is close to the limit). Good idea?
Sep 21 12:44:02 <kanavin> rburton: at least two major automotive vendors have to artificially slow down builds because of this issue, I think YP can do better here
Sep 21 12:44:14 <rburton> can the make thing be handled inside bitbake by using the makeserver thing?
Sep 21 12:44:34 <kanavin> rburton: possibly, but ninja cannot
Sep 21 12:47:10 <kanavin> rburton: also the idea is to upstream this as new command line parameters similar to -j, as makeserver thing uses unofficial, undocumented interface if I remember right
Sep 21 12:47:31 <rburton> oh its documented but its definitely make-centric
Sep 21 13:01:38 <kanavin> rburton: the pseudo thing is a disappointment of the year! :(
Sep 21 13:01:47 <kanavin> that it didn't solve the legendary glibc-locale thing
Sep 21 13:13:46 <mithro> kanavin: I'm pretty sure ninja already has load average watching
Sep 21 13:16:05 <kanavin> mithro: right, then just the low-RAM situation needs addressing
Sep 21 13:21:19 <rburton> kanavin: yeah i was all excited
Sep 21 13:21:35 <rburton> kanavin: at least it failed within an hour of me doing the update so i didn't get my hopes up
Sep 21 13:27:22 <mcfrisk> rburton: then cmake is buggy with its module generation as it expands to the full path and breaks everything
Sep 21 13:28:04 <rburton> mcfrisk: cmake broken? shock!
Sep 21 13:28:10 <rburton> say it can't be true
Sep 21 13:29:05 <rburton> mcfrisk: note that pkgconfig only does the sysroot magic on --cflags and --libs, if whatever is using --variable to get the value then sysroot magic won't happen
Sep 21 13:32:13 <mcfrisk> yea, cmake... my problems is somehow with the pkg-config --libs
Sep 21 13:33:58 <mcfrisk> but that ends with recipes using each others sysroots, seccomp or fs namespaces would be nice to block this from happening
Sep 21 13:35:58 <rburton> have you checked that the pc file in the sysroot is correctly just showing /usr/lib/ and /usr/include/...?
Sep 21 13:38:33 <mcfrisk> rburton: yes, after exporting PKG_CONFIG_PATH in devshell, I can see pkg-config --libs libcrypto reporting the absolute path: ../recipe-sysroot/usr//lib -lcrypto
Sep 21 13:38:43 <mcfrisk> this ends up the cmake module and bang..
Sep 21 13:38:55 <rburton> mcfrisk: what does the file actually say though
Sep 21 13:39:19 <rburton> but that path should be good
Sep 21 13:39:25 <rburton> so yeah, blame cmake i guess
Sep 21 13:40:52 <mcfrisk> and if I edit ../recipe-sysroot/usr/lib/pkgconfig/libcrypto.pc and replace libdir=${exec_prefix}//lib with libdir=${exec_prefix}/lib then all is well and the absolute path is gone
Sep 21 13:41:21 <mcfrisk> AND, I saw the extra slash openssl Makefile in variable LIBDIR=/lib
Sep 21 13:41:43 <mcfrisk> but after rebuilding openssl from sources it is gone and says plain LIBDIR=lib...
Sep 21 13:42:23 <mcfrisk> so it's actually not cmake but openssl and it's libcrypto.pc
Sep 21 13:44:19 <ag_nmiller> Not sure if this is the right place to ask but how would I go about modifying the compile flags for the kernel in Yocto/Bitbake? I'm trying to debug some stuff and wanted to add -DDEBUG and -DVERBOSE_DEBUG but I'm coming up short with google on how to do that.
Sep 21 13:54:14 <mcfrisk> found it, openssl recipes and libdirleaf leave and extra slash / to .pc files causing all this...
Sep 21 14:22:00 <alexlarsson> rburton: it built!
Sep 21 14:22:04 <alexlarsson> rburton: thanks a bunch!
Sep 21 14:22:43 <alexlarsson> rburton: also, one builder is slower than the others... https://flathub.org/builds/#/builders/2/builds/4650
Sep 21 14:38:35 <rburton> alexlarsson: is that building on a rpi or something?
Sep 21 14:38:53 <alexlarsson> rburton: its just the others being really fast...
Sep 21 14:38:57 <rburton> alexlarsson: glad that was easy to solve.  even better when the fix is deleting stuff...
Sep 21 14:39:57 <alexlarsson> rburton: https://twitter.com/ramcq/status/964299811997536256
Sep 21 14:41:18 <alexlarsson> The aarch64 build ended up on that
Sep 21 14:41:27 <alexlarsson> and the arm one on some codethink machine...
Sep 21 16:06:19 <davenporten> Hey Everyone, can anyone tell me how exactly to us DISTRO_FEATURES_append?
Sep 21 16:06:23 <davenporten> use*
Sep 21 16:08:38 <rburton> DISTRO_FEATURES_append = " pam"
Sep 21 16:08:44 <rburton> will add the pam feature to DISTRO_FEATURES
Sep 21 16:12:15 <davenporten> rburton: Ok, but couldn't that be done with IMAGE_INSTALL_append?
Sep 21 16:12:30 <rburton> no becase distro features are totally unrelated to image install
Sep 21 16:12:30 <davenporten> rburton: Or something similar
Sep 21 16:12:49 <rburton> a DISTRO_FEATURE is something like 'supports opengl' or 'has bluetooth'
Sep 21 16:13:16 <rburton> just having opengl supported doesn't mean mesa is in every image
Sep 21 16:13:23 <rburton> you wouldn't want mesa in your initramfs
Sep 21 16:13:24 <davenporten> rburton: Ah, ok, gotcha. I didn't really understand pam I guess. Thanks a lot
Sep 21 16:16:45 <rburton> mcfrisk: well done :)
Sep 21 18:13:26 <mcfrisk> rburton: thanks, I have a new QA check on top of that to make sure this never happens again but it's already catching more offenders... just grep for TMPDIR path in .pc and .cmake files in sysroot... sigh
Sep 21 19:00:40 <uglyoldbob> is there a recipe that builds a gdb-cross-native or equivalent? gdb runs on host and targets the MACHINE being built for?
Sep 21 19:54:45 <rburton> mcfrisk: i thought we had a check for tmpdir appearing in the sysroot already
Sep 21 19:54:52 <rburton> maybe its not on by default
Sep 21 20:59:08 <JPEW> Hmm, I would like the option to split the -dbg package in two: one that contains the source, and one that contains the debug symbols extracted from the elf files.... Thoughs?
Sep 22 00:07:01 <yocti> New news from stackoverflow: Yocto update to Sumo with Multilib results in error in do_image_wic <https://stackoverflow.com/questions/50470148/yocto-update-to-sumo-with-multilib-results-in-error-in-do-image-wic>
**** ENDING LOGGING AT Sat Sep 22 03:00:00 2018