| 00:20.07 | *** join/#oe infobot (~infobot@rikers.org) |
| 00:20.07 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 00:29.01 | MrKevin | Has anyone out there successfully built oe/poky using Windows Subsystem for Linux? I got the build to start, but I had to build in /mnt/e since I didn't have enough space in my C drive, so I ran afoul of filenames with ":" in them. |
| 00:32.51 | *** join/#oe Jackie (~quassel@106.120.101.38) |
| 01:15.38 | *** join/#oe bluelightning (~paul@85.159.237.199) |
| 01:15.38 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 02:11.16 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-aprgxdzqkfevjcfw) |
| 02:28.02 | khem | MrKevin: I would suggest to use a linux VM on windows |
| 02:28.31 | khem | We do support SDKs on mingw |
| 02:28.37 | kergoth | would be nice to support the windows subsystem for linux in general, my main concern would be filesystem capabilities, but i doubt anyone has messed with it much yet |
| 02:28.43 | kergoth | a vm is definitely a good way to go |
| 03:28.23 | *** join/#oe _dv_ (~quassel@62-178-118-86.cable.dynamic.surfer.at) |
| 03:37.11 | *** join/#oe anarsoul|2 (~anarsoul@216-71-193-140.dyn.novuscom.net) |
| 05:12.10 | *** join/#oe sgw_ (~sgw_@c-24-21-121-142.hsd1.or.comcast.net) |
| 05:14.42 | *** join/#oe AndersD (~anders@194.237.220.218) |
| 05:16.37 | *** join/#oe dl9pf (~quassel@static.88-198-106-157.clients.your-server.de) |
| 05:16.37 | *** join/#oe dl9pf (~quassel@opensuse/member/dl9pf) |
| 05:18.46 | *** join/#oe sgw_1 (~sgw_@134.134.139.78) |
| 05:28.42 | *** join/#oe adam-trhon (~dadam@ip-62-245-109-85.net.upcbroadband.cz) |
| 05:38.19 | *** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com) |
| 05:51.42 | *** join/#oe Jackie (~quassel@106.120.101.38) |
| 06:00.45 | *** join/#oe joseppc (~josep@c-8614e455.010-118-73746f7.cust.bredbandsbolaget.se) |
| 06:00.46 | *** join/#oe joseppc (~josep@linaro/joseppc) |
| 06:09.39 | *** join/#oe snowkidind (~textual@216-15-40-124.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com) |
| 06:20.45 | *** join/#oe adam-trhon (~dadam@176.74.132.138) |
| 06:21.25 | *** join/#oe anarsoul|2 (~anarsoul@216-71-193-140.dyn.novuscom.net) |
| 06:45.09 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 06:50.21 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 07:00.57 | *** join/#oe jku (~jku@192.198.151.44) |
| 07:01.09 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-aluwwxpufmuzfxrv) |
| 07:05.54 | *** join/#oe MarcWe (~hmw@zimbra.welvaarts.com) |
| 07:23.49 | *** join/#oe Bunio_FH (~bunio@89-79-16-212.dynamic.chello.pl) |
| 07:27.25 | *** join/#oe stefan_schmidt (~stefan@p2003004809283B6F9A8389FFFE2E3FAE.dip0.t-ipconnect.de) |
| 07:38.54 | *** join/#oe ao2 (~ao2@host52-146-dynamic.43-79-r.retail.telecomitalia.it) |
| 07:45.15 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:19.41 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:20.37 | *** join/#oe florian_ (~fuchs@p2E5258F0.dip0.t-ipconnect.de) |
| 08:35.29 | *** join/#oe yann (~yann@LFbn-1-489-101.w86-245.abo.wanadoo.fr) |
| 09:04.39 | *** join/#oe ao2_ (~ao2@host150-148-dynamic.16-87-r.retail.telecomitalia.it) |
| 09:06.26 | *** join/#oe mario-goulart (~user@email.parenteses.org) |
| 09:21.31 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:24.26 | *** join/#oe ant_work (~ant__@host215-70-dynamic.249-95-r.retail.telecomitalia.it) |
| 09:29.44 | *** join/#oe tasslehoff (~Tasslehof@82.147.55.166) |
| 09:36.50 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 09:48.34 | *** join/#oe ao2__ (~ao2@host179-223-dynamic.51-79-r.retail.telecomitalia.it) |
| 10:15.30 | *** join/#oe Bunio_FH (~bunio@89-79-16-212.dynamic.chello.pl) |
| 10:17.56 | *** join/#oe bluelightning_ (~paul@85.159.237.199) |
| 10:17.56 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 11:03.59 | *** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com) |
| 11:34.19 | *** join/#oe berton (~berton@179.105.243.125) |
| 11:40.47 | *** join/#oe ldnunes (~ldnunes_@179.105.243.125) |
| 11:41.43 | *** join/#oe caiortp (~inatel@131.221.240.233) |
| 11:54.43 | *** join/#oe MarcWe (~hmw@zimbra.welvaarts.com) |
| 12:29.14 | *** join/#oe hrww (~hrw@redhat/hrw) |
| 12:39.04 | *** join/#oe Bunio_FH (~bunio@89-79-16-212.dynamic.chello.pl) |
| 12:48.59 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-fzmpfwwolyoanpgv) |
| 12:59.19 | *** join/#oe ao2_ (~ao2@host228-145-dynamic.55-82-r.retail.telecomitalia.it) |
| 13:06.20 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 13:36.07 | *** join/#oe marka (~masselst@135-23-92-83.cpe.pppoe.ca) |
| 13:42.21 | *** join/#oe neomilium (~quassel@LFbn-1-11819-107.w90-93.abo.wanadoo.fr) |
| 13:50.59 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 13:51.07 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 14:52.50 | *** join/#oe ao2__ (~ao2@host149-34-dynamic.16-87-r.retail.telecomitalia.it) |
| 15:07.43 | *** join/#oe anarsoul|2 (~anarsoul@216-71-193-140.dyn.novuscom.net) |
| 15:09.52 | *** join/#oe armpit (~armpit@2601:202:4001:9ea0:4500:a5e9:7fec:f9a5) |
| 15:14.50 | *** join/#oe ao2_ (~ao2@host190-94-dynamic.49-82-r.retail.telecomitalia.it) |
| 15:19.39 | cbrake | what is the difference between tmp/sysroots and tmp/sysroots-components ? |
| 15:21.03 | kergoth | cbrake: with recipe specific sysroots, each recipe has its own native and target sysroot just with its dependencies |
| 15:21.03 | *** join/#oe stephano (~stephano@134.134.139.72) |
| 15:21.13 | kergoth | sysroot-components holds the content used to construct them |
| 15:21.40 | kergoth | afaik, anyway |
| 15:21.53 | cbrake | kergoth: is it normal that tmp/sysroots does not contain anything? |
| 15:22.05 | kergoth | yes |
| 15:22.12 | kergoth | as i said, sysroots are recipe specific now |
| 15:22.18 | kergoth | the notion of a global one doesn't make much sense anymore |
| 15:22.47 | cbrake | kergoth: IC -- thanks for the explanation |
| 15:23.15 | kergoth | 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 |
| 15:23.25 | kergoth | i.e. the wic-tools recipe populates a sysroot with the bits wic needs |
| 15:23.27 | *** join/#oe ao2__ (~ao2@host96-137-dynamic.56-79-r.retail.telecomitalia.it) |
| 15:23.55 | kergoth | not 100% clear on the details of all those myself |
| 15:24.30 | cbrake | how does a path get set then with binaries in different directories? |
| 15:24.46 | cbrake | for example when a recipe needs to access tools during a build |
| 15:25.05 | cbrake | guess I should go look at a temp/run.do_compile script ... |
| 15:27.06 | kergoth | not sure what you mean |
| 15:27.09 | kergoth | as i said, each recipe gets its own sysroots |
| 15:27.12 | kergoth | those are in PATH |
| 15:27.25 | kergoth | a task is run before configure tha tpopulates them based on the deps |
| 15:34.22 | cbrake | 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 ... |
| 15:35.32 | Crofton|work | cbrake, why not use populate_sdk and make a stand alone toolchain? |
| 15:35.38 | *** join/#oe stephano (~stephano@134.134.139.83) |
| 15:36.22 | cbrake | 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 |
| 15:36.27 | kergoth | yeah, the answer is usually "don't do that" |
| 15:36.41 | kergoth | but iirc there is a recipe to populate the global sysroot with what's been built thus far |
| 15:37.08 | cbrake | I think once I figure out where everything is, it will be a simple matter to include in the path |
| 15:37.16 | kergoth | tmp is called tmp for a reason, you can't rely on its contents being usable by anything but bitbake |
| 15:37.26 | kergoth | if it breaks on occasion due to an assumption, that's to be expected |
| 15:38.08 | kergoth | 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 |
| 15:39.10 | cbrake | 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. |
| 15:42.04 | Crofton|work | that reminds me, I need to recheck AB sdk building u-boot |
| 15:42.13 | Crofton|work | I swear there is an issue building u-boot |
| 15:43.24 | cbrake | OK, I think you folks have talked me into just using the SDK :-) |
| 15:43.49 | kergoth | cbrake: oe-core/meta/recipes-core/meta/build-sysroots.bb |
| 15:44.07 | Crofton|work | if you have issues building some fdt thing let me know |
| 15:44.12 | Crofton|work | I have an interest |
| 15:45.26 | cbrake | tries build-sysroots ... |
| 15:50.29 | *** join/#oe snowkidind (~textual@216-15-40-124.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com) |
| 16:07.24 | cbrake | kergoth: build-sysroots is a winner -- thanks for the tip. |
| 16:07.31 | kergoth | nice, np |
| 16:07.42 | kergoth | figured it might unblock you at least, can always consider moving to an sdk later |
| 16:13.54 | cbrake | 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 |
| 16:14.52 | kergoth | can always use devtool modify / devtool build / etc, but yeah, slightly more overhead |
| 16:15.48 | kergoth | wonder how well memres is working nowadays |
| 16:17.17 | cbrake | 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 ... |
| 16:25.39 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-kafpynlhcbuvkumt) |
| 16:52.23 | ensc|w | cbrake: we are using https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/meta/recipes/elito-develcomp/elito-makefile.bb |
| 16:52.56 | ensc|w | creates makefile wrappers with a customizable sysroot environment |
| 17:00.22 | cbrake | ensc|w: neat -- thanks for the link. What are some examples of what you use these resulting Makefiles for? |
| 17:03.01 | *** join/#oe Varti (~varthall@dynamic-adsl-78-12-165-102.clienti.tiscali.it) |
| 17:03.44 | ensc|w | cbrake: kernel can be built by: make -f ../Makefile.kernel.<project-name> KBUILD_OUTPUT= |
| 17:04.28 | ensc|w | 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 |
| 17:04.54 | ensc|w | there is a 'make pkg-install P=foo' functionality too, which install package 'foo' in the image (which is exported by NFS) |
| 17:07.48 | ensc|w | cbrake: https://pastebin.com/BnpnAgCQ |
| 17:15.19 | *** join/#oe neomilium (~quassel@LFbn-1-11819-107.w90-93.abo.wanadoo.fr) |
| 17:38.18 | *** join/#oe paulg (~paulg@198-84-239-75.cpe.teksavvy.com) |
| 18:27.43 | *** join/#oe adam-trhon (~dadam@ip-62-245-109-85.net.upcbroadband.cz) |
| 18:29.43 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:05.11 | *** join/#oe t0mmy (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 19:22.07 | *** join/#oe denix0 (~denix@pool-100-15-85-143.washdc.fios.verizon.net) |
| 19:25.19 | *** join/#oe volestorm (~volestorm@23.105.205.111.16clouds.com) |
| 19:25.19 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 20:09.14 | *** join/#oe stephano (stephano@nat/intel/x-wyenbrgcgrwuqkdb) |
| 20:42.27 | khem | cbrake: I would suggest to see if devtool workflow would be a better long time solution |
| 20:43.09 | *** join/#oe t0mmy (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 20:43.15 | khem | 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 |
| 20:43.51 | khem | they dont have to worry about the internal restructuring like this |
| 20:45.24 | cbrake | khem: looks interesting |
| 20:46.10 | cbrake | khem: documentation is a little terse, so will need to spend some playing with it |
| 20:46.44 | *** join/#oe t0mmy (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 20:52.43 | khem | cbrake: few steps devtool modify -x <recipe> |
| 20:52.52 | khem | devtool build <recipe> |
| 20:52.57 | khem | thats it |
| 20:53.28 | khem | now you have the sources checked out into a directory called workspace/sources/<recipe> |
| 20:53.40 | khem | now you can build with devtool or bitbake doesnt matter |
| 20:53.54 | khem | it will always use your external source tree for <Recipe> |
| 20:54.28 | khem | you can fix things and commit into workspace/sources/<recipe> ( its a git tree ) |
| 20:54.58 | khem | in the end you can do devtool finish <recipe> <layer-name where the recipe belongs to e.g. meta-oe> |
| 20:55.20 | khem | it will do all the needed bits of creating patches and applying them back into meta data |
| 20:55.39 | khem | if you dont want to keep your changes and delete the external source |
| 20:55.48 | khem | devtool reset <Recipe> will do it |
| 20:55.57 | khem | these are primary steps you will need |
| 20:56.15 | *** join/#oe armpit (~armpit@2601:202:4001:9ea0:4500:a5e9:7fec:f9a5) |
| 20:56.16 | kergoth | note: it doesn't delete the external source, it leaves it there, just stops using it |
| 20:56.23 | kergoth | can always use it again later |
| 20:56.32 | khem | yes and it informs about it nicely :) |
| 20:56.38 | kergoth | indeed |
| 20:57.04 | khem | I also go into sources and links to oe-logdir and oe-workdir are there which are handy to peek into objdir |
| 20:57.35 | khem | I usually do oe-logdir/run.do_compile when doing changes in src |
| 20:57.51 | khem | which tells me quickly if the change compiles and links |
| 20:57.56 | khem | pretty handy |
| 20:58.28 | khem | devtool upgrade --version x.y.x <recipe> works great too |
| 20:58.38 | khem | for upgrading tarball based recipes |
| 20:59.41 | khem | may be in future we can have devtool test <recipe> |
| 21:00.10 | khem | which will effectively do equivalent of make check |
| 21:00.24 | khem | but run on a cross target |
| 21:00.36 | khem | that will be so cool |
| 21:00.36 | kergoth | that'd be cool, could just have it run the ptests |
| 21:00.45 | khem | yeah exactly |
| 21:01.03 | kergoth | thinks ptests are sadly neglected, last time he tried to run them at least half failed across numerous recipes :) |
| 21:01.38 | khem | I am running bitbake -ctestimage <image> which then runs on real board like dart board or rpi3 |
| 21:01.51 | khem | its an extention of that |
| 21:01.52 | kergoth | nice, i still need to play with that |
| 21:02.27 | khem | kergoth: all you need is |
| 21:02.34 | khem | TEST_TARGET ?= "simpleremote" |
| 21:02.35 | khem | TEST_SERVER_IP = "10.0.0.10" |
| 21:02.37 | khem | TEST_TARGET_IP ?= "192.168.7.2" |
| 21:02.51 | khem | here change the target and server ips to your taste |
| 21:03.49 | khem | there is one kink though |
| 21:04.20 | khem | you need to 1. build the image 2. flash it onto your board 3. run the -ctestimage target |
| 21:04.36 | khem | so its not as automated as qemu machines |
| 21:04.59 | khem | 2.5 - boot the machine ofcourse |
| 21:10.02 | kergoth | still, that's not bad, considering |
| 21:11.18 | khem | absolutely |
| 21:22.17 | cbrake | khem: pretty neat -- I can see where that would work well for kernel dev |
| 21:22.46 | khem | cbrake: cool |
| 21:23.01 | khem | cbrake: they can push from their git tree to remote as well |
| 21:23.35 | cbrake | khem: can sources/recipe be used in a permanent setup? |
| 21:24.12 | khem | cbrake: dont think so but you can provide a setup script to do so |
| 21:25.00 | cbrake | 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 |
| 21:25.15 | cbrake | khem: but you could devtool them as part of the setup process |
| 21:25.55 | cbrake | khem: (instead of fetching sources in a more tradition way) |
| 21:26.13 | khem | actually you for own packages you could ship original recipe with sources pointing to submod |
| 21:26.24 | khem | although with devtool you dont need that |
| 21:26.36 | khem | devtool would be uniform workflow across all packages |
| 21:26.38 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 21:27.13 | khem | so you could let the private recipes point to private git repos upstream |
| 21:27.22 | khem | and then let devtool do the local source setup |
| 21:27.33 | khem | instead |
| 21:27.50 | khem | you can control the revisions via SRCREV in recipe |
| 21:28.19 | khem | so I see it will divorce from submodule workflow |
| 21:30.10 | cbrake | Khem -- will need to revisit all this soon -- lots of neat ideas |
| 21:30.48 | khem | cbrake: yeah, it is a bit of mindset change game but I have found it more productive |
| 21:31.02 | khem | I have sometimes 5-10 components under devtool |
| 21:31.12 | cbrake | khem: neat |
| 21:31.13 | khem | but this all is under my control, I like it |
| 21:31.25 | khem | and process is same |
| 21:31.50 | khem | so its like checking out only the bits that I need to change and look into |
| 21:32.11 | khem | instead of checking out a monolith ( taking a jibe at android ) |
| 21:32.27 | khem | and then change 2 lines |
| 21:33.04 | cbrake | khem: :-) -- where did devtool come from? |
| 21:33.05 | khem | here I only check out sources of whats really needed |
| 21:33.22 | khem | devtool came from Yocto project |
| 21:33.58 | kergoth | iirc it was paul eggleton's baby |
| 21:34.08 | khem | thats right |
| 21:34.51 | khem | although a lot learning from hob/sdk etc. |
| 21:35.35 | khem | its a good tool |
| 21:37.09 | kergoth | it is |
| 21:37.12 | kergoth | recipetool is oto |
| 21:37.13 | kergoth | too |
| 21:37.29 | khem | right |
| 21:37.50 | khem | we also need a workspace setup tool now :) |
| 21:38.29 | kergoth | 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 |
| 21:39.29 | khem | thats in right direction though |
| 21:39.45 | khem | looking at go ecosystem or nodejs or java |
| 21:40.01 | khem | thats one way to have rich ecosystem |
| 21:40.34 | kergoth | 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 |
| 21:40.41 | kergoth | shrugs |
| 21:41.02 | khem | there is govendor |
| 21:41.03 | cbrake | using vscode has been interesting -- they do plugins and settings very well. A lot of tools could learn from that. |
| 21:41.27 | kergoth | khem: yeah, and glide, etc |
| 21:41.39 | khem | cbrake: indeed, its 21-19 in favor of vscode vs atom for me |
| 21:41.49 | kergoth | ponders |
| 21:42.06 | kergoth | i still like sublime. still a lot faster than either of those |
| 21:42.15 | kergoth | though vscode is faster than atom in my experience, still not quite up to par with st3 |
| 21:42.42 | cbrake | I've been applying some of what I learn in vscode back to nvim |
| 21:43.00 | cbrake | automatic formatting and linting, etc |
| 21:43.04 | kergoth | i still haven't made the switch to neovim or vim 8, need to get switched |
| 21:43.23 | kergoth | the 'ale' plugin for async linting is pretty fantastic, does it all the time, not just on save like syntastic did |
| 21:43.33 | kergoth | (for vim/neovim) |
| 21:43.46 | cbrake | I'll have to check that out |
| 21:44.03 | kergoth | cbrake: https://github.com/w0rp/ale |
| 21:44.29 | kergoth | 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 |
| 21:44.30 | kergoth | heh |
| 21:45.01 | cbrake | 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. |
| 21:45.37 | kergoth | speeds up the test cycle, since you see basic issues immediately |
| 21:46.44 | kergoth | i hate it when a recipe doesn't work with externalsrc. get spoiled by devtool working |
| 21:46.55 | cbrake | 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. |
| 21:50.55 | kergoth | 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*) |
| 21:50.59 | kergoth | s/safe/sane/ |
| 21:53.59 | cbrake | nod! |
| 22:09.44 | *** join/#oe ant_home (~ant__@host251-139-dynamic.104-80-r.retail.telecomitalia.it) |
| 22:17.56 | Crofton|work | any clues? |
| 22:17.57 | Crofton|work | http://paste.debian.net/974184/ |
| 22:29.49 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-vptrezvzdsvzsppl) |
| 22:49.06 | khem | I spent good time configuring atom I agree |
| 22:54.36 | ant_home | khem, I'll do some builds tomorrow with master. What is worth to check first? armv4 or armv5? |
| 22:54.51 | khem | armv5? |
| 22:54.59 | khem | out of those two armv5 |
| 22:55.10 | ant_home | ok |
| 22:59.35 | khem | Crofton|work: check_SYS_getrandom.patch .. which layer is slapping it in ? |
| 22:59.52 | ant_home | hm, seems there are no changes for gcc 7.1 after 'disable thumb' which I did already have |
| 23:00.20 | khem | ant_home: its possible that these devices are not widely tested |
| 23:00.25 | khem | so something crept in |
| 23:00.59 | khem | most of times its some code misunderstanding between kernel source and gcc |
| 23:01.01 | ant_home | ok, to nail down the issue I stay with the same kenel 4.12-rc (or old 4.4) |
| 23:01.15 | khem | is 4.12rc working ? |
| 23:01.28 | khem | if nothing is working them I would say debug the latest |
| 23:01.35 | ant_home | issues with display but ok on console |
| 23:01.40 | khem | you will find some support for that on mailing lists |
| 23:02.30 | ant_home | sam ekernel is booting compiled with OE gcc6 |
| 23:02.47 | ant_home | so it should be just gcc |
| 23:02.51 | khem | understood, there might be some optimization |
| 23:03.11 | khem | can you try using -Os eg. |
| 23:03.19 | khem | to compile it |
| 23:04.35 | ant_home | it was the xz decompressor failing in my case |
| 23:04.57 | ant_home | early |
| 23:05.01 | khem | xz in kernel ? |
| 23:05.05 | ant_home | yes |
| 23:05.19 | khem | did you enable all early printks ? |
| 23:05.33 | khem | sometimes such issues are also related to kernel size |
| 23:05.56 | khem | where bootloader might have reserved x bytes but now code is x+10 and it booms |
| 23:06.03 | ant_home | yes, you told me. But the size did not increase |
| 23:06.17 | ant_home | in our case kernel is kexec'. no issue |
| 23:06.22 | khem | I would suggest to play with optimizations |
| 23:06.40 | khem | we can narrow it down that way |
| 23:06.50 | khem | unless you have a better way of stepping through the flow |
| 23:06.56 | ant_home | ok, iirc it is already optimized for size |
| 23:07.00 | khem | and see where it digresses with 6.x built kernel |
| 23:07.09 | khem | then use -O2 |
| 23:07.14 | khem | do something different |
| 23:07.21 | ant_home | understood |
| 23:07.27 | ant_home | thanks |
| 23:07.41 | khem | other option is to disable xz and use gz |
| 23:07.42 | ant_home | see, in emergency I can branch a gdb |
| 23:07.47 | khem | or lzma |
| 23:07.50 | khem | and see if that works |
| 23:08.08 | khem | it needs to be narrowed down further |
| 23:08.52 | khem | RP: I think the AB testimage failures with my hardening patches are bogus |
| 23:10.03 | *** join/#oe sgw_ (sgw_@nat/intel/x-hywdcwlavzvnnhua) |
| 23:10.05 | khem | kernel logs in passing case are emitted to kern.log and in failing case are emitted into user.log |
| 23:10.13 | khem | and they are line by line identical |
| 23:10.34 | khem | the error that its flagging exists in logs of passing case as well. |
| 23:10.46 | khem | its just that its in a different log file |
| 23:11.07 | khem | now why its collecting logs differently remains to be seen |
| 23:11.18 | khem | but as per runs I dont see any difference |
| 23:48.00 | *** join/#oe adam-trhon (~dadam@ip-62-245-109-85.net.upcbroadband.cz) |