**** BEGIN LOGGING AT Thu Nov 09 03:00:03 2017 Nov 09 03:24:15 how come even with DL_DIR set, and files all there, it seems my build is still trying to reach out to download files? Nov 09 03:24:25 also BB_GENERATE_MIRROR_TARBALLS is set Nov 09 03:32:52 bodangly: all files or just some files? Nov 09 03:34:54 well, I just realized I forgot to mount the NFS share lol, false alarm. Nov 09 03:49:39 bodangly: heh, well, at least the mystery is solved :D Nov 09 06:29:48 New news from stackoverflow: why u-boot source code remove while compiling? Nov 09 06:37:21 Does anyone knows the meaning of PACKAGE_CLASSES ?= "package_rpm package_ipk" ? Does it mean there are 2 package managers ? Nov 09 06:51:53 Does anyone knows the meaning of PACKAGE_CLASSES ?= "package_rpm package_ipk" . Does it mean there are 2 package managers ? Nov 09 07:21:13 I see that my image have both rpm and opkg, is it possible to use 2 package manager at the same time ? Nov 09 08:56:59 Hi all. GStreamer 1.12.3 (latest stable release) is in master but not rocko. Are you planning to update or is it freeze to 1.12.2? I'm not sure what's Yocto policy on stable releases. Nov 09 09:00:52 cassidy: here you go https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Nov 09 09:01:30 ranran: PACKAGE_CLASSES ?= "package_rpm package_ipk" means .rpm AND .ipk packages are build. You can use both at the same time. Even with two package managers installed on the same image Nov 09 09:02:32 zzeroo: BUT it means that the first one is used for the image creation processm AND it means that if you mix up two runtime package managements you are completely on your own Nov 09 09:04:19 LetoThe2nd, thanks. So that means you don't update even for upstream stable releases in the same branch, right? Nov 09 09:04:25 LetoThe2nd: this is true thank you for clarifying that. but isn't it standard? Nov 09 09:04:50 zzeroo: what is standard? Nov 09 09:05:18 cassidy: if there is no security or bugfixing necessity then not, right Nov 09 09:05:36 LetoThe2nd, thanks for the clarification :) Nov 09 09:08:48 LetoThe2nd: Sorry I thought that this is the default in local.conf. But it isn't my mistake Nov 09 09:10:59 zzeroo: the standard is rpm. mind, i didn't say that "rpm is standar", i said the first is standard. thats why PACKAGE_CLASSES ?= "package_rpm package_ipk" is not the same as PACKAGE_CLASSES ?= "package_ipk package_rpm", although the values seem to bge identical Nov 09 09:38:08 Hmmm that busybox bug... looks like a big one... rocko (/bin/sh -> /bin/busybox.nosuid), master (/bin/sh -> /bin/busybox.suid) :| Nov 09 11:00:37 New news from stackoverflow: Put files which are compiled in yocto Nov 09 11:17:17 nrossi: what?! i thought i ripped that out of my branches Nov 09 11:17:26 argh Nov 09 11:20:28 nrossi: oh yay you found the problem \o/ Nov 09 11:25:53 rburton: :) Nov 09 11:26:08 i wonder why my check-bashisms script didn't notice that earlier Nov 09 11:28:29 nrossi: tbh probably worth adding a check in the recipe that the bad linking doesn't happen Nov 09 11:56:08 rburton: yes, probably worth having a sanity check for suid, so that it only creates the symlinks expected and fails otherwise Nov 09 12:00:47 New news from stackoverflow: Is it possible to import a command-line build into toaster? Nov 09 12:17:08 rburton: should the busybox recipe just check to see if the links file has the same link in both .suid and .nosuid? and show a warning for it? Nov 09 12:17:37 nrossi: that could work. or just explicitly check that sh isn't suid and error if so. Nov 09 12:18:22 rburton: should it matter that the binary could still have sh builtin? even if it doesn't provide the symlink? Nov 09 12:19:52 special-casing a check that if sh->busybox.suid then error out would be good enough for me Nov 09 12:21:00 rburton: ok will sort a patch that checks it (just fail in do_compile is fine right?) Nov 09 12:21:15 wherever is good enough to check Nov 09 12:22:16 possible bashism in do_compile line 176 (should be 'b = a'): Nov 09 12:22:22 grrrr Nov 09 12:22:35 i'll run it over the entire repo just to see if anything else has sneaked in Nov 09 13:11:57 rburton: rp: the lttng-modules are not compatible with 4.14 kernel. We are using it on meta-freescale and it has been made a new release which fixes those issues. Nov 09 13:12:36 rburton: being the release just to fix those intrumentation issues, it seems that upgrading makes more sense then backporting Nov 09 13:24:18 otavio: to rocko? Nov 09 13:38:28 is there a simple way to show task and recipe dependencies? Using -g creates too large sheets to gain any real overview... Nov 09 13:38:52 can it be limited to, say 2 or 3 levels? Nov 09 13:41:20 RP: ye Nov 09 13:41:23 RP: yes Nov 09 13:41:57 RP: I sent the patch and it includes the changelog provided by upstream Nov 09 13:42:16 RP: once it goes in, I can work on upgrading lttng to 2.10 Nov 09 13:45:17 found it, bitbake -g -u taskexp Nov 09 13:45:49 Is recipes listed in RDEPENDS always dependencies when building a recipe? Nov 09 13:46:05 *packages listed in RDEPENDS Nov 09 13:47:02 sveinse: they are added to the build list but not a dependency of the recipe Nov 09 13:47:12 sveinse: so order is not deterministic Nov 09 13:49:06 otavio: ok, I just noticed that when i have a recipe "a" which has RDEPENDS="b" in it also builds "b" when I write "bitbake a" Nov 09 13:49:25 I didn't expect that Nov 09 13:50:22 sveinse: because it is an installation dependency; package a cannot be installed without b Nov 09 13:50:50 sveinse: so it must be ready at rootfs generation or for package feed Nov 09 13:51:42 I'd expect that it would be built from IMAGE_INSTALL="a" would build and install "a" and "b" to satify RDEPENDS. But not when only building recipe "a". Nov 09 13:51:43 * otavio goes for lunch! Nov 09 13:52:59 sveinse: if you are building packages for a remote package feed, then you would want all of the dependencies Nov 09 13:54:02 kanavin: yes, of course. But does a "bitbake recipe" imply that you need to rebuild all RDEPENDS? Nov 09 13:54:16 But ok, this is one of the implicit rules in bitbake I suppose Nov 09 13:55:01 sveinse: if the resulting package is not in sstate cache, then you certainly do Nov 09 13:55:17 sveinse: otherwise, the package is taken from the cache and moved to deploy dir, which is a lot faster Nov 09 13:58:20 kanavin: yeah, I am probably not seeing the whole picture for it. In other packaging system, RDEPENDS is only something which comes into play when installing a image. A local recipe is ignorant to if a RDEPENDS is updated or not at buildtime. Nov 09 13:58:52 But granted, bitbake has different behaviours, which was my question. Nov 09 14:00:52 sveinse: we want consistent, reproducible builds. If you build something, and I build something, we should get the same set of resulting packages, but if RDEPENDS is ignored, then that is not guaranteed. Nov 09 14:03:23 thanks Nov 09 14:04:23 so then you have a runtime issue which you want me to look into, and I can't easily reproduce it, because I can't easily get the same set of packages as you :) Nov 09 14:06:28 kanavin: but you do, don't you? Because to have a runtime issue, you need to install it somewhere. And install will honor RDEPENDS. Thus it's deterministic, isn't it. Nov 09 14:07:11 But 'bitbake recipe' has nothing to do with run time has it? It just builds and packages it, right? Nov 09 14:08:57 sveinse: when installing using remote feeds, you would have one set of packages, and I would have another. Nov 09 14:12:56 right, so it is a policy to update the full dependency tree, even RDEPENDS. Fine. Nov 09 14:13:09 sveinse: but what would the other option be? Nov 09 14:14:22 you do need to build all of the runtime dependencies before placing the package into the package feed, otherwise you'll end up with a package in a feed, but not its dependencies Nov 09 14:16:10 like other packaging systems do: care not about RDEPENDS until install or feed deployment. Nov 09 14:17:00 I think the difference with other systems is that 'bitbake recipe' implies that its being built for image or feed deployment, while other are just building the recipe packages. Nov 09 14:17:22 sveinse: its actually due to debian.bbclass - the package names depend on the contents of the packages Nov 09 14:17:38 sveinse: so before it can depend on "b", it needs to know what "b" will be called Nov 09 14:17:50 sveinse: so packaging for a needs b Nov 09 14:18:14 right. even on RDEPENDS Nov 09 14:18:35 sveinse: even for RDEPENDS since it has to know whether to rename it or not Nov 09 14:18:52 got it Nov 09 14:19:04 well, thanks a lot for the insight Nov 09 14:19:21 sveinse: if you drop debian.bbclass, the dependencies do simplify Nov 09 14:22:23 Something else: I have qmake5 based recipe, and for some unknown reason it ends up in "cortexa9hf-neon-mx6qdl-poky-linux-gnueabi", while the other non-qmake based recipes ends up in "cortexa9hf-neon-poky-linux-gnueabi" when being built to tune. For some reason qt picks up MACHINE_SOCARCH_SUFFIX Nov 09 14:23:29 The strange thing is that I just modified another qmake5 recipe and all of the sudden it changed directory from the -mx6qdl to the one without. What could cause something like this? Nov 09 14:31:15 New news from stackoverflow: Yocto Multifile compilation Nov 09 14:56:04 If I want to rsync sources into the build tree, can I simply override do_fetch, or does this task have additional roles other than copying/fetching? Nov 09 15:01:05 At what task is the src hash-sum evaluated? Nov 09 15:05:41 I'm trying to find an efficient way to handle larger in-meta-source trees Nov 09 15:30:37 Will SRC_URI = " file://directory/" work? Will it monitor changes in directory? Nov 09 15:34:52 Is anyone familiar with web browser which can be added to image in yocto ? Nov 09 15:35:41 there's epiphany in meta/recipes-gnome Nov 09 15:36:03 other browsers are in meta-browser, eg chromium Nov 09 15:36:03 ranran: also, see meta-browser layer (has mozilla and chrome i think) Nov 09 15:36:49 sveinse: what you need is probably externalsrc.bbclass Nov 09 15:37:26 One of my projects need access to libclang.so Because an issue with meta-rust I cannot just use meta-clang. What can I do? Nov 09 15:39:02 zzeroo: describe your issue to meta-clang and meta-rust maintainers Nov 09 15:40:14 kanavin: https://github.com/kraj/meta-clang/issues/43 && https://github.com/meta-rust/meta-rust/issues/173 Nov 09 15:40:22 kanavin: I might be wrong, but I think externalsrc will force a rebuild every time Nov 09 15:43:16 is there a way to cause do_compile to emit the actual compile commands with all options? i'm tracing down a bug in a .dts compile and running the yocto build takes 10-15 minutes just to get to that phase - too long. i'd like to just run the compile interactively while tracking my bug Nov 09 15:44:01 yates: devtool modify Nov 09 15:45:48 kanavin: i am already doing a devtool modify , and it takes too long Nov 09 15:46:36 devtool modify is a one-time operation, after that you just devtool build or bitbake -c compile, which will only run the one task Nov 09 15:47:35 Does yocto/bitbake have any concepts for having sources and recipes together. Much like native deb packages (not to be intermixed with yocto's "native" term) Nov 09 15:48:57 can be done locally, as long as BBFILES includes the recipe where it lives in the source tree, and you can set S relative to FILE/FILE_DIRNAME/THISDIR. but it wouldn't handle fetching/unpacking the sources+recipe, that'd have to be done already. i don't know of anyone who has done much with that sort of thing Nov 09 15:50:59 We have a large, multi application codebase that compiles to different kinds of platforms, including yocto. However yocto, tends to want one source repo per recipe (or at least it checks out one per recipe). We did explore having a separate meta-layer for our apps, but that complete fell out of sync with the main apps repo. Thus our meta-layer has been incorporated into the main app repo. Nov 09 15:51:18 kergoth: ah. thanks for the clarification. i missed that. Nov 09 15:51:25 or had forgotten.. Nov 09 15:52:22 devtool modify unpacks/patches the source tree locally and appends the recipe to make it use it there, making local source modifications more convenient and safer than trying to dig around inside of tmp/work/, and making bitbake no longer re-unpack/patch unnecessarily Nov 09 15:55:42 I have been experiment with setting S="${THISDIR}/../appsrc" in a qmake5 recipe, and it did seem to work... Until today, where I sometimes see that the source tree is deleted. But I have no clue to what task is cleaning too much. Nov 09 15:56:14 sveinse: my guess would be a cleandirs flag Nov 09 15:56:23 that's the dirs to wipe before running the task in question Nov 09 15:56:43 thanks, let me grep the sources for it Nov 09 15:58:29 kergoth: is cleandirs scm aware? If the said dir contains .git it will not clean registered files from that repo? So if the dir is a subdir of a git-repo, it would not see the .git dir and thus clean it completely? Plausible? Nov 09 15:59:44 i doubt it's that complex, likely just a naïve rm -rf by bitbake. should be able to explicitly remove it if needed, though, or even write an event handler in the metadata to remove it if .git exists at that level Nov 09 16:01:13 kergoth: thing is that my recipe that use S="${THISDIR}/.." which points to the root of the layer/sources, does not delete anything, while putting a subdir does Nov 09 16:05:32 odd Nov 09 16:05:53 i'd just remove S from cleandirs in the recipe Nov 09 16:06:05 I wish there were a way to point to a in-tree source, but not copy it to ${WORKDIR}, but still keep hash-sum record of it. Nov 09 16:06:46 might be doable with file-checksums flag Nov 09 16:06:53 not sure if that can handle a directory offhand or not Nov 09 16:07:10 but even easier would be to just aadd to SRC_URI but use the url parameter to disable unpack Nov 09 16:07:21 i.e. file://some-path;unpack=no Nov 09 16:07:35 kergoth: let me try that Nov 09 16:08:17 might be easier to just use externalsrc class, though, and point to the xisting THISDIR-based path as EXTERNALSRC Nov 09 16:08:31 since that class is expected to handle all the "this source tree already exists at this path" stuff, including checksumming hte tree Nov 09 16:12:17 kergoth: is externalsrc handling checksumming? Nov 09 16:12:37 i just said that, yes Nov 09 16:12:44 because I've experienced that it wants to rebuild the reciped using externalsrc all the time, but I might not be right with that Nov 09 16:12:47 it arranges for bitbake to do it, anyway Nov 09 16:12:54 i think that changed somewhat recently Nov 09 16:12:58 it used to just nostamp the thing Nov 09 16:12:59 thats perfect actually Nov 09 16:13:15 yeah, i'm on pyro Nov 09 16:13:20 it's possible i'm remembering wrong, but i think that's the case now, i saw the patches hit the list ages ago Nov 09 16:13:28 should chec the master version of the bbclass Nov 09 16:24:44 sveinse: the MACHINE_SOCARCH is a meta-freescale thing; it allows for sharing binaries across same SoC family processors. This is because some packages need to have changes for i.MX (qtbase, in your case) so it becomes machine specific but to avoid rebuilding it for every machine we ended using this dynamic package arch schema. Nov 09 16:40:12 otavio: aha, thanks, so thats why all my qt5 based apps are specific to SOCARCH. thanks Nov 09 17:01:46 New news from stackoverflow: GStreamer source code understanding (gst-pligins-base,... gst-plugin-vspfilter, element, pipeline) Nov 09 17:12:43 Am I reading externalsrc.bbclass:L176 in Pyro where srctree_hash_files() is only making hashindex if the external src is a git repo? Nov 09 17:12:52 Am I reading this correctly? Nov 09 17:17:31 hey guys! I'm hitting some strange problem with WebEngineView of meta-qt5 on a Raspberry Pi 3. Detailed log here. https://pastebin.com/qNx75AEd . Most noticeable: glGetError 0x505, GL ERROR :GL_OUT_OF_MEMORY : glTexImage2D:, Error: 5 for Command kTexImage2D, GLES2DecoderImpl: Trying to make lost context current. All this results in a white screen with EGLFS backend Nov 09 17:20:46 sveinse: yw Nov 09 17:45:01 This is excellent: I'm using EXTERNALSRC to point to the in-meta-tree-source, and use SRC_URI="file://...;unpack=no" in addition to allow the checksummer to detect any src changes. I had to use QMAKE_PROFILES="`ls ${EXTERNALSRC}/*.ori`" to allow qmake to pick up the external source. But now, finally, it works Nov 09 17:46:21 thanks, kergoth for pointing me in the right direction Nov 09 18:01:57 New news from stackoverflow: GStreamer source code understanding (gst-pligins-base,... gst-plugin-vspfilter, element, pipeline) [on hold] Nov 09 19:24:29 If I want the entire build to fail/stop during parsing due to some configuration check I have in a recipe using anonymous python, do I have to raise parse.ParseError? I tried using bb.error() but everything continues on happily Nov 09 19:24:50 Well, the error message shows up, but it proceeds to run tasks Nov 09 19:36:08 rewitt: try bb.fatal() Nov 09 20:11:42 Why does recompiling the kernel appear to cause half my userspace to rebuild :( Nov 09 20:12:42 heh, in AGL it's usually because of mesa -> qt -> * Nov 09 20:13:47 linux kernel headers -> libc -> your userspace? Nov 09 20:14:01 I didn't touch the headers, that I would have understood... Nov 09 20:14:18 I'll poke around it shortly and figure out why its doing this. It just seems bad :( Nov 09 20:18:34 RP: I wonder if we should be diffing task graphs between releases, assuming that's even practical Nov 09 20:22:47 bluelightning: That does it thanks Nov 09 20:28:26 maybe the kernel is self-aware ? Nov 09 20:33:05 bluelightning: there are probably patters we should be looking for Nov 09 20:42:55 RP: Does it actually matter if the contents of the headers change if the checksum of the task that produces them changes? Nov 09 20:43:56 neverpanic: sadly the checksums aren't intelligent like that Nov 09 20:44:45 Yeah, that's what I thought. Even if the headers don't change, bitbake will still rebuild your entire userland, wouldn't it? Nov 09 20:46:01 We actually have some code to re-use sstate if the dependencies didn't change (for some defined notion of change) Nov 09 21:00:44 bluelightning: So here is another question. I basically don't want an image to be built unless the kernel provider is a particular kernel. However, I don't want to wait until the build phase to tell the user things are wrong. So I'm trying to do it during parse. But that won't really work because the recipe always gets parsed. Nov 09 21:01:27 bluelightning: So what is the best way to error early, but only if the image is in the task graph? Nov 09 21:12:32 if I don't want dropbear in my image (have my own version of SSH in a custom layer), what is the best way to remove it? IMAGE_INSTALL_remove += ? Nov 09 21:19:53 bodangly: I'm pretty sure you need to remove ssh-server-dropbear from IMAGE_FEATURES, otherwise some things will still happen during rootfs creation Nov 09 21:19:54 bodangly: find why its being pulled in and remove it, its not in all images out of the box Nov 09 21:20:11 yes, if you have it in IMAGE_FEATURES then remove that Nov 09 21:29:19 I removed it from IMAGE_FEATURES and it still ended up in my image Nov 09 21:29:20 hmm Nov 09 21:30:17 can I do IMAGE_FEATURES_remove ? Nov 09 21:30:43 if I put that in my image recipe, (and its the last one included), shouldn't that ensure it gets removed? Nov 09 21:31:20 _remove is always processed at expansion time. doesn't matter where it's defined, it'll remove it last Nov 09 21:31:25 bodangly: presumably this is your image recipe? Nov 09 21:31:45 i'd be using taskexp to find out what is pulling it in if you don't mention it in your recipe Nov 09 21:31:55 yeah my image recipe had IMAGE_FEATURES += "ssh-server-dropbear" Nov 09 21:32:02 I deleted that line, but it still ended up in there Nov 09 21:32:12 ls Nov 09 21:32:14 see EXTRA_IMAGE_FEATURES in your local.conf Nov 09 21:32:19 rburton: I didn't think you could use IMAGE_FEATURES in an image recipe Nov 09 21:32:20 ah where can I find documentation for taskexp? Nov 09 21:32:31 yes, you can, image features are by definition image specific Nov 09 21:32:36 bodangly: bitbake -g -u taskexp Nov 09 21:32:41 thanks Nov 09 21:32:51 kergoth: Ahh I thought it was another global config thing Nov 09 21:33:04 nope, just a terrible example being set by local.conf :) Nov 09 21:33:27 much fun when you do IMAGE_FEATURES_append=dbg-pkgs and wonder why your initramfs is giant :) Nov 09 21:33:31 EXTRA_IMAGE_FEATURES is, it's provided so the user doesn't have to muck with _append, but it's still just pulled in and used by the image, which can override it (and does, in some cases, i.e. initramfs images) Nov 09 21:33:38 indeed Nov 09 21:33:40 been there Nov 09 21:33:50 yeah, i think my time was with tools-sdk Nov 09 21:34:07 so I see its in an EXTRA_IMAGE_FEATURES in one of the "require"'d parent inc files Nov 09 21:34:35 I guess I can remove it there, but I would prefer to remove it from my own recipe Nov 09 21:35:04 bodangly: use _remove in the recipe but i'd be looking at sorting out the parent inc so it wasn't setting stuff that isn't actually universal Nov 09 21:35:23 its from Technexion's BSP layer Nov 09 21:35:38 bsp layer in being rubbish shocker Nov 09 21:36:01 fuck it I keep it in my own repo anyhow I'll remove it from the BSP Nov 09 21:36:12 sounds like thats how it should have been done anyhow Nov 09 21:36:15 because an ssh server is totally needed for a bsp :-D Nov 09 21:36:19 yeah haha Nov 09 21:36:40 not sure why a bsp needs to have a .inc that you need to include for images to work either Nov 09 21:37:12 their layers are shit to be honest I am learning not to question it and just fix it myself Nov 09 21:37:24 also stuck on Jethro Nov 09 21:37:43 bsp="bsp+distro" for most places unfortunately Nov 09 21:38:00 yeah thats what it is Nov 09 21:38:06 * kergoth shakes head Nov 09 21:38:07 its part of their "guI" image recipe Nov 09 21:38:10 "GUI" Nov 09 21:38:19 which is their distro Nov 09 21:38:23 good news is that YP layer guidelines v2 explicitly block that sort of behaviour Nov 09 21:38:47 we really should provide a nicer way for bsps to identify gui-specific desired components, i.e. x11 driver, gstreamer plugin, etc Nov 09 21:38:55 a lot of them end up appending images and crap Nov 09 21:38:56 but still, why does a GUI distro need to have the SSH server either? Nov 09 21:39:08 well, x11 is at least covered by XSERVER Nov 09 21:39:28 bodangly: It probably doesn't need it, but you don't need half the stuff on most distros that get installed Nov 09 21:39:31 ssh in an image is often a development/debugging tool more than anything else, unless they really want that open in production.. Nov 09 21:39:48 "Unable to import extension module "taskexp" from bb.ui. Valid extension modules: knotty or ncurses" Nov 09 21:39:56 is that something from a later version? Nov 09 21:40:33 rewitt: Yeah, I am trying to pare down this distro for production. Its a touch screen controller for an oven, and has CUPS in it among other nonsensical things lol Nov 09 21:40:39 yikes Nov 09 21:41:25 If you use "bitbake -e" that will also let you see what caused what to get added to variables Nov 09 21:41:51 also has tools-debug in the distro lol Nov 09 21:42:19 i.e. bitbake -e foo-image, then look and see what all touched IMAGE_FEATURES, or IMAGE_INSTALL, etc Nov 09 21:42:26 thanks Nov 09 21:42:37 how can i do a git bisect on a repository of a recipe (ie blabla.bb uses somewhere/over/there/bla.git, i want to git bisect somewhere/over/there/bla.git) Nov 09 21:42:39 I have used bitbake -e, didn't realize I could pass a recipe Nov 09 21:43:12 uglyoldbob: devtool modify blabla; cd workspace/sources/blablah; git bisect Nov 09 21:43:54 +1 devtool, so glad it's not devshell anymore :) Nov 09 21:45:07 I remember a guy freaking out once because he had been doing all of his development in devshell, and then ran bitbake and it refetched Nov 09 21:47:06 kergoth: what if devtool fails? Nov 09 21:47:12 so after removing packages from my image, is doing bitbake -f my-image enough to force it to not include them in the rootfs/ Nov 09 21:47:50 or do I need to clean the build first Nov 09 21:49:50 looks like that worked as I shaved off 100 megs from my build last night Nov 09 21:50:02 by getting rid of qt5 demos, tools-debug, tools-profile Nov 09 21:51:45 any suggestions on a strategy to implement overlayfs? possible to get it built that way, or should I do it with post-inst scripts? Nov 09 21:54:22 uglyoldbob: i don't understand the question. devtool just unpacks and patches the sources. if it fails, you've got bigger problems Nov 09 22:02:53 another question, how do I pick which package manager I want to be used on the system? this build I was given doesn't have opkg or rpm installed into the rootfs, but its building rpm files Nov 09 22:03:34 should be an example in local.conf/local.conf.sample/local.conf.sample.extended Nov 09 22:03:42 ok thanks Nov 09 22:03:52 kergoth: "fatal: Not a git repository: '/tmp/devtoolGYHNbU/workdir/git'" Nov 09 22:04:06 kergoth: what should i look at? Nov 09 22:07:02 anybody else get a morty udev image to stop right after init? Nov 09 22:07:44 all i get is Error opening /dev/fb0: No such file or directory and then udevd[96]: starting eudev-3.2 Nov 09 22:08:28 *neo basic with mainline kernel/u-boot Nov 09 22:11:06 kergoth: I see PACKAGE_CLASSES, and i do have rpm selected, but the resulting system has no rpm binary on it... Nov 09 22:11:26 sounds like your'e using an image that lacks pakcage-management in IMAGE_FEATURES Nov 09 22:11:36 which results in no package manager Nov 09 22:12:02 ah I see Nov 09 22:12:03 ty Nov 09 22:13:11 otavio: do i need to enable systemd i suppose? Nov 09 23:22:28 halstead: I've been debugging random qemu image hangs. It looks like the AB workers are running out of entropy Nov 09 23:23:01 halstead: Could we install haveged or rng-tools onto the workers to try and increase it? Nov 09 23:23:16 RP, Inside the VM? I don't think the host should run low easily. Nov 09 23:23:31 halstead: the hosts are running low afaict Nov 09 23:23:59 halstead: we already have rng-tools inside the VMs and pass host entropy in through virtio Nov 09 23:24:31 halstead: I can make images "hang" by running "dd if=/dev/random of=/dev/null bs=1" on the hosts Nov 09 23:24:32 RP, Okay. Wow. Yes I can add an entropy daemon. Nov 09 23:25:04 The hang looks the same as the hangs in the images Nov 09 23:26:09 halstead: partly its due to the VMs discarding bits quite happily upon startup in a crusade to improve the quality :/ Nov 09 23:26:15 That's expected if you pull all the entropy with dd but weird under normal usage. The test VMs are generating a lot of ssh host keys at boot though. Nov 09 23:26:47 That makes sense. Stop wasting good entropy VMs! ;) Nov 09 23:27:33 halstead: I think this is the next thing we need to try and see if these hangs stop appearing Nov 09 23:27:44 hopefully its not too hard to do Nov 09 23:28:03 Just a few minutes I expect. Nov 09 23:28:18 halstead: thanks Nov 09 23:44:24 halstead: I'll write up my findings tomorrow about all this... Nov 09 23:44:54 RP, I've added rng-tools and have it working except on the debian hosts. Nov 10 00:08:46 halstead: I wrote up my findings: https://wiki.yoctoproject.org/wiki/Entropy_on_Autobuilders Nov 10 00:08:57 halstead: great, thanks. What was the issue with debian? Nov 10 00:10:04 RP, None of the tpms are producing randomness on .io. The debian boxes were the only ones not to silently fail. I've installed haveged for now. Nov 10 00:11:18 I may need to change some bios settings. To rng-tools working like I'd prefer. These machines don't need high quality entropy though as far as I know. Nov 10 00:11:25 Do this should work. Nov 10 00:12:43 halstead: we don't need "high quality" entropy, no, this is mainly for testing Nov 10 00:13:03 halstead: I did think rng-tools might have picked up rdrand as a source Nov 10 00:14:34 It didn't automatically. I need to read more. Nov 10 00:26:26 halstead: as far as I can tell the kernels should be using rdrand as a source too (and are configured to do that at least on fedora) Nov 10 00:27:50 RP, It does seem so. I'm a bit foggy today and missing some things. rng-tools is working on the non-debian machines but it still logs an error about the tpm. **** ENDING LOGGING AT Fri Nov 10 02:59:59 2017