**** BEGIN LOGGING AT Fri Jun 30 03:00:03 2017 Jun 30 15:19:39 what is the difference between tmp/sysroots and tmp/sysroots-components ? Jun 30 15:21:03 cbrake: with recipe specific sysroots, each recipe has its own native and target sysroot just with its dependencies Jun 30 15:21:13 sysroot-components holds the content used to construct them Jun 30 15:21:40 afaik, anyway Jun 30 15:21:53 kergoth: is it normal that tmp/sysroots does not contain anything? Jun 30 15:22:05 yes Jun 30 15:22:12 as i said, sysroots are recipe specific now Jun 30 15:22:18 the notion of a global one doesn't make much sense anymore Jun 30 15:22:47 kergoth: IC -- thanks for the explanation Jun 30 15:23:15 iirc it still may be used in certain contexts -- there are boundaries where external tools need access to sysroot content, and have mechanisms to do so Jun 30 15:23:25 i.e. the wic-tools recipe populates a sysroot with the bits wic needs Jun 30 15:23:55 not 100% clear on the details of all those myself Jun 30 15:24:30 how does a path get set then with binaries in different directories? Jun 30 15:24:46 for example when a recipe needs to access tools during a build Jun 30 15:25:05 guess I should go look at a temp/run.do_compile script ... Jun 30 15:27:06 not sure what you mean Jun 30 15:27:09 as i said, each recipe gets its own sysroots Jun 30 15:27:12 those are in PATH Jun 30 15:27:25 a task is run before configure tha tpopulates them based on the deps Jun 30 15:34:22 we're running into an issue using the OE toolchain in sysroots to build a linux kernel outside OE (part of our standard development flow). Still digging to better understand all this ... Jun 30 15:35:32 cbrake, why not use populate_sdk and make a stand alone toolchain? Jun 30 15:36:22 Crofton|work: that would work, but requires extra steps, disk space, etc. Most of the time, the OE/kernel developers are the same people, so by setting a few variables, we can just use the OE toolchain Jun 30 15:36:27 yeah, the answer is usually "don't do that" Jun 30 15:36:41 but iirc there is a recipe to populate the global sysroot with what's been built thus far Jun 30 15:37:08 I think once I figure out where everything is, it will be a simple matter to include in the path Jun 30 15:37:16 tmp is called tmp for a reason, you can't rely on its contents being usable by anything but bitbake Jun 30 15:37:26 if it breaks on occasion due to an assumption, that's to be expected Jun 30 15:38:08 if you really want to add 47 different dirs in sysroot-components to your PATH, sure, otherwise no, not unless you use the recipe i just mentioned, or write your own to do similarly Jun 30 15:39:10 yeah, maybe this is not practical -- but still, the tools required to build kernel and u-boot are fairly minimal, which is the primary need. App developers use the SDK. Jun 30 15:42:04 that reminds me, I need to recheck AB sdk building u-boot Jun 30 15:42:13 I swear there is an issue building u-boot Jun 30 15:43:24 OK, I think you folks have talked me into just using the SDK :-) Jun 30 15:43:49 cbrake: oe-core/meta/recipes-core/meta/build-sysroots.bb Jun 30 15:44:07 if you have issues building some fdt thing let me know Jun 30 15:44:12 I have an interest Jun 30 15:45:26 * cbrake tries build-sysroots ... Jun 30 16:07:24 kergoth: build-sysroots is a winner -- thanks for the tip. Jun 30 16:07:31 nice, np Jun 30 16:07:42 figured it might unblock you at least, can always consider moving to an sdk later Jun 30 16:13:54 yeah, building the kernel is so simple -- all you need is ARCH, CROSS_COMPILE, and add tools to PATH ... hard to give up the simplicity of that when doing kernel + OE work together Jun 30 16:14:52 can always use devtool modify / devtool build / etc, but yeah, slightly more overhead Jun 30 16:15:48 wonder how well memres is working nowadays Jun 30 16:17:17 I should try devtool again. Having the OE recipe pull kernel from git, and then push kernel changes to git from tree outside OE just works so well and as so fast I have little motivation to try something else ... Jun 30 16:52:23 cbrake: we are using https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/meta/recipes/elito-develcomp/elito-makefile.bb Jun 30 16:52:56 creates makefile wrappers with a customizable sysroot environment Jun 30 17:00:22 ensc|w: neat -- thanks for the link. What are some examples of what you use these resulting Makefiles for? Jun 30 17:03:44 cbrake: kernel can be built by: make -f ../Makefile.kernel. KBUILD_OUTPUT= Jun 30 17:04:28 or 'make shell' (which is a toplevel wrapper) creates a shell where arm-....-gcc and all the other stuff from the sysroot is in the path Jun 30 17:04:54 there is a 'make pkg-install P=foo' functionality too, which install package 'foo' in the image (which is exported by NFS) Jun 30 17:07:48 cbrake: https://pastebin.com/BnpnAgCQ Jun 30 20:42:27 cbrake: I would suggest to see if devtool workflow would be a better long time solution Jun 30 20:43:15 cbrake: that workflow gives best of both worlds devs get to hack on a src tree that is under their control + the infra and tools are managed by OE Jun 30 20:43:51 they dont have to worry about the internal restructuring like this Jun 30 20:45:24 khem: looks interesting Jun 30 20:46:10 khem: documentation is a little terse, so will need to spend some playing with it Jun 30 20:52:43 cbrake: few steps devtool modify -x Jun 30 20:52:52 devtool build Jun 30 20:52:57 thats it Jun 30 20:53:28 now you have the sources checked out into a directory called workspace/sources/ Jun 30 20:53:40 now you can build with devtool or bitbake doesnt matter Jun 30 20:53:55 it will always use your external source tree for Jun 30 20:54:28 you can fix things and commit into workspace/sources/ ( its a git tree ) Jun 30 20:54:59 in the end you can do devtool finish Jun 30 20:55:20 it will do all the needed bits of creating patches and applying them back into meta data Jun 30 20:55:39 if you dont want to keep your changes and delete the external source Jun 30 20:55:48 devtool reset will do it Jun 30 20:55:57 these are primary steps you will need Jun 30 20:56:16 note: it doesn't delete the external source, it leaves it there, just stops using it Jun 30 20:56:23 can always use it again later Jun 30 20:56:32 yes and it informs about it nicely :) Jun 30 20:56:38 indeed Jun 30 20:57:04 I also go into sources and links to oe-logdir and oe-workdir are there which are handy to peek into objdir Jun 30 20:57:35 I usually do oe-logdir/run.do_compile when doing changes in src Jun 30 20:57:51 which tells me quickly if the change compiles and links Jun 30 20:57:56 pretty handy Jun 30 20:58:28 devtool upgrade --version x.y.x works great too Jun 30 20:58:38 for upgrading tarball based recipes Jun 30 20:59:41 may be in future we can have devtool test Jun 30 21:00:10 which will effectively do equivalent of make check Jun 30 21:00:24 but run on a cross target Jun 30 21:00:36 that will be so cool Jun 30 21:00:36 that'd be cool, could just have it run the ptests Jun 30 21:00:45 yeah exactly Jun 30 21:01:03 * kergoth thinks ptests are sadly neglected, last time he tried to run them at least half failed across numerous recipes :) Jun 30 21:01:38 I am running bitbake -ctestimage which then runs on real board like dart board or rpi3 Jun 30 21:01:51 its an extention of that Jun 30 21:01:52 nice, i still need to play with that Jun 30 21:02:27 kergoth: all you need is Jun 30 21:02:34 TEST_TARGET ?= "simpleremote" Jun 30 21:02:35 TEST_SERVER_IP = "10.0.0.10" Jun 30 21:02:37 TEST_TARGET_IP ?= "192.168.7.2" Jun 30 21:02:51 here change the target and server ips to your taste Jun 30 21:03:49 there is one kink though Jun 30 21:04:20 you need to 1. build the image 2. flash it onto your board 3. run the -ctestimage target Jun 30 21:04:36 so its not as automated as qemu machines Jun 30 21:04:59 2.5 - boot the machine ofcourse Jun 30 21:10:03 still, that's not bad, considering Jun 30 21:11:18 absolutely Jun 30 21:22:17 khem: pretty neat -- I can see where that would work well for kernel dev Jun 30 21:22:46 cbrake: cool Jun 30 21:23:01 cbrake: they can push from their git tree to remote as well Jun 30 21:23:35 khem: can sources/recipe be used in a permanent setup? Jun 30 21:24:12 cbrake: dont think so but you can provide a setup script to do so Jun 30 21:25:00 khem: one thing my customers do is like to have their app sources controlled with submodules in the build tree, and then have the recipe build directly from those sources Jun 30 21:25:15 khem: but you could devtool them as part of the setup process Jun 30 21:25:55 khem: (instead of fetching sources in a more tradition way) Jun 30 21:26:13 actually you for own packages you could ship original recipe with sources pointing to submod Jun 30 21:26:24 although with devtool you dont need that Jun 30 21:26:36 devtool would be uniform workflow across all packages Jun 30 21:27:13 so you could let the private recipes point to private git repos upstream Jun 30 21:27:22 and then let devtool do the local source setup Jun 30 21:27:33 instead Jun 30 21:27:50 you can control the revisions via SRCREV in recipe Jun 30 21:28:19 so I see it will divorce from submodule workflow Jun 30 21:30:10 Khem -- will need to revisit all this soon -- lots of neat ideas Jun 30 21:30:48 cbrake: yeah, it is a bit of mindset change game but I have found it more productive Jun 30 21:31:02 I have sometimes 5-10 components under devtool Jun 30 21:31:12 khem: neat Jun 30 21:31:13 but this all is under my control, I like it Jun 30 21:31:25 and process is same Jun 30 21:31:50 so its like checking out only the bits that I need to change and look into Jun 30 21:32:12 instead of checking out a monolith ( taking a jibe at android ) Jun 30 21:32:27 and then change 2 lines Jun 30 21:33:04 khem: :-) -- where did devtool come from? Jun 30 21:33:05 here I only check out sources of whats really needed Jun 30 21:33:22 devtool came from Yocto project Jun 30 21:33:58 iirc it was paul eggleton's baby Jun 30 21:34:09 thats right Jun 30 21:34:51 although a lot learning from hob/sdk etc. Jun 30 21:35:35 its a good tool Jun 30 21:37:09 it is Jun 30 21:37:12 recipetool is oto Jun 30 21:37:13 too Jun 30 21:37:29 right Jun 30 21:37:50 we also need a workspace setup tool now :) Jun 30 21:38:29 ugh, everybody and their brother has one. the intel one isn't bad, but i'm not sure how i feel about relying on a layer index instance. adds overhead, requiing that companies host their own indexes Jun 30 21:39:29 thats in right direction though Jun 30 21:39:45 looking at go ecosystem or nodejs or java Jun 30 21:40:01 thats one way to have rich ecosystem Jun 30 21:40:34 i like go's use of arbitrary repositories and a tool to fetch them rather than having to have a master index to map layer name to url, though Jun 30 21:40:41 * kergoth shrugs Jun 30 21:41:02 there is govendor Jun 30 21:41:03 using vscode has been interesting -- they do plugins and settings very well. A lot of tools could learn from that. Jun 30 21:41:27 khem: yeah, and glide, etc Jun 30 21:41:39 cbrake: indeed, its 21-19 in favor of vscode vs atom for me Jun 30 21:41:49 * kergoth ponders Jun 30 21:42:06 i still like sublime. still a lot faster than either of those Jun 30 21:42:15 though vscode is faster than atom in my experience, still not quite up to par with st3 Jun 30 21:42:42 I've been applying some of what I learn in vscode back to nvim Jun 30 21:43:00 automatic formatting and linting, etc Jun 30 21:43:05 i still haven't made the switch to neovim or vim 8, need to get switched Jun 30 21:43:23 the 'ale' plugin for async linting is pretty fantastic, does it all the time, not just on save like syntastic did Jun 30 21:43:33 (for vim/neovim) Jun 30 21:43:46 I'll have to check that out Jun 30 21:44:03 cbrake: https://github.com/w0rp/ale Jun 30 21:44:29 really fast and responsive. i'd imagine it uses a bit more cpu than one that only does it on save, but i don't care, it's great Jun 30 21:44:30 heh Jun 30 21:45:01 kergoth: yeah, I can believe I've ignored formatters and linters until recently. They actually teach you quite a bit about a language, and really clean up code. Jun 30 21:45:37 speeds up the test cycle, since you see basic issues immediately Jun 30 21:46:44 i hate it when a recipe doesn't work with externalsrc. get spoiled by devtool working Jun 30 21:46:55 with vscode, I'm learning that plugins should be supported directly in any tool and not an afterthought. And the tool should be good at helping users determine what plugins they need, and provide reasonable defaults. Jun 30 21:50:55 more and more as i get older, i want tools with safe defaults in general. it shouldn't take 12 plugins just to make it usable (*cough*zsh*cough*) Jun 30 21:50:59 s/safe/sane/ Jun 30 21:53:59 nod! Jun 30 22:17:56 any clues? Jun 30 22:17:57 http://paste.debian.net/974184/ Jun 30 22:49:06 I spent good time configuring atom I agree Jun 30 22:54:36 khem, I'll do some builds tomorrow with master. What is worth to check first? armv4 or armv5? Jun 30 22:54:51 armv5? Jun 30 22:54:59 out of those two armv5 Jun 30 22:55:10 ok Jun 30 22:59:35 Crofton|work: check_SYS_getrandom.patch .. which layer is slapping it in ? Jun 30 22:59:52 hm, seems there are no changes for gcc 7.1 after 'disable thumb' which I did already have Jun 30 23:00:20 ant_home: its possible that these devices are not widely tested Jun 30 23:00:25 so something crept in Jun 30 23:00:59 most of times its some code misunderstanding between kernel source and gcc Jun 30 23:01:01 ok, to nail down the issue I stay with the same kenel 4.12-rc (or old 4.4) Jun 30 23:01:15 is 4.12rc working ? Jun 30 23:01:28 if nothing is working them I would say debug the latest Jun 30 23:01:35 issues with display but ok on console Jun 30 23:01:40 you will find some support for that on mailing lists Jun 30 23:02:31 sam ekernel is booting compiled with OE gcc6 Jun 30 23:02:47 so it should be just gcc Jun 30 23:02:51 understood, there might be some optimization Jun 30 23:03:11 can you try using -Os eg. Jun 30 23:03:19 to compile it Jun 30 23:04:35 it was the xz decompressor failing in my case Jun 30 23:04:57 early Jun 30 23:05:01 xz in kernel ? Jun 30 23:05:05 yes Jun 30 23:05:19 did you enable all early printks ? Jun 30 23:05:33 sometimes such issues are also related to kernel size Jun 30 23:05:56 where bootloader might have reserved x bytes but now code is x+10 and it booms Jun 30 23:06:03 yes, you told me. But the size did not increase Jun 30 23:06:17 in our case kernel is kexec'. no issue Jun 30 23:06:22 I would suggest to play with optimizations Jun 30 23:06:40 we can narrow it down that way Jun 30 23:06:50 unless you have a better way of stepping through the flow Jun 30 23:06:56 ok, iirc it is already optimized for size Jun 30 23:07:00 and see where it digresses with 6.x built kernel Jun 30 23:07:09 then use -O2 Jun 30 23:07:14 do something different Jun 30 23:07:21 understood Jun 30 23:07:27 thanks Jun 30 23:07:41 other option is to disable xz and use gz Jun 30 23:07:42 see, in emergency I can branch a gdb Jun 30 23:07:47 or lzma Jun 30 23:07:50 and see if that works Jun 30 23:08:08 it needs to be narrowed down further Jun 30 23:08:52 RP: I think the AB testimage failures with my hardening patches are bogus Jun 30 23:10:05 kernel logs in passing case are emitted to kern.log and in failing case are emitted into user.log Jun 30 23:10:13 and they are line by line identical Jun 30 23:10:34 the error that its flagging exists in logs of passing case as well. Jun 30 23:10:46 its just that its in a different log file Jun 30 23:11:07 now why its collecting logs differently remains to be seen Jun 30 23:11:18 but as per runs I dont see any difference Jul 01 02:16:09 finally back to this qemuppc compiler ICE: Jul 01 02:16:13 | ../../libjpeg-turbo-1.5.1/simd/jdmrgext-altivec.c:247:17: internal compiler error: Segmentation fault Jul 01 02:16:14 | edgeh = vec_ld(min(num_cols - 1, RGB_PIXELSIZE * 16), outptr); Jul 01 02:17:30 I'll start on it on Monday unless anyone (khem!) can point to a fix. **** ENDING LOGGING AT Sat Jul 01 03:00:01 2017