IRC logs for #automotive for Monday, 2015-09-07

*** waltminer has quit IRC00:58
*** waltminer has joined #automotive01:06
*** waltminer has joined #automotive01:40
*** waltminer has left #automotive01:41
*** persia_ has joined #automotive02:10
*** paulsher1ood has joined #automotive02:10
*** paulsherwood has quit IRC02:15
*** persia has quit IRC02:15
*** Luming has quit IRC02:41
*** Luming has joined #automotive02:46
*** wto has quit IRC02:57
*** felipealmeida has quit IRC03:00
*** wto has joined #automotive03:02
*** mpaolino has joined #automotive06:18
*** jacobo has joined #automotive08:00
*** toscalix__ has joined #automotive08:09
*** CTtpollard has joined #automotive08:54
CTtpollardawesome, meta-ivi maintainer has cherry picked the common api fix onto the 7.0 branch, should be able to remove the append in genivi-demo now09:01
jeremiahI saw that, good news. :-)09:09
CTtpollardI'll get a build going asap, and then pushes09:10
jeremiahOr w00t even09:12
CTtpollardI don't have persistence over the weekend here, did you see the chat about gitolite admin on genivi project?09:21
jeremiahCTtpollard: I guess I missed that.09:22
jeremiahHmm, I'll check the archives.09:22
CTtpollardfrom about 14:24 on friday on my timezone09:23
jeremiahIs it in that list?09:24
jeremiahCTtpollard: Or do you mean in #automotive?09:25
CTtpollardjeremiah: sorry I mean on here09:25
jeremiahCTtpollard: I think I found it, it was for me to do a set-head no?09:26
jeremiahI'll do that, thanks09:26
CTtpollardyes that's the one jeremiah :)09:26
jeremiahOkay, let me see if I can do this, I'm not certain I have shell access to the git repos.09:29
jeremiahI do have access to a machine at LF so I'll see if I can find the repos there.09:29
CTtpollardyou should be able to ssh in as the git user09:30
*** wschaller has joined #automotive09:31
*** Egy has joined #automotive09:37
*** Egy has quit IRC09:40
*** Egy has joined #automotive09:40
*** rZr is now known as RzR09:59
CTtpollardbuilding with latest ivi patch on 7.0 and removal of append on meta-genivi-demo10:12
*** Egy has quit IRC10:18
*** Egy has joined #automotive10:19
CTtpollardshould I be able to ssh into a qemu genivi-demo instance as root?10:39
jeremiahCTtpollard: That would be very interesting to know. :-)10:39
jeremiahIt should be root:root10:39
CTtpollardyeh that's what I presumed, I'll have to look at how I'm routing  / port forwarding10:40
*** wschaller has quit IRC10:41
CTtpollardhmm port-forwarding from my host to 22 on the vm gives me connection refused on ssh as root10:45
radiofreehow is your qemu network setup? libvirt?10:45
radiofreeyou can see if it's actually there by pinging the broadcast address10:45
radiofree`-b -c 3 -i 10` or some such10:46
*** Egy has quit IRC10:49
*** Egy1 has joined #automotive10:49
jeremiahI'm pretty sure I don't have shell access to the machine hosting gitolite.11:00
jeremiahYou have to configure ssh as well as gitolite and I don't believe that's configured to permit logins11:00
CTtpollardjeremiah: what does ssh help give you11:00
jeremiahThis error message seems to support my understanding:11:01
jeremiah PTY allocation request failed on channel 011:01
jeremiahCTtpollard: I have the same list of repo commands as you do when I query help11:02
jeremiahdesc, help, info, perms, writable11:02
jeremiahI hope gitolite doesn't allow shell access to the git user out of the box, that's a wee bit scary11:02
jeremiahI logged onto the shell I have access to but I don't think there are any git repos there I have access to.11:03
jeremiahI'll have to send a request to LF helpdesk11:03
jeremiahI just created a new build for GDP, not much really, just adding meta-perl to get some testing goodness via TAP11:09
jeremiahBut I noticed that when I use tar to copy over the file system, there is a link there to the kernel11:09
jeremiahin /boto/11:10
jeremiahSorry, in /boot/11:10
jeremiahIs that useable? I'm gonna check. =)11:10
jeremiahYep. Works for me11:12
CTtpollardfor koelsch I manually add the uboot kernel to boot11:12
CTtpollardjeremiah: have you ever had a problem writing creating the SD filesystem for koelsh / porter, I'm trying to diagnose it now because it is somewhat of a hindrance11:23
*** wschaller has joined #automotive11:27
*** Egy1 has quit IRC11:44
*** Egy has joined #automotive11:44
*** wschaller has quit IRC11:45
CTtpollardI'm going to boot a live disk to see if it's an issue with my OS / kernel11:49
*** Egy has quit IRC11:56
CTtpollardI'm currently getting 'ssh_exchange_identification: read: Connection reset by peer' when trying to ssh into the qemu-kvm12:14
*** jacobo has quit IRC12:33
paulsher1oodGENIVI Tools Team meeting will start here in approx 20 minutes' time12:39
CTtpollardpaulsher1ood: are you in USA?12:40
paulsher1ooddraft agenda is
* paulsher1ood will be meeting on an empty stomach12:42
jeremiahCTtpollard: I've only done it a couple of times and not really had any hiccups.12:49
jeremiahAlthough I usually have issues, SD card writing is fussy, at least for me12:50
radiofreeCTtpollard: is "PermitRootLogin yes" enabled in /etc/ssh/sshd_config ?12:51
jeremiahradiofree: If I remember correctly that is on in the Porter config12:52
radiofreealso what does ifconfig in the guest tell you12:52
*** wschaller has joined #automotive12:52
CTtpollardone min radiofree12:52
CTtpollardgah it's playing up, will get back to you when I can get to a console12:58
paulsher1ood== GENIVI Tools Team Starts ==13:00
*** philrob has joined #automotive13:00
paulsher1oodanone here? :)13:00
philrobhi there !13:00
paulsher1oodhi philrob13:00
paulsher1oodthis time i managed to post an agenda... which begins by reviewing the charterr (
paulsher1oodthe main reason i  added this was i wanted to be sure we're workign on the right things13:02
paulsher1oodafaik we've had (almost) no discussion on somoe of the tools mentioned there13:02
paulsher1oodi wanted to check if we need to modify either the charter, or our work or both?13:03
paulsher1oodphilrob: do you have any view on this?13:03
philrobnot at this point13:04
paulsher1oodif others have no comments either i'll proceed to the rest of the agenda13:04
*** pavelk has joined #automotive13:05
philrobexcept the question of commonapi tools13:05
*** BjoernC has joined #automotive13:05
paulsher1ood(the agenda includes line items for the topics from the charter)13:05
paulsher1oodphilrob: please go ahead13:05
philrobas every knows, common api tech and tooling are central to genivi, how to disseminate it is very important, how can the tool team improve this ?13:07
paulsher1oodphilrob: not sure i understand the question?13:07
jeremiahI think Philippe is referring to the Franca / Common API deliverables that right now come out of Eclipse13:08
philrob@jeremiah: are the ++ for common api topic ?13:08
paulsher1oodi agree they're importany, but can you highlight the problem/issue specifically?13:08
jeremiahThis does not fit well in a continuous intergration environment.13:08
jeremiahphilrob: yes, this is an important topic I feel.13:08
pavelkone can use command line tools with capi-c++ 3.1+13:08
pavelkI acutally tried this13:08
paulsher1oodjeremiah: maybe it's an advantage that we don't have one yet? :)13:08
pavelkthe only dependency is java13:09
pavelk...and libc, etc.13:09
jeremiahpavelk: How does one do this?13:09
jeremiahAh, its in the new version.13:09
pavelkthere are binaries on yamaica update site13:09
pavelkthey only require java and bundle the rest of dependencies inside them13:09
jeremiahOkay, excellent. We ought to have a write up on that for the BIT perhaps.13:09
pavelkwith the tools one can generate the code13:09
jeremiahCan one use an Open Source Java?13:10
*** gunnarx has joined #automotive13:10
pavelkI will eventually have to put together a setup where this works as a part of a yocto recipe13:10
jeremiahOh really?13:10
pavelkI have some ideas by now, but will have to come with the first versino of the generators for capi-c13:10
jeremiahThat would be great to know more about since it might get incorporated into any proposed CI system13:10
pavelkopenjdk works just fine13:11
jeremiahJacques Guillou developed a tool to do this too, I don't know if it is maintained13:11
jeremiahI can ask him what he did and get him to write an email?13:11
gunnarxthere is an open TT topic on integrated java/capi tools...13:11
paulsher1oodphilrob: what did you mean by disseminate wrt this, please?13:11
gunnarxare you up for it pavelk ?13:11
pavelkgunnarx: up to what?13:12
philrobI mean advertize and promote the techno with other communities13:12
gunnarxfiguring out how to do it13:12
pavelkyes, this is what I will eventually need for capic13:12
paulsher1oodi guess we *could*, but that's maybe a more egeneral question than commonapi? why would we do that for just this?13:13
pavelkwhat is currently not quite clear to me is the best / recommended way to use java as a part of the build tool chain on the host13:13
pavelkthere are several way that work, but I will have to research the current state of the art a little bit more13:14
pavelk( the above is in the context of yocto build)13:14
pavelkin a summary, generating capi code with yocto boils down to installing two additional tools as a part of the tool chain on the host13:15
pavelkone is java and another one is the generator binary provided by e.g. capic-c++13:16
paulsher1oodsimilar for baserock, i expect. but who would maintain the results?13:16
paulsher1oodis that a solution?13:16
pavelkthe only things to maintain would be the recipes13:16
pavelkthe generated code is throw-away13:16
pavelkthe generators would have to be maintained by the capi projects13:17
gunnarxI see pavelk is also (the only) participant on the Trello card in question.  Sorry I came in late - I am now caught up on the logs, all is well. :)13:17
paulsher1oodso i think you have actions pavelk - do you need any help on this?13:18
pavelkI will ask once I bump into questions--thanks13:18
jeremiahIts likely part of his Common API C - PoC13:18
pavelkyep :-)13:18
paulsher1oodcan someone comment on philrob's question  about dissemination?13:18
jeremiahI believe the dissemination in question is how to get the common API generators out of Eclipse13:19
jeremiahWithout human intervention13:19
paulsher1oodhe mentioned promotion too?13:19
pavelkI was thinking about a conference talk (elc or als) for the next year about capi in general13:19
pavelkbut this is very fuzzy for now13:20
philrobwho knows why Franca moved away from Eclipse ?13:20
gunnarxphilrob:  it hasn't moved from Eclipse afaik?13:20
jeremiahI thought it was going to be an official plugin?13:20
pavelkthey moved to github13:20
gunnarxIt moved some repos from google code however13:21
pavelkafaik, they still wait to become an official eclipse project13:21
gunnarxbecause google was shutting down that service IIRC13:21
jeremiahThat's because Google Code is going away, no?13:21
gunnarxpavelk:  your line starting with "in summary" is a solution.  yocto by convention builds all the tools to minimize host dependencies so I think people have assumed that also java would be built and that it would be difficult (never heard why), but placing it as a host dependency might be acceptable.13:21
pavelkwell, both is possible13:22
pavelksome folks (e.g., Mark Hatle) suggest the shortcut of using prebuilt binaries13:22
gunnarxI'd welcome analysis of each option by someone.  I only hear "it is hard" with little details from the baseline maintainers.13:22
pavelkaltnernatively, meta-java could possibly be used to build it from scratch (need to check, though)13:22
gunnarxphilrob:  you're right, EclipseLabs is apparently shut down, not only google code (according to mail from klausb)13:23
gunnarxphilrob:  Anyhow, that's the reason and I suppose it does not affect us much13:24
* paulsher1ood has added a card for 'dissemination of common-api'
philrobthx, Paul13:24
paulsher1oodok,... please let's move on13:24
paulsher1ood= Progress on Confluence =13:24
paulsher1oodi have migrated the content that i created now, including minutes13:25
paulsher1oodit took me a few hours. i would rather not do this again :(13:25
*** toscalix__ is now known as toscalix13:25
paulsher1oodi see several parked cards for this... can they be brought to life again?13:26
pavelkI was hoping to have the hierarchy / organization fixed before starting the big migration13:26
pavelkotoh, migrating local page hierarchies would probably work as well13:27
paulsher1oodwe were told that the organization wouldn't affect anything13:27
pavelk...unless the page hierarchy and possibly naming does not matter13:27
pavelkcorrection: do matter13:28
gunnarxmoving pages between spaces should be easy13:28
pavelkso, what are spaces then13:28
pavelkshould eac h topic create its own space?13:28
jeremiahI think for now, yes.13:28
gunnarxjoel!  :)13:28
jeremiahThere is a bit of a chicken/egg problem13:29
jeremiahNo data means no hierarchy.13:29
pavelkI will probably move a local capic hierarchy to /somewhere/ on the public wiki13:29
jeremiahSo if we can start to use new projects as templates for organization13:29
paulsher1oodwell, ok. but at this rate i feel that one of things i'll have to report re tools team at the amm is that we almost got our wiki content tidy!13:29
jeremiahpavelk: I've asked for a JIRA for you13:29
pavelkjeremiah: we do have the old hierarchy (in two places meanwhile)13:29
gunnarxre page names: the only thing I've noticed on GENIVI wiki is that the search box has a global namespace.  So it's not good to have an "unimportant" page inside an "unimportant" space to be named as something else that 80% of people are actually searching for.13:29
pavelkjeremiah: thanks for jira13:29
jeremiahgunnarx: Good point.13:30
gunnarxpeople end up on the unimportant page...13:30
philrobFYI joel said last week he would prefer waiting for +2 weeks (until 24 Sep then) before populating confluence on a wider scale13:30
pavelkthe other thing that I would prefere to have fixed asap is the URL to wiki pages13:30
gunnarxthat said, for the public wiki I'd still propose simple setup, quite flat hierarchy, and straight forward names (i.e. not GENIVISysInfraGroupComponentXMeetingMinutesMeeting20150101)13:30
pavelkotherwise it is difficult to point to them from elsewhere (internal wiki, readmes, etc.)13:31
* paulsher1ood doesn't know what to say on this13:31
pavelkgunnarx: simple setup is ok, we just need to point to one13:32
jeremiahgunnarx: Shouldn't it be GENIVI/SI-EG/Component/ ?13:32
paulsher1oodshall we leave confluence for 2 weeks, then?13:32
gunnarx+1.  the current statement is "start migrating content" but I'm not sure I agree that it really works.  Stable URL soon I hope.13:32
gunnarxjeremiah:  afaik, slashes appear only if you have a separate space13:32
* paulsher1ood wishes he'd never introduced the topic13:32
gunnarxpaulsher1ood needs thicker skin.  no offense :)13:32
gunnarxyou want to move on paulsher1ood ?13:33
paulsher1oodalways :)13:33
paulsher1ood= Jira vs Trello vs writing on the back of our hands =13:33
paulsher1oodwe've been 'using' trello. but now there's a jira too. are we going to switch? or use something elsee?13:34
pavelkmy personal efficiency is inversely proportional to the number of tools used for the same purpose13:34
gunnarxhope everyone else was ready to move on... I only asked if we should...13:34
CTtpollardpavelk: +113:34
philrobFYI the stable url will come once the ongoing RfQ for hosting is completed, (hopefully end of September)13:34
paulsher1oodRfQ for hosting?13:34
philrobthis is a IT-infra question (no more comment on this)13:35
paulsher1oodjira vs trello or something else?13:35
gunnarxno opinion13:35
philrobfyi you can do in jira same todo list as in trello13:36
pavelkfrom what genivi currently has to offer, I would prefer to go with jira for capic issue tracking13:37
pavelkby extension, i would prefer to stick to this tools for other issue tracking as well13:37
paulsher1oodjeremiah: ?13:37
pavelkunknown tool ":-)"13:37
jeremiahI'm going to use what everyone else uses.13:37
pavelkjeremiah: cool13:38
paulsher1oodso that seems to be +1 for jira, no other preferences?\13:39
* paulsher1ood noticies how slow today's meeting is13:39
jeremiahThe new JIRA has a Kanban tool13:39
BjoernCi prefer jira13:40
paulsher1oodthanks BjoernC13:40
paulsher1oodso +2 for jira... any against?13:40
* paulsher1ood proposes we start using the pulbic jira, then13:41
philrobBjoern: ++1 for Kanban, I have just check Jeremiah's kanban board13:41
CTtpollardI've not used it so I can't vote13:41
paulsher1oodphilrob: you mean jira kanban?13:41
paulsher1oodsold, then.13:41
paulsher1ood= Tools Team co-ordination with BIT =13:42
paulsher1oodjeremiah: how do you think this would work best? you know all the parties i think13:42
pavelkpaulsher1ood: is this about the process in general, or rather about the current issues?13:43
paulsher1oodpavelk: both13:43
paulsher1oodif there are current issues, please raise them13:43
pavelkcapi code generation :-)13:43
gunnarxneed to remind myself what the issue is here, except for capi already covered13:44
pavelkautomated code generation as a part of the build13:44
pavelkthis is more of a mid-term issue, to be sure13:44
pavelkthere is an interim solution for the current release afaik13:45
pavelkgunnarx: that's what I mean--it is already covered earlier today13:45
gunnarxcan't find any more info in TT/Minutes.  No trello card right?13:45
jeremiahI think the issue is coordinating GDP with the baselines13:46
paulsher1oodyes, i think so too13:46
gunnarxnot sure it's a tools issue?13:46
jeremiahNow that we're seeing some fixes of meta-ivi, we seem to have decent communication13:46
jeremiahBut that probably needs to be a bit more formal and make its way into PMO13:46
gunnarxI'd say maintainer (of GDP) is the one driving GDP to adopt the latest baseline, basically.  anyone see a problem with that principle?13:47
jeremiahCurrently we're just watching the meta-ivi mailing list and CTtpollard and folks are picking up things that are happening13:47
paulsher1oodok, so TT and BIT co-ordination is already hunky-dory?13:47
gunnarxyou tell me, who added the item?13:47
jeremiahgunnarx: I'd agree. Perhaps then the GDP maintainer (continues) to be part of the BIT?13:47
gunnarxI'm not aware of what the concern is, that's all13:47
gunnarx^^ paulsher1ood13:48
paulsher1oodi added it. i'm just checking13:48
paulsher1oodif folks are happy, that's fine13:48
jeremiahMy worry is that there are bugs and patches lingering on the meta-ivi list13:48
jeremiahBut it looks like they're being addressed13:48
jeremiahso perhaps its not the end of the world13:48
gunnarxGDP maintainer welcome to join BIT, I doubt it's necessary all the time.  baseline releases aren't that frequent13:48
gunnarxjeremiah: valid concern but not something TT will solve probably13:49
paulsher1oodsimilarly baseline maintainers would be welcome to participate in public here :)13:49
paulsher1oodok moving on then?13:49
paulsher1ood= Build Tools =13:50
paulsher1ood(from the charter)13:50
paulsher1oodanything to discuss on this?13:51
gunnarxah. I think the charter has already been broken down into topics, items, actions...?13:51
gunnarxe.g. debian principle, franca_automation, sdks...13:51
pavelk...and approved by the board13:51
paulsher1oodi'm trying to formalize our agenda so we don't miss things in future13:51
jeremiahI think that link that gunnarx discovered last week is important.13:51
jeremiahIt feels like a quick way to host sources from a build13:52
pavelkwhat link?13:52
paulsher1oodplease remind me?13:52
jeremiahwhich can allow use to push binaries13:52
jeremiahLet me find it . . .13:52
gunnarxAh, ok.  recurring topics.  I'd say it is more  efficient to stick to our cards, but those cards might need to be categorized under that agenda then.13:52
gunnarxcards, tickets - whatever jira calls them them, from now on13:52
gunnarxok, so yeah I've looked at it...13:53
gunnarxhad some issues figuring out how it behaves actually, especially when using BB_GENERATE_TARBALLS13:53
gunnarxin some cases it goes out to fetch git from network despite a tarred up git existing...13:54
gunnarxbecause I've been controlling the source/downloads directory, have not successfully evaluated the results of inheriting "archiver" yet13:54
jeremiahokay, so it might not be ready for our use yet?13:55
gunnarxmaybe, anyone feel free to try13:55
paulsher1oodwe're running late, folks...13:56
gunnarxresults of archiver can be tried independently of my investigations into source mirror part.  just build with internet fetching as usual.13:56
gunnarxyeah I have no more to add.13:56
gunnarxpaulsher1ood:  does anyone own an action on this?13:56
paulsher1oodyou and jeremiah, iirc?13:57
gunnarxpaulsher1ood:  Is all we do on this meeting to have headings, and then people talk about what they think that heading is about?13:57
gunnarxuntil you think they talk too much?13:57
gunnarxok, you may be right.13:57
paulsher1oodgunnarx: i dont know, actually. i think i've lost my way here13:57
gunnarxI propose, as part of meeting, state the action owners if there is any confusion, so people know they are expected to talk13:58
jeremiahWe've also lost some participants along the way13:58
gunnarxturns out jeremiah and I engaged anyhow.  I think we can move to the next topic.13:58
paulsher1oodI propose we can't cover the resty of the agenda in reasonable time13:59
*** jacobo has joined #automotive13:59
paulsher1oodi propose we try a conf call next week to improve things13:59
gunnarxfair enough.13:59
gunnarx you're the boss, don't forget :)13:59
gunnarxmight be a good idea, yes,13:59
paulsher1oodthat's too complex a topic for 1 mintue13:59
paulsher1oodanything i should raise at AGL tmrw?14:00
gunnarxis it "layer design meeting"?14:00
gunnarxor something else?14:00
paulsher1ood(since this is time-sensitive)14:00
jeremiahpaulsher1ood: What are their plans for Lifecycle?14:00
philrobgood question14:00
paulsher1oodi meet walt for the first time14:00
jeremiahpaulsher1ood: Are they *really* going to use Android's init system?14:00
gunnarxsystemd?  (ducks)14:00
pavelkwhat is their stance to genivi compliance in general?14:01
gunnarxwait, what?14:01
paulsher1oodthere is some discussion wth Qt folsk that may affect lifecycle for them14:01
jeremiahpavelk: I think they've said they don't aim to be GENIVI compliant14:01
pavelkjeremiah: too bad....14:01
gunnarxjeremiah:  you think?14:01
paulsher1oodjeremiah: i had not heard any mention of android inthat context so far, i may have missed it?14:01
paulsher1ood(or are you trolling? :-)14:02
jeremiahI'll have to look on the mailing list, but I'm pretty sure I heard that in a fairly official capacity.14:02
BjoernChave to leave now, bye bye14:02
paulsher1oodme too :)14:02
gunnarxI think let's have proper discussions about this, not speculation or rumors.  Today seems to be unusually few AGL members in the channel, but I suppose they will catch up on logs.14:02
jeremiahLater BjoernC14:02
paulsher1oodthanks all14:02
*** BjoernC has quit IRC14:02
paulsher1ood== GENIVI Tools Team Meeting Ends ==14:03
paulsher1oodI'll raise the lifecycle question properly tmrw14:03
jeremiahgunnarx: Not so much speculation as EOOM14:03
gunnarxpavelk:  groan14:03
pavelkgunnarx: note how it keeps the allocated memory warm ;-)14:04
gunnarxok, yes.  why are you working on C implementation again? :)14:05
*** philrob has quit IRC14:05
pavelksince nobody else does, really...14:05
paulsher1oodi was going to say that :)14:05
gunnarxah yes14:05
paulsher1oodgunnarx: so wrt 'boss' - as i understand g it bossing doesn't work very well in open source14:06
paulsher1oodso tools team members are voluntary, not much use me telling people what to do14:08
gunnarxpaulsher1ood: deciding about process, leading, works fine.   I'm not saying you should not ask for opinions, just that you can decide on things like whether the meeting needs to end and invite people to a conf call.14:08
pavelkfwiw, all teams in genivi are voluntary14:09
gunnarxthe topics being discussed at the time14:09
paulsher1oodpavelk: not quite. CTtpollard was voluntold to work on GDP :)14:09
pavelksure, what i mean is that genivi has no authority to tell any team member what they do14:10
gunnarxI for one would like leadership in projects where I volunteer, so I don't see any contradiction.14:10
pavelk...only what they shouldn't14:10
gunnarxpavelk:  sometimes not even that14:10
pavelkgunnarx: unfortunately14:10
paulsher1oodgunnarx: ack. it's a balancing act. i fall over all the time :)14:11
gunnarxit's a free world after all.  you can for example create a new distro and contemplate crazy choices for init system14:11
jeremiahNo, you really can't.14:12
gunnarx(oops, I've stayed out of the debate until now)14:12
gunnarxbut I think it's so obvious to me I don't understand what there is to debate.  we in #automotive have lots of interesting things to talk about instead.14:12
paulsher1oodgunnarx: you mean the init system  debate ?14:13
gunnarxpaulsher1ood:  yes, it's the one I have stayed out of...  I have stayed out of it haven't I?  (I forget :-P )14:14
paulsher1oodgunnarx: fwiw that's how i feel about the git mirroring debate :-)14:14
pavelkjeremiah: why on earth xml?..14:14
gunnarxNo, we have discussed actual aspects and consequences of that.14:14
jeremiahpavelk: I dunno. :/14:15
jeremiahPerhaps because you can get dbus XML via introspection?14:15
jeremiahNot sure.14:15
gunnarxWhat's your proposal again.  I'm open for many proposals as I have repeatedly stated.  We modify the  poky layers to use git only?14:15
pavelkjeremiah: does it generate the same code as 'official' capi-c++? or is it a different franca -> C++ mapping?14:16
paulsher1oodgunnarx: never mind. i'm waiting to know what the 'official'  yocto/bitbake solution is14:16
gunnarxby poky layers, I mean things like poky, meta-oe, meta-qt5, various BSPs...14:16
* paulsher1ood needs to breakfast14:16
gunnarxpaulsher1ood:  yes I think that's where we are in the discussion right now.14:16
jeremiahpavelk: Its designed around the official CommonAPI14:16
jeremiahThe older version though14:17
pavelkjeremiah: re. xml you seem to be right14:17
pavelkwill check it out14:17
jeremiahYeah, check it out. It may not be relevant to your work, but it might.14:18
gunnarxpaulsher1ood:  Actually, with exception of the overall layer strategy which significantly impacts our ability to share technology I stay out of meddling in most of AGL decisions, not only init.14:19
pavelkjeremiah: at least it gives one an idea, what parsing of franca outside eclipse platform looks like14:20
CTtpollardgdp builds with from the tip of meta-ivi 7.0 branch with the append removed from meta-genivi-demo :)14:32
gunnarxCTtpollard: nice to have meta-ivi caught up :)14:35
gunnarxbut now it's time to upgrade to newer baselines :)14:35
CTtpollardgunnarx: aye, will patch meta-genivi and genivi-demo-platforms submodules now14:35
*** Egy has joined #automotive14:39
CTtpollardmeta-genivi-demo has been updated with the removal of the common api append and readme update, and all branches of genivi-demo-platform are upto date with meta-ivi and meta-genivi demo :)16:07
paulsher1oodCTtpollard: great. now what about the baserock gdp? :)16:09
gunnarxCTtpollard:  don't listen to boss, you are working with yocto now.  :) :)16:11
gunnarxjust kidding, I want GDP built with baserock.16:11
radiofreewe have a gdp branch already, i just didn't merge it because of the large amount of patches you need to apply to our genivi baseline components16:12
paulsher1oodhow large is large?16:12
gunnarxradiofree:  is that b/c baserock baseline is deviating a lot from the yocto version?16:13
CTtpollardhopefully jeremiah will get a response soon so we can set head in the remote refs16:13
radiofreemy comments were posted here
gunnarxradiofree:  If the baselines include bad/wrong components from GDP perspective, this could influence the baseline planning.16:13
radiofreethe biggest issue is weston16:14
gunnarxah yes, classic16:14
radiofreegunnarx: no, but the GDP does16:14
radiofree(deviate from the baseline)16:14
gunnarxunderstood.  then maybe the problem aligns with earlier  comment, that GDP needs to update to modern baseline(s)16:15
radiofreeindeed it does, however this is going to take some "actual programming™" to fix16:15
radiofreee.g hmi-controller will need updating for the new wayland-ivi-extension16:16
gunnarxoh no, actual programming! :)16:17
gunnarxyes, I think quite many are running into this problem now16:17
paulsher1oodradiofree: so re-reading your june email, basically this all needs cleaning up?16:18
radiofreeunless there's been any updates to it since june, yes16:18
paulsher1oodCTtpollard: ??16:18
paulsher1oodCTtpollard: note by cleanup i mean using stuff from upstream, not cleaner patches hiding in meta-whatever16:19
radiofreei sent a patch to AudioManagerDemo that was accepted so you can now compile that on a system without 16G of ram16:19
paulsher1oodlol )16:19
gunnarxpaulsher1ood:  My attempt to bring some patches out of meta-whatever was voted down by SAT members last week. :(16:19
radiofreei think i sent another patch that i didn't receive any feedback from16:19
gunnarxthat was related to generated code however, so if we only can get generation into the build properly I think everyone's happier16:20
CTtpollardpaulsher1ood: I've not worked on the baserock gdp16:20
gunnarxby the way, and probably this feedback could be given better through other channels, but it means baserock-baseline is responsible for solving the inclusion of CommonAPI generated code, one way or another.16:21
gunnarxI suspect at least *you* will put them in git (as was my proposal)  ;-)16:21
paulsher1oodCTtpollard: i meant the yocto gdp16:22
paulsher1oodhas anything been cleaned up there? ie less patches in meta-foo, more upstream16:23
radiofreeQtWayland is still messy. See the recent discussion on the lm list16:23
paulsher1ood17:19 < gunnarx> paulsher1ood:  My attempt to bring some patches out of meta-whatever was voted down by SAT members last week. :(16:24
CTtpollardpaulsher1ood: there hasn't been any appends added to meta-genivi-demo (now the comon one has gone) since I started16:24
paulsher1oodgunnarx: this is, frankly, because some folks are either pretendign to understand how to do this work, or have a vested interest in making it cost more16:25
paulsher1oodCTtpollard: have any been *removed*?16:25
CTtpollardpaulsher1ood: not on my watch16:26
paulsher1oodgunnarx: please name and shame the SAT members :)16:27
gunnarxI can't speak to their intentions, maybe some people were just uneasy with the idea of more git repositories, maybe they don't like committing generated code...16:27
gunnarxpaulsher1ood:  you have access to the wiki to read the minutes.  I was voted 7 against 1!16:27
gunnarxso basically I'd have to name them all, lol16:28
gunnarxyou win some, you lose some.  it's a good thing the SAT democracy works at least.16:28
paulsher1oodharumph :)16:28
paulsher1oodgunnarx: at least i only committed to this gig until the next AMM :-)16:29
gunnarxmost arguments seemed illogical to me so it's hard to speculate about the rason.   the code is hidden in layer patches... which are committed to git.  So there is no logical difference except one less repo I suppose.  and that there is no sharing between different baselines this way :-/16:30
gunnarxpaulsher1ood:  wait, what?  no, pretty sure it is "until you are fired" :)16:31
*** toscalix has quit IRC16:33
paulsher1oodgunnarx: as i've been trying to explain, the bb appendmechanism  systemically encourages folks to create hidden forks. that everyone thinks thisis a good thing astonishes me16:34
gunnarxIt's a very useful mechanism16:34
gunnarxAs usual people can create crap though16:34
paulsher1oodrjek: what does that signify?16:35
paulsher1oodrjek: that i'm astonished?16:35
rjekNo, I'm sharing your astonishment.16:36
gunnarxpaulsher1ood: as you also know I have given the same exact argument against your idea of prematurely creating local git copies of upstream repos - that too simplifies the addition of local changes.16:36
* rjek would like to understand the issue and its politics in more depth, but has to go to throw a kilderkin around a cellar.16:36
gunnarxwhat is "hidden" is probably in some part a matter of experience also.  if you work a lot in yocto, you'll be on the lookout for bbappends and patches.  in other tools you'll notice other things.16:36
gunnarx /define kilderkin16:37
rjekgunnarx: 18 gallon cask.16:37
gunnarxwhoa.  me likes.16:37
rjekNo, I maintain a pub's cellar in my spare time :)16:37
gunnarxok, either that or you have large a very large consumption16:38
paulsher1oodgunnarx: most of the software world doesn't use bitbake. keeping patchfiles in jrandom directories is not comparable to maintaining a git branch.16:41
gunnarxpaulsher1ood:  I agree for patches, but you brought up bbappend16:41
paulsher1oodthey'r bothe exampls of the same thing: quirky delta kept out of upstream by design16:42
paulsher1oodie hidden cost.16:42
gunnarxConsider the fact that for example a BSP layer may need a particular fix for that hardware for a component that is not a BSP component per se.  In many cases a bbappend will fix what is necessary in a certain context, and it will work automagically in new configurations of layers.  Sometimes it doesn't, and then you need to figure out why.16:43
gunnarxIt's a double edged sword but I think you are disregarding that layers serve a purpose.16:43
paulsher1oodwhat is that purpose?16:44
gunnarxsee above16:44
persia_The key issue there is that the problem ends up being solved N times by N different folk using the same differing hardware.  Putting a detection routine upstream avoids the problem in the future forever for everyone.16:44
gunnarxone person creates a modification that is relevant for "situation X", then that modification is later combined in a new setting.16:44
gunnarxpersia_:  That speaks to the opposite of what Isaid.  If it's solved in a BSP layer, that fix is reused by all people who use that layer.16:45
persia_Yes, for folk that use bitbake.16:46
gunnarxI don't know where you get the point that the same thing is solved multiple times for the same hardware.16:46
gunnarxThat's precisely what layers should avoid16:46
*** persia_ is now known as persia16:46
gunnarxpersia: I don't know if you're speaking for or against :)16:46
gunnarxThe "detection routine" may or may not make sense in the upstream component I bet.  But generally I agree - more build systems would probably be able to share the fix.16:47
persiaI prefer there to be no deviations (either patch to code or patch to config) downstream.  We ought be able to push things upstream to have a generic solution.16:48
persiaExcellent.  We agree then.  You can maybe now tell whether I'm arguing for or against :)16:49
gunnarxOf course we would all prefer no deviations downstream generally speaking.  That's ought to be an obvious point.16:49
gunnarxI don't think smart yocto devs prefer making fixes all the time either.  I'm just saying the world is not black and white.16:50
gunnarx^^ if the alternative is that the component builds correctly from upstream for their particular situation16:51
gunnarxpaulsher1ood:  you believe yocto devs prefer maintaining their appends and patches?   you think the self-preservation aspect of getting your stuff upstream does not work?  Maybe you are right, I don't know.  I just don't think the technology forces that to happen, just like a particular programming language does not force crap code to be produced.16:53
paulsher1oodgunnarx: depends on the devs. but in any case, cross-compile toolchain makes it harder for usptreams to accept patches16:55
gunnarxI did not know that.  But that means if you want to cross compile you may have no choice but to carry your own changes one way or another.16:56
*** mpaolino has quit IRC16:57
gunnarxso to some extent that makes it understandable that the embedded world (well, those who want to cross compile) needs its own ecosystem of stuff.16:57
paulsher1oodit's understandable, it's just not the right way to do things :)16:59
gunnarxLet me ask, in baserock is there a way to define "I want all the branches of all the components that are known to work with Intel hardware" or is that a manual setup for every new hardware.16:59
gunnarxWe're essentially talking about two different information models - you can almost see it mathematically. The alternative of BSP layers with special patches pertaining to that BSP would be some way to slice the set of all component repos to use the correct branch of each.17:00
paulsher1oodi don't understand your question at all, i'm afraid. in baserock only the bsp and toolchain are arch-specific. all the other stuff is generic17:01
paulsher1oodnote bsp for intel board #1 may or may not work for intel board #217:02
gunnarxSo your experience is that they are always distinct?  There are no fixes required in the non-BSP components to support certain hardware for example?17:03
paulsher1oodnot so far, no17:03
gunnarxdo you even use different branches then?  if not for hardware, for what?17:03
persiaI've had such experiences (e.g. special versions of libraries), but in every case, patches could end up upstream to address the issue in a generic fashion, rendering the special library unnecessary.17:04
gunnarxI mean if everything just builds as is with the upstream branch in all situations17:04
paulsher1oodwe have branches for work-in-progress changes to the example systems17:04
gunnarxI see.  Well I'm not against the practice of upstreaming obviously.   I've come to understand through discussions with Paul that git branches are important for the workflow.17:04
paulsher1ood(eg radiofree's branch of GDP)17:05
gunnarxOK, so patches  rarely stay there for long.17:05
gunnarxSo it comes down to that you easier get your changes upstream because of no cross-compilation.17:05
persiaI think (please correct if I'm wrong), that paulsher1ood's position on git branches is that they ought be branches of upstream, targeted for submission upstream, and short-lived, rather than being patches in the build tooling.17:06
paulsher1oodgunnarx: branches can stay or not, but it's much easier to grok and work with branches than loads of patch files17:06
paulsher1oodgunnarx: that's one advantage. another is that it's all in git, not sets of patch files17:06
gunnarxno problem with that, but in order to explain what you didn't understand I need to know if a particular project includes branches with project-specific changes or not17:07
gunnarxI mean if it's not needed in that case it's not needed in a yocto case either.  cross-compilation is the only variable factor17:07
paulsher1oodthat's a hard-to-parse sentence, gunnarx17:08
gunnarxI'll draw you a picture sometime :)17:08
gunnarxI maintain that there is nothing that changes the fundamentals.  If components are independent and don't need to adapt to each other, then this ought to lead to (in the yocto case) very independent layers that are easily composable too17:09
gunnarxvery little bbappends are necessary.  the technology does not make significant difference here, the culture perhaps does17:09
paulsher1oodought to. then look at the actual examples of how it works in practice, and weep :)17:10
gunnarxwell I suppose there are two possible reasons.  changes are not being upstreamed or there really is a lot that needs to be adjusted when you combine different softwares (and BSPs)17:10
* paulsher1ood should do something worthwhile instead of trolling 17:10
persia+1 on it being a culture thing.  There exist few technologies that are insufficiently generic to allow poor practices.  Fixing the culture is the important part.  Sometimes describing certain technologies helps cultural shift.17:13
gunnarxpersia:  Insightful.  And thanks for previous clarification on branches.  I'm usually unsuccessful to "drill down" into the actual mechanics behind this with Paul.  I was  looking to investigate if it was only "ought" (agree, obvious) or also "is" in a typical complex setup.17:16
persiaI don't promise I'm correct, but that's the only way that what I read from paulsher1ood was making sense :)17:16
paulsher1oodpersia: i take it as always that what i am saying can more easily be interpreted as not making sense :)17:17
gunnarxYes I play that game too, he must mean X in order for Y and Z to make sense.  I rarely am successful in confirming my presuppositions though :-/17:18
*** Egy has quit IRC17:19
gunnarxcan we continue talking about paulsher1ood  in the third person style like this?  it's fun.17:20
gunnarxwhat's up with your nick today anyway?17:21
gunnarxyes we're on speaking terms again :-)17:21
*** jacobo has quit IRC17:39
*** paulsher1ood is now known as paulsherwood17:51
paulsherwoodgunnarx: are you talking to me? :)18:13
*** jlrmagnus has joined #automotive18:16
*** pavelk has quit IRC18:23
*** jlrmagnus has quit IRC18:44
*** wschaller has quit IRC19:26
*** gunnarx has quit IRC19:55
*** jlrmagnus has joined #automotive20:11
*** fernandod has quit IRC20:41
*** fernandod has joined #automotive20:41
*** jlrmagnus has quit IRC20:45

Generated by 2.14.0 by Marius Gedminas - find it at!