**** BEGIN LOGGING AT Tue Mar 14 03:00:03 2017 Mar 14 03:43:16 Hello all. Interested in working on the Documentation for the Yocto autobuilder project as part of Outreachy. Mar 14 03:43:29 Who do I contact as regards this? Mar 14 09:39:42 when I switch from linux-xlnx to linux-xlnx-dev the ethernet no longer works, I no longer see eth0... Mar 14 10:36:04 Hi ... is there a way to get a kind of "bare minimum" SDK out of yocto ... so basically just a self contained toolchain installable on a linux host Mar 14 10:38:01 MDNNeo: something like meta-toolchain you mean? Mar 14 10:38:56 LetoThe2nd: not tried so far bur maybe I should have a look :) so ... simply adding it as meta-layer and then ... is there some docu for it? Mar 14 10:39:09 nope. just bitbake meta-toolchain Mar 14 10:40:42 and i think when building the esdk, a toolchain-only archive is also created. Mar 14 10:41:24 just checked, it is. Mar 14 10:42:27 LetoThe2nd: just currently check what happens with meta-toolchain ... have a look for the esdk afterwards ... but thx so far Mar 14 10:43:11 is there a way to specify a preferred provider for FEATURE_PACKAGES_myfeature ? Mar 14 10:55:41 Is it possible to reference a recipe with a specific version in IMAGE_INSTALL instead of just the most recent one? Mar 14 10:56:43 And the same for "requires". Mar 14 11:02:02 deva: PREFERRED_VERSION_mypackage = "1.0" Mar 14 11:02:50 LetoThe2nd: so building meta-toolchain still builds and SDK containing a lot of stuff I would expect not to need ... python, perl, aso so basically I would really just need the minimum like gcc and binutils Mar 14 11:07:43 mdnneo_: no idea then, sorry. Mar 14 11:08:32 or I need to find some way to use the created nativesdk package on a host ... I need to have a closer look Mar 14 11:08:47 deva: you can use PREFERRED_VERSION_pn in a config file to select a version. inside a recipe, it is not possible. basically this sounds liek you want a derivative distro. Mar 14 11:29:26 T_UNIX, LetoThe2nd, Thanks for the replies :-) Mar 14 11:41:34 LetoThe2nd: wouldn't that rather be PREFERRED_VERSION_${PN} ? Mar 14 11:41:49 ah, you were using it as a variable in this context :D Mar 14 11:41:54 T_UNIX: :-) Mar 14 11:43:07 deva: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PREFERRED_VERSION Mar 14 11:53:29 Works beautifully :-) Mar 14 12:50:13 ed2: i'm rebasing my patchset and noticed that wic tests take noticeably longer than they did back in January, it seems that there's a new instance of Wic() for each test run Mar 14 12:50:38 huh Mar 14 12:51:12 There's some workaround to fix the the problem arm-poky-linux-gnueabi-gcc: error: unrecognized command line option '-fp-model' in yocto morty (I'm using ubuntu 14.04) Mar 14 12:51:21 mborzecki: that may be caused by changes in oe-selftest. I didn't see any changes in wic tests that may cause this. Mar 14 12:51:36 mborzecki: can you verify that by puitting a print in the __init__? Mar 14 12:51:38 yeah, that would by my guess too Mar 14 12:51:40 mborzecki: can you investigate this further, please? Mar 14 12:52:05 if you can, just make it print a stacktrace Mar 14 12:52:06 yup, i'll look into it, maybe there's something on my end Mar 14 12:52:22 mborzecki: there were couple of test cases added though. they're running qemu, so may slow down tests too. Mar 14 12:53:29 i'll dig in, maybe i've just screwed somethng up, as usual :) Mar 14 12:55:50 ed2: btw. should we reset image_is_ready at the end of this test case? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/wic.py#n151 Mar 14 13:00:03 mborzecki: not sure why we would need it. can you elaborate? Mar 14 13:04:12 core-image-minimal is built once in setUp() and we set image_is_ready, but then test_iso_image() modifies the config and rebuilds core-image-minimal, so test cases that run after this one will not use the same image as tcs that ran before (actually test_systemd_bootdisk() is the same) Mar 14 13:16:12 mborzecki: well, as soon as we have rootfs dir we can produce an image. we can set image_is_ready to False just to be safe, but if this doesn't break tests … dunno if we need to … Mar 14 13:18:04 don't know either, i think aside from test_exclude_paths there are no tests that list image contents, so even if image is not rebuilt, nothing should technically break Mar 14 13:22:06 mborzecki: i don't think rootfs is changed a lot. that test case builds initramfs and efi. I don't know if it influences rootfs build at all. Mar 14 13:22:41 ok, i'll leave it as it is then :) Mar 14 14:30:20 is there a way to RDEPEND on a MACHINE_FEATURE ? Mar 14 14:32:04 MACHINE_ESSENTIAL_EXTRA_RDEPENDS i guess Mar 14 14:36:31 though that would be the inverse :-/ Mar 14 14:40:06 a machine feature doesn't generate a package, so no you can't rdepend on it Mar 14 14:46:38 T_UNIX: you can just check for it in the recipe and err out if its not present. this is done at several places for DISTRO features. Mar 14 14:55:39 LetoThe2nd: like `bb.error('%s does not appear in package list, please add it' % pkg_systemd)` ? Mar 14 14:57:36 T_UNIX: maybe. ATM i dn't have the time to look up an example, but i'm sure they are present in poky Mar 14 14:59:11 yeah, I guess it would work. But, as rburton said, it seems not to be intended that way. Mar 14 15:00:09 MACHINE_ESSENTIAL_EXTRA_RDEPENDS is a way for a machine configuration to add extra packages to the images Mar 14 15:00:13 like essential firmware blobs Mar 14 15:00:38 rburton: well. Problem is I want the inverse. Mar 14 15:00:54 T_UNIX: that var is just not what you want Mar 14 15:01:01 but a machine feature doesn't generate packages, so you can't Mar 14 15:01:09 i want the recipe (a GUI) to complain, if a MACHINE_FEATURE (touchscreen) isn't provided. Mar 14 15:01:32 why not error out if there are no touchscreens present Mar 14 15:01:51 machine features are quite overrated and should be used sparingly Mar 14 15:02:01 So I've merged dnf into M3. We'll see whether that was a good move now I guess :) Mar 14 15:02:05 if that's the way to go, I'll do. I just hoped there would be a 'clean' way to manage that dependency Mar 14 15:02:18 note how nothing in oe-core actually respects that machine feature :) Mar 14 15:02:25 :D Mar 14 15:02:26 RP: OH NO ITS ON FIRE! Mar 14 15:02:40 rburton: i hear fire? where? *popcorn* Mar 14 15:03:37 * rburton grabs the essentials for working on boost build problems. a good book to pass the time, a coffee to keep awake, and a whiskey to keep sane Mar 14 15:04:16 rburton: s/book/whiskey/g; s/coffee/whiskey/g; Mar 14 15:05:38 rburton: it is the pyro release ;-) Mar 14 15:06:13 rburton: I'd skip straight to the whiskey ;-) Mar 14 15:06:32 :) Mar 14 15:06:46 i'll make a note of that for when i speak to my manager Mar 14 15:07:43 rburton: you have a fairly understanding manager Mar 14 15:30:14 Hi all. I'd like to talk about versioning the SDK.Is there any best practice on that? Because currently we're incrementing SDK_VERSION (respectivly DISTRO_VERSION) every time a new SDK is built. Now i thought i could automate it by using git-describe and simply tagging out layer. However that wouldn't make external layers tracable for us Mar 14 15:53:57 Anticom: these kinds of issues are one reason we started working on the eSDK Mar 14 16:01:43 RP: on that note, remember me that I owe you one when we meet next time :) Mar 14 16:03:07 I assume there is still not support to split the image by partition besides manually providing a IMAGE_CMD_mycmd that woult package a specific subdirectory? Mar 14 16:31:22 RP: eSDK? Mar 14 16:31:25 sorry for the late response Mar 14 16:33:37 Oh btw we're still on jethro :( Mar 14 16:38:57 I just built core-image-minimal, is it expected there is no sshd running? Mar 14 16:39:12 also, for some reason I can't log in with a usb keyboard Mar 14 16:39:31 it prints login: but does not register any key presses Mar 14 16:39:58 it also prints some usb dmesg messages Mar 14 16:41:37 it doesn't even allow me to toggle the num lock state Mar 14 16:41:50 heeen: minimal is pretty minimal :) Mar 14 16:42:15 this is on an intel atom fwiw. I can ping the device Mar 14 16:42:18 heeen: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/images/core-image-minimal.bb Mar 14 16:42:45 rburton: is this normal? console login not working? Mar 14 16:43:03 Anticom: ^ Mar 14 16:43:34 wait for rburton to answer. haven't built core-image-minimal in months Mar 14 16:43:43 but iirc yes Mar 14 16:43:59 why would it print a login prompt then Mar 14 16:44:07 missing usb hID drivers? Mar 14 16:44:20 I mean I can see it registering the keyboard if I replug it Mar 14 16:44:32 heeen: no, you should be able to login from a console. sounds like your kernel is missing drivers. Mar 14 16:44:33 heeen: Compare to http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-sato/images/core-image-sato.bb it has ssh-server-dropbaer Mar 14 16:45:24 yeah, but also x11 and lots of other stuff Mar 14 16:45:57 rburton: another oddity, I followed http://wiki.minnowboard.org/Yocto_Project (this is not a moinnmowboard but a gigabyte brix) Mar 14 16:46:28 and when I used that mkefidisk script it would not exit the efi shell Mar 14 16:46:40 503 for me Mar 14 16:46:44 but when I just dd the hddimage to the usb drive it boots Mar 14 16:47:34 hm seems to be down now Mar 14 16:47:51 if dd'ing the hddimg to a usb stick works, do that. that's how its meant to work. Mar 14 16:47:56 I just cloned fido poky and meta-intel Mar 14 16:48:27 fido is a bit old... Mar 14 16:48:53 hmm Mar 14 16:48:54 almost two years old now Mar 14 16:48:58 I see Mar 14 16:49:08 should I try dizzy? Mar 14 16:49:16 thats older Mar 14 16:49:19 2.5 years old Mar 14 16:49:37 whats current stable Mar 14 16:50:02 https://wiki.yoctoproject.org/wiki/Releases Mar 14 16:50:02 morty Mar 14 16:50:30 i thought morty was replaced already :O When is the next release comming up? Mar 14 16:50:38 https://www.yoctoproject.org/product/minnowboard Mar 14 16:50:41 in about a month Mar 14 16:50:48 \o/ Mar 14 16:50:55 this says compatible up to 1.5 which is dora? Mar 14 16:51:00 or am I missing something Mar 14 16:51:03 And we won't migrate to it /o\ Mar 14 16:51:24 heeen: that's specifically regarding the "Compatible" branding, which has been undergoing a redesign so nobody has been updating it. just use latest meta-intel release. Mar 14 16:53:11 sync Mar 14 16:53:25 ah, keyboard focus on wrong window Mar 14 17:00:46 * nerdboy still wrestling mesa-17 autotools badness... Mar 14 19:14:12 hi folks, I've been seeing gobject introspection fail looking for `qemu-arm` to execute, and another recipe (can't recal the name) fail due to looking for sha256sum to execute in PATH. Was there some change to how native binaries was handled recently? It's possible these were using system-installed versions on my linux install previously Mar 14 19:15:24 ah, HOSTTOOLS is the keyword, apparently. Mar 14 19:16:39 looks like I'll just be waiting for some patches to land that add the missing deps, then Mar 14 20:11:01 jmesmon: current master should be good Mar 14 21:24:34 QA Issue: file blah is owned by uid 1002, which is the same as the user running bitbake. Mar 14 21:24:48 ^^ what's the "standard" fix for this? Mar 14 21:25:44 * nerdboy finally got silly mesa-17 to build without coughing QW warnings/errors... Mar 14 21:25:53 *QA even Mar 14 21:26:51 kinda stinky that it fails looking for llvm-config even when llvm options are disabled Mar 14 21:27:39 * nerdboy just wants the new arm stuff, doesn't give a squat about radeon/other Mar 14 21:30:11 nerdboy: if you're copying/creating files in a custom do_install or something, ensure you either preserve ownership or set it. Mar 14 21:30:16 ie use install instead of cp Mar 14 21:31:32 nope, the silly upstream install does that Mar 14 21:31:54 static makefile hack i guess... Mar 14 21:32:17 looks like XORG_CRYPTO is missing from DEPENDS Mar 14 21:32:38 it thinks it needs nettle when i have it set to openssl Mar 14 21:32:52 *on morty Mar 14 21:42:14 still seeing the Mar 14 21:42:27 gobject-introspection failure on current master. Mar 14 21:44:13 https://gist.github.com/e7e2d8024845e39d6d954134e76f1d2b "build/g-ir-scanner-qemuwrapper: line 6: qemu-arm: command not found" Mar 14 21:44:45 seems that qemu-native is for some reason not getting placed in the appropriate sysroot Mar 14 21:45:50 `find . -name qemu-arm` in the build dir returns no results. I did this build after removing tmp/ and cache/. Mar 14 21:46:32 Aha: `ASSUME_PROVIDED="qemu-native"` does not work with HOSTTOOLS Mar 14 21:46:54 * jmesmon forgot he added that Mar 14 21:47:43 or rather, can't automatically populate HOSTTOOLS. Unfortunately. Mar 14 22:04:42 who does this ?? INSTALL= cp -r Mar 14 23:41:12 RP: posted a pull request which fixes go for target and mesa Mar 14 23:59:20 then again, those guys have hiredis in the redis repo *and* a separate hiredis repo Mar 14 23:59:32 so, there ya go... Mar 14 23:59:46 * nerdboy answers his own questions today Mar 15 00:00:29 * nerdboy had to package it for redis-ipc Mar 15 00:00:36 *dep Mar 15 00:02:55 * nerdboy notes that second copy was b0rking the redis package a while back... **** ENDING LOGGING AT Wed Mar 15 03:00:02 2017