| 00:02.59 | smurray | bluelightning: thanks for the comments. wrt to debugging sstate issues is there documentation on how to go about doing that? |
| 00:03.11 | bluelightning | smurray: there |
| 00:03.34 | bluelightning | smurray: there's general documentation about sstate which may cover that, let me have a look |
| 00:04.08 | bluelightning | http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache |
| 00:04.26 | bluelightning | there's a "Tips and tricks" subsection further down that has some debugging info |
| 00:06.09 | smurray | bluelightning: I'll give it a read. |
| 00:08.48 | smurray | bluelightning: wrt devtool and the extensible SDK, I definitely need to play with them some more. |
| 00:09.02 | bluelightning | ok, no worries |
| 00:09.09 | bluelightning | the docs improved further in 2.1 FYI |
| 00:09.38 | smurray | bluelightning: yeah, I was looking at the devtool docs in 2.1 |
| 00:12.18 | smurray | bluelightning: I must admit that it's still not obvious to me how I could leverage eSDK in my customer's environment (100s of devs, shared install on NFS, with archiving of previous releases) |
| 00:12.51 | bluelightning | it won't work well in the shared NFS scenario, that is true |
| 00:13.37 | bluelightning | it could be that we need to adjust the structure a little so that that's possible |
| 00:15.03 | smurray | bluelightning: they're happy with the regular SDK, so not a big problem. It'd be nice if I could get it installed to the NFS server faster ;) |
| 00:15.57 | bluelightning | surely the solution there is do the install on the server itself ;) |
| 00:16.20 | bluelightning | otherwise we're just untaring a tarball, I don't think there's much we can do to speed that up |
| 00:20.31 | smurray | bluelightning: their IT locks things down, complicates life. wrt speed, I was thinking the relocate script took a bunch of time, but I've not double-checked that theory |
| 00:24.17 | bluelightning | I'd have to check myself, but I don't think that part takes a huge amount of time, though it may depend on what you have in your SDK of course |
| 00:25.17 | bluelightning | btw re the relocation after the fact, that is something we could look to change; i.e. we could leave the relocation script there and re-run it when sourcing the env setup script if the path has changed |
| 00:25.22 | bluelightning | brb |
| 00:37.04 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-edxsfcetltgotuli) |
| 00:57.07 | *** join/#oe evanmeagher (~MongooseW@c-73-71-33-109.hsd1.ca.comcast.net) |
| 01:28.06 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 02:21.14 | kergoth | We're using bits for auto-relocation of sdk at source-time in meta-mentor. not as clean as i'd like, though, which is why I haven't submitted it to oe-core yet. https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/classes/sdk_auto_relocate.bbclass + https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-core/meta/nativesdk-sdk-relocate.bb -- the ugliest bit is i didn't feel like invasively reworking |
| 02:21.14 | kergoth | <PROTECTED> |
| 02:21.16 | kergoth | bluelightning: ^ |
| 02:21.52 | bluelightning | kergoth: ok, I'll take a look, thanks |
| 02:22.14 | kergoth | refactoring and submitting is on the radar, just behind other higher priority bits :) |
| 02:25.38 | kergoth | we have an sdk-like construct which is aligned iwth the yocto sdk but distributes in a different way, and that distribution mechanism lacks post-install scripts, so had to work around that to get it relocated, otherwise probably wouldn't have bothered |
| 02:25.38 | kergoth | heh |
| 03:00.35 | *** join/#oe evanmeagher (~MongooseW@c-73-71-33-109.hsd1.ca.comcast.net) |
| 03:04.41 | *** join/#oe coolmouse (~coolmouse@123.138.169.113) |
| 03:17.55 | *** join/#oe muep (~quassel@muep.iki.fi) |
| 03:45.22 | *** join/#oe Aethenelle_ (~Aethenell@107.138.98.226) |
| 04:59.36 | *** join/#oe Mowgli (~mowgli@123.176.34.117) |
| 05:14.08 | *** join/#oe AndersD (~anders@213-64-218-130-no126.business.telia.com) |
| 05:29.45 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 05:31.58 | *** join/#oe AndersD (~anders@213-64-218-130-no126.business.telia.com) |
| 06:12.15 | *** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 06:12.15 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 06:14.57 | *** join/#oe tasslehoff (~Tasslehof@ti0260a430-0753.bb.online.no) |
| 06:29.25 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 06:33.31 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:40.28 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 06:53.03 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-aftgzfdxdwgkjfie) |
| 07:10.35 | *** join/#oe jku (jku@nat/intel/x-hmoozhyiherlkzke) |
| 07:21.17 | *** join/#oe yann (~yann@85-171-21-92.rev.numericable.fr) |
| 07:41.06 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 07:41.07 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:46.59 | *** join/#oe edbart (ebartosh@nat/intel/x-ufgdwqqribjqksyd) |
| 07:49.13 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-vtjfdczoqyeqpfbj) |
| 07:55.19 | *** join/#oe ftonello (~felipe@81.145.202.106) |
| 07:59.29 | *** join/#oe nrossi (~nrossi@CPE-123-211-45-7.lnse3.cha.bigpond.net.au) |
| 08:06.24 | *** join/#oe mago__ (~mago@88.131.56.168) |
| 08:28.07 | *** join/#oe vdehors (~vdehors@193.56.60.161) |
| 08:28.17 | *** join/#oe edbart (~ebartosh@192.198.151.44) |
| 08:29.33 | *** join/#oe joshuagl (joshuagl@nat/intel/x-anusstegtaxkfmoq) |
| 08:29.35 | hrw | https://github.com/bitkeeper-scm/bitkeeper - will we move again? ;d |
| 08:33.29 | joshuagl | wonders if there's a git import |
| 08:33.42 | joshuagl | slight irony that it's hosted on Github too :-) |
| 08:34.40 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 08:40.55 | *** join/#oe stefan_schmidt (~stefan@p2003004809258C67F2DEF1FFFE6228F7.dip0.t-ipconnect.de) |
| 08:45.30 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:01.25 | *** join/#oe belen (~Adium@134.134.137.71) |
| 09:08.54 | *** join/#oe ecloud (quassel@nat/digia/x-cktvrnfhexahqewn) |
| 09:19.36 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 09:51.36 | *** join/#oe armpit (~akuster@2601:202:4000:1239:d479:c1c3:6c29:187a) |
| 10:22.36 | *** join/#oe dv_ (~quassel@62-178-118-86.cable.dynamic.surfer.at) |
| 10:55.34 | *** join/#oe ecloud (quassel@nat/digia/x-fpkhcutvlzprmkej) |
| 11:31.54 | *** join/#oe ldnunes (~ldnunes_@187.23.154.250) |
| 11:50.31 | *** join/#oe berton (~fabio@187.23.154.250) |
| 12:09.50 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 12:14.09 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 12:24.54 | *** join/#oe vmesons (~rmacleod@128.224.252.2) |
| 12:24.56 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 12:28.09 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 12:47.37 | AndersD | uuuu:q! |
| 13:35.02 | *** join/#oe vdehors_ (~vdehors@193.56.60.161) |
| 14:01.59 | *** join/#oe simosx (~simosx@ubuntu/member/simosx) |
| 14:03.57 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 14:26.12 | *** join/#oe madisox (~madison@12.30.244.5) |
| 14:30.32 | *** join/#oe ntl (~nathanl@cpe-24-242-75-173.austin.res.rr.com) |
| 14:35.24 | *** join/#oe rperier (~quassel@2001:41d0:52:100::44a) |
| 14:37.18 | *** join/#oe ftonello (~felipe@81.145.202.106) |
| 14:44.15 | *** join/#oe joshuagl (joshuagl@nat/intel/x-pohsrbcgytfzlson) |
| 14:51.51 | *** join/#oe ftonello (~felipe@81.145.202.106) |
| 15:01.17 | *** join/#oe belen (~Adium@134.134.139.78) |
| 15:01.33 | *** join/#oe Nilesh__ (uid116340@gateway/web/irccloud.com/x-vkhggqyijgpnntla) |
| 15:02.35 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 15:10.07 | *** join/#oe bpittman (~bill@130.164.62.212) |
| 15:25.20 | *** join/#oe ChrisD1_Away (~ChrisD@2a02:8010:6087:0:230:bdff:feba:a4ac) |
| 15:31.39 | *** join/#oe shagu (~eric@p5B2E8725.dip0.t-ipconnect.de) |
| 15:41.19 | *** join/#oe belen (~Adium@134.134.139.78) |
| 15:46.11 | *** join/#oe bpittman (~bill@130.164.62.212) |
| 15:47.03 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 16:05.38 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 16:11.48 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 16:28.12 | *** join/#oe belen (Adium@nat/intel/x-qakeyxyqrqyyxnfw) |
| 16:44.29 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 16:57.55 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 17:01.01 | *** join/#oe Crofton (~balister@65.158.198.3) |
| 17:06.16 | *** join/#oe paulg (~paulg@128.224.252.2) |
| 17:19.21 | *** join/#oe belen (~Adium@134.134.137.71) |
| 17:27.28 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 17:41.50 | *** join/#oe Jefro (~jefro@50-0-157-200.dsl.static.fusionbroadband.com) |
| 17:47.43 | *** join/#oe dv (~quassel@62-178-118-86.cable.dynamic.surfer.at) |
| 17:49.00 | *** join/#oe ftonello (~felipe@81.145.202.106) |
| 17:51.03 | *** join/#oe ntl (~nathanl@cpe-24-242-75-173.austin.res.rr.com) |
| 17:51.12 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 18:28.03 | *** join/#oe armpit (~akuster@64.2.3.194) |
| 18:45.39 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:52.50 | *** join/#oe hofstee (~jeroen@2001:1c01:c03:1100:f9ff:e2b3:6069:4cb7) |
| 18:58.48 | hofstee | hi, I am wondering if there is a easy way to speed up the build process by reusing the host binaries for the next build (e.g. meta-toolchain and adding a bunch of ASSUME_PROVIDED) |
| 18:59.48 | hofstee | has anyone ever tried something like that? is that feasible? |
| 19:00.42 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 19:00.44 | *** join/#oe josep (~jhunt@c-dac072d5.010-118-73746f7.cust.bredbandsbolaget.se) |
| 19:02.13 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 19:02.39 | rburton | hofstee: host binaries get reused automatically |
| 19:02.40 | rburton | (via sstate) |
| 19:04.09 | hofstee | rburton: yes, I am aware of that, but this is for a build server which start from scratch every time (for different MACHINES / releases) |
| 19:07.41 | rburton | native binaries are shared |
| 19:07.41 | rburton | ie foo-native is always the same, no matter what machine |
| 19:07.49 | kergoth | you dont need to start from scratch, a single sstate dir can be shared just fine between machines, distros, yocto releases, etc |
| 19:08.02 | kergoth | you won't always get 100% reuse, of course, but it's harmless to have a single pool |
| 19:08.32 | hofstee | yeah, but what if recipes forget to add things to sstate? |
| 19:08.39 | kergoth | that doesn't make sense |
| 19:09.04 | kergoth | it's not up to the recipe to do it, the classes take care of it for all recipes |
| 19:09.50 | hofstee | and there is autoconf and friends, which might do things differently depending on seeing a library or not. If those sstate information is not complete, bugs might go unnoticed by the tester.. right? |
| 19:10.05 | rburton | only if you have broken recipes |
| 19:10.19 | rburton | there's quite a lot of testing to make sure that recipes don't behave like that |
| 19:10.56 | rburton | basically, sstate is great at re-use |
| 19:11.04 | kergoth | there are test scripts and package qa to check for precisely that case, autodetected deps |
| 19:11.19 | rburton | especially host stuff which is only rebuilt when your distro changes its release name |
| 19:11.21 | kergoth | the issue with sstate is pretty much never about reusing when it shouldn't |
| 19:11.35 | *** join/#oe paulg (~paulg@128.224.252.2) |
| 19:11.37 | kergoth | it's that it ends up not reusing easily, but that's the safest route, the failure mode is rebuild from scratch, not use something wrong |
| 19:12.16 | kergoth | there's really no reason to start from scratch unless you're doing a release build or something similar that really needs to be paranoid |
| 19:12.21 | kergoth | IMO anyway |
| 19:16.19 | *** join/#oe yann (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 19:18.47 | hofstee | ok thanks, I will test some things with sstate a see if I can fool it... regarding the original question (to simply reuse the host binaries from a bitbaked toolchain)... |
| 19:19.18 | Marex | khem: nice burst of gcc6 upgrades, looking forward to fixing all the nios2 bugs with it ;-) |
| 19:20.21 | hofstee | would there be pitfalls (besides the obvious one, you won't notice if they got accidentally changed (but that is rarely done in my case) |
| 19:21.01 | kergoth | hofstee: probably doable, but you'd definitely be on your own with it, and as you've said there's a certain amount of risk with it. at least using a yocto toolchain rather than a host you know tools like autoconf have the necessary patches, so that'd be less of a concern |
| 19:21.26 | kergoth | at one point i had a little class that injected entries into assume_provided based on what it detected on the host, but only for specific ones where it seemed safe to do so |
| 19:21.31 | kergoth | but with sstate i pretty much set that aside |
| 19:25.30 | hofstee | kergoth: the idea I have is to feed the OE sdk output back in to the next build (for native tools), not the ones of the host, I could have been a bit clearer about that |
| 19:25.36 | kergoth | nods |
| 19:26.02 | kergoth | no, i got that, saying that definitely avoids issues you'd hit if you did go based on host tools |
| 19:26.37 | kergoth | so it does seem like a viable approach, though i question the benefits vs sstate, would be best testing them out and measuring that |
| 19:34.39 | hofstee | is there a way to only use sstate for the native build, and always rebuild for the target? that would basically boil down to the same, with the additional benefit that native changes also gets noticed... |
| 19:36.27 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 20:09.18 | khem | Marex: yeah, you can start even now |
| 20:13.59 | *** join/#oe ant_home (~ant__@host175-222-dynamic.20-79-r.retail.telecomitalia.it) |
| 20:19.21 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:27.10 | Marex | khem: whee |
| 20:46.52 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 20:47.47 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 21:17.23 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 21:23.16 | *** join/#oe moto-timo (ttorling@nat/intel/x-rvyfbmrduruiiowg) |
| 21:23.17 | *** join/#oe moto-timo (ttorling@fsf/member/moto-timo) |
| 21:32.42 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 21:51.22 | *** join/#oe Crofton (~balister@66-87-80-207.pools.spcsdns.net) |
| 21:56.12 | *** join/#oe moto-timo (~ttorling@134.134.139.70) |
| 21:56.12 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 22:37.59 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 22:40.59 | *** join/#oe evanmeagher (~MongooseW@184-23-29-14.dsl.dynamic.fusionbroadband.com) |
| 22:48.24 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 23:15.22 | *** join/#oe boz_v1 (~juukorho@projects.sse.fi) |
| 23:32.31 | *** join/#oe Aethenelle (~Aethenell@166.170.220.117) |
| 23:34.45 | *** join/#oe mario-go` (~user@email.parenteses.org) |