| *** waltminer has quit IRC | 00:58 | |
| *** waltminer has joined #automotive | 01:06 | |
| *** waltminer has joined #automotive | 01:40 | |
| *** waltminer has left #automotive | 01:41 | |
| *** persia_ has joined #automotive | 02:10 | |
| *** paulsher1ood has joined #automotive | 02:10 | |
| *** paulsherwood has quit IRC | 02:15 | |
| *** persia has quit IRC | 02:15 | |
| *** Luming has quit IRC | 02:41 | |
| *** Luming has joined #automotive | 02:46 | |
| *** wto has quit IRC | 02:57 | |
| *** felipealmeida has quit IRC | 03:00 | |
| *** wto has joined #automotive | 03:02 | |
| *** mpaolino has joined #automotive | 06:18 | |
| *** jacobo has joined #automotive | 08:00 | |
| *** toscalix__ has joined #automotive | 08:09 | |
| *** CTtpollard has joined #automotive | 08:54 | |
| CTtpollard | awesome, 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 now | 09:01 |
|---|---|---|
| jeremiah | I saw that, good news. :-) | 09:09 |
| CTtpollard | I'll get a build going asap, and then pushes | 09:10 |
| jeremiah | w--t | 09:12 |
| jeremiah | Or w00t even | 09:12 |
| CTtpollard | heh | 09:13 |
| CTtpollard | I don't have persistence over the weekend here, did you see the chat about gitolite admin on genivi project? | 09:21 |
| jeremiah | CTtpollard: I guess I missed that. | 09:22 |
| jeremiah | Hmm, I'll check the archives. | 09:22 |
| CTtpollard | from about 14:24 on friday on my timezone | 09:23 |
| jeremiah | http://lists.genivi.org/pipermail/genivi-projects/2015-September/date.html#start | 09:24 |
| jeremiah | Is it in that list? | 09:24 |
| jeremiah | CTtpollard: Or do you mean in #automotive? | 09:25 |
| jeremiah | https://irclogs.baserock.org/automotive/%23automotive.2015-09-04.log.html | 09:25 |
| CTtpollard | jeremiah: sorry I mean on here | 09:25 |
| jeremiah | CTtpollard: I think I found it, it was for me to do a set-head no? | 09:26 |
| jeremiah | I'll do that, thanks | 09:26 |
| CTtpollard | yes that's the one jeremiah :) | 09:26 |
| jeremiah | Okay, let me see if I can do this, I'm not certain I have shell access to the git repos. | 09:29 |
| jeremiah | I do have access to a machine at LF so I'll see if I can find the repos there. | 09:29 |
| CTtpollard | you should be able to ssh in as the git user | 09:30 |
| *** wschaller has joined #automotive | 09:31 | |
| *** Egy has joined #automotive | 09:37 | |
| *** Egy has quit IRC | 09:40 | |
| *** Egy has joined #automotive | 09:40 | |
| *** rZr is now known as RzR | 09:59 | |
| CTtpollard | building with latest ivi patch on 7.0 and removal of append on meta-genivi-demo | 10:12 |
| *** Egy has quit IRC | 10:18 | |
| *** Egy has joined #automotive | 10:19 | |
| CTtpollard | should I be able to ssh into a qemu genivi-demo instance as root? | 10:39 |
| jeremiah | CTtpollard: That would be very interesting to know. :-) | 10:39 |
| jeremiah | It should be root:root | 10:39 |
| CTtpollard | yeh that's what I presumed, I'll have to look at how I'm routing / port forwarding | 10:40 |
| *** wschaller has quit IRC | 10:41 | |
| CTtpollard | hmm port-forwarding from my host to 22 on the vm gives me connection refused on ssh as root | 10:45 |
| radiofree | how is your qemu network setup? libvirt? | 10:45 |
| radiofree | you can see if it's actually there by pinging the broadcast address | 10:45 |
| radiofree | `-b -c 3 -i 10` or some such | 10:46 |
| *** Egy has quit IRC | 10:49 | |
| *** Egy1 has joined #automotive | 10:49 | |
| jeremiah | I'm pretty sure I don't have shell access to the machine hosting gitolite. | 11:00 |
| jeremiah | You have to configure ssh as well as gitolite and I don't believe that's configured to permit logins | 11:00 |
| CTtpollard | jeremiah: what does ssh git-genivi@git.projects.genivi.org help give you | 11:00 |
| jeremiah | This error message seems to support my understanding: | 11:01 |
| jeremiah | PTY allocation request failed on channel 0 | 11:01 |
| jeremiah | CTtpollard: I have the same list of repo commands as you do when I query help | 11:02 |
| jeremiah | desc, help, info, perms, writable | 11:02 |
| jeremiah | I hope gitolite doesn't allow shell access to the git user out of the box, that's a wee bit scary | 11:02 |
| jeremiah | I 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 |
| jeremiah | I'll have to send a request to LF helpdesk | 11:03 |
| jeremiah | I just created a new build for GDP, not much really, just adding meta-perl to get some testing goodness via TAP | 11:09 |
| jeremiah | But I noticed that when I use tar to copy over the file system, there is a link there to the kernel | 11:09 |
| jeremiah | in /boto/ | 11:10 |
| jeremiah | Sorry, in /boot/ | 11:10 |
| jeremiah | Is that useable? I'm gonna check. =) | 11:10 |
| jeremiah | Yep. Works for me | 11:12 |
| CTtpollard | for koelsch I manually add the uboot kernel to boot | 11:12 |
| CTtpollard | jeremiah: 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 hindrance | 11:23 |
| *** wschaller has joined #automotive | 11:27 | |
| *** Egy1 has quit IRC | 11:44 | |
| *** Egy has joined #automotive | 11:44 | |
| *** wschaller has quit IRC | 11:45 | |
| CTtpollard | I'm going to boot a live disk to see if it's an issue with my OS / kernel | 11:49 |
| *** Egy has quit IRC | 11:56 | |
| CTtpollard | I'm currently getting 'ssh_exchange_identification: read: Connection reset by peer' when trying to ssh into the qemu-kvm | 12:14 |
| *** jacobo has quit IRC | 12:33 | |
| paulsher1ood | GENIVI Tools Team meeting will start here in approx 20 minutes' time | 12:39 |
| CTtpollard | paulsher1ood: are you in USA? | 12:40 |
| paulsher1ood | yup | 12:40 |
| paulsher1ood | draft agenda is https://genivi-oss.atlassian.net/wiki/pages/viewpage.action?pageId=4292786 | 12:40 |
| * paulsher1ood will be meeting on an empty stomach | 12:42 | |
| jeremiah | CTtpollard: I've only done it a couple of times and not really had any hiccups. | 12:49 |
| jeremiah | Although I usually have issues, SD card writing is fussy, at least for me | 12:50 |
| radiofree | CTtpollard: is "PermitRootLogin yes" enabled in /etc/ssh/sshd_config ? | 12:51 |
| jeremiah | radiofree: If I remember correctly that is on in the Porter config | 12:52 |
| radiofree | also what does ifconfig in the guest tell you | 12:52 |
| *** wschaller has joined #automotive | 12:52 | |
| CTtpollard | one min radiofree | 12:52 |
| CTtpollard | gah it's playing up, will get back to you when I can get to a console | 12:58 |
| paulsher1ood | == GENIVI Tools Team Starts == | 13:00 |
| *** philrob has joined #automotive | 13:00 | |
| paulsher1ood | anone here? :) | 13:00 |
| philrob | hi there ! | 13:00 |
| paulsher1ood | hi philrob | 13:00 |
| paulsher1ood | this time i managed to post an agenda... which begins by reviewing the charterr (https://genivi-oss.atlassian.net/wiki/display/TOOL/Tools+Team+Charter) | 13:01 |
| paulsher1ood | the main reason i added this was i wanted to be sure we're workign on the right things | 13:02 |
| paulsher1ood | afaik we've had (almost) no discussion on somoe of the tools mentioned there | 13:02 |
| paulsher1ood | i wanted to check if we need to modify either the charter, or our work or both? | 13:03 |
| paulsher1ood | philrob: do you have any view on this? | 13:03 |
| philrob | not at this point | 13:04 |
| paulsher1ood | ok | 13:04 |
| paulsher1ood | if others have no comments either i'll proceed to the rest of the agenda | 13:04 |
| *** pavelk has joined #automotive | 13:05 | |
| philrob | except the question of commonapi tools | 13:05 |
| *** BjoernC has joined #automotive | 13:05 | |
| paulsher1ood | (the agenda includes line items for the topics from the charter) | 13:05 |
| paulsher1ood | philrob: please go ahead | 13:05 |
| philrob | as 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 |
| jeremiah | hi! | 13:07 |
| paulsher1ood | philrob: not sure i understand the question? | 13:07 |
| jeremiah | philrob++ | 13:07 |
| jeremiah | I think Philippe is referring to the Franca / Common API deliverables that right now come out of Eclipse | 13:08 |
| philrob | @jeremiah: are the ++ for common api topic ? | 13:08 |
| paulsher1ood | i agree they're importany, but can you highlight the problem/issue specifically? | 13:08 |
| jeremiah | This does not fit well in a continuous intergration environment. | 13:08 |
| jeremiah | philrob: yes, this is an important topic I feel. | 13:08 |
| pavelk | one can use command line tools with capi-c++ 3.1+ | 13:08 |
| pavelk | I acutally tried this | 13:08 |
| paulsher1ood | jeremiah: maybe it's an advantage that we don't have one yet? :) | 13:08 |
| pavelk | the only dependency is java | 13:09 |
| jeremiah | :) | 13:09 |
| pavelk | ...and libc, etc. | 13:09 |
| jeremiah | pavelk: How does one do this? | 13:09 |
| jeremiah | Ah, its in the new version. | 13:09 |
| pavelk | there are binaries on yamaica update site | 13:09 |
| pavelk | they only require java and bundle the rest of dependencies inside them | 13:09 |
| jeremiah | Okay, excellent. We ought to have a write up on that for the BIT perhaps. | 13:09 |
| pavelk | with the tools one can generate the code | 13:09 |
| jeremiah | Can one use an Open Source Java? | 13:10 |
| *** gunnarx has joined #automotive | 13:10 | |
| pavelk | I will eventually have to put together a setup where this works as a part of a yocto recipe | 13:10 |
| jeremiah | Oh really? | 13:10 |
| pavelk | I have some ideas by now, but will have to come with the first versino of the generators for capi-c | 13:10 |
| jeremiah | That would be great to know more about since it might get incorporated into any proposed CI system | 13:10 |
| pavelk | openjdk works just fine | 13:11 |
| jeremiah | Jacques Guillou developed a tool to do this too, I don't know if it is maintained | 13:11 |
| jeremiah | I can ask him what he did and get him to write an email? | 13:11 |
| gunnarx | there is an open TT topic on integrated java/capi tools... | 13:11 |
| paulsher1ood | philrob: what did you mean by disseminate wrt this, please? | 13:11 |
| gunnarx | are you up for it pavelk ? | 13:11 |
| pavelk | gunnarx: up to what? | 13:12 |
| philrob | I mean advertize and promote the techno with other communities | 13:12 |
| gunnarx | figuring out how to do it | 13:12 |
| pavelk | yes, this is what I will eventually need for capic | 13:12 |
| paulsher1ood | i guess we *could*, but that's maybe a more egeneral question than commonapi? why would we do that for just this? | 13:13 |
| pavelk | what 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 host | 13:13 |
| pavelk | there are several way that work, but I will have to research the current state of the art a little bit more | 13:14 |
| pavelk | ( the above is in the context of yocto build) | 13:14 |
| pavelk | in a summary, generating capi code with yocto boils down to installing two additional tools as a part of the tool chain on the host | 13:15 |
| pavelk | one is java and another one is the generator binary provided by e.g. capic-c++ | 13:16 |
| paulsher1ood | similar for baserock, i expect. but who would maintain the results? | 13:16 |
| pavelk | nobody? | 13:16 |
| paulsher1ood | is that a solution? | 13:16 |
| pavelk | the only things to maintain would be the recipes | 13:16 |
| pavelk | the generated code is throw-away | 13:16 |
| pavelk | the generators would have to be maintained by the capi projects | 13:17 |
| paulsher1ood | ok | 13:17 |
| gunnarx | I 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 |
| paulsher1ood | :) | 13:17 |
| paulsher1ood | so i think you have actions pavelk - do you need any help on this? | 13:18 |
| pavelk | I will ask once I bump into questions--thanks | 13:18 |
| jeremiah | Its likely part of his Common API C - PoC | 13:18 |
| jeremiah | :-) | 13:18 |
| pavelk | yep :-) | 13:18 |
| paulsher1ood | can someone comment on philrob's question about dissemination? | 13:18 |
| jeremiah | I believe the dissemination in question is how to get the common API generators out of Eclipse | 13:19 |
| jeremiah | Without human intervention | 13:19 |
| paulsher1ood | he mentioned promotion too? | 13:19 |
| pavelk | I was thinking about a conference talk (elc or als) for the next year about capi in general | 13:19 |
| pavelk | but this is very fuzzy for now | 13:20 |
| philrob | who knows why Franca moved away from Eclipse ? | 13:20 |
| pavelk | ??? | 13:20 |
| gunnarx | philrob: it hasn't moved from Eclipse afaik? | 13:20 |
| jeremiah | I thought it was going to be an official plugin? | 13:20 |
| pavelk | they moved to github | 13:20 |
| gunnarx | It moved some repos from google code however | 13:21 |
| pavelk | afaik, they still wait to become an official eclipse project | 13:21 |
| gunnarx | because google was shutting down that service IIRC | 13:21 |
| jeremiah | That's because Google Code is going away, no? | 13:21 |
| gunnarx | right | 13:21 |
| gunnarx | pavelk: 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 |
| pavelk | well, both is possible | 13:22 |
| pavelk | some folks (e.g., Mark Hatle) suggest the shortcut of using prebuilt binaries | 13:22 |
| gunnarx | I'd welcome analysis of each option by someone. I only hear "it is hard" with little details from the baseline maintainers. | 13:22 |
| pavelk | altnernatively, meta-java could possibly be used to build it from scratch (need to check, though) | 13:22 |
| gunnarx | philrob: you're right, EclipseLabs is apparently shut down, not only google code (according to mail from klausb) | 13:23 |
| gunnarx | philrob: Anyhow, that's the reason and I suppose it does not affect us much | 13:24 |
| philrob | agreed | 13:24 |
| * paulsher1ood has added a card for 'dissemination of common-api' https://trello.com/c/WbkjiXl7 | 13:24 | |
| philrob | thx, Paul | 13:24 |
| paulsher1ood | ok,... please let's move on | 13:24 |
| gunnarx | ack | 13:24 |
| paulsher1ood | = Progress on Confluence = | 13:24 |
| paulsher1ood | i have migrated the content that i created now, including minutes | 13:25 |
| paulsher1ood | it took me a few hours. i would rather not do this again :( | 13:25 |
| *** toscalix__ is now known as toscalix | 13:25 | |
| paulsher1ood | i see several parked cards for this... can they be brought to life again? | 13:26 |
| pavelk | I was hoping to have the hierarchy / organization fixed before starting the big migration | 13:26 |
| pavelk | otoh, migrating local page hierarchies would probably work as well | 13:27 |
| paulsher1ood | we were told that the organization wouldn't affect anything | 13:27 |
| paulsher1ood | iirc | 13:27 |
| pavelk | ...unless the page hierarchy and possibly naming does not matter | 13:27 |
| pavelk | correction: do matter | 13:28 |
| gunnarx | moving pages between spaces should be easy | 13:28 |
| pavelk | so, what are spaces then | 13:28 |
| pavelk | should eac h topic create its own space? | 13:28 |
| jeremiah | I think for now, yes. | 13:28 |
| gunnarx | joel! :) | 13:28 |
| jeremiah | heh | 13:28 |
| jeremiah | There is a bit of a chicken/egg problem | 13:29 |
| jeremiah | No data means no hierarchy. | 13:29 |
| pavelk | I will probably move a local capic hierarchy to /somewhere/ on the public wiki | 13:29 |
| jeremiah | So if we can start to use new projects as templates for organization | 13:29 |
| paulsher1ood | well, 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 |
| jeremiah | pavelk: I've asked for a JIRA for you | 13:29 |
| pavelk | jeremiah: we do have the old hierarchy (in two places meanwhile) | 13:29 |
| gunnarx | re 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 |
| pavelk | jeremiah: thanks for jira | 13:29 |
| jeremiah | gunnarx: Good point. | 13:30 |
| gunnarx | people end up on the unimportant page... | 13:30 |
| philrob | FYI joel said last week he would prefer waiting for +2 weeks (until 24 Sep then) before populating confluence on a wider scale | 13:30 |
| pavelk | the other thing that I would prefere to have fixed asap is the URL to wiki pages | 13:30 |
| gunnarx | that said, for the public wiki I'd still propose simple setup, quite flat hierarchy, and straight forward names (i.e. not GENIVISysInfraGroupComponentXMeetingMinutesMeeting20150101) | 13:30 |
| pavelk | otherwise it is difficult to point to them from elsewhere (internal wiki, readmes, etc.) | 13:31 |
| * paulsher1ood doesn't know what to say on this | 13:31 | |
| pavelk | gunnarx: simple setup is ok, we just need to point to one | 13:32 |
| jeremiah | gunnarx: Shouldn't it be GENIVI/SI-EG/Component/ ? | 13:32 |
| paulsher1ood | shall 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 |
| gunnarx | jeremiah: afaik, slashes appear only if you have a separate space | 13:32 |
| * paulsher1ood wishes he'd never introduced the topic | 13:32 | |
| gunnarx | paulsher1ood needs thicker skin. no offense :) | 13:32 |
| gunnarx | you want to move on paulsher1ood ? | 13:33 |
| paulsher1ood | always :) | 13:33 |
| gunnarx | :) | 13:33 |
| paulsher1ood | = Jira vs Trello vs writing on the back of our hands = | 13:33 |
| paulsher1ood | we've been 'using' trello. but now there's a jira too. are we going to switch? or use something elsee? | 13:34 |
| pavelk | my personal efficiency is inversely proportional to the number of tools used for the same purpose | 13:34 |
| gunnarx | hope everyone else was ready to move on... I only asked if we should... | 13:34 |
| CTtpollard | pavelk: +1 | 13:34 |
| philrob | FYI the stable url will come once the ongoing RfQ for hosting is completed, (hopefully end of September) | 13:34 |
| paulsher1ood | RfQ for hosting? | 13:34 |
| philrob | this is a IT-infra question (no more comment on this) | 13:35 |
| paulsher1ood | ok | 13:35 |
| paulsher1ood | jira vs trello or something else? | 13:35 |
| gunnarx | no opinion | 13:35 |
| philrob | fyi you can do in jira same todo list as in trello | 13:36 |
| pavelk | from what genivi currently has to offer, I would prefer to go with jira for capic issue tracking | 13:37 |
| pavelk | by extension, i would prefer to stick to this tools for other issue tracking as well | 13:37 |
| paulsher1ood | jeremiah: ? | 13:37 |
| jeremiah | :-) | 13:37 |
| pavelk | unknown tool ":-)" | 13:37 |
| jeremiah | I'm going to use what everyone else uses. | 13:37 |
| jeremiah | ¯\_(ツ)_/¯ | 13:38 |
| pavelk | jeremiah: cool | 13:38 |
| paulsher1ood | so that seems to be +1 for jira, no other preferences?\ | 13:39 |
| * paulsher1ood noticies how slow today's meeting is | 13:39 | |
| jeremiah | The new JIRA has a Kanban tool | 13:39 |
| jeremiah | FWIW | 13:40 |
| paulsher1ood | ack | 13:40 |
| BjoernC | i prefer jira | 13:40 |
| paulsher1ood | thanks BjoernC | 13:40 |
| paulsher1ood | so +2 for jira... any against? | 13:40 |
| * paulsher1ood proposes we start using the pulbic jira, then | 13:41 | |
| philrob | Bjoern: ++1 for Kanban, I have just check Jeremiah's kanban board | 13:41 |
| CTtpollard | I've not used it so I can't vote | 13:41 |
| paulsher1ood | philrob: you mean jira kanban? | 13:41 |
| philrob | yes | 13:41 |
| paulsher1ood | sold, then. | 13:41 |
| paulsher1ood | next... | 13:42 |
| paulsher1ood | = Tools Team co-ordination with BIT = | 13:42 |
| paulsher1ood | jeremiah: how do you think this would work best? you know all the parties i think | 13:42 |
| pavelk | paulsher1ood: is this about the process in general, or rather about the current issues? | 13:43 |
| paulsher1ood | pavelk: both | 13:43 |
| paulsher1ood | if there are current issues, please raise them | 13:43 |
| pavelk | capi code generation :-) | 13:43 |
| gunnarx | need to remind myself what the issue is here, except for capi already covered | 13:44 |
| pavelk | automated code generation as a part of the build | 13:44 |
| pavelk | this is more of a mid-term issue, to be sure | 13:44 |
| jeremiah | hmm | 13:44 |
| pavelk | there is an interim solution for the current release afaik | 13:45 |
| pavelk | gunnarx: that's what I mean--it is already covered earlier today | 13:45 |
| gunnarx | can't find any more info in TT/Minutes. No trello card right? | 13:45 |
| jeremiah | I think the issue is coordinating GDP with the baselines | 13:46 |
| gunnarx | ah | 13:46 |
| paulsher1ood | yes, i think so too | 13:46 |
| gunnarx | not sure it's a tools issue? | 13:46 |
| jeremiah | Now that we're seeing some fixes of meta-ivi, we seem to have decent communication | 13:46 |
| jeremiah | But that probably needs to be a bit more formal and make its way into PMO | 13:46 |
| gunnarx | I'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 |
| jeremiah | Currently we're just watching the meta-ivi mailing list and CTtpollard and folks are picking up things that are happening | 13:47 |
| paulsher1ood | ok, so TT and BIT co-ordination is already hunky-dory? | 13:47 |
| gunnarx | you tell me, who added the item? | 13:47 |
| jeremiah | gunnarx: I'd agree. Perhaps then the GDP maintainer (continues) to be part of the BIT? | 13:47 |
| gunnarx | I'm not aware of what the concern is, that's all | 13:47 |
| gunnarx | ^^ paulsher1ood | 13:48 |
| paulsher1ood | i added it. i'm just checking | 13:48 |
| gunnarx | ok | 13:48 |
| paulsher1ood | if folks are happy, that's fine | 13:48 |
| jeremiah | My worry is that there are bugs and patches lingering on the meta-ivi list | 13:48 |
| jeremiah | But it looks like they're being addressed | 13:48 |
| jeremiah | so perhaps its not the end of the world | 13:48 |
| gunnarx | GDP maintainer welcome to join BIT, I doubt it's necessary all the time. baseline releases aren't that frequent | 13:48 |
| jeremiah | Agreed. | 13:48 |
| gunnarx | jeremiah: valid concern but not something TT will solve probably | 13:49 |
| paulsher1ood | similarly baseline maintainers would be welcome to participate in public here :) | 13:49 |
| jeremiah | :) | 13:49 |
| paulsher1ood | ok moving on then? | 13:49 |
| paulsher1ood | = Build Tools = | 13:50 |
| paulsher1ood | (from the charter) | 13:50 |
| paulsher1ood | anything to discuss on this? | 13:51 |
| gunnarx | ah. I think the charter has already been broken down into topics, items, actions...? | 13:51 |
| gunnarx | e.g. debian principle, franca_automation, sdks... | 13:51 |
| pavelk | ...and approved by the board | 13:51 |
| paulsher1ood | i'm trying to formalize our agenda so we don't miss things in future | 13:51 |
| jeremiah | I think that link that gunnarx discovered last week is important. | 13:51 |
| jeremiah | It feels like a quick way to host sources from a build | 13:52 |
| pavelk | what link? | 13:52 |
| paulsher1ood | please remind me? | 13:52 |
| jeremiah | which can allow use to push binaries | 13:52 |
| jeremiah | Let me find it . . . | 13:52 |
| gunnarx | Ah, 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 |
| jeremiah | http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle | 13:52 |
| gunnarx | cards, tickets - whatever jira calls them them, from now on | 13:52 |
| paulsher1ood | thanks | 13:53 |
| gunnarx | ok, so yeah I've looked at it... | 13:53 |
| gunnarx | had some issues figuring out how it behaves actually, especially when using BB_GENERATE_TARBALLS | 13:53 |
| gunnarx | in some cases it goes out to fetch git from network despite a tarred up git existing... | 13:54 |
| gunnarx | because I've been controlling the source/downloads directory, have not successfully evaluated the results of inheriting "archiver" yet | 13:54 |
| jeremiah | okay, so it might not be ready for our use yet? | 13:55 |
| gunnarx | maybe, anyone feel free to try | 13:55 |
| paulsher1ood | we're running late, folks... | 13:56 |
| gunnarx | results of archiver can be tried independently of my investigations into source mirror part. just build with internet fetching as usual. | 13:56 |
| gunnarx | yeah I have no more to add. | 13:56 |
| gunnarx | paulsher1ood: does anyone own an action on this? | 13:56 |
| paulsher1ood | you and jeremiah, iirc? | 13:57 |
| gunnarx | paulsher1ood: Is all we do on this meeting to have headings, and then people talk about what they think that heading is about? | 13:57 |
| gunnarx | until you think they talk too much? | 13:57 |
| gunnarx | ok, you may be right. | 13:57 |
| paulsher1ood | gunnarx: i dont know, actually. i think i've lost my way here | 13:57 |
| jeremiah | heh | 13:58 |
| gunnarx | I propose, as part of meeting, state the action owners if there is any confusion, so people know they are expected to talk | 13:58 |
| jeremiah | We've also lost some participants along the way | 13:58 |
| gunnarx | turns out jeremiah and I engaged anyhow. I think we can move to the next topic. | 13:58 |
| paulsher1ood | ok | 13:58 |
| paulsher1ood | I propose we can't cover the resty of the agenda in reasonable time | 13:59 |
| *** jacobo has joined #automotive | 13:59 | |
| paulsher1ood | i propose we try a conf call next week to improve things | 13:59 |
| gunnarx | fair enough. | 13:59 |
| gunnarx | you're the boss, don't forget :) | 13:59 |
| gunnarx | might be a good idea, yes, | 13:59 |
| paulsher1ood | that's too complex a topic for 1 mintue | 13:59 |
| gunnarx | agreed | 13:59 |
| paulsher1ood | :) | 13:59 |
| paulsher1ood | AOB? | 14:00 |
| paulsher1ood | anything i should raise at AGL tmrw? | 14:00 |
| gunnarx | is it "layer design meeting"? | 14:00 |
| gunnarx | or something else? | 14:00 |
| paulsher1ood | (since this is time-sensitive) | 14:00 |
| paulsher1ood | AMM | 14:00 |
| jeremiah | paulsher1ood: What are their plans for Lifecycle? | 14:00 |
| philrob | good question | 14:00 |
| paulsher1ood | i meet walt for the first time | 14:00 |
| jeremiah | paulsher1ood: Are they *really* going to use Android's init system? | 14:00 |
| gunnarx | systemd? (ducks) | 14:00 |
| pavelk | what is their stance to genivi compliance in general? | 14:01 |
| gunnarx | wait, what? | 14:01 |
| paulsher1ood | there is some discussion wth Qt folsk that may affect lifecycle for them | 14:01 |
| jeremiah | pavelk: I think they've said they don't aim to be GENIVI compliant | 14:01 |
| pavelk | jeremiah: too bad.... | 14:01 |
| jeremiah | Yep | 14:01 |
| gunnarx | jeremiah: you think? | 14:01 |
| paulsher1ood | jeremiah: 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 |
| jeremiah | I'll have to look on the mailing list, but I'm pretty sure I heard that in a fairly official capacity. | 14:02 |
| paulsher1ood | really? | 14:02 |
| BjoernC | have to leave now, bye bye | 14:02 |
| jeremiah | Yep | 14:02 |
| paulsher1ood | me too :) | 14:02 |
| gunnarx | I 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 |
| jeremiah | Later BjoernC | 14:02 |
| paulsher1ood | thanks all | 14:02 |
| *** BjoernC has quit IRC | 14:02 | |
| paulsher1ood | == GENIVI Tools Team Meeting Ends == | 14:03 |
| pavelk | this->pavelk::~pavelk(); | 14:03 |
| paulsher1ood | I'll raise the lifecycle question properly tmrw | 14:03 |
| jeremiah | gunnarx: Not so much speculation as EOOM | 14:03 |
| gunnarx | pavelk: groan | 14:03 |
| pavelk | gunnarx: note how it keeps the allocated memory warm ;-) | 14:04 |
| gunnarx | ok, yes. why are you working on C implementation again? :) | 14:05 |
| *** philrob has quit IRC | 14:05 | |
| pavelk | since nobody else does, really... | 14:05 |
| paulsher1ood | i was going to say that :) | 14:05 |
| gunnarx | ah yes | 14:05 |
| paulsher1ood | gunnarx: so wrt 'boss' - as i understand g it bossing doesn't work very well in open source | 14:06 |
| paulsher1ood | so tools team members are voluntary, not much use me telling people what to do | 14:08 |
| gunnarx | paulsher1ood: 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 |
| pavelk | fwiw, all teams in genivi are voluntary | 14:09 |
| gunnarx | the topics being discussed at the time | 14:09 |
| paulsher1ood | pavelk: not quite. CTtpollard was voluntold to work on GDP :) | 14:09 |
| pavelk | sure, what i mean is that genivi has no authority to tell any team member what they do | 14:10 |
| gunnarx | I for one would like leadership in projects where I volunteer, so I don't see any contradiction. | 14:10 |
| pavelk | ...only what they shouldn't | 14:10 |
| gunnarx | pavelk: sometimes not even that | 14:10 |
| pavelk | gunnarx: unfortunately | 14:10 |
| paulsher1ood | gunnarx: ack. it's a balancing act. i fall over all the time :) | 14:11 |
| gunnarx | it's a free world after all. you can for example create a new distro and contemplate crazy choices for init system | 14:11 |
| jeremiah | No, you really can't. | 14:12 |
| gunnarx | (oops, I've stayed out of the debate until now) | 14:12 |
| gunnarx | but 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 |
| paulsher1ood | gunnarx: you mean the init system debate ? | 14:13 |
| jeremiah | https://github.com/Pelagicore/FrancaCCG | 14:13 |
| gunnarx | paulsher1ood: yes, it's the one I have stayed out of... I have stayed out of it haven't I? (I forget :-P ) | 14:14 |
| paulsher1ood | gunnarx: fwiw that's how i feel about the git mirroring debate :-) | 14:14 |
| pavelk | jeremiah: why on earth xml?.. | 14:14 |
| gunnarx | No, we have discussed actual aspects and consequences of that. | 14:14 |
| jeremiah | pavelk: I dunno. :/ | 14:15 |
| jeremiah | Perhaps because you can get dbus XML via introspection? | 14:15 |
| jeremiah | Not sure. | 14:15 |
| gunnarx | What'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 |
| pavelk | jeremiah: does it generate the same code as 'official' capi-c++? or is it a different franca -> C++ mapping? | 14:16 |
| paulsher1ood | gunnarx: never mind. i'm waiting to know what the 'official' yocto/bitbake solution is | 14:16 |
| gunnarx | by poky layers, I mean things like poky, meta-oe, meta-qt5, various BSPs... | 14:16 |
| * paulsher1ood needs to breakfast | 14:16 | |
| gunnarx | paulsher1ood: yes I think that's where we are in the discussion right now. | 14:16 |
| jeremiah | pavelk: Its designed around the official CommonAPI | 14:16 |
| jeremiah | The older version though | 14:17 |
| pavelk | jeremiah: re. xml you seem to be right | 14:17 |
| pavelk | will check it out | 14:17 |
| jeremiah | Yeah, check it out. It may not be relevant to your work, but it might. | 14:18 |
| gunnarx | paulsher1ood: 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 |
| pavelk | jeremiah: at least it gives one an idea, what parsing of franca outside eclipse platform looks like | 14:20 |
| CTtpollard | gdp builds with from the tip of meta-ivi 7.0 branch with the append removed from meta-genivi-demo :) | 14:32 |
| gunnarx | CTtpollard: nice to have meta-ivi caught up :) | 14:35 |
| gunnarx | but now it's time to upgrade to newer baselines :) | 14:35 |
| CTtpollard | gunnarx: aye, will patch meta-genivi and genivi-demo-platforms submodules now | 14:35 |
| *** Egy has joined #automotive | 14:39 | |
| paulsher1ood | http://motherboard.vice.com/read/how-debian-is-trying-to-shut-down-the-cia-and-make-software-trustworthy-again | 16:07 |
| CTtpollard | meta-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 |
| paulsher1ood | CTtpollard: great. now what about the baserock gdp? :) | 16:09 |
| gunnarx | CTtpollard: don't listen to boss, you are working with yocto now. :) :) | 16:11 |
| gunnarx | just kidding, I want GDP built with baserock. | 16:11 |
| radiofree | we 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 components | 16:12 |
| paulsher1ood | how large is large? | 16:12 |
| gunnarx | radiofree: is that b/c baserock baseline is deviating a lot from the yocto version? | 16:13 |
| CTtpollard | hopefully jeremiah will get a response soon so we can set head in the remote refs | 16:13 |
| radiofree | my comments were posted here http://lists.genivi.org/pipermail/genivi-projects/2015-June/000238.html | 16:13 |
| gunnarx | radiofree: If the baselines include bad/wrong components from GDP perspective, this could influence the baseline planning. | 16:13 |
| radiofree | the biggest issue is weston | 16:14 |
| gunnarx | ah yes, classic | 16:14 |
| radiofree | gunnarx: no, but the GDP does | 16:14 |
| radiofree | (deviate from the baseline) | 16:14 |
| gunnarx | understood. then maybe the problem aligns with earlier comment, that GDP needs to update to modern baseline(s) | 16:15 |
| radiofree | indeed it does, however this is going to take some "actual programming™" to fix | 16:15 |
| radiofree | e.g hmi-controller will need updating for the new wayland-ivi-extension | 16:16 |
| gunnarx | oh no, actual programming! :) | 16:17 |
| radiofree | :) | 16:17 |
| gunnarx | yes, I think quite many are running into this problem now | 16:17 |
| paulsher1ood | radiofree: so re-reading your june email, basically this all needs cleaning up? | 16:18 |
| radiofree | unless there's been any updates to it since june, yes | 16:18 |
| paulsher1ood | CTtpollard: ?? | 16:18 |
| paulsher1ood | CTtpollard: note by cleanup i mean using stuff from upstream, not cleaner patches hiding in meta-whatever | 16:19 |
| radiofree | i sent a patch to AudioManagerDemo that was accepted so you can now compile that on a system without 16G of ram | 16:19 |
| paulsher1ood | lol ) | 16:19 |
| gunnarx | paulsher1ood: My attempt to bring some patches out of meta-whatever was voted down by SAT members last week. :( | 16:19 |
| radiofree | i think i sent another patch that i didn't receive any feedback from | 16:19 |
| gunnarx | that was related to generated code however, so if we only can get generation into the build properly I think everyone's happier | 16:20 |
| CTtpollard | paulsher1ood: I've not worked on the baserock gdp | 16:20 |
| gunnarx | by 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 |
| gunnarx | I suspect at least *you* will put them in git (as was my proposal) ;-) | 16:21 |
| paulsher1ood | CTtpollard: i meant the yocto gdp | 16:22 |
| paulsher1ood | has anything been cleaned up there? ie less patches in meta-foo, more upstream | 16:23 |
| radiofree | QtWayland is still messy. See the recent discussion on the lm list | 16:23 |
| paulsher1ood | 17:19 < gunnarx> paulsher1ood: My attempt to bring some patches out of meta-whatever was voted down by SAT members last week. :( | 16:24 |
| CTtpollard | paulsher1ood: there hasn't been any appends added to meta-genivi-demo (now the comon one has gone) since I started | 16:24 |
| paulsher1ood | gunnarx: 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 more | 16:25 |
| paulsher1ood | CTtpollard: have any been *removed*? | 16:25 |
| CTtpollard | paulsher1ood: not on my watch | 16:26 |
| paulsher1ood | gunnarx: please name and shame the SAT members :) | 16:27 |
| gunnarx | I 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 |
| gunnarx | paulsher1ood: you have access to the wiki to read the minutes. I was voted 7 against 1! | 16:27 |
| gunnarx | so basically I'd have to name them all, lol | 16:28 |
| gunnarx | you win some, you lose some. it's a good thing the SAT democracy works at least. | 16:28 |
| paulsher1ood | harumph :) | 16:28 |
| paulsher1ood | gunnarx: at least i only committed to this gig until the next AMM :-) | 16:29 |
| gunnarx | most 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 |
| gunnarx | paulsher1ood: wait, what? no, pretty sure it is "until you are fired" :) | 16:31 |
| *** toscalix has quit IRC | 16:33 | |
| paulsher1ood | gunnarx: 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 me | 16:34 |
| rjek | ! | 16:34 |
| gunnarx | It's a very useful mechanism | 16:34 |
| gunnarx | As usual people can create crap though | 16:34 |
| paulsher1ood | rjek: what does that signify? | 16:35 |
| rjek | Surprise | 16:35 |
| paulsher1ood | rjek: that i'm astonished? | 16:35 |
| rjek | No, I'm sharing your astonishment. | 16:36 |
| gunnarx | paulsher1ood: 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 | |
| gunnarx | what 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 kilderkin | 16:37 |
| rjek | gunnarx: 18 gallon cask. | 16:37 |
| gunnarx | whoa. me likes. | 16:37 |
| gunnarx | homebrewer? | 16:37 |
| rjek | No, I maintain a pub's cellar in my spare time :) | 16:37 |
| gunnarx | ok, either that or you have large a very large consumption | 16:38 |
| paulsher1ood | gunnarx: most of the software world doesn't use bitbake. keeping patchfiles in jrandom directories is not comparable to maintaining a git branch. | 16:41 |
| gunnarx | paulsher1ood: I agree for patches, but you brought up bbappend | 16:41 |
| paulsher1ood | they'r bothe exampls of the same thing: quirky delta kept out of upstream by design | 16:42 |
| paulsher1ood | ie hidden cost. | 16:42 |
| gunnarx | Consider 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 |
| gunnarx | It's a double edged sword but I think you are disregarding that layers serve a purpose. | 16:43 |
| paulsher1ood | what is that purpose? | 16:44 |
| gunnarx | see above | 16: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 |
| gunnarx | one person creates a modification that is relevant for "situation X", then that modification is later combined in a new setting. | 16:44 |
| gunnarx | persia_: 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 |
| gunnarx | I don't know where you get the point that the same thing is solved multiple times for the same hardware. | 16:46 |
| gunnarx | That's precisely what layers should avoid | 16:46 |
| *** persia_ is now known as persia | 16:46 | |
| gunnarx | persia: I don't know if you're speaking for or against :) | 16:46 |
| gunnarx | The "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 |
| persia | I 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 |
| persia | Excellent. We agree then. You can maybe now tell whether I'm arguing for or against :) | 16:49 |
| gunnarx | Of course we would all prefer no deviations downstream generally speaking. That's ought to be an obvious point. | 16:49 |
| gunnarx | I 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 situation | 16:51 |
| gunnarx | paulsher1ood: 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 |
| paulsher1ood | gunnarx: depends on the devs. but in any case, cross-compile toolchain makes it harder for usptreams to accept patches | 16:55 |
| gunnarx | I 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 IRC | 16:57 | |
| gunnarx | so 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 |
| paulsher1ood | it's understandable, it's just not the right way to do things :) | 16:59 |
| gunnarx | Let 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 |
| gunnarx | We'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 |
| paulsher1ood | i 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 generic | 17:01 |
| paulsher1ood | note bsp for intel board #1 may or may not work for intel board #2 | 17:02 |
| gunnarx | So 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 |
| paulsher1ood | not so far, no | 17:03 |
| gunnarx | do you even use different branches then? if not for hardware, for what? | 17:03 |
| persia | I'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 |
| gunnarx | I mean if everything just builds as is with the upstream branch in all situations | 17:04 |
| paulsher1ood | we have branches for work-in-progress changes to the example systems | 17:04 |
| gunnarx | I 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 |
| gunnarx | OK, so patches rarely stay there for long. | 17:05 |
| gunnarx | patches/changes | 17:05 |
| gunnarx | So it comes down to that you easier get your changes upstream because of no cross-compilation. | 17:05 |
| persia | I 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 |
| paulsher1ood | gunnarx: branches can stay or not, but it's much easier to grok and work with branches than loads of patch files | 17:06 |
| paulsher1ood | gunnarx: that's one advantage. another is that it's all in git, not sets of patch files | 17:06 |
| gunnarx | no 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 not | 17:07 |
| gunnarx | I mean if it's not needed in that case it's not needed in a yocto case either. cross-compilation is the only variable factor | 17:07 |
| paulsher1ood | that's a hard-to-parse sentence, gunnarx | 17:08 |
| gunnarx | I'll draw you a picture sometime :) | 17:08 |
| gunnarx | I 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 too | 17:09 |
| gunnarx | very little bbappends are necessary. the technology does not make significant difference here, the culture perhaps does | 17:09 |
| paulsher1ood | ought to. then look at the actual examples of how it works in practice, and weep :) | 17:10 |
| gunnarx | well 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 |
| gunnarx | persia: 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 |
| persia | I don't promise I'm correct, but that's the only way that what I read from paulsher1ood was making sense :) | 17:16 |
| paulsher1ood | persia: i take it as always that what i am saying can more easily be interpreted as not making sense :) | 17:17 |
| gunnarx | Yes 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 IRC | 17:19 | |
| gunnarx | can we continue talking about paulsher1ood in the third person style like this? it's fun. | 17:20 |
| gunnarx | what's up with your nick today anyway? | 17:21 |
| gunnarx | yes we're on speaking terms again :-) | 17:21 |
| *** jacobo has quit IRC | 17:39 | |
| *** paulsher1ood is now known as paulsherwood | 17:51 | |
| gunnarx | yay! | 18:01 |
| paulsherwood | gunnarx: are you talking to me? :) | 18:13 |
| *** jlrmagnus has joined #automotive | 18:16 | |
| *** pavelk has quit IRC | 18:23 | |
| *** jlrmagnus has quit IRC | 18:44 | |
| *** wschaller has quit IRC | 19:26 | |
| *** gunnarx has quit IRC | 19:55 | |
| *** jlrmagnus has joined #automotive | 20:11 | |
| *** fernandod has quit IRC | 20:41 | |
| *** fernandod has joined #automotive | 20:41 | |
| *** jlrmagnus has quit IRC | 20:45 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!