**** BEGIN LOGGING AT Wed Mar 28 03:00:01 2018
Mar 28 03:15:10 <yocti> New news from stackoverflow: Yocto: create a symlink in an image recipe <https://stackoverflow.com/questions/49525426/yocto-create-a-symlink-in-an-image-recipe>
Mar 28 03:21:43 <kireevco> ok. i figured it out. all.bash -related message is not really an error, it doesn't prevent building stuff. so deceptive :-D
Mar 28 05:45:37 <yocti> New news from stackoverflow: Keeping rootfs with Inheriting rm_work in yocto <https://stackoverflow.com/questions/49526623/keeping-rootfs-with-inheriting-rm-work-in-yocto>
Mar 28 06:15:43 <yocti> New news from stackoverflow: Difference between wic and hddimg format in yocto <https://stackoverflow.com/questions/49527057/difference-between-wic-and-hddimg-format-in-yocto>
Mar 28 08:01:25 <fberg> hello guys ! I have a recipe that builds a .so library. I have added the  PACKAGES="${PN}-dev". Bitbake complains that QA Issue: -dev package contains non-symlink .so:
Mar 28 08:02:42 <fberg> what am I supposed to do ?
Mar 28 08:03:17 <LetoThe2nd> fberg: are you manually installing the files, or have you modified the FILES_* variables?
Mar 28 08:03:47 <LetoThe2nd> fberg: basically the warning tells you that your library ends up in the -dev package, not the standard one.
Mar 28 08:04:24 <fberg> LetoThe2nd: I haven't overwritten/updated the FILES_${PN}-dev
Mar 28 08:05:08 <LetoThe2nd> fberg: and what installation process are you using?
Mar 28 08:05:13 <fberg> but i have updated the FILES_${PN}-dbg variable only
Mar 28 08:06:45 <fberg> do_install(){
Mar 28 08:06:45 <fberg>         oe_runmake install incdir=${D}${includedir} libdir=${D}${libdir}
Mar 28 08:06:45 <fberg> }
Mar 28 08:08:34 <LetoThe2nd> well chances are that either your probably handwritten Makefile deploys to something else than libdir - or that you have to manually expand FILES_${PN} to pull the library into the correct image. inspecting the recipes sysroot respective packagesplit directories should give you some hints whats going on.
Mar 28 08:12:07 <fberg> LetoThe2nd: probably you are right
Mar 28 08:12:14 <fberg> the non -dev packages is empty
Mar 28 08:12:20 <LetoThe2nd> \o/
Mar 28 08:14:47 <fberg> that is quite stringe since the install target install to libdir and incdir
Mar 28 08:15:29 <fberg>         @echo "CP mylib.so"
Mar 28 08:15:29 <fberg>         $(E)$(INSTALL) -m 644 libtinkerforge.so $(libdir)
Mar 28 08:59:06 <fberg> how can I disable -Werror flag within a recipe ? I've tried setting TARGET_CFLAGSi but it only adds additional flags
Mar 28 09:10:42 <mcfrisk> should I file bugs for unfixed CVE's in poky master branch?
Mar 28 09:20:23 <nayfe> mcfrisk: I think you can post CVE issues in oe-core mailinglist (kanavin rburton)
Mar 28 09:22:30 <kanavin> mcfrisk: it's better if you post patches
Mar 28 09:24:41 <LetoThe2nd> an alternative is to post cards!
Mar 28 09:24:45 <LetoThe2nd> </SCNR>
Mar 28 09:26:16 <mcfrisk> :) yea, I know. planning for yocto update and our current brach has no cve check findings, but master branch has so..
Mar 28 09:30:50 <mcfrisk> core-image-minimal cve check findings are: coreutils CVE-2017-18018, shadow CVE-2016-6252, db CVE-2016-0682 CVE-2016-0689 CVE-2016-0692 CVE-2016-0694 CVE-2016-3418, perl CVE-2016-1238, libarchive CVE-2017-14501 CVE-2017-14503, libpcre CVE-2017-11164, busybox CVE-2017-15874, binutils CVE-2018-6543 CVE-2018-6759 CVE-2018-6872 CVE-2018-7208 CVE-2018-7568 CVE-2018-7569 CVE-2018-7570 CVE-2018-7642 CVE-2018-7643
Mar 28 09:31:47 <rburton> mcfrisk: so do you have patches for eg all those db CVEs in your current branch?
Mar 28 09:32:22 <nayfe> maybe its cve tool in master branch that detects more things ?
Mar 28 09:32:36 <rburton> maybe the cve-check-tool is useless
Mar 28 09:32:54 <rburton> (and yes, i made it find db cves in master)
Mar 28 09:33:07 <mcfrisk> or cve check isn't finding these from our branch due to older versions, and possibly NVD database has bad version details (likely)
Mar 28 09:33:26 <rburton> we were looking up 'db' in the database but the correct product is "oracle berkeley db' or similar
Mar 28 09:34:22 <nayfe> rburton: you find that tool useless?
Mar 28 09:34:36 <rburton> well not so much useless as not reliable
Mar 28 09:34:54 <rburton> the solution is to watch the feed of new CVEs and review every single one
Mar 28 09:35:15 <mcfrisk> well, the tool itself is roughly reliable and NVD databse is very unreliable for some CVEs where version details are just plain wrong. but it is better than nothing.
Mar 28 09:36:05 <rburton> mcfrisk: but passable isn't good enough for "did a security review" if it eg misses out all of berkeley db because nobody noticed the mitre database uses a different product name
Mar 28 09:36:57 <rburton> oh great, the mitre database is bust at the moment anyway
Mar 28 09:37:25 <mcfrisk> doing something is better than nothing..
Mar 28 09:37:47 <nayfe> be better than the others :)
Mar 28 09:38:30 <rburton> lovely, the mitre database is now returning http 503
Mar 28 09:39:36 <kanavin> we should do security reviews the hard way
Mar 28 09:39:41 <kanavin> as rburton says
Mar 28 09:39:52 <kanavin> the tools are too unreliable
Mar 28 09:40:25 <kanavin> debian for example has a team which reviews every incoming cve, and decides on action points towards supported releases
Mar 28 09:40:40 <kanavin> the key thing is that this needs to be done by humans
Mar 28 09:40:44 <mcfrisk> well, I follow Debian and Ubuntu security notices and file things into internal bug tracker based on that too..
Mar 28 09:42:09 <mcfrisk> some old issues have been found by yocto cve check so it's not completely useless
Mar 28 09:42:45 <mcfrisk> and for a few issues I have contacted NVD to update e.g. version details for some CVEs
Mar 28 09:44:03 <kanavin> I guess I generally don't like the idea of backporting CVEs, and the fact that a large proportion of security issues never even get a CVE id
Mar 28 09:48:39 <mcfrisk> agreed, escpecially Linux kernel CVE data in NVD is useless, but I have found https://github.com/nluedtke/linux_kernel_cves/ to be useful for them..
Mar 28 09:50:43 <kanavin> mcfrisk: the industry should move towards rolling releases, where instead of backporting security fixes, you'd simply keep up with upstream.
Mar 28 09:51:03 <kanavin> mcfrisk: obviously after thorough runtime testing
Mar 28 09:51:42 <BCMM> both need to exist, imho
Mar 28 09:52:04 <BCMM> (not in yocto, necessarily, but in general)
Mar 28 09:52:30 <BCMM> debian stable *does* work, and it exists for a reason - keeping up with upstream means a whole lotta new problems
Mar 28 09:52:52 <BCMM> backporting fixes (but not new features) takes care of old problems with fewer new problems introduced
Mar 28 09:53:31 <BCMM> (although, as was pointed out, debian does a massive amount of work to maintain that, and it's not perfect)
Mar 28 09:54:48 <kanavin> backporting fixes is often not technically possible, as you do need to understand the code, and even if you do, it might have changed too much between what you need to fix and where the upstream added the fix
Mar 28 09:55:07 <kanavin> for example, no one backports webkit fixes, it's too complex and too much work
Mar 28 09:55:32 <kanavin> so it either goes unpatched, or some distros do keep up with upstream
Mar 28 09:55:47 <kanavin> I'd say a browser engine is a rather security critical component
Mar 28 10:05:51 <rburton> armpit: do you plan on doing the bind upgrade?
Mar 28 10:13:09 <arkom> How to get Kernel build directory (not kernel-build-artifacts) in my recipe?
Mar 28 10:14:23 <arkom> I'm trying to create recipe for propetiary driver, and their build process require path to kernel build dir.
Mar 28 10:18:37 <LetoThe2nd> arkom: have you looked up the documentation on out-of-tree kernel modules?
Mar 28 10:19:23 <LetoThe2nd> arkom: it should all be documented here neatly: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#working-with-out-of-tree-modules
Mar 28 10:23:02 <RyanMeulenkamp> Hi! Question: why does 'make menuconfig' always start from scratch, and not from the provided .config?
Mar 28 10:23:18 <RyanMeulenkamp> And how do I make it start from .config?
Mar 28 10:26:19 <arkom> LetoThe2nd: Yes I did. But inheriting from module.bbclass did not solve my problem. I can get path to kernel-build-artifacts, but it is not enough. The driver I'm trying to integrate, has his weird build process
Mar 28 10:27:54 <LetoThe2nd> arkom: well in my experience, if things like that become too weird its easier to roll a custom kernel repo that integrates whatever you need.
Mar 28 10:28:02 <fberg> hello guys, I'm trying to compile fcgiwrap. I've created a basic recipe that fetch fcgiwrap-1.0.0 from github. By the way during the do_compile() process bitbake exit with the following error:
Mar 28 10:28:05 <fberg> fcgiwrap.c:573:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
Mar 28 10:28:24 <fberg> how can I disbale the -Werror flags ?
Mar 28 10:29:05 <rburton> fberg: -Werror isn't us, its the fcgiwrap recipe
Mar 28 10:29:30 <rburton> some projects think using it is clever but its actually really stupid for exactly this reason
Mar 28 10:29:46 <rburton> (you're using a newer compiler, so get new errors, so the build breaks)
Mar 28 10:29:52 <fberg> that's interesting..
Mar 28 10:30:09 <rburton> if you're lucky there's an option to stop the makefile passing -Werror, if youre unlucky you'll need to patch it out
Mar 28 10:30:19 <fberg> by the way thank you rburton
Mar 28 10:30:25 <rburton> either way complain to the fcgiwrap maintainers that werror should be *opt in*
Mar 28 10:30:41 <fberg> I will
Mar 28 10:54:59 <RyanMeulenkamp> Another question: I built a kernel with perf enabled, and now I get a segfault when loading module 8021q. Why does this happen?
Mar 28 10:57:58 <LetoThe2nd> RyanMeulenkamp: options: 1) module does not match the kernel 2) module is buggy 3) kernel is buggy.
Mar 28 10:58:03 <LetoThe2nd> (all are possible)
Mar 28 10:59:13 <RyanMeulenkamp> It also happens on g_ether
Mar 28 11:00:58 <RyanMeulenkamp> Apparently all kinds of things break when enabling perf..
Mar 28 11:16:43 <yocti> New news from stackoverflow: Yocto generated nativesdk-cmake SDK is incomplete <https://stackoverflow.com/questions/49532977/yocto-generated-nativesdk-cmake-sdk-is-incomplete>
Mar 28 13:47:12 <yocti> New news from stackoverflow: How to setup an Yocto recipe to build from a local git source? <https://stackoverflow.com/questions/49535881/how-to-setup-an-yocto-recipe-to-build-from-a-local-git-source>
Mar 28 14:12:10 <laplante> Now that insserv is gone, has everyone pretty much moved to systemd?
Mar 28 14:17:47 <jww> Hello !
Mar 28 15:09:46 <jww> I have some troubles with a custom recipe, I can build it using bitbake ecsw-lib , but I cannot add it to an image I have an error from dnf telling me it cannot find it.here is the .bb file source, the .bbappend and bitbake output with error : http://dpaste.com/1TWH1H7 , can somebody help please ?
Mar 28 15:17:14 <otavio> rburton: i reported a serious bug on golang
Mar 28 15:38:29 <laplante> jww: check the packages-split directory under the recipe's workdir (e.g. build/tmp/work/mymachine/ecsw-lib/1.0r0..../packages-split/ecsw-lib/) and ensure it's not empty
Mar 28 15:47:45 <fberg> hello guys ! I ahve a recipe whose makefile install mylib.a in /usr/lib using:         install:all install -d -m 755 ${DESTDIR}$(libdir) install -m 644 libjsmn.a ${DESTDIR}$(libdir)
Mar 28 15:48:18 <fberg> the compilation process has no problem, but the QA complains that Files/directories were installed but not shipped in any package:
Mar 28 15:48:47 <fberg>  
Mar 28 15:48:55 <fberg>  usr/lib
Mar 28 15:49:02 <fberg> usr/lib/mylib.a
Mar 28 15:49:37 <fberg> by the way in my recipe I've added: PACKAGES = "${PN} ${PN}-dev"
Mar 28 15:49:49 <kergoth> you removed ${PN}-staticdev, so it's not packaged anymore
Mar 28 15:49:58 <fberg> Does anyone have any suggestion ?
Mar 28 15:55:47 <rburton> fberg: why are you changing PACKAGES?
Mar 28 15:56:06 <rburton> as kergoth said it goes into PN-staticdev normally, which you've explicitly removed
Mar 28 15:57:53 <fberg> rburton:
Mar 28 16:00:10 <fberg> kergoth:
Mar 28 16:00:13 <fberg> thank you
Mar 28 16:01:31 <fberg> I have seen that FILES_${PN} also include ${libdir}/*.a
Mar 28 16:01:43 <fberg> by the way it's not the case
Mar 28 16:01:56 <rburton> only staticdev has .a in by default
Mar 28 16:03:06 <zeddii> somtimes I wish I understood WTF go wants from me when building things
Mar 28 16:03:11 * zeddii wanders off in a rage
Mar 28 16:03:19 <rburton> your firstborn
Mar 28 16:03:53 <zeddii> I'm also wondering why my core-image-kernel-dev has latched onto a kernel module from a kernel version I'm not building and refuses to assemble
Mar 28 16:03:58 <zeddii> this is not helping the rage
Mar 28 16:04:07 <zeddii>  * Solver encountered 1 problem(s):
Mar 28 16:04:07 <zeddii>  * Problem 1/1:
Mar 28 16:04:07 <zeddii>  *   - nothing provides kernel-module-6lowpan-4.15.0-rc9-yoctodev-standard needed by kernel-modules-4.15-rc++git0+ee7e849882_c36098c410-r0.qemux86_64
Mar 28 16:04:07 <zeddii>  *
Mar 28 16:04:08 <rburton> and this is why i do builds in a tmpfs
Mar 28 16:04:15 <rburton> good for blasting away tmp if i need to
Mar 28 16:04:22 <zeddii> I'M BUILDING 4.14 for rburton's test failure!!!
Mar 28 16:04:31 <rburton> yay zeddi
Mar 28 16:04:42 <zeddii> but I can't assemble the core-image-kernel-dev
Mar 28 16:04:50 <zeddii> I guess I'll rm -rf tmp and wait the time again.
Mar 28 16:04:59 * zeddii waves by to the hour that first one took.
Mar 28 16:05:03 <zeddii> bye even
Mar 28 16:05:11 <zeddii> the rage has stopped me from properly typing :D
Mar 28 16:06:35 <jww> laplante: this directory is empty !
Mar 28 16:06:38 <fberg> rbuton: tahnk you
Mar 28 16:09:26 <zeddii> rburton. just drop all my recent SRCREV updates. it's going to be next week before I get another version of the patches out. since I'm off for a 4 day easter weekend and this obscure build error has run me out of time.
Mar 28 16:11:49 <laplante> jww: then packaging failed, I think, and so no rpm is generated. Can you try a bitbake ecsw-lib -c cleansstate, and then try again with bitbake ecsw-lib?
Mar 28 16:12:23 <rburton> jww, laplante: bitbake ecsw-lib -C unpack is faster
Mar 28 16:12:37 <rburton> doesn't spend an age trying to find sstate to remove, just forces a rebuild
Mar 28 16:12:43 <laplante> rburton: sweet, thanks!
Mar 28 16:13:07 <kergoth> indeed, -C is great. also the only way to force a build from scratch when sstate mirrors are involved
Mar 28 16:13:20 <kergoth> well, otehr than the heavier-handed --no-setscene
Mar 28 16:14:58 <jww> laplante: I get the same issue.
Mar 28 16:15:24 <laplante> jww: strange, perhaps an expert can chime in :/
Mar 28 16:16:08 <rburton> jww: remove do_configure and do_compile
Mar 28 16:16:52 <jww> rburton: ok I'll try it .
Mar 28 16:16:58 <rburton> jww: well, your do_install and FILES dont match do they
Mar 28 16:17:19 <rburton> install is putting files into $(includedir) but FILES is hardcoding (bad) /usr/lib
Mar 28 16:17:43 <rburton> if you just delete FILES then those headers will be in PN-dev like you'd expect
Mar 28 16:17:49 <jww> yes that wrong, I'll correct that too.
Mar 28 16:18:27 <jww> rburton: I thinked I had some Q/A error when I did not used FILEs
Mar 28 16:19:31 <rburton> not any that FILES would be fixing
Mar 28 16:20:04 <jww> allright I remove it too.
Mar 28 16:20:13 <rburton> what's happening is that you're installing two headers, which get packaged into ecsw-lib-dev
Mar 28 16:20:24 <rburton> nothing is going into ecsw-lib, so the package doesn't exist
Mar 28 16:20:40 <rburton> so you just want to add ecsw-lib-dev to install the headers in your image
Mar 28 16:21:10 <rburton> "oe-pkgdata-util list-pkg-files -p ecsw-lib" will show you what was packaged
Mar 28 16:23:34 <jww> rburton: I checked for file to be installed in build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/ecsw-lib/1.0-r0/image is that wrong ?
Mar 28 16:24:30 <jww> oh the build is over, I still have the same issue :\
Mar 28 16:24:34 <rburton> no, but it won't work if you enable rm_work, or if you want to know what is in a pacakge that was pulled from sstate
Mar 28 16:24:55 <rburton> tell us what you expect, as at the moment i'm kind of guessing
Mar 28 16:25:23 <jww> I just wish to add this package to core-image-full-cmdline
Mar 28 16:25:30 <rburton> what does the package contain
Mar 28 16:25:37 <jww> 2 headers files.
Mar 28 16:25:43 <rburton> so your do_install works
Mar 28 16:26:01 <rburton> remove do_configure/do_compile/FILES as they're all useless
Mar 28 16:26:11 <rburton> your headers have gone into ecsw-lib-dev
Mar 28 16:26:17 <jww> I've done it
Mar 28 16:26:19 <rburton> because they're headers
Mar 28 16:26:37 <jww> oh so I should add ecsw-lib-dev and ecsw-lib ?
Mar 28 16:26:40 <rburton> *but* the catch is that PN-dev by default depends on PN, on the rationale that typically if you install libfoo-dev you want libfoo
Mar 28 16:26:48 <rburton> *but* PN is empty so doesn't get generated
Mar 28 16:26:59 <rburton> easily solved by adding RDEPENDS_${PN}-dev = ""
Mar 28 16:27:07 <rburton> then add ecsw-lib-dev to your image
Mar 28 16:28:22 <jww> I try this !
Mar 28 16:31:30 <peacememories> hey everyone. i've got a recipe that installs precompiled binaries, available for x86, x86_64, arm32 and arm64. is there a way to specify that this recipe is only compatible with certain architectures
Mar 28 16:31:33 <peacememories> *?
Mar 28 16:31:52 <rburton> peacememories: COMPATIBLE_*, lots of examples in oe-core
Mar 28 16:31:55 <jww> rburton: it worked ! but should I better set PN ? as you guessed I'm new to yocto.
Mar 28 16:32:08 <kergoth> jww: PN is set by default based on the recipe filename.
Mar 28 16:32:09 <peacememories> rburton thx, will look into it. apparently i just didn't know how to google it^^
Mar 28 16:32:49 <jww> kergoth: oh. I must have misunderstood.
Mar 28 16:33:32 <peacememories> hmm, i can find COMPATIBLE_MACHINE, but that seems to want me to specify specific machines, not processor architectures
Mar 28 16:33:47 <kergoth> peacememories: grep more.
Mar 28 16:34:00 <kergoth> peacememories: on the first page of results is both COMPATIBLE_HOST and COMPATIBLE_MACHINE
Mar 28 16:34:07 <jww> laplante / rburton / kergoth thanks for your help .
Mar 28 16:34:39 <peacememories> aah, i thought COMPATIBLE_HOST was only for the host system
Mar 28 16:37:44 <kergoth> it's HOST in autoconf-parlance. build == what we're running on, host == what the binaries will on, target == what the binaries support / target
Mar 28 16:38:02 <kergoth> BUILD_*, HOST_*, and TARGET_* in bitbake.conf use the same convention
Mar 28 16:38:07 <laplante> jww: happy to provide what little help I did. I'm also relatively new to Yocto. It will become much easier as you play with it more.
Mar 28 16:38:15 <kergoth> s/will on/will run on/
Mar 28 16:53:26 <peacememories> hmm, another stupid question. right now i'm not inheriting any class (because i'm not using autotools) and have added one .tgz file to the SRC_URI. it is being downloaded, but apparently it is not being extracted. do i need to inherit a specific class for that behaviour or do anything else?
Mar 28 16:54:20 <kergoth> nope, base.bbclass sets up the default do_unpack task
Mar 28 16:54:57 <peacememories> and base.bbclass is being inherited automatically?
Mar 28 16:55:03 <kergoth> yep
Mar 28 16:55:17 <peacememories> okay... so what else could be going wrong?
Mar 28 16:55:27 <peacememories> (do_unpack runs before i hit my errors, btw)
Mar 28 16:56:57 <peacememories> (this is the file, btw: https://hastebin.com/isitokoqik.bb)
Mar 28 17:06:58 <peacememories> nvm, found the problem. against all convention the folder inside the tgz is not called the same as the tgz^^
Mar 28 17:09:36 <peacememories> oh, additional fun. the installer is trying to add users^^ can i even allow that in a do_install?
Mar 28 17:18:10 <kergoth> nope, need tou se the useradd class
Mar 28 17:18:57 <peacememories> i got around the problem by just not installing udev rules^^
Mar 28 17:18:59 <peacememories> the next one is a bit more ugly though. apparently the installer uses hardcoded installation paths
Mar 28 17:19:01 <peacememories> meaning it tries to write to /usr/lib ^^
Mar 28 17:19:36 <peacememories> is there a way to work around that with bitbake or should i just burn the installer to the ground and copy the files manually?^^
Mar 28 17:35:12 <rburton> peacememories: burn the installer to the ground
Mar 28 17:35:36 <rburton> peacememories: assuming it doesn't have a hidden option to change it - always worth checking other distributions quickly
Mar 28 17:40:33 * peacememories lights a match
Mar 28 18:20:23 <peacememories> well, turns out it was easier to rip the dependency out of our project since it wasn't being used anymore anyway^^
Mar 28 18:20:27 <peacememories> thanks for all your help :)
Mar 28 18:20:41 <peacememories> gotta go catch some z's now
Mar 28 18:35:16 <AbleBacon> so what's the strategy with all this? set everything up the best you can, hope the build comes out right, and if not, try again?
Mar 28 18:48:15 <yocti> New news from stackoverflow: Error building meta-debian in yocto <https://stackoverflow.com/questions/49541571/error-building-meta-debian-in-yocto>
Mar 28 19:03:51 <rburton> AbleBacon: pretty much.  not sure what the alternative would be to "try your best, iterate when it doesn't work"
Mar 28 19:12:03 <laplante> anyone here available to answer a question about .scc files?
Mar 28 19:18:21 <yocti> New news from stackoverflow: configuration of user and group setting in pulseaudio <https://stackoverflow.com/questions/49542426/configuration-of-user-and-group-setting-in-pulseaudio>
Mar 28 19:40:20 <laplante> Is there something special I need to do when modifying .scc files to ensure the .cfgs actually get copied to build/tmp/work-shared/MACHINE/kernel-source/.kernel-meta/configs ???
Mar 28 19:51:23 <Ely> Anyone else hit by "nothing provides python3-sqlite3 needed by dnf-2.7.5-r0.aarch64" during do_rootfs in master ?
Mar 28 19:57:21 <rburton> Ely: python3 should have built that, use oe-pkgdata-util list-pkgs -p python3 to check
Mar 28 19:58:30 <Ely> not in there, mmh
Mar 28 19:58:35 <Ely> Only python3-sqlite3-tests
Mar 28 19:58:56 <Ely> This error started appearing after I pulled the latest master, hadn't updated for like 2-3 weeks
Mar 28 19:59:02 <Ely> I did a full rebuild though..
Mar 28 20:02:10 <rburton> soundspython3-sqlite3:
Mar 28 20:02:10 <rburton>         /usr/lib/python3.5/lib-dynload/_sqlite3.cpython-35m-x86_64-linux-gnu.so
Mar 28 20:02:22 <rburton> though interestingly other bits of it are in python3-misc, thats not right
Mar 28 20:03:09 <Ely> bitbake tells me " python3 RPROVIDES python3-sqlite3" also, but somehow the package isn't there
Mar 28 20:22:11 <Ely> Like, it's there in packages-split, but it's not forwarded to deploy-rpms
Mar 28 20:22:53 <Ely> ah nevermind the folder is empty in packages-split/python3-sqlite3
Mar 28 20:25:20 <rburton> sounds like for whatever reason it doesnt want to build the sqlite module
Mar 28 20:25:24 <rburton> you'll want to read configure.log
Mar 28 20:30:29 <aehs29> Ely: The python3-sqlite folder should have _sqlite.so library in it, I agree with rburton, it looks like its not building the module
Mar 28 20:30:30 <Ely> Good call..
Mar 28 20:30:31 <Ely> The necessary bits to build these optional modules were not found:
Mar 28 20:30:31 <Ely> _bz2                  _curses_panel         _dbm
Mar 28 20:30:31 <Ely> _gdbm                 _lzma                 _sqlite3
Mar 28 20:33:21 <aehs29> Ely: yeah thats it
Mar 28 20:39:16 <rozachar> i am running into a weird problem , when I add kernel-devsrc to my CORE_IMAGE_EXTRA_INSTALL list I get a build error , complaining about /local/rozachar/poky/build/tmp/pkgdata/intel-corei7-64/runtime-reverse/libpython2.7-1.0 but python2 should not be installed in the system
Mar 28 20:42:11 <Ely> ahh my bad, the culprit was meta-clang.. I added python3 to nonclangable and it works :<
Mar 28 20:42:12 <Ely> sorry
Mar 28 21:29:19 <AbleBacon> noooooo! fatal error after like 4 hours of building
Mar 28 21:36:52 <Crofton|work> AbleBacon, fix and restart?
Mar 28 21:40:47 <aehs29> Ely: awesome, no worries
Mar 28 21:47:38 <rozachar> it seems like kernel-devsrc has a implicit dependancy on python2 , the spec file it generates requires /usr/bin/python
Mar 28 21:48:55 <zeddii_home> the current kernel devsrc is basically garbage
Mar 28 21:49:02 <zeddii_home> but my re-write didn’t make it into this release
Mar 28 21:49:16 <zeddii_home> in the rewrite, I have the python dependency explicitly added.
Mar 28 21:49:35 <rozachar> cool - is that in master?
Mar 28 21:49:38 <zeddii_home> nope
Mar 28 21:49:45 <zeddii_home> if it was in master, that would imply it made the release
Mar 28 21:50:05 <zeddii_home> there was some bizarre multilib error with openssl that I never tracked down.
Mar 28 21:50:08 <zeddii_home> so it sits.
Mar 28 21:50:14 <zeddii_home> but you can find the variants on the mailing list.
Mar 28 21:50:32 <rozachar> thanks
Mar 28 21:50:40 <zeddii_home> but my advice is do as little with devsrc as possible, since once the current release is done, everything in the existing code will be blown away.
Mar 28 21:51:08 * zeddii_home is a little bitter about multilib breakage. 
Mar 28 21:51:10 <zeddii_home> but alas :D
Mar 28 21:51:45 <zeddii_home> the new devsrc is about 10Megs, instead of the current 600M, so that’s a bonus :D
Mar 28 21:57:14 <rburton_> Ely: connection got dropped a bit but can you send a patch to meta-clang to add python please?
Mar 28 22:02:11 <Ely> rburton_: sure
Mar 28 22:45:23 <noway96> how to set password of root user?
Mar 28 22:45:31 <khem> rburton: you forgot the x264 patch
Mar 28 22:47:08 <khem> rburton: https://patchwork.openembedded.org/patch/149334/
Mar 28 23:08:01 <noway96> in usermod -P can I use any character on the keyboard for password?
Mar 28 23:12:30 <aehs29> noway96: unlikely
Mar 28 23:15:52 <noway96> where can I find the list of valid/invalid characters?
Mar 28 23:16:05 <noway96> for usermod -P <pass> root
Mar 28 23:16:11 <kergoth> presumably the man page for usermod or passwd. also consider shell quoting issues
Mar 28 23:16:29 <noway96> usermod -P is not valid in linux
Mar 28 23:16:33 <noway96> ubuntu*
Mar 28 23:16:37 <noway96> usermod -p however is
Mar 28 23:16:47 <noway96> and linux has no character restrictions
Mar 28 23:16:54 <kergoth> irrelevent, the allowed characters in a password is completely independent of command syntax
Mar 28 23:17:48 <noway96> kergoth, sure
Mar 28 23:19:56 <noway96> can I treat the recipe as a script so I can do PASSWORD="<pass>"
Mar 28 23:20:08 <noway96> and then later usermod -P $PASSWORD root
Mar 28 23:21:37 <kergoth> ${PASSWORD} would be needed unless you export it
Mar 28 23:21:39 <kergoth> but otherwise yes
Mar 28 23:54:47 <khem> rburton: https://patchwork.openembedded.org/patch/149334/
Mar 28 23:55:57 * khem 's UP arrow key needs to be replaced
Mar 29 00:15:41 <Ely> khem: So, python3's setup.py will basically do this:
Mar 29 00:15:41 <Ely> if cross_compiling:
Mar 29 00:15:41 <Ely>             self.add_gcc_paths()
Mar 29 00:15:41 <Ely> And this function will only fill the include/lib dirs if it is gcc.. They also add those dirs from the args in CPPFLAGS and LDFLAGS but in our case they don't have any paths. I'll see what can be done tomorrow, going to bed now. Cya
Mar 29 00:24:12 <khem> Ely: voila !!
Mar 29 02:45:57 <khem> bluelightning: devtool modify virtual/bootloader checks out u-boot sources but devtool build virtual/bootloader bails out with "ERROR: No recipe named 'virtual/bootloader' in your workspace"
Mar 29 02:46:44 <khem> we could either not do the 1st step or do the second step as well, for consistentcy, what do you think ?
Mar 29 02:49:39 * moto-timo scratches head
**** ENDING LOGGING AT Thu Mar 29 03:00:03 2018