*** jlrmagnus has joined #automotive | 00:00 | |
*** Dthiriez has quit IRC | 00:14 | |
*** Dthiriez has joined #automotive | 00:33 | |
*** waltminer has quit IRC | 00:36 | |
*** jlrmagnus has quit IRC | 00:47 | |
*** Dthiriez has quit IRC | 00:47 | |
*** waltminer has joined #automotive | 01:08 | |
*** fernandod has quit IRC | 01:37 | |
*** fernandod has joined #automotive | 01:38 | |
*** Dthiriez has joined #automotive | 01:59 | |
*** Dthiriez has quit IRC | 02:03 | |
*** Dthiriez has joined #automotive | 02:05 | |
*** waltminer has quit IRC | 02:35 | |
*** Dthiriez has quit IRC | 03:20 | |
*** Dthiriez has joined #automotive | 03:21 | |
*** Dthiriez has quit IRC | 03:31 | |
*** Walkerdine has quit IRC | 03:32 | |
*** Walkerdine has joined #automotive | 03:34 | |
*** Dthiriez has joined #automotive | 04:11 | |
*** Dthiriez has quit IRC | 04:15 | |
*** Dthiriez has joined #automotive | 04:30 | |
*** Dthiriez has quit IRC | 04:32 | |
*** Dthiriez has joined #automotive | 04:33 | |
*** Dthiriez has quit IRC | 04:38 | |
*** gunnarx has joined #automotive | 06:24 | |
*** paulsherwood has joined #automotive | 06:53 | |
paulsherwood | morning all | 06:53 |
---|---|---|
paulsherwood | gunnarx, jeremiah - are you around? | 06:53 |
*** jacobo has joined #automotive | 06:54 | |
gunnarx | yep | 06:57 |
paulsherwood | great | 06:57 |
paulsherwood | i'm writing some background, will paste in a momnet | 06:57 |
gunnarx | if it's just us I'm thinking a combination of voice call and irc might be really efficient | 06:58 |
paulsherwood | can do that | 06:58 |
gunnarx | irc scales better than voice for many people, but if we're 3... | 06:58 |
gunnarx | let's wait for jeremiah | 06:58 |
gunnarx | paulsherwood: do you have your secret telco code for tools meeting? :) alt. we'll use SAT. | 07:00 |
gunnarx | host code I mean :) | 07:00 |
paulsherwood | i have that code yes | 07:00 |
gunnarx | ok | 07:01 |
* paulsherwood looks for it :) | 07:02 | |
paulsherwood | ok i've started a call, guest code is 41459199402 | 07:03 |
gunnarx | no I don't think it is, because I know it by heart :) | 07:04 |
paulsherwood | uk dialin if anyone is interested is +44 330 336 6001 | 07:04 |
gunnarx | small mistake, but it doesn't matter, you don't need to post it | 07:04 |
paulsherwood | erk | 07:04 |
gunnarx | the necessary info is in the GENIVI wiki under Teleconferencing | 07:04 |
paulsherwood | 4149199402 | 07:05 |
gunnarx | looks better | 07:05 |
paulsherwood | topic will be mirroring of source code | 07:05 |
gunnarx | except that I wouldn't have posted it on a public channel | 07:05 |
gunnarx | yes | 07:05 |
paulsherwood | why not? | 07:06 |
paulsherwood | tools team discussion is public, i got approval to use genivi facilities for calls | 07:06 |
gunnarx | because the code may be used for other calls | 07:06 |
gunnarx | it's not unique to tools | 07:07 |
paulsherwood | ah, i understand. sorry | 07:07 |
gunnarx | unfortunately | 07:07 |
paulsherwood | well, maybe genivi would benefit from gatecrashers :) | 07:07 |
paulsherwood | but still, i'll flag this to others as a data breach | 07:07 |
paulsherwood | anyway, im on the call if you want to join... | 07:08 |
paulsherwood | and will paste this... | 07:08 |
gunnarx | if they would join the calls and actually engage in the conversation, yes :) | 07:08 |
gunnarx | oh we started? :) | 07:08 |
gunnarx | let me get that outdated thing we call a phone | 07:08 |
paulsherwood | iirc we should talk about mirroring of repos for genivi and possibly other situations. | 07:08 |
paulsherwood | the basic premise is that it's sensible to maintain a copy of upstreams' code so that if upstream goes down or moves, our systems (eg automated build systems) are unaffected | 07:08 |
paulsherwood | the baserock project has been doing this for a few years... we have an appliance called 'trove' which does the mirroring | 07:08 |
paulsherwood | we've made some opinionated decisions on what we see as 'good practice' here... | 07:08 |
paulsherwood | the most obvious one is that we prefer to put everything in git, so downstream tooling doesn't have to handle svn, hg, bzr, cvs etc | 07:08 |
paulsherwood | maybe the next-most important thing is that we collect updates every day | 07:08 |
paulsherwood | that doesn't mean builds need to adopt the updates, but at least we've got them for when we need them | 07:08 |
paulsherwood | there are various corner-cases to deal with (eg occasionally upstreams behave badly, re-writing history) but this soln has been working reliably for us (24/7 with only a few outages) since 2012 | 07:08 |
paulsherwood | it requires very little maintenance (occasional updates, checking free space etc) | 07:08 |
paulsherwood | and it's deployable on cloud or inhouse | 07:08 |
paulsherwood | jeremiah: are you around? | 07:09 |
gunnarx | one sec paul i'll be with you | 07:10 |
paulsherwood | k | 07:10 |
paulsherwood | so one thing i'm unclear on is how genivi infrastructure decisions/operations/mgmt are handled. iiuc there are multiple parties involved already | 07:11 |
paulsherwood | one or more of those could create and host an appliance such as this, or a new participant could do so | 07:12 |
paulsherwood | another question is the 'forking recipes' discussion from last week, which i found myself unable to comment properly on | 07:13 |
paulsherwood | (and i should mention backups, security etc) | 07:14 |
gunnarx | you still there? | 07:35 |
jeremiah | Hi! | 07:41 |
jeremiah | Sorry | 07:41 |
jeremiah | We have someone celebrating a birthday in the office so I started my day with a little cake. :-) | 07:42 |
gunnarx | hi jeremiah | 07:42 |
* jeremiah reads discussion so far | 07:43 | |
paulsherwood | most of the discussion is on the call, i'm afraid | 07:44 |
jeremiah | Okay, I'll hop on | 07:44 |
*** toscalix has joined #automotive | 07:53 | |
paulsherwood | unfortunately i have a hardstop at 09:00 | 07:54 |
*** mdunford has joined #automotive | 08:09 | |
gunnarx | https://github.com/gunnarx/gdp-source | 08:13 |
CTtpollard | interesting | 08:13 |
*** jonathanmaw has joined #automotive | 08:15 | |
*** apinheiro has joined #automotive | 08:18 | |
CTtpollard | gunnarx: has this been linked from the phone discussion? | 08:23 |
gunnarx | CTtpollard: yes | 08:31 |
gunnarx | so let me give some context | 08:31 |
gunnarx | first, this is experimentation | 08:31 |
gunnarx | do you have any experience with git annex? | 08:31 |
CTtpollard | gunnarx: not first-hand | 08:32 |
CTtpollard | I am aware of it though | 08:32 |
gunnarx | me and paul never got to this level of detail, but agreed to move forward in clarifying the options | 08:32 |
gunnarx | so I don't think git-annex is user friendly for most of our users first of all :) some have enough trouble with the git submodules :) | 08:32 |
gunnarx | but what I find interesting about this is that gitannex tracks the content precisely (using git, and sha sums) | 08:33 |
gunnarx | if you clone that repo, you get just a lot of broken symlinks, but what those symlinks point to will precisely define the content | 08:34 |
gunnarx | in order to actually get the content, you would need a git-annex repository that actually has the content (github copy does not), and fetch it from that | 08:34 |
gunnarx | a neat thing is that it is still a git repo at the surface. If I were to put this as a submodule into my gdp project (I'm saying "my" because I don't know if this is usable for all) | 08:35 |
gunnarx | ... then just like with the layers, there's a hash that 100% defines the content in the downloads directory that would be needed to make a successful build. | 08:36 |
*** CTtpollard has quit IRC | 08:42 | |
*** mdunford has quit IRC | 08:42 | |
*** jonathanmaw has quit IRC | 08:42 | |
*** mdunford has joined #automotive | 08:43 | |
*** jonathanmaw has joined #automotive | 08:43 | |
*** CTtpollard has joined #automotive | 08:43 | |
*** jeremiah has quit IRC | 08:44 | |
*** jeremiah has joined #automotive | 08:51 | |
CTtpollard | gunnarx: and would you expect genivi to be the host of the actual content, which others could sync off? | 08:53 |
gunnarx | yeah | 08:53 |
gunnarx | i'm careful... it's just experiments | 08:53 |
gunnarx | so so far I'm not expecting much, but *if* you want to use this, you need a mirror (or many) to host the actual content, yes | 08:54 |
gunnarx | thing is, it might be more logical to expect people to have rsync as a dependency and use that instead of git-annex (for example) | 08:56 |
gunnarx | I'm not convinced about if git-annex is something that should be required. Although I admit by now it is becoming standard software that is packaged in most distros | 08:57 |
CTtpollard | I like the idea of it potentially being a sub-module, which a user could sync to do local yocto builds | 08:58 |
gunnarx | yeah in principle it's cool right? :) | 08:58 |
CTtpollard | obviously there needs to be a lot more orchestration than that though | 08:58 |
gunnarx | you have the scripts, and the sources 100% controlled. build should not be able to fail basically. | 08:59 |
gunnarx | rsyncing would work well to fetch but only git-annex would (at least with this setup) give you a guarantee that you have all the sources, and the correct versionsif you want it to be failsafe. | 09:00 |
CTtpollard | how do we go about maintaining the sources that are checkedin the annex repo? | 09:00 |
gunnarx | granted, yocto will do checksum checks,I just mean with this you can know beforehand that the build should not fail | 09:00 |
CTtpollard | yeh the sha's for using git-annex are ++ over rsync for me | 09:00 |
gunnarx | if this is offered as part of a project the maintainer needs to maintain also the git-annex repo | 09:01 |
gunnarx | that activity is made up of "git annex add" and "git rm" on the files. (yes it's asymmetrical, but that's how you do it) | 09:02 |
gunnarx | followed by "git annex sync" and "git annex copy --to <contentmirror>" most likely, which pushes the content to the mirror. | 09:03 |
CTtpollard | gunnarx: and would this take troves approach of taking daily updates, even if we're not using the latest upstream commits? or would we only update sources on a needs basis? | 09:05 |
gunnarx | imho, the purpose of pulling the latest updates from upstream all the time is only to make them visible in the git web? | 09:06 |
gunnarx | unless you as maintainer are pulling those changes into the "official" build, testing and committing a new version of the build that works, then there is no need to pull them every day. that's a work process thing that I think is independent. | 09:07 |
gunnarx | nice to have, but I don't know what it has to do with publishing a build setup. the published build builds the exact content you have defined it to build, irrespective of what new changes the upstream may contain. | 09:08 |
CTtpollard | indeed | 09:14 |
CTtpollard | in the case of GDP | 09:14 |
*** wschaller has joined #automotive | 09:16 | |
CTtpollard | for development of genivi / agl on a wider scale, then keep a constant mirror of upstream sounds more useful | 09:19 |
*** toscalix has quit IRC | 09:27 | |
gunnarx | I still don't see it, but this seems to be important for Codethink. There is some kind of working process that makes this useful I guess. That's what is missing in the discussion. I'm fine with it. We can mirror as many gits as we like. | 09:27 |
* paulsherwood reads backscroll | 09:28 | |
CTtpollard | I'm not taking a Codethink view on it :) | 09:28 |
paulsherwood | CTtpollard: :-) | 09:28 |
CTtpollard | I can just see the benefits for developers | 09:29 |
gunnarx | CTtpollard: good for you :-) | 09:29 |
gunnarx | What is it you do with the upstream code you have pulled in? Study it? Compare your master/develop branch with the upstream? How do you do that comparison? | 09:31 |
gunnarx | s/you/theoretical GENIVI,AGL developer/ | 09:33 |
CTtpollard | I know I have source to which I can pull everything I need, without relying on n number of hosts | 09:34 |
paulsherwood | gunnarx: fwiw I'm not taking a Codethink-specific view either. I'm taking a purist engineering view. you may think i'm over-engineering :) | 09:37 |
gunnarx | ? | 09:37 |
gunnarx | But how do you know you need what suddenly appeared upstream the last 24h. | 09:37 |
paulsherwood | in my (personal) worldview we need to be advancing lots of upstreams, faster than a single integration engineer can keep up with | 09:38 |
gunnarx | What you absolutely need to have available without relying on n hosts is what you already have in your repo because your current stable build depends on it. | 09:38 |
paulsherwood | gunnarx: we can make some decisions about what we need and what we don't, for some of the work | 09:38 |
paulsherwood | that's one thing you need, yes :) | 09:38 |
gunnarx | paulsherwood: that's only useful if you are going to actually look at that code. so again, I'm asking about the day to day processes. What do you actually do with it? | 09:39 |
paulsherwood | and then you need a guaranteed configuration of 'build-system' that you can reproduce if your specific build machine dies | 09:39 |
gunnarx | that is covered above | 09:39 |
gunnarx | "is what you already have in your repo" | 09:40 |
paulsherwood | we actually advance shas, and build them | 09:40 |
gunnarx | now we're getting somewhere! | 09:40 |
*** jeremiah has quit IRC | 09:40 | |
gunnarx | OK, so we are talking about automated test builds based on the latest upstream sources to see if they break | 09:41 |
paulsherwood | gunnarx: i thought you knew this. i was demonstrating building genivi systems with latest kernel regularly at genivi events for the last couple of ywars? | 09:41 |
gunnarx | the point is, this is the level of detail that is never covered. | 09:41 |
gunnarx | in our discussions. All you claim is "we need the latest source all the time" | 09:41 |
paulsherwood | i stand by that claim :) | 09:41 |
gunnarx | but you fail, so far, to explain why | 09:42 |
paulsherwood | i don't trust all upstreams. some misbehave :) | 09:42 |
gunnarx | now you're backtracking (IMHO) | 09:42 |
gunnarx | my point being, that why would you base your builds on that misbehaving upstream... | 09:42 |
*** jeremiah has joined #automotive | 09:42 | |
paulsherwood | because genivi decided to, for example? | 09:43 |
gunnarx | there is normally a process (including the test builds you mention, which are good) to move code from just an idea, to something you have accepted into your stable product | 09:43 |
gunnarx | code that appears, and then disappears in the upstream can't be a significant important part... | 09:43 |
paulsherwood | or because jrandom project made choices which later proved to be bad? | 09:43 |
paulsherwood | gunnarx: what if upstream gets hacked? | 09:43 |
gunnarx | git is safe | 09:43 |
paulsherwood | nope | 09:43 |
gunnarx | ? | 09:44 |
gunnarx | hacked, with what exact result? unavailable repo, or modified repo? | 09:44 |
paulsherwood | nothing is really 'safe'... we just need to bear in mind the risks, but that's offtopic probably | 09:44 |
paulsherwood | both are possible | 09:44 |
Figure | git + gerrit Qt does fine with those | 09:45 |
Figure | ci for building | 09:45 |
gunnarx | yeah off topic maybe but importantly for me, it's not precise. I'm aiming for our discussion to be based on precise, real differences | 09:46 |
gunnarx | please don't just say "hacked" and not explain what it means for our discussion | 09:46 |
paulsherwood | Figure: that's great - do you know how they deal with the non-Qt source? | 09:46 |
gunnarx | git is safe from the perspective of content not being altered. we agree on that point at least? | 09:46 |
paulsherwood | if we have a git mirror with sensible security policies, we can hope to notice if/when upstream re-writes history etc | 09:48 |
gunnarx | agreed | 09:48 |
paulsherwood | but, for example, if you don't know about ''GIT_NO_REPLACE_OBJECTS', you could easily be mislet | 09:48 |
paulsherwood | misled. (i believe, based on my colleagues' observations... i am not an expert in this) | 09:49 |
gunnarx | I don't know what that is either. shall we go back on topic? | 09:50 |
paulsherwood | it's ON TOPIC | 09:50 |
gunnarx | on which topic? :) | 09:51 |
paulsherwood | :-) | 09:51 |
gunnarx | so what's the deal with GIT_NO_REPLACE_OBJECTS then? | 09:51 |
paulsherwood | git can be fudged and most users won't notice is the upshot | 09:51 |
Figure | paulsherwood: depends on 3rd party | 09:51 |
Figure | paulsherwood: on qtwebengine we use submodule | 09:51 |
gunnarx | ok, surprising. | 09:51 |
paulsherwood | gunnarx: i was surprised too | 09:52 |
Figure | and directly link to certaing known working version of chromium | 09:52 |
paulsherwood | Figure: pulling direct from upstream? | 09:52 |
gunnarx | I'm more concerned with us going through the working process to understand what we need. | 09:52 |
Figure | in git you need to manually update the submodule sha which is fetched | 09:52 |
Figure | so it's always predefined | 09:52 |
Figure | and freezed when e.g. making Qt 5.5 | 09:53 |
gunnarx | You provided one specific input that makes sense to me so far which is automatically building with the latest upstream code in order to try it, does it fail, does it succeed? | 09:53 |
paulsherwood | gunnarx: well, what we need depends on what we think the work is, i think | 09:53 |
gunnarx | i would agree, I've been trying to get our conversation into those details | 09:53 |
gunnarx | such trial builds are not critical and could also pull the source from upstream into the build directory. the risk of the upstream not being available is not a risk since this is not a critical build. | 09:55 |
paulsherwood | that's your opinion, i think - who knows what's critical? | 09:56 |
paulsherwood | but you may be right :) | 09:57 |
gunnarx | I'm just pointing it out because in this conversation I frequently see a mix of "we need to know the source is available at all times" and "we need to have exactly repeatable builds" and "we need the latest upstream source all the time" | 09:57 |
paulsherwood | ok, i can stop saying those things, that's fine | 09:58 |
gunnarx | they're different is all I'm saying | 09:58 |
gunnarx | they can have different solutions. In principle I have no problem with continuous mirroring of all git repos. | 09:59 |
gunnarx | just want the arguments to be sound | 09:59 |
paulsherwood | thing is, i don't think we need to argue | 10:00 |
paulsherwood | we can continue getting stuff done... show me the code is usually best, as you know :) | 10:00 |
gunnarx | Yes I saw it more as a shared analysis | 10:00 |
paulsherwood | i'm thinkign about your git-annex idea | 10:00 |
gunnarx | we'll keep working on figuring out the connection to yocto builds based on git-only, or based on poky/oe layers as-is | 10:00 |
gunnarx | I'd be happy to answer any questions :) | 10:01 |
paulsherwood | i don't have any for the moment - it seems a bit clunky (as with the submodules approach) but can work and maybe it's good enough for many usecases | 10:01 |
paulsherwood | and to be fair, most software is clunky, isn't it :) | 10:02 |
gunnarx | a fair analysis, on both points | 10:02 |
paulsherwood | Figure: so i may be misunderstanding but i think a difference is that Qt is interested in ci Qt, which is admittedly a humungous amount of code...but still it's Qt... | 10:03 |
paulsherwood | whereas we're interested in ci for a set of complete systems with various versions of Qt integrated into them... to be supported for 10 years or more | 10:04 |
paulsherwood | (or maybe it's just me that's interested in that) | 10:04 |
* paulsherwood needs to dash for a while | 10:04 | |
*** mdunford has quit IRC | 10:06 | |
Figure | paulsherwood: I would suggest how debian is doing it | 10:08 |
Figure | paulsherwood: they have been supporting multiple versions of debian through out the years and have proven rock solid way of creating new stable releases | 10:09 |
*** toscalix__ has joined #automotive | 10:10 | |
*** toscalix__ is now known as toscalix | 10:10 | |
Figure | btw also in Qt we have this new thing called Device Creation package that also contains different environments for different platform. It's created using yocto and git | 10:10 |
*** mdunford has joined #automotive | 10:26 | |
paulsherwood | Figure: that seems sensible. but then debian expressly avoids cross-compile iiuc | 10:37 |
rjek | Yes, everything is built natively on Debian | 10:37 |
*** jmacs has joined #automotive | 10:57 | |
*** wschaller has quit IRC | 10:59 | |
CTtpollard | jonathanmaw has a patch on a development branch for meta-genivi-demo, it has a +1 off jeremiah and I'm happy to back it myself and merge | 11:01 |
CTtpollard | do we want to follow any process when doing this, or should I just reply to the thread with merged? | 11:01 |
paulsherwood | i think that's the process, tbh :) | 11:03 |
CTtpollard | paulsherwood: cool | 11:07 |
*** dannas has joined #automotive | 11:10 | |
CTtpollard | ooi has anyone tried a build with the genivi-demo-platform repo, whilst following the wiki instructions? | 11:17 |
*** waltminer has joined #automotive | 11:20 | |
gunnarx | throwing out a few more ideas: one thing git-annex does is dedup the files. so if the project provides different branches with slightly different content in the sources/downloads folder, you will be storing a single superset of what the branches needs | 11:26 |
gunnarx | an alternative is to host different directories per build (or actually per tag/hash/version however far back you want to provide history) | 11:27 |
gunnarx | and what you'd do then is to hardlink all the files that are identical to the same physical file on disk (like rsnap and similar backup systems) | 11:27 |
gunnarx | that's going down the route of "invent something and provide some convenience scripts..." but it avoids users to have git annex installed | 11:28 |
gunnarx | both for the mirror and for the users, deduplicating files makes sense. | 11:30 |
gunnarx | yes, paulsherwood, git also achieves some dedup :) But it also stores all the history you are not using - from the perspective of the actual build that is. | 11:30 |
*** gunnarx is now known as gunnarx_afk | 11:32 | |
CTtpollard | when you say 'project provides' which project are you referring to? | 11:34 |
*** wschaller has joined #automotive | 11:55 | |
*** gunnarx_afk is now known as gunnarx | 12:02 | |
gunnarx | well any project. the hypothetical project that would include a downloads dir in the form of a git-annex repo | 12:03 |
gunnarx | I meant if the sources folder was a submodule like we discussed | 12:04 |
gunnarx | the submodule is versioned / branched, like the meta layers are now | 12:05 |
gunnarx | one of the nice things with git-annex, since the metadata is commited to git multiple variants (branches) of that metadata can be maintained using normal git. (diff / merge / etc.) | 12:07 |
gunnarx | posted some more info/example: http://paste.baserock.org/owumusiyuf | 12:27 |
paulsherwood | and the content is tarballs? or something else? | 12:30 |
gunnarx | I'd like it to be consistent, so all tarballs. but this is not what yocto is producing atm. It's still doing a checkout of svn repos. | 12:35 |
gunnarx | another option is SRPMs. I imagine Yocto can produce them? | 12:35 |
gunnarx | jeremiah was going to get info from yocto upstream, on this, and general advice | 12:36 |
*** waltminer has quit IRC | 12:38 | |
gunnarx | Or, a novel idea, we could read the documentation :) http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle | 12:40 |
rjek | Reading the manual is like reading the last page of a murder mystery novel first. Spoils all the fun. | 12:41 |
CTtpollard | mega-manual fills me with joy | 12:42 |
gunnarx | you have to admit it's a cool name at least | 12:44 |
CTtpollard | if it contains 1x10^6 pages | 12:45 |
gunnarx | mega manual is the concatenation of all yocto manuals in one. /me likes | 12:46 |
rjek | Does it have more pages than atoms in the universe? | 12:46 |
*** jacobo has quit IRC | 12:47 | |
gunnarx | rjek: no it doesn't | 12:48 |
rjek | Well at least we have that :) | 12:49 |
gunnarx | I checked and the whole manual can be digitally stored and the current state of the art digital storage density is vastly lower than one page per atom. ergo. | 12:52 |
rjek | :) | 12:53 |
* gunnarx has gone into asperger mode now, so beware | 12:53 | |
*** waltminer has joined #automotive | 12:53 | |
CTtpollard | patch merged | 12:55 |
gunnarx | (if any of the readers are diagnosed with Asperger syndrome, let me be clear that it is OK to have that diagnosis) | 12:56 |
gunnarx | CTtpollard: woot | 13:00 |
CTtpollard | just updating submodules now | 13:00 |
gunnarx | Now, why is there so much x11 junk reported when doing a minnowboard build? | 13:00 |
jeremiah | CTtpollard: I followed the wiki instructions for a Porter GDP build | 13:41 |
CTtpollard | ok all branches of gdp repo have the submodule update | 13:46 |
CTtpollard | jeremiah: cool, do you think anything could be added to the steps? | 13:47 |
jeremiah | CTtpollard: I think the steps, at least as I followed them, were pretty darn good. | 13:47 |
jeremiah | I changed the networking stuff | 13:47 |
jeremiah | I should say that I changed my networking config rather. | 13:48 |
jeremiah | But that is not really super relevant I suppose. | 13:48 |
CTtpollard | jeremiah: it could be, what did you go about doing? | 13:49 |
jeremiah | Well, I wanted ssh without passwords, so I set it up that way. | 13:49 |
jeremiah | I wanted this since I thought I'd use a test user with a shared public key for login | 13:50 |
CTtpollard | with authorised keys? | 13:50 |
CTtpollard | ah ok cool | 13:50 |
jeremiah | Yeah, since it would be scriptable that way | 13:50 |
jeremiah | I'll reuse the authorized keys file for the test user to run tests on the Porter. | 13:50 |
jeremiah | I'm not so sure this is the best way to go for writing tests in Qemu though. | 13:51 |
jeremiah | In any case, I don't have any additions to the wiki as far as the instructions go. :-) | 13:52 |
CTtpollard | were you making root passwordless? I'm not sure if you mean a local test user or a test user on the gdp | 13:53 |
jeremiah | gunnarx: The mega-manual seems to provide a pretty clear and comprehensive approach to hosting source | 13:53 |
jeremiah | CTtpollard: I decided to create a test user instead of root | 13:53 |
jeremiah | (I use my personal ssh key, i.e. ~/.ssh/id_rsa) when I shell in, i.e. 'ssh test@porter' | 13:54 |
CTtpollard | understood | 13:55 |
jeremiah | CTtpollard: Do you think this is sane? | 13:55 |
jeremiah | Would you do it differently? | 13:55 |
CTtpollard | depending on the tests you're trying to run | 13:56 |
CTtpollard | but I tend to setup passwordless on most of my machines | 13:56 |
jeremiah | Yeah, this won't fit some tests clearly. | 13:56 |
gunnarx | jeremiah: yes, it says what configuration to add to create the source packages. need to study the result... | 13:58 |
CTtpollard | gunnarx: is it reporting anything which is making the build fail? | 13:58 |
*** dannas has quit IRC | 13:58 | |
* CTtpollard starts a build | 14:14 | |
*** toscalix has quit IRC | 14:14 | |
*** toscalix__ has joined #automotive | 14:15 | |
gunnarx | if you're asking about minnowboard, no, it is reported as warnings, or maybe even errors (I think) but it builds an image. | 14:16 |
gunnarx | you see it at the beginning of the build | 14:16 |
gunnarx | x11 and qt4 garbage :) | 14:16 |
gunnarx | x11 and qt4 bad, wayland and qt5 good! | 14:17 |
gunnarx | I suppose it must come from the intel bsp then...? | 14:18 |
CTtpollard | ok I've just got them now | 14:22 |
jeremiah | Hmm, I think I should go and get a Minnow board | 14:22 |
jeremiah | all the cool kids have them | 14:22 |
CTtpollard | yes it looks like intel is calling it | 14:24 |
*** bbranch has joined #automotive | 14:29 | |
CTtpollard | from the intel-corei7-64.conf in meta-intel | 14:40 |
*** bbranch has quit IRC | 14:42 | |
*** waltminer has quit IRC | 15:07 | |
*** gunnarx has quit IRC | 15:30 | |
*** jlrmagnus has joined #automotive | 15:47 | |
jlrmagnus | Morning | 15:47 |
*** jacobo has joined #automotive | 16:02 | |
*** wschaller has quit IRC | 16:20 | |
*** jonathanmaw has quit IRC | 16:27 | |
*** toscalix__ has quit IRC | 16:40 | |
*** waltminer has joined #automotive | 16:44 | |
*** toscalix__ has joined #automotive | 16:48 | |
*** gunnarx has joined #automotive | 17:04 | |
*** waltminer has quit IRC | 17:09 | |
*** toscalix__ has quit IRC | 18:00 | |
*** gunnarx has quit IRC | 18:02 | |
*** Walkerdine__ has joined #automotive | 18:15 | |
*** bbranch has joined #automotive | 18:21 | |
*** Walkerdine__ has quit IRC | 18:27 | |
*** Egy has joined #automotive | 18:31 | |
*** fernandod has quit IRC | 18:38 | |
*** fernandod has joined #automotive | 18:38 | |
*** apinheiro has quit IRC | 18:48 | |
*** Egy has quit IRC | 18:49 | |
*** Egy has joined #automotive | 18:49 | |
*** Egy1 has joined #automotive | 18:57 | |
*** Egy has quit IRC | 18:57 | |
*** Egy1 has quit IRC | 18:57 | |
*** Egy has joined #automotive | 18:57 | |
*** Egy1 has joined #automotive | 18:58 | |
*** Egy has quit IRC | 18:58 | |
*** Egy1 has quit IRC | 18:59 | |
*** Egy has joined #automotive | 18:59 | |
*** jacobo has quit IRC | 19:38 | |
*** Egy has quit IRC | 20:00 | |
*** waltminer has joined #automotive | 20:14 | |
*** toscalix__ has joined #automotive | 22:56 | |
*** waltminer has quit IRC | 23:14 | |
*** toscalix__ has quit IRC | 23:28 | |
*** jlrmagnus has quit IRC | 23:45 | |
*** bbranch has quit IRC | 23:46 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!