IRC logs for #automotive for Wednesday, 2016-04-20

*** astrophys has quit IRC00:14
*** waltminer has quit IRC00:22
*** bjones has quit IRC00:23
*** Sisco has quit IRC00:35
*** Sisco has joined #automotive00:38
*** waltminer has joined #automotive01:18
*** mdurnev has joined #automotive01:24
*** sanjeev has quit IRC01:33
*** waltminer has quit IRC01:35
*** kooltux_ has quit IRC03:24
*** kooltux_ has joined #automotive03:27
*** Sisco has quit IRC03:29
*** Sisco has joined #automotive03:30
*** rosch has quit IRC04:11
*** warter_ has joined #automotive04:11
*** warter has quit IRC04:12
*** rosch has joined #automotive04:12
*** Sisco has quit IRC05:12
*** Sisco has joined #automotive05:14
*** AlisonChaiken has joined #automotive06:06
*** mps_ has joined #automotive06:17
*** fredcadete has quit IRC07:01
*** mpaolino has joined #automotive07:04
* CTtpollard yawns 07:17
*** leon has joined #automotive07:36
*** leon is now known as Guest2159907:36
*** jobol has joined #automotive07:38
*** jobol has joined #automotive07:40
warter_is there a mailing list for the graphics and UI expert group?08:10
*** warter_ is now known as jbocklage108:10
*** picoblw has joined #automotive08:11
*** bruce_ has joined #automotive08:18
*** picoblw has quit IRC08:22
*** jonathanmaw has joined #automotive08:27
*** fredcadete has joined #automotive08:34
rjekAnd another: http://www.bbc.co.uk/news/business-3608955808:40
paulsherwoodoh dear08:44
paulsherwoodethics matter08:45
*** steve_l has joined #automotive09:01
*** gunnarx has joined #automotive09:01
*** gunnarx has joined #automotive09:01
gunnarxHi09:01
*** weson has joined #automotive09:01
wesonhi all09:02
gunnarxNo lead for the ToolTeam meeting available today?09:02
wesonI was testing the latest GDP today morning. Please see the latest failures.WARNING: Failed to fetch URL svn://anonymous@navit.svn.sourceforge.net/svnroot/navit/trunk;module=navit;protocol=http, attempting MIRRORS if available ERROR: Fetcher failure: Fetch command failed with exit code 1, output: svn: E000111: Unable to connect to a repository at URL 'http://navit.svn.sourceforge.net/svnroot/navit/trunk/navit' svn: E000111: Error r09:03
steve_lgunnarx: see there were some more email on ML. Various ppl can't join09:03
gunnarxtoscalix sent an invite but won't be leading it.  kbirken here?09:03
gunnarxsteve_l, ah09:03
steve_lgunnarx: klaus can't make it09:03
CTtpollardweson: please try to force the package09:04
gunnarxweson, CTtpollard.  Hmm I thought we had switched navit to the git url...09:04
gunnarxforce how, CTtpollard?09:04
wesonCTtpollard: can you share the command?09:04
wesonwih -C -F?09:04
CTtpollardnope navit is still svn09:06
gunnarxOK, concluding that we don't have a formal TT meeting today.  Could have a brief informal discussion if someone has something to report.09:06
CTtpollardbitbake -f -c compile navit09:06
paulsherwoodwell, i could report that the above is a clear example of the mirroring problems i tried to solve last year09:07
steve_lI remember that navit had moved its hosting so the URL redirects, but I guess the recipe was updated for that... If not, possible they moved again and the redirect is broken. Its a while since I downloaded again09:07
gunnarxthat's not a report :)09:08
CTtpollardalthough your error weson could be due to being behind a firewall09:08
paulsherwoodgunnarx: no, it's not, and i'm no longer in the tools team. that doesn't make me wrong09:08
paulsherwood:)09:08
gunnarxno you were never "wrong", just the question was intertwined with many other things09:09
CTtpollardI can't generate the navit fetch error personally, so it is more than likely a network hiccup, or a firewall issue09:09
gunnarxpoint is paulsherwood that we could keep a mirror to avoid the above but it is not a solution for "car companies that want repeatable builds" as you stated09:09
gunnarxbecause car companies have their own mirrors.09:09
gunnarxthey have no reason to trust GENIVI more than any other outside entity....09:10
gunnarxthe recent failure of GENIVI git server shows that09:10
paulsherwoodgunnarx: i'm not going to go around this again :)09:10
gunnarxok09:10
gunnarxwe're in agreement though.  I have no problem with GENIVI keeping mirrors.  First step would be to move navit URL to git though, since it exists09:11
gunnarxMain problem seems to be that everyone keeps fetching the same source code over and over, it's some weird artifact of Yocto build culture09:11
* CTtpollard tries not to do that 09:12
gunnarxCTtpollard is a good Yocto builder09:13
CTtpollardfsvo good :)09:13
gunnarxVery high on my list now is the wish to standardize local mirror on all Go agents.  I know CT does this but it's not everywhere09:14
gunnarxHowever, I have first to finalize migration of Go server.  Very close now.09:14
steve_l+109:14
CTtpollard+109:15
pedroalvarezgunnarx: "standardize local mirror" ? what's that :/09:17
gunnarx:)09:17
gunnarxStating that /srv/dl is the path at which downloads should be stored on all agents,  and subsequently fetched by the pipeline definitions09:18
gunnarxthat's all basically09:18
gunnarxmaybe some other name than /srv/dl can be agreed - anything that is very unlikely to clash with anything existing on any typical system...09:18
rjek/tmp/genivi-dl/09:19
rjekOr something09:19
rjek'dl' is a bit vague09:19
steve_lyou will need to pad that 1 page of content with another 789 pages to call it a standard09:19
gunnarxYes but /tmp is tricky, sometimes it's a limited space etc.09:19
rjek/var/spool/genivi/downloads09:19
gunnarxand it might be wiped.  I think the point is it should be persistent09:20
rjekgunnarx: Which path has unlimited space? :D09:20
gunnarxMy /volumes/ does :)09:20
rjekHave you backed up the internet to it yet? :)09:20
steve_lJust the cat videos09:20
gunnarxif we agree on the path then the recipes themselves could define a mirror variable in the bb recipes.  If it's there it's used, if not it's not09:20
gunnarxSimple.  I put one of those chinese USB sticks there.  When it gets to the end, it loops around.09:21
rjekheh09:21
gunnarx(No offence intended to chinese USB manufacturers that actually work)09:22
CTtpollardgunnarx: we can pre mirror in local.conf for each branch/build09:22
rjekWell, /var/spool or /var/cache strike me as idiomatic09:22
rjek(As defaults)09:22
*** mpaolino has quit IRC09:23
*** mpaolino has joined #automotive09:23
gunnarx/var/cache/gdp_downloads ?09:23
*** jeremiah_ has joined #automotive09:24
jeremiah_ohai!09:24
fredcadeteCTtpollard: why ore mirror over DL_DIR? (http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#var-DL_DIR)09:24
fredcadeteI've been sharing DL_DIR between builds on the same machine and it works fine; I have not tried pre mirror09:24
rjekgunnarx: /var/cache/gdp/downloads perhaps; you never know what else might want caching in future :)09:25
gunnarxbetter09:25
gunnarxyocto/downloads...09:25
CTtpollardfredcadete: dl_dir is also a sane posibilty (I also share dl_dir locally)09:25
gunnarxThat's the question.  DL_DIR is required to exist right?09:26
* jeremiah_ lurks09:26
gunnarxI was thinking MIRROR is used if it is there and if it's not it still works09:26
gunnarx?09:26
fredcadeteI think so. if you pre-mirror it will fetch from your mirror but still put things in a download dir09:26
*** jeremiah_ has quit IRC09:27
fredcadeteI *think*09:27
gunnarxPREMIRRORS is the variable09:27
gunnarxfredcadete, right.  It uses space still but I imagine it's acceptable.09:27
CTtpollarddl_dir defaults to $builddir/downloads09:28
CTtpollardhttp://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-PREMIRRORS09:30
gunnarxOK, so option 1: Setting PREMIRRORS to /var/cache/gdp/yocto/downloads in recipes.   Encouraging agents to provide persistent storage at that location.  That means files are copied from the shared space to downloads for each build but we avoid the network traffic.09:30
CTtpollardpersonally I'd probably vote for mirrors (so it tries to pull from upstream first, less load on the genivi mirror)09:31
gunnarxoption 2.  Setting DL_DIR to /var/cache/gdp/yocto/downloads    It means it must exist and Go Agents that don't provide it will fail.  Downloads will be shared across all GDP builds run on that agent.09:31
fredcadetegunnarx: right, but that space grows. My downloads dir is now at 14G. If you multiply this by all variants, it adds up. You also add the copying from your premirror to downloads.09:31
gunnarxin option 2 the DL dir is shared among all variants so will grow to your 14G something09:33
gunnarxin option 1 you manually need to fill the content of the PREMIRROR location though09:33
gunnarx+ as you say you will get duplicates for each pipeline.  However this is already the case today and the source big but not the biggest part - all the build artifacts are IIRC09:34
fredcadeteto save fetching and disk space on the same agent -> DL_DIR.  to have a single GDP mirror that will maybe be more reliable than upstream fetches -> PRE_MIRROR09:34
fredcadeteto save fetching and disk space on the same agent -> DL_DIR.  to have a single GDP mirror that will maybe be more reliable than upstream fetches -> PRE_MIRROR09:35
CTtpollardare you wanting to have the pre_mirror openly available and set by default?09:35
gunnarxfredcadete, yes.  I'd say option two also also saves fetching (over network) though, it copies locally since we're talking about a local mirror.09:36
gunnarxfredcadete, maybe not clear I'm not talking about the reliability problem primarily actually09:36
fredcadeteyes09:36
gunnarxMy first point was to reduce network traffic and speed up builds09:37
fredcadeteoh, ok09:37
gunnarxbut reliability might be a good offshoot09:37
fredcadetefor that use case DL_DIR has been working fine for me09:37
gunnarxBut are you running a Go Agent?  (just putting it in context)09:37
gunnarxAs we said above both are possible for Go Agent09:38
fredcadeteno, sorry :)09:38
fredcadeteno, sorry :)09:39
gunnarxChecked a current GDP build on real silicon - 4GB DL DIR, QEMU is around 3.09:39
gunnarxSo I imageine 14G is if you let it accumulate over many versions and variants...09:39
fredcadetejust many builds for troubleshooting: vanilla poky, yocto build as recommended by the silicon provider, a GDP build, variants of our internal distro09:39
gunnarxSo we should expect 4*(number of variants) or 14.  Not 14*(number of variants) necessarily...09:40
fredcadeteyes it is accumulated09:40
gunnarxfredcadete, good point and I realized it may be good to avoid specializing the cache path too much09:40
gunnarxmany may want to build different systems that are similar09:40
fredcadetealso over a year or so, so it has caught two poky upgrades and for many packages there are a couple of versions09:40
fredcadeteyou may want to consider this too :/09:40
gunnarxat the same time I'd like to be able to roll it out directly in the configs without clashing with something09:41
fredcadeteyou mean clashing with things people may have in their local.conf?09:42
gunnarxno just choosing a path that isn't used already09:43
*** Sisco has quit IRC09:43
gunnarxthose that have the need to edit their conf manually will sort it out.  but for GDP I'm eager it works out of the box with no manual fiddling09:43
gunnarxand the third aspect is that it should build successfully on any Go Agent.09:43
pedroalvarezI asked in #yocto a while back about this, and some people with CI setups were using DL and SSTATE  dirs to share all the things that were possible09:43
pedroalvarezand every weekend cleaning everything from them09:44
gunnarxI still don't trust sstate sharing09:44
fredcadetepedroalvarez: yes, SSTATE also speeds up a lot, I discovered that recently though so I don't have it set up09:44
gunnarxsorry, in theory I guess it's supposed to be OK but I've seen too much weirdness09:44
gunnarxAt least I can confirm that an interrupted yocto build can end up being unbuildable until you wipe state and other things.09:45
gunnarxThat said, for basic CI I might be OK with it.09:45
gunnarxIf it works it works.  If it fails, we'll know.  CI is not about product quality (yet) :)09:46
pedroalvarezgunnarx: that was one of the reasons they had to clean up sstate sometimes09:46
gunnarxok09:46
CTtpollardwe've had to kill the sstate on the codethink agents before due to sharing weirdness09:46
pedroalvarezhm.. I wonder if it's possible to run a job in all the agents to syncronise the cleanup every weekend09:46
jeremiahShave that yak!09:47
pedroalvarezyeah.. better use baserock :P09:47
gunnarx:)09:47
jeremiahCan we run baserock on a Go.CD instance?09:48
gunnarxpedroalvarez, there's no separation between pipelines AFAIK.  We can have a manually triggered pipeline that deletes stuff on the agent.09:48
gunnarxSet each agent up with its own resource and there can be one job per agent.  Not very pretty but it should be quite OK.09:49
gunnarxs/job/pipeline/g09:49
gunnarxs@s/job/pipeline/g@s/job/pipeline/@  :)09:49
pedroalvarezit could be less ugly if we can make it run automatically09:50
pedroalvarezjeremiah: it should be possible yes09:50
gunnarxyes but that also means installing that solution on all agents, which makes them specialized.  I think simplicity there is quite important.09:50
pedroalvarezgunnarx: nope, I was just suggesting that gocd could run the job for us, instead of having to click a button of the manually triggered pipeline09:52
gunnarxpedroalvarez, forget what I said.  You could set them up as pipelines, not cron-jobs on agents.   You can time-trigger pipelines.09:52
gunnarxYou got it09:52
pedroalvarezppeeeeeeeerfect09:52
steve_loff to work. but my 2c on above. maybe avoid sstate sharing across pipelines as first step - as others note it can be cause of issues when mixing machines.10:10
steve_lpremirror would be useful to many people outside of go.cd. shared downloads folder on go is obvious first step.10:12
CTtpollardafter the genivi git woes, having a central premirror scares me, I think a normal mirror (checked after upstream) is safer and probably faster10:13
paulsherwoodwhat is a 'normal mirror' ?10:13
CTtpollardpaulsherwood: bitbake checks dl_dir - pre mirror - upstream - mirror10:14
CTtpollardso if we move to pre_mirror default everything, it needs to be robust and stable10:15
steve_lthat's one nice thing about yocto premirror entirely optional. If I drop it from my local.conf it just goes to the upstream. If the premirror isnt working it will also go to upstream. but yes your right. should look at the needs and decide what is best.10:16
steve_llow hanging fruit is shared DL folder :)10:16
CTtpollardand controlled by genivi, so we don't have to go through layers of loops to get things fixed :)10:17
*** steve_l has quit IRC10:18
wesonCTtpollard: sorry, I missed the updates. What is the reason behind the navit failure on latest GDp for rasp?10:22
CTtpollardweson: I believe it was either a network hiccup (why I asked you to try and force the recipe) or your firewall does not like it10:24
CTtpollardas gunnarx suggested, we should move the recipe to a git source, if you wish to add that to a jira ticket :)10:24
CTtpollardor send a patch ofc10:25
gunnarxYes,   https://github.com/navit-gps/navit.git  as the source location10:28
gunnarx^^ is the official source location according to home page, I meant to say10:28
CTtpollardgreat10:29
wesonok, so what is the temporary workaround to pass the build?10:30
CTtpollardweson: have you tried pulling from the svn link manually on your system?10:31
wesonCTtpollard: let me check it.. Please hold10:32
wesonunable to connect, connection refused.10:43
wesonsvn co <svn://link to navit>10:43
CTtpollardsounds like it's your firewall then10:43
CTtpollardor the svn server not liking your IP10:43
wesonok, then I will try from home :)10:45
CTtpollardweson: for now you could use an append, or manually edit the recipe to pull from the git repo10:46
wesonCTtpollard: git address please10:47
CTtpollardhttps://github.com/navit-gps/navit.git10:47
wesonok, where I need to change?10:47
CTtpollardnavit_svn.bb, you'll probably have to find the corresponding commit, or w/e term svn call it10:49
wesonI will check this file in the GDP folder and will change the link to take it from git instead of svn10:50
wesonThank you.10:50
wesonbrb10:50
*** weson has quit IRC11:58
*** gunnarx has quit IRC12:05
*** CTtpollard has quit IRC12:16
*** CTtpollard has joined #automotive12:19
*** waltminer has joined #automotive13:10
*** hammer_gaidin has quit IRC13:19
*** mvick has quit IRC13:19
*** mdurnev has quit IRC13:50
*** Sisco has joined #automotive13:52
*** CTtpollard has quit IRC14:02
*** CTtpollard has joined #automotive14:16
andrunkohi, I've created SPEC-172 on jira to add support for some genivi components to agl - if someone could please take a look and let me know what I should do next to push the changes I'd appreciate, tnx14:31
*** jobol has quit IRC14:42
*** Sisco has quit IRC14:44
*** tjamison has joined #automotive14:45
*** astrophys has joined #automotive14:49
*** Sisco has joined #automotive14:54
CTtpollardWeekly GDP call is about to start14:59
*** gunnarx has joined #automotive15:01
*** gunnarx has joined #automotive15:01
*** Sisco has quit IRC15:02
CTtpollardCan anybody here us in the call?15:05
CTtpollardgunnarx ^15:05
gunnarxYes I hear you15:05
CTtpollardhmm, will try a different device15:05
CTtpollardbrb15:05
CTtpollardI heard you join15:06
CTtpollardodd15:06
*** smiller6 has joined #automotive15:06
gunnarxnp, we will wait :)15:06
*** amcgee7 has joined #automotive15:07
*** mvick has joined #automotive15:08
gunnarxWe're speaking15:12
gunnarxYou're not hearing us CTtpollard15:12
waltminermy wife says that to me a lot15:13
gunnarxweird... you have audio only in one direction gunnarx15:13
gunnarxwaltminer, do you use Webex to communicate with your better half?15:13
gunnarxI hope not :)15:13
gunnarxCTtpollard, we can hear you fine but you don't hear us15:14
CTtpollardit looks like we're having problem then15:14
gunnarxyes15:14
CTtpollardwill try and reconnect one more time15:14
gunnarxIt's like we're in two separate calls with a one-way bridge :)15:14
gunnarxCan you hear us??15:14
gunnarxoh no :(15:15
gunnarxTry the volume control15:15
*** jbocklage1 has quit IRC15:24
*** warter has joined #automotive15:25
CTtpollardthanks everyone15:48
CTtpollardand for baring with the technical difficulties15:48
*** bruce_ has quit IRC15:51
CTtpollardleon-anavi-cloud: are you going to the AMM?15:54
*** Sisco has joined #automotive15:59
*** gan has joined #automotive16:00
*** gan has joined #automotive16:00
*** gunnarx has quit IRC16:01
*** Guest21599 is now known as leon-anavi16:02
*** AlisonChaiken has quit IRC16:08
leon-anaviCTtpollard, yes, I will arrive on Monday (25 april) and I will go back home on 28 April.16:08
leon-anaviCTtpollard, so I will be there for the meetings & sessions on 26-27 April.16:09
*** waltminer has quit IRC16:12
*** leon-anavi has quit IRC16:16
*** gan has quit IRC16:18
*** fredcadete has quit IRC16:20
*** jonathanmaw has quit IRC16:33
*** mpaolino has quit IRC16:35
*** bjones has joined #automotive16:55
*** tjamison has quit IRC17:06
*** tjamison has joined #automotive17:06
*** waltminer has joined #automotive17:17
*** fury- has joined #automotive17:44
*** fury has quit IRC17:44
*** fury- is now known as fury17:44
*** praneeth_ has quit IRC17:59
*** praneeth_ has joined #automotive17:59
*** gan has joined #automotive18:32
*** gan has quit IRC18:45
*** bjones has quit IRC18:49
*** gan has joined #automotive19:08
*** smiller6 has quit IRC20:12
*** gan has quit IRC20:25
*** mps_ has quit IRC20:56
*** waltminer has quit IRC21:26
*** waltminer has joined #automotive22:16
*** Sisco has quit IRC23:21
*** amcgee7 has quit IRC23:27
*** waltminer has quit IRC23:37

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!