**** BEGIN LOGGING AT Mon Apr 11 02:59:58 2016 Apr 11 07:31:39 good morning Apr 11 09:23:31 hi. Is there anybody experienced with TPM (trusted platform module)? Apr 11 09:23:43 I have it on my board but I have no idea how I can use it Apr 11 10:31:42 dol: mjg59 has been writing lots of interesting blog posts about that recenrl Apr 11 10:31:44 recently Apr 11 10:56:22 rbutton, what's the link for that blog? Apr 11 10:58:42 found it: https://mjg59.dreamwidth.org/ Apr 11 14:16:00 #oe-board Apr 11 15:20:58 I built a custom image, but when booting I ge tthe OE splash screen then the terminal gets frozen at "Please wait: booting…" Apr 11 15:21:18 Is there a way to see what it is getting hung up on or does anyone know the cause of this? Apr 11 15:58:23 Is there a sane way to get kernel menuconfig to use nconfig? I am having some issues with screen && menuconfig Apr 11 17:13:46 Has anyone booted and had the terminal immediately freeze with the following: "Please wait: booting…"? Apr 11 17:26:02 anyone know where the extensible sdk is documented? Apr 11 17:34:56 Crofton|work: paul is writing docs now, so check the yocto-docs git repo to see if anything got merged? Apr 11 17:35:21 I followed smurray's advice and loaded latest mega manual Apr 11 17:35:28 got some hits Apr 11 17:55:07 Crofton|work: \o/ Apr 11 17:58:16 I'm curious, what do other distros (commercial or otherwise) do when you have to fix something in a machine that's outside your control but you don't want to fork their layer? Apr 11 17:58:26 i.e. they forgot something in MACHINE_FEATURES Apr 11 17:59:22 ouch Apr 11 17:59:28 are they taking patches? Apr 11 17:59:55 koen, likely has the most experience changing things like that Apr 11 18:00:19 this happens to us all the time, and often our release schedules don't align, or things are frozen temporarily, or timelines just don't line up, so pushing them upstream directly is unlikely to be viable Apr 11 18:00:57 I figured that was the case, although if vendors aren't taking fixes, I'd like to know about it Apr 11 18:01:03 we've taken multiple approaches in the past, we've added ne wmachines that include the original, i.e. mel-foo, but we've moved more away from that for most cases and now we're using local.conf fragments supported by our scripts Apr 11 18:01:57 See https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/local.conf.append.intel-corei7-64 Apr 11 18:03:28 kergoth: in order of preference: Apr 11 18:03:47 1) in DISTRO.conf Apr 11 18:04:06 2) python in DISTRO.conf (e.g. fix up wrong tune choice) Apr 11 18:04:12 3) copy MACHINE.conf Apr 11 18:04:52 or use script to muck with local.conf :) Apr 11 18:05:18 kergoth: I hate all options, I wish it was easier to append .conf, .inc and .bbclass files Apr 11 18:05:22 * kergoth nods Apr 11 18:05:44 I use 3) when the layer wreaks havoc Apr 11 18:05:55 e.g. meta-minnow with its old version of X11 for powervr Apr 11 18:06:05 i hate having the distro touch the machine at all, it violates our philosophy, but when the machine is basically broken or missing something required there really isnl't any other option.. Apr 11 18:06:11 i'm sure as hell not forking the bsp layers Apr 11 18:06:13 ah, eys Apr 11 18:06:15 yes Apr 11 18:07:00 kergoth: I've been thinking about this for a while now, and for angstrom v2016.06 I want to do the following in my copious spare time: Apr 11 18:07:07 * create a few new layers: Apr 11 18:07:13 not really related: does anyone have a script / recipe handy for resizing the partition/rootfs to the max available size at runtime, the way debian does on boneblack? Apr 11 18:07:20 would make wic sd images much eaiser to work with Apr 11 18:07:21 o meta-angstrom-arch support, with generic$ARCH.conf files Apr 11 18:07:36 o meta-angstrom-machine-fixups with fixups like you mentioned Apr 11 18:08:07 o meta-angstrom-distro with just the distro and some .conf magic to disable everything when DISTRO != angstrom Apr 11 18:08:34 that sounds like a step in the right direction Apr 11 18:08:40 kergoth: https://github.com/96boards/96boards-tools/blob/master/resize-helper Apr 11 18:08:49 we were thinking about the same. we already have meta-mentor broken up, but was thinking about creating a meta-mel-bsp repo to hold the bsp fixups Apr 11 18:09:08 ah, thanks Apr 11 18:09:18 right now we have a bunch of wks files for each sd card size, which isn't ideal :) Apr 11 18:09:26 check the complete tree for the systemd service Apr 11 18:09:37 we run it at first boot, haven't tried running it offline yet Apr 11 18:09:44 nice Apr 11 18:11:51 perhaps the bsp fixups layer would be something multiple distros could collaborate on, and split it up into at least two individual layers, to separate bits-which-are-staged-for-upstream from bits-upstream-is-fighting-and-wont-accept Apr 11 18:11:58 heh Apr 11 18:15:17 speaking of that Apr 11 18:15:39 kergoth: https://git.linaro.org/openembedded/meta-backports.git is something we want to publish soon-ish and have other contribute to it Apr 11 18:23:46 nice **** ENDING LOGGING AT Tue Apr 12 02:59:58 2016