*** FelixH has quit IRC | 00:17 | |
*** FelixH has joined #automotive | 00:17 | |
*** albanc has quit IRC | 00:17 | |
*** albanc has joined #automotive | 00:20 | |
*** Tarnyko has quit IRC | 00:27 | |
*** IOBN has quit IRC | 01:29 | |
*** IOBN has joined #automotive | 01:31 | |
*** AlisonChaiken has joined #automotive | 03:34 | |
*** jobol has joined #automotive | 06:59 | |
*** leon-anavi has joined #automotive | 07:03 | |
leon-anavi | morning | 07:03 |
---|---|---|
*** fredcadete has joined #automotive | 07:05 | |
*** CTtpollard has quit IRC | 07:10 | |
*** rajm has joined #automotive | 07:10 | |
*** CTtpollard has joined #automotive | 07:13 | |
*** shout-user18 has joined #automotive | 07:31 | |
*** shout-user18 has left #automotive | 07:31 | |
*** Tarnyko has joined #automotive | 07:38 | |
*** kooltux_ has joined #automotive | 07:50 | |
CTtpollard | morning all | 07:52 |
fredcadete | good morning | 08:09 |
*** kooltux_ has quit IRC | 08:15 | |
*** toscalix has joined #automotive | 08:16 | |
*** rajm has quit IRC | 08:20 | |
*** rajm has joined #automotive | 08:21 | |
Tarnyko | morning | 08:32 |
*** jonathanmaw has joined #automotive | 08:34 | |
toscalix | morning | 08:49 |
*** sanjeev has quit IRC | 08:56 | |
jbocklage2 | german, but mabye you get the point: http://www.heise.de/developer/meldung/Qt-will-mit-einer-eigenen-Suite-ins-Auto-3233599.html?wt_mc=rss.developer.beitrag.atom | 09:09 |
jbocklage2 | it mentions AGL: http://www.heise.de/developer/meldung/Qt-will-mit-einer-eigenen-Suite-ins-Auto-3233599.html?view=zoom;zoom=1 | 09:11 |
toscalix | by twiter I asked yesterday the Qt company if they see AGL and GENIVI only as middleware | 09:31 |
toscalix | they did not answer. I will ask formally | 09:31 |
toscalix | but the block diagram is misleading, in my opinion | 09:31 |
toscalix | specially in the case of AGL | 09:32 |
toscalix | well, in both cases | 09:32 |
Tarnyko | toscalix: interesting diagram, thanks | 09:38 |
Tarnyko | toscalix: I suppose their automotive parts are the red ones ; it consists mostly in an Application Framework and its backends (plugins ?) apparently | 09:39 |
rjek | All block diagrams have to be simplified in order to fit onto one page/slide, and that simplification causes them to become outright lies. | 09:40 |
rjek | If things were actually that simple we'd all be much happier, though | 09:40 |
Figure | toscalix: if you look it from the ui perspective only then yes GENIVI and AGL are mostly visible as middleware | 09:50 |
Figure | maybe middleware is not the right wording | 09:50 |
Figure | but in a sense app developers would be using Qt API's that transfer/translate information to GENIVI middleware | 09:51 |
Figure | toscalix: in our vision Application Manager replaces weston completely and removes the need for over complex buffer transfer in current layer management | 09:53 |
Figure | that's my 2 cents | 09:53 |
CTtpollard | Figure: what vision is that out of interest? | 09:55 |
toscalix | Figure: is that similar to the approach with QNX? | 09:55 |
Figure | CTtpollard: Application Manager would implement QtCompositor API and be responsible of controlling the wayland layers. | 09:57 |
Figure | toscalix: QNX is a bit difference since we can't use directly the QtCompositor API. In QNX we need to play around with the QNX screen that should be able to do same things as wayland | 09:58 |
toscalix | Figure: got it | 09:59 |
Figure | CTtpollard: the compositor codes are available @ http://code.qt.io/cgit/qt-apps/neptune-ui.git/ | 10:01 |
CTtpollard | Figure: cool, will take a look | 10:03 |
Figure | also all the other parts are open as well | 10:03 |
Figure | http://code.qt.io/cgit/ | 10:04 |
toscalix | Figure: good stuff | 10:13 |
toscalix | Will be a talk about it at QtCon ? | 10:13 |
Figure | toscalix: not sure I haven't followed who from our side goes to QtCon | 10:20 |
Figure | I've been busy optimizing boot time :) | 10:20 |
Figure | current number is 1.266ms cold boot to our cluster demo | 10:20 |
Figure | initial was 1.560 http://blog.qt.io/blog/2016/04/20/fast-booting-qt-devices-part-1-automotive-instrument-cluster/ | 10:21 |
fredcadete | Figure: could you detail how an compositor that doubles as application manager would simplify buffer *transfer* ? | 10:25 |
fredcadete | I understand how it would simplify management of buffer display | 10:26 |
fredcadete | but qtwayland still uses the wayland API, wayland_egl and stuff between the applications and the compositor | 10:26 |
fredcadete | or not, please correct me if I am wrong | 10:27 |
*** mdurnev has joined #automotive | 10:34 | |
Figure | fredcadete: your are correct. It simplifies tha managet of buffer displays not the transfer it self | 10:37 |
Figure | fredcadete: also it allows that if end user want's they can also implement first class application that would run inside the application manager | 10:37 |
Figure | fredcadete: those would have direct access to the gpu so no wayland over head at all | 10:37 |
Figure | of course this comes with the cost that you really need to trust those applications. since if they crash then crashes the compositor also | 10:38 |
fredcadete | ok thanks | 10:39 |
Figure | fredcadete: also with the qtcompositor api you can easly run shader programs over wayland surfaces so for example blurring application behind when popup comes would be really easy | 10:39 |
fredcadete | yes, that's the kind of things that are much much easier to do directly in the compositor | 10:40 |
Figure | same of course applies to animations etc since in the end it's just a qml engine also running so I would imagine that having custom transformation for wayland buffers would be nice way to animate opening and closing of the application | 10:40 |
fredcadete | I don't mean to nitpick much more (sorry...), but wayland applications outside the compositor do have direct access to the GPU, just not to the display | 10:41 |
fredcadete | animations and resize are very tricky with an external layer manager, I have white hairs that prove it | 10:41 |
Figure | fredcadete: well it's good to correct if some one else is reading this also. Anyhow that's completely true. | 10:42 |
fredcadete | great :) | 10:42 |
fredcadete | I can also say from my experience that having rich UI effects in the compositor with a framework familiar to HMI developers probably makes it easier to transition from a monolithic application to separate components | 10:43 |
*** gunnarx has joined #automotive | 10:44 | |
gunnarx | Hi | 10:44 |
fredcadete | resizing/overlay animations are always what HMI developers ask for when you propose composited components | 10:44 |
gunnarx | HMI developers... | 10:46 |
Figure | Hi | 10:46 |
gunnarx | I better not finish that thought :-) | 10:46 |
gunnarx | fredcadete, On recent Volvo systems the ask is more like: Zoom this out by 12%, blur it and keep it in the background, split this item in two and let it fly in from z axis, and display everything on top of each other at 60fps. :-P | 10:48 |
Figure | gunnarx: exactly where QtCompositor api comes handy :P | 10:49 |
gunnarx | Yes, I am not disputing that. | 10:49 |
Figure | gunnarx: that was something we were discussing before you joined | 10:50 |
gunnarx | Got it | 10:50 |
gunnarx | At least what can be seen in production now got some of it. It's acceptable but we can do even better soon. Obviously can't go into any more details. | 10:50 |
gunnarx | CTtpollard, where are we with Go stuff. Did we have some more things to sort out or any news since yesterday? | 10:51 |
gunnarx | and pedroalvarez if you're there... | 10:51 |
pedroalvarez | things seems to be working so far | 10:52 |
CTtpollard | gunnarx: just sent a simple PR to g-d-p.git to test those 4 pipelines, one has failed due to a non related issue but it is reporting | 10:52 |
CTtpollard | https://github.com/GENIVI/genivi-dev-platform/pull/17 | 10:52 |
*** rosch has quit IRC | 10:53 | |
gunnarx | Good. I'm thinking about some minor tweaks. Grouping of pipelines. GDP_Maintenance - how about calling it something with Pull_Request_Testing (so it's more obvious why these may be failing once in a while) | 10:53 |
pedroalvarez | +1 | 10:53 |
gunnarx | Mind if I restructure a bit (I usually just do it :-) | 10:53 |
*** rosch has joined #automotive | 10:54 | |
pedroalvarez | I don't mind, please go ahead | 10:54 |
gunnarx | don't want to step on the revered GDP maintenance team's delicate toes. | 10:54 |
* CTtpollard puts on steel-toecap boots | 10:54 | |
gunnarx | awesome | 10:56 |
CTtpollard | sure go ahead | 10:56 |
CTtpollard | leon-anavi: have you ever had meta-rust fail to fetch a snapshot in rustc-1.7.0? | 10:57 |
leon-anavi | CTtpollard, hm, no but I haven't recently tried it out. | 10:59 |
leon-anavi | Do you have such a problem? | 10:59 |
CTtpollard | 'curl: (77) error setting certificate verify locations' | 10:59 |
CTtpollard | one moment | 11:00 |
CTtpollard | leon-anavi: http://paste.baserock.org/kowiticofu | 11:00 |
CTtpollard | on of our pipelines failed with that | 11:00 |
leon-anavi | hm... | 11:04 |
leon-anavi | is any of the other pipelines having the same issue? | 11:04 |
CTtpollard | the other target pipelines building the same PR have not failed yet, although qemu is the only one so far too finish | 11:05 |
CTtpollard | will keep an eye out | 11:05 |
leon-anavi | ok | 11:05 |
leon-anavi | ping me when you have results | 11:05 |
gunnarx | Anyone familiar with "my-genivigo-testagent" that has popped up? | 11:07 |
CTtpollard | nope | 11:08 |
jbocklage2 | (just for completeness: https://blog.qt.io/blog/2016/06/08/announcing-the-qt-automotive-suite/ ) | 11:14 |
gunnarx | I feel like it is "announced" over and over again. ;-) | 11:49 |
*** IOBN has quit IRC | 11:55 | |
Figure | gunnarx: now the source code is actually available :) | 12:00 |
gunnarx | Ah yes, I could see it was (new) implementation that was the news here | 12:02 |
gunnarx | Although v1.0 planned to be tagged end of the month it seems | 12:02 |
*** praneeth has quit IRC | 12:06 | |
*** praneeth has joined #automotive | 12:07 | |
gunnarx | pedroalvarez, CTtpollard you might want to study the pipeline group: Administration_for_codethink-genivigo-agent1-x86 and the wipe-temp-dir job . For the others I have set it to run on a timer once a week. I didn't want to force it onto your agent unless you think it's a good idea. | 13:19 |
pedroalvarez | I think it's a good idea, will look into it | 13:20 |
CTtpollard | not sure if I have access to be able to view that | 13:20 |
gunnarx | The Parameters tab on the pipeline is important. | 13:21 |
gunnarx | CTtpollard, do you see the pipeline group? the pipeline? | 13:23 |
CTtpollard | I can see the pipelines, but I get a different view of the xml compared to pedroalvarez | 13:23 |
gunnarx | CTtpollard, can you access any templates at all? | 13:23 |
CTtpollard | and I have no options to modify anything on the agent tab | 13:23 |
CTtpollard | yes I can access the templates, but not in xml form | 13:24 |
gunnarx | well that's by design ;) | 13:24 |
gunnarx | No only pedroalvarez is l33t enough. | 13:24 |
pedroalvarez | muahah | 13:24 |
gunnarx | You want to edit XML CTtpollard? I can make it happen. But it's a masochistic behavior. | 13:25 |
gunnarx | Only admin can use the backdoor of hacking the XML directly, I guess it makes some sense - it is quite easy to wipe out the whole configuration in one go. | 13:27 |
pedroalvarez | gunnarx: btw, I've seen some sort of backup in github of the XML | 13:34 |
CTtpollard | gunnarx: I'm ok to not have this responsibility for now | 13:35 |
gunnarx | pedroalvarez, that is correct. It is backed up once an hour IIRC | 13:36 |
pedroalvarez | cool | 13:36 |
gunnarx | just a feature I added when I first installed Go | 13:37 |
gunnarx | pretty useful. | 13:37 |
pedroalvarez | gunnarx: regarding "wipe_dir_pattern" template, it has hardcoded some /var/lib/.. paths | 13:37 |
gunnarx | oh | 13:37 |
pedroalvarez | but anyway it can run in our server anyway | 13:37 |
gunnarx | ah yes I guess it has hard coded the standard installation path of go-agent, yes | 13:37 |
gunnarx | Go internally puts the config in git so it was just a matter of adding an ssh key to a github account and a cron job that does git push. | 13:38 |
gunnarx | The git history is a useful audit log if required so it makes it more secure also. | 13:39 |
pedroalvarez | gunnarx: I was actually pondering cleaning all of /var/lib/go-agent/pipelines/ | 13:49 |
gunnarx | Sure if you wish. Generally I think downloads should remain. | 13:50 |
gunnarx | We should align on whether to reuse DL_DIR or use PREMIRRORS | 13:50 |
gunnarx | Some part of me felt it safer to copy to a fresh DL_DIR but from a local mirror. I'm not sure it matters but that's what I thought | 13:50 |
gunnarx | At least it's a local file copy rather than using bandwidth | 13:50 |
gunnarx | I think this is repetition, but I've settled on /var/cache/yocto/downloads as my preferred path | 13:51 |
pedroalvarez | that would be for DL_DIR, right? | 13:52 |
gunnarx | damn there is a "gunnarx2" in github. | 13:53 |
pedroalvarez | haha | 13:53 |
* gunnarx 'gonna have to go Highlander on him | 13:55 | |
gunnarx | pedroalvarez, yes either DL_DIR or local mirror. It can be both I suppose. | 14:01 |
pedroalvarez | I'm ok for enabling /var/cache/yocto/download instead of /srv/go/dl in our pipelines | 14:05 |
pedroalvarez | "ct_test" resource has to die :) | 14:06 |
gunnarx | +1 | 14:18 |
CTtpollard | I think building each target for every commit to g-d-p also has to die, in terms of that being the trigger | 14:18 |
gunnarx | unless we can very heavily optimize the build? | 14:19 |
gunnarx | I'd like to see reliable incremental builds on those quick checks | 14:19 |
gunnarx | with reused sstate etc. | 14:19 |
*** mdurnev has quit IRC | 14:20 | |
CTtpollard | I'd want to switch to time based polling in those pipelines, at least until we have more agent bandwith | 14:20 |
gunnarx | sure, we can do that | 14:21 |
gunnarx | it's a good idea | 14:21 |
CTtpollard | but they do still server a purpose, just because a PR pipeline built fine doesn't mean it will once it is merged | 14:22 |
*** AlisonChaiken has quit IRC | 14:22 | |
CTtpollard | e.g other PR's could be merged during that time window, which just so happen to break the PR that at the time built ok | 14:22 |
gunnarx | yes | 14:23 |
CTtpollard | but still, building per 24h would catch such small chances | 14:23 |
gunnarx | sounds good to me. With the timer setup in cron format it can be spaced over time | 14:35 |
gunnarx | So which one should be triggered first is the question :) | 14:36 |
CTtpollard | qemu | 14:39 |
*** oscaletta has joined #automotive | 14:42 | |
CTtpollard | if that daily is broke, then we're doomed | 14:43 |
fredcadete | I have been reusing sstate for my development builds and it has been going well | 14:43 |
fredcadete | I did have issues with some things like for example Renesas kernel modules, so I hesitate to use it on CI | 14:44 |
fredcadete | reusing sstate on CI should work as long as the build does not involve rebuilding the kernel modules | 14:45 |
CTtpollard | I've had problems with unpacking navit from sstate before across different builds | 14:45 |
fredcadete | that will have worse effects than the kernel module, because I imagine navit is nearer the tips of the dependency tree and is rebuilt more often | 14:46 |
fredcadete | anyway, it should be a matter of analyzing the offending recipes and go Yocto IRC help on them | 14:47 |
fredcadete | maybe manually correcting the sstate directories for those packages : http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#shared-state | 14:48 |
fredcadete | such a simple and fun thing to do that I have spent about 2 months thinking of it and never started it | 14:49 |
CTtpollard | fredcadete: friday afternoon sounds the perfect time to start then! | 14:49 |
fredcadete | it's also a great prank for a newbie in the team | 14:50 |
fredcadete | "easy starter task, just make this sstate thing work. report back this afternoon" | 14:51 |
fredcadete | the last rookie here was unfortunately too good to try this, he would have caught on to it | 14:52 |
gunnarx | aaaah, great rookie task :) | 14:55 |
gunnarx | sstate looks like some black art magic for sure... | 14:56 |
gunnarx | not that I have looked into it. | 14:56 |
*** CTtpollard has quit IRC | 14:57 | |
gunnarx | When I've been really upset with Yocto, I have however considered a loop that builds one package, commits the entire build state to git, build one more package, commit to git, and so on...! | 14:57 |
gunnarx | But that would probably make the whole build totally predictable and turn Yocto into Baserock... so that can't be right ;-) | 15:00 |
*** CTtpollard has joined #automotive | 15:01 | |
*** rajm has quit IRC | 15:01 | |
*** oscaletta has quit IRC | 15:05 | |
*** Tarnyko has quit IRC | 15:06 | |
*** rajm has joined #automotive | 15:13 | |
*** AlisonChaiken has joined #automotive | 15:15 | |
*** mvick has quit IRC | 15:17 | |
*** mvick has joined #automotive | 15:19 | |
toscalix | gunnarx: all CTs are in a meeting...otherwise they would have jumped like popcorn | 15:33 |
gunnarx | :) | 15:33 |
*** CTtpollard has quit IRC | 15:36 | |
*** rajm has quit IRC | 15:37 | |
*** rajm has joined #automotive | 15:37 | |
*** jonathanmaw has quit IRC | 15:49 | |
*** gunnarx has quit IRC | 15:52 | |
*** toscalix has quit IRC | 16:11 | |
*** jonathanmaw has joined #automotive | 16:12 | |
pedroalvarez | hahah | 16:14 |
pedroalvarez | believe me, baserock is not about pushing binaries to git to get reproducible builds :) | 16:15 |
*** rajm has quit IRC | 16:15 | |
*** fredcadete has quit IRC | 16:16 | |
*** nisha has quit IRC | 16:21 | |
*** nisha has joined #automotive | 16:26 | |
*** leon-anavi has quit IRC | 16:28 | |
*** jlrmagnus has quit IRC | 16:46 | |
*** jobol has quit IRC | 16:52 | |
*** jonathanmaw has quit IRC | 16:54 | |
*** Tarnyko has joined #automotive | 17:39 | |
*** jlrmagnus has joined #automotive | 17:50 | |
*** chbae has joined #automotive | 18:33 | |
*** chbae has quit IRC | 19:06 | |
*** jlrmagnus has quit IRC | 19:07 | |
*** clopez_ is now known as clopez | 20:06 | |
*** AlisonChaiken has quit IRC | 21:46 | |
*** AlisonChaiken has joined #automotive | 21:49 | |
*** mvick has quit IRC | 23:11 | |
*** e8johan has quit IRC | 23:48 | |
*** AlisonChaiken has quit IRC | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!