**** BEGIN LOGGING AT Tue Sep 30 02:59:58 2014 **** BEGIN LOGGING AT Tue Sep 30 03:37:28 2014 **** BEGIN LOGGING AT Tue Sep 30 03:52:43 2014 **** BEGIN LOGGING AT Tue Sep 30 04:01:58 2014 Sep 30 06:51:50 good morning Sep 30 08:34:13 morning all Sep 30 09:42:30 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/51/steps/Building%20Toolchain%20Images_1/logs/stdio <—why is a ppc-fsl image building mesa? Sep 30 09:44:39 mornin Sep 30 09:45:01 how do I build matchbox-stroke? Sep 30 09:45:47 I figured out the other bits that weren't prebuilt in debian but matchbox-stroke requires some mbstroke library that I do not see neither in debian nor in the git repo Sep 30 09:46:12 or it it part of other of the libraries and not properly installed in the Debian packages? Sep 30 09:47:33 should package buildhistory be written if I'm using sstate-cache? There's a commit bb.debug(2, '--- this task: %s' % (d.getVar('BB_CURRENTTASK', True)))by Paul Eggleton Sep 30 09:47:45 other than important bits missing in Debian matchbox seems quite usable Sep 30 09:48:22 should package buildhistory be written if I'm using sstate-cache? There's a commit a41d97a23bc8bd01c9bc625d21a3c933d392dcc0 by Paul that supposedly fixes the problem, but I don't really see buildhistory_emit_pkghistory being called for do_packagedata_setscene task Sep 30 09:49:45 I would prefer more keyboard options but I guess that's something left as the exercise for the reader. the one keyboard supplied works good enough as an example implementation Sep 30 09:51:25 bboozzoo: it should be yes... what version/branch of the build system are you using? Sep 30 09:51:53 bluelightning: master 8ac8eca Sep 30 09:52:16 if someone has broken this again I may have to go postal Sep 30 09:52:23 funnily, I see buildhistory_emit_pkghistory being called after do_package_qa_setscene and do_package_qa Sep 30 09:54:25 testing now Sep 30 09:57:43 hramrach_: machbox-stroke isn't very good, it was just an experiment Sep 30 09:58:29 bboozzoo: so I just tried it and it appears to work here... Sep 30 09:59:55 bluelightning: what revision from master do you use? Sep 30 10:00:37 bboozzoo: basically the same one; I have some of my own changes on top but they are not related to buildhistory Sep 30 10:02:48 bboozzoo: I don't suppose there's anything unusual about the recipe in question? Sep 30 10:05:42 bluelightning: no there's nothing unsual, actually I'm building an image with fairly minimal set of packages, but only image build history is there Sep 30 10:14:36 bboozzoo: so a test case would be to build an image completely from sstate and see if the package history gets populated? Sep 30 10:15:35 bluelightning: that's what I'm doing right now Sep 30 10:16:30 SSTATEPOISTINSTFUNCS seems to be set correctly Sep 30 10:16:32 , I suppose sstate_install[vardepsexclude] includes buildhistory_emit_pkghistory Sep 30 10:17:03 no to trigger rebuilds right? Sep 30 10:19:31 right Sep 30 10:22:06 bboozzoo: hmm... so I just tried that exact test here, works... Sep 30 10:22:18 something must be different in your case, not sure what it would be though Sep 30 10:25:07 trying to quickly wrap my head around sstate, there's STATETASKS variable, that lists the tasks that may be overridden by sstate.bbclass Sep 30 10:25:35 correct Sep 30 10:25:41 then each of these tasks is added a post/prefuncs, where sstate_task_postfunc will call state_install that shoudl write buildhistory right? Sep 30 10:26:36 that's the way it ought to work , yes Sep 30 10:27:06 since buildhistory_emit_pkghistory is in SSTATEPOSTINSTFUNCS, it should be called somewhere around sstate.bbclass:211 Sep 30 10:30:54 is there a way to not trigger a rebuild if sstate_install (or actually sstate.bbclass) changes? Sep 30 10:31:53 unfortunately that function's contents figure into the signature of the task... so not really :/ Sep 30 11:05:48 bluelightning: got it, silly me, I have 'inherit buildhistory' in image recipe only, so it obviously wasn't applied to any of the packages that it pulled in Sep 30 11:07:09 is there a way to record build history for all packages other than by adding INHERIT.. in local.conf? for instance would distro conf work? Sep 30 11:48:24 what are more choices for remote access / remote command shell if I 'm not allowed to have SSH? Telnet ? ? anything better ? Sep 30 11:48:38 export compliance paranoia Sep 30 11:49:33 b00^wk: the options are sane (ssh) or stupid (telnet) surely Sep 30 11:50:36 rburton, and how do i surgically remote encryption from it? i'm browsing source and see that option "none" for ciphers is basically not allowed in SSH2 Sep 30 11:50:47 remove Sep 30 12:00:07 b00^wk, well removing encryption from SSH would move it from sane (ssh) to stupid (telnet), using rburton's language... Sep 30 12:00:21 ok Sep 30 12:02:49 never realised export controls would be so strict as to mean removal of all encryption from ssh Sep 30 12:05:05 bboozzoo: distro conf should work yes Sep 30 12:07:33 rburton, from the system as whole. the reason i wanted to remove it from ssh is because i have some other docs explaining how to connect to the sys using ssh, and don't want to update that. so i thought keeping ssh wo encryption would save extra doc crap... Sep 30 12:09:36 actually many places ref using ssh .. Sep 30 12:10:23 bluelightning: thanks Sep 30 12:58:52 Sep 30 13:59:59 rburton: arm! :) Sep 30 14:07:50 otavio: non-x86, whatever ;) Sep 30 14:46:04 BB_ENV_EXTRAWHITE... Sep 30 14:46:32 anyone used this? Sep 30 14:47:38 I need to use an environment variable to selects a recent enough git version (don't ask) Sep 30 14:47:59 otherwise it falls back on 1.7.4.1, and the sanity checker stops the show Sep 30 14:48:57 extending that variable in your local.conf with the variable name you want preserved will work, yes Sep 30 14:49:04 I've tried: export BB_ENV_EXTRAWHITE=MYVAR but does not seem to... Sep 30 14:49:13 oh, it has to be in local.conf? Sep 30 14:49:16 trying now Sep 30 14:49:19 BB_ENV_EXTRAWHITE isn't in the whitelist :) Sep 30 14:52:43 pretty sure BB_ENV_EXTRAWHITE wont' be of much use in local.conf Sep 30 14:52:51 by the time that's parsed isn't it past the filtering stage? Sep 30 14:52:52 hmm Sep 30 14:53:00 admittedly i haven't had my caffeine yet Sep 30 14:54:42 hm i thought that's where i used it before Sep 30 14:54:50 but that was some time ago Sep 30 14:54:51 * kergoth shrugs Sep 30 14:55:32 rburton, which ciphers have you left in then ? Sep 30 15:06:16 I got BB_EN_EXTRAWHITE to work! Cant' say where it should be put yet since I've put it everywhere. Brute force first, refine later Sep 30 15:06:23 thx anyway Sep 30 15:07:00 hehe Sep 30 15:21:00 rburton: yes we build it as it usse mesa to provide the headers Sep 30 15:21:54 otavio: oh thats not pretty. you could probably make a new recipe that just ships headers. Sep 30 15:28:37 I am seeing ERROR: Worker process (21354) exited unexpectedly (-9), shutting down... Sep 30 15:29:04 in master, when building world with some extra layers added Sep 30 15:29:14 anyone else seeing it Sep 30 15:46:28 hello, looking for people working on 64-bit baytrail, got some troubles (starting with X86_INTEL_MID depends on X86_32 as per arch/x86/Kconfig) Sep 30 15:47:54 WHat in X86_INTEL_MID do you need for Baytrail? Sep 30 15:52:23 so I don't? :) guessed that I might be missing BATTERY_INTEL_MID for https://bugzilla.kernel.org/show_bug.cgi?id=69011 (a few people have posted their .config for 32-bit kernels) Sep 30 15:52:25 Bug 69011: was not found. Sep 30 15:53:37 it's an aava inari 8 with atom z3745 over here, basic linux+xorg+plasma boots and works at the moment, there are problems with battery status (the referenced bug), screen brightness and suspend (freeze/disk only) so far Sep 30 15:54:43 looks like emlix people have stepped down from this particular target... would be nice to find those who are interested in getting this working Sep 30 15:56:16 so basically a sample X86_64 .config for any kernel (be it yocto or mainline) would probably help Sep 30 15:57:48 Building an SDK image from the latest master, the environment file is looking for the target sysroot as arm-poky-linux-gnueabi but it's still installed as cortexa9hf-vfp-neon-poky-linux-gnueabi. Anyone have an idea of what is the cause? Sep 30 15:58:44 dvhart, I've also subscribed to https://lists.yoctoproject.org/listinfo/meta-intel -- looks like subscribing to https://lists.yoctoproject.org/listinfo/linux-yocto is also recommended, right? Sep 30 15:58:44 gvy, have you tried the intel-corei7-64 BSP? which has the baytrail config and is the supported BSP for the minnowboard MAX? Sep 30 15:58:53 dvhart, where do I get it? Sep 30 15:59:00 from meta-intel Sep 30 15:59:01 01? Sep 30 15:59:17 http://git.yoctoproject.org/meta-intel Sep 30 15:59:25 erm Sep 30 15:59:26 wait Sep 30 15:59:42 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/ Sep 30 16:00:09 linux-yocto list is where you will send patches to change the meta-data Sep 30 16:00:13 conf/machine/intel-corei7-64.conf, yup Sep 30 16:00:19 meta-intel is for general development of the BSPs Sep 30 16:00:49 gvy, so generally speaking, that is the BSP which supports all 64b Intel BSPs since the core264 family Sep 30 16:02:08 erm... core2-64 Sep 30 16:02:38 * gvy greps over meta-intel Sep 30 16:22:26 rburton: yes; it can be an option Sep 30 16:22:33 but I didn't see how to do it yet Sep 30 16:22:43 do you happen to have an example? Sep 30 16:24:47 otavio: guess it depends on how much you need installed Sep 30 16:24:59 otavio: a custom do_build/do_install that just copies the headers might work Sep 30 16:39:16 otavio: do you know of a change in master that would cause the i.mx6 sysroot to change from cortexa9hf-vfp-neon-poky-linux-gnueabi to arm-poky-linux-gnueabi in the SDK environment file (but the actual directory is still cortex...). Means the environment file needs to be manually edited after installation to work correctly. Sep 30 16:40:10 staylor: this is weird indeed. I am trying to figure out why it happens Sep 30 16:40:25 otavio: okay so you're seeing this as well? Sep 30 16:40:59 one customer found it in ppc Sep 30 16:41:25 staylor: how did you change the env file to workaround it? Sep 30 16:41:56 I've been working on daisy for the last couple weeks so I'm not sure when this broke, but I updated our master repo and did a new sdk build a few days ago and the issue came up. Sep 30 16:42:47 but this customer is using daisy Sep 30 16:43:33 I edit the environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi file, first line is the export SDKTARGETSYSROOT so I update that portion. Also broken is the PKG_CONFIG_PATH it sets it to $SDKTARGETSYSROOT/opt/poky/... so you end up with it looking in /opt/poky/1.7/sysroots/arm-poky-linux-gnueabi/opt/poky/1.7/... Sep 30 16:43:57 Ahh Sep 30 16:44:11 see poky's change in meta-environment which RP pushed Sep 30 16:44:37 Our daisy repo appears unaffected Sep 30 16:51:19 otavio, does meta-freescale do something funny to tune settings? I have build that includes it and local.conf is setting all boards to same compiler settings Sep 30 16:51:37 but it seems like something in meta-freescale meses things up Sep 30 16:51:55 I haven't looked into this really hard Sep 30 16:52:24 Crofton: yes; check imx-base.inc file Sep 30 16:52:31 ok Sep 30 16:52:34 hf by default Sep 30 16:52:42 Crofton: patches welcome Sep 30 16:53:58 I'll try and poke at this some next week Sep 30 16:54:07 at a customers this week Sep 30 16:54:14 Ok Sep 30 16:54:28 Crofton: thx Sep 30 16:54:40 one day I need to pick up a freescale board since people are doing gnuradio stuff on them Sep 30 16:54:54 Crofton: which board? Sep 30 16:54:57 I assume this is to be compatible with binary only blobs? Sep 30 16:55:11 I need to ask my friend Sep 30 16:55:18 a quad core :) Sep 30 16:56:31 let me know ;) Sep 30 16:56:45 ok Sep 30 16:57:05 otavio: so you figure this is a configuration issue on my part or something that's broken right now in yocto? Sep 30 16:57:56 staylor: neither; I asked you to try to check Poky as it had a change in meta-environment Sep 30 16:58:31 otavio: could you clarify what you mean, I didn't see that as a question sorry. Sep 30 17:03:29 otavio: I see now, thank you I'll rebuild with poky commit 78b2f5a72e0f33e551307a1d4c1f99e81aea4cac see if that fixes things. Sep 30 17:06:14 * gvy . o O ( thank you dvhart, see you next time ) Sep 30 17:27:58 @kergoth looks like you were right: BB_ENV_EXTRAWHITE changes in local.conf do not seem to have any effect Sep 30 17:28:19 neither with +=, nor with _append... Sep 30 17:29:04 whereas BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE MYGITVERSION" passes the check on the command line Sep 30 17:29:42 any can confirm? Sep 30 17:29:46 any better way? Sep 30 17:48:27 Correction (oh my...): the environment variable reliably passes the initial git version check. And then later in the build bitbake seems to clear the environment again... Sep 30 17:48:52 tar: license-destdir/xz/generic_GPLv2: file changed as we read it in sstate_create_package. anyone else running into these? they keep breaking our jenkins builds Sep 30 20:04:56 Hi Everyone, Has anyone successfully installed libgfortran? I'm following this guide http://www.jumpnowtek.com/linux/yocto/Add-Fortran-support-to-a-Yocto-build.html but I'm not getting "gthr.h:148:26: fatal error: gthr-default.h: No such file or directory" compile errors. Any suggestions? Sep 30 23:29:33 meh, i need to get a handle on the linux-yocto kernel dev process and tools one of these days Sep 30 23:29:37 * kergoth busts out the kenrel dev manual Sep 30 23:36:04 kergoth, please let me know what you think Sep 30 23:36:13 and if you find anything to be missing or difficult to find. Sep 30 23:36:17 will do Sep 30 23:36:41 as close as I ever got is linux-yocto-custom Sep 30 23:36:49 and i still get angry at times Sep 30 23:37:13 although the upstream bsp guys tend to try and make it do shit, and do not send stuff upstream Sep 30 23:58:53 dvhart: i notice there isn't much info about how you guys maintain the branch tree in the linux-yocto repo, nor what the kern-tools are and what they're used for Oct 01 00:00:10 kergoth, that's true - and that's the case because I set out to help people USE the system rather than recreate it. Oct 01 00:00:20 * kergoth nods Oct 01 00:00:21 Also, I wanted to define an "API" if you will Oct 01 00:00:32 and then establish unit tests to ensure we abided by it Oct 01 00:00:40 which means changing a lot of what the kern-tools do Oct 01 00:00:45 mostly gutting out the cruft Oct 01 00:00:54 i can see why what's there now was the focus, but i could still see folks wanting to contribute their bsps, or maintain forks to leverage the capabilities of the tools for their own stuff Oct 01 00:00:55 and ensuring we maintained the documented usage cases Oct 01 00:01:23 Hrm, hopefully there is enough there to contribute BSPs Oct 01 00:01:29 if not, that's most definitely a gap Oct 01 00:02:16 kergoth, does appendix A.2 help? Oct 01 00:02:40 AS well as B Oct 01 00:04:46 gotta run - but feel free to follow-up via email Oct 01 02:45:24 anyone else having problems downloading from git.yoctoproject.org? I've had multiple attempts to get linux-yocto 3.14 fail today. From two different locations now. **** ENDING LOGGING AT Wed Oct 01 03:00:00 2014