| Walkerdine | I can't figure out how to build off of local changes | 01:49 |
|---|---|---|
| Walkerdine | Everytime I try it says it can't find a morph file | 01:49 |
| Walkerdine | Do I have to make a new morph file in order to build from local? | 01:49 |
| *** gtristan has joined #baserock | 02:58 | |
| Walkerdine | Does this baserock give an error when building if something doesn't compile? | 03:26 |
| gtristan | On the baserock side... I see that various modules pass --sysconfdir manually in the definitions... should I take it that every module's morph should have that setup individually ? | 03:35 |
| gtristan | or is there some shared build info for defining such target dirs ? | 03:35 |
| gtristan | Walkerdine, ybd halts the build and points to the build log of the failing module, I havent tried with morph, but I would expect it does as it's more mature | 03:36 |
| Walkerdine | I wish I was sure that I'm actually building the system with my changes | 03:38 |
| Walkerdine | I can't tell | 03:38 |
| Walkerdine | Maybe I should try to make it error | 03:38 |
| gtristan | that's certainly a sane approach to finding out | 03:39 |
| Walkerdine | Yup thats what I'm gonna do | 03:40 |
| Walkerdine | Yup thats what I'm gonna do | 03:42 |
| gtristan | Followup on that other question... I see that configure scripts make use of the $PREFIX env var, would it be a good idea to introduce other such variables for SYSCONFDIR ? | 03:42 |
| Walkerdine | Oops | 03:42 |
| gtristan | s/configure scripts/configure invocations/ | 03:43 |
| Walkerdine | Most people are based in europe so your questions will probably be answered tomorrow | 03:43 |
| gtristan | Walkerdine, later today | 03:46 |
| gtristan | I am in east asia :) | 03:46 |
| Walkerdine | Ah, I'm on the east coast | 03:47 |
| Walkerdine | I guess I can't just say that can I | 03:47 |
| Walkerdine | In the US but I'm sure enough people just say that expecting people know what that means | 03:47 |
| gtristan | yeah, I presume you dont mean the east coast of Italy :) | 03:48 |
| gtristan | in this context | 03:48 |
| gtristan | hmmm | 03:48 |
| gtristan | well, for now I think I'll build with many patches against the builds to hardwire the missing sysconfdir statements to /etc | 03:49 |
| gtristan | sigh, problem is... finding out every package which either A.) installs something in ${sysconfig}... or B.) reads something in ${sysconfig} | 03:51 |
| * gtristan thinks, safe bet: do it everywhere that it's still unspecified | 03:52 | |
| Walkerdine | The jetson-tk1 pin config is so confusing to read | 04:02 |
| Walkerdine | I just want to set it as output | 04:02 |
| gtristan | Another question is... I'm looking through definitions/ and... while there are various systems which use/share the same strata... what is the policy/approach to use when say, system A and system B share strata N, but system B requires that strata N be configured/built differently than in system A ? | 04:09 |
| gtristan | In one specific case (which I'm not sure is the best example), building gnome-system; requires that xserver.morph does _not_ use the --disable-glx line, however, modifying xserver.morph in place feels inaccurate, perhaps there is another system which specifically wants --disable-glx for a justified reason | 04:12 |
| Walkerdine | It didn't error | 04:29 |
| gtristan | Yeah, I also have to figure out the dev story, how to test your changes to the gits locally still confuses me ;-) | 04:35 |
| Walkerdine | Yeah I've been trying to figure this out for a few weeks | 04:36 |
| gtristan | ouch | 04:36 |
| Walkerdine | It says to set --local-changes=include to do it but I haven | 04:37 |
| Walkerdine | haven't been able to get that to work | 04:37 |
| Walkerdine | I just keep getting that it has no commit | 04:37 |
| gtristan | Walkerdine, I dont know I guess you are with morph ? | 04:38 |
| Walkerdine | yeah | 04:38 |
| gtristan | I assume you have to at least stage the changes you want included ? | 04:38 |
| gtristan | i.e. create local commits | 04:39 |
| Walkerdine | I think I tried that but I can try again | 04:39 |
| Walkerdine | If I do commit this how would I undo that | 04:40 |
| gtristan | Walkerdine, interactive rebase is what I normally do | 04:44 |
| gtristan | but there are several ways, git reset for instance | 04:44 |
| Walkerdine | git reset makes the branch reset? | 04:45 |
| gtristan | if you are working against master or <branch>, and you know you only have one commit to test (to see it fail)... | 04:45 |
| gtristan | then you could do: git reset --hard <branch> | 04:45 |
| gtristan | but that's hardcore, use with care | 04:45 |
| Walkerdine | how do I make a test branch of my current branch | 04:45 |
| Walkerdine | git branch currentbranch -b testbranch | 04:46 |
| Walkerdine | ? | 04:46 |
| gtristan | right, a reset without --hard, basically resets your HEAD to point to where you tell it, and makes the changes in your commits beyond head unstaged again | 04:46 |
| gtristan | you can just do git branch <newbranchname> | 04:46 |
| Walkerdine | And that makes a branch off my current one? | 04:46 |
| gtristan | right, a local one | 04:47 |
| gtristan | which does not track any remote branch | 04:47 |
| Walkerdine | How do I swicth to it | 04:47 |
| gtristan | later, if that branch is upstreamed, you need to normally delete it and checkout the branch again | 04:47 |
| Walkerdine | git checkout testbranch? | 04:47 |
| gtristan | right | 04:47 |
| gtristan | git branch all alone will tell you what branch you are on | 04:47 |
| Walkerdine | Wait if I just switched branches whathappens to the changes I made that werent committed | 04:48 |
| Walkerdine | It still said it has no commit | 04:51 |
| gtristan | it should refuse | 04:51 |
| gtristan | switching a branch with unstaged changes should cause git to complain normally | 04:51 |
| Walkerdine | It didn't do anything it seemed to have kept the changes | 04:51 |
| Walkerdine | It says it has no commit at ref test | 04:52 |
| gtristan | what exactly did you do in what order ? | 04:52 |
| Walkerdine | In the morphology there is a ref section which I changed to test | 04:54 |
| gtristan | ok so you created a branch called 'test' in your local git, but morph does not find the branch, is what you're saying ? | 04:55 |
| Walkerdine | It lists the repository of the repository that I'm trying to change and then there is a line that says ref: sdf30723085jef but I changed the repo to file::///src/whatever and the ref to test | 04:56 |
| Walkerdine | If I didn't change that I think it was just finding the cached chunk that I built from the system I didnt change | 04:57 |
| Walkerdine | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/bsp-jetson.morph?h=baserock/james/genivi-demo-platform-0.1-rebase | 04:58 |
| Walkerdine | The name linux-jetson-tk1 is what I modified | 04:59 |
| gtristan | yeah, I thought this was still a git question at first... unfortunately I can't exactly help with the morph stuff so much, looks like you are doing the right thing though, pointing the morph to file:///path/to/local/git | 05:00 |
| gtristan | with ybd, if I change a morph file, it rebuilds the cache keys from that point of the build and rebuilds from that point as I would expect | 05:01 |
| Walkerdine | Isnt the ref part of git though | 05:01 |
| gtristan | the ref I think is a branch or tag yes | 05:02 |
| gtristan | yeah, docs say that the ref is either the specific commit's SHA, or a branch or tag name | 05:03 |
| gtristan | Walkerdine, the question would be, where is the 'repo' pointing to ? | 05:04 |
| Walkerdine | My local directory | 05:04 |
| gtristan | that should, as far as I can imagine, work as you intend it to, then | 05:05 |
| gtristan | but as you know, I'm also trying to figure this out :) | 05:05 |
| Walkerdine | That ref is the part that is giving me issues | 05:05 |
| gtristan | Walkerdine, with ybd for example, it downloads the gits into a local cache directory, as --bare repositories | 05:05 |
| Walkerdine | I wish ybd worked for the jetson | 05:05 |
| gtristan | So, I'm not really sure on my side how I'm supposed to play in those | 05:06 |
| gtristan | manually clone a copy from the bare repo in ~/.cache/ybd/gits, and actually *push* my changes to the upstream cache for the build to pick up, possibly ? | 05:06 |
| gtristan | but ybd seems very young, probably just a todo item | 05:07 |
| gtristan | for now seems like it's just to build something that already works | 05:07 |
| Walkerdine | Morph needs way more documentation for making actual changes | 05:07 |
| gtristan | Hmmm, http://wiki.baserock.org/Morph/morphology-files/ seems out of date | 05:10 |
| * gtristan looks for docs on 'system-integration' | 05:10 | |
| * gtristan uses git annotate to track down the commit which adds a chunk with 'system-integration' ... and hopes viewing the entire commit will reveal more | 05:11 | |
| Walkerdine | optional fields? What if I delete it | 05:12 |
| Walkerdine | must find out | 05:12 |
| Walkerdine | Nope it errored | 05:14 |
| Walkerdine | Its not going to let me build anything I have concluded | 05:31 |
| Walkerdine | Jk it won't build if it already has the chunk in cache | 05:42 |
| gtristan | Walkerdine, I would take it to the ML honestly, asynchronous conversation is usually of a higher quality than irc/deskside chitchat ;-) | 05:44 |
| Walkerdine | The ML? | 05:44 |
| gtristan | mailing list | 05:45 |
| gtristan | echo "I was unable to build and test my changes in my local git, and am still unable to figure out how to get morph to pick up my changes, please help" | sendmail ;-) | 05:46 |
| paulsherwood | ref: can be a branch, tag, or sha | 05:55 |
| paulsherwood | Walkerdine: if it 'already has the chunk in cache' it hasn't noticed your change, which suggests that the morph file may be incorrect | 05:56 |
| paulsherwood | ybd does work for the jetson, afaik. radiofree has used it there | 05:58 |
| paulsherwood | gtristan: ybd works on whatever is in the current definitions directory, so working on a component should just be edit the definition referring to it, replace upstream: with wherever you component checkout is | 06:01 |
| * paulsherwood should improve the documentation | 06:01 | |
| paulsherwood | we used to have 'morph edit' which did the magic for local checkout and fixing ref: in the morph file... but it seemed to cause confusion | 06:03 |
| gtristan | paulsherwood, I see, indeed it's something I expected to be a ybd detail (incorrectly), but seems more a detail of morphology | 06:04 |
| gtristan | still, it *would* be good to have some HOWTO about 'I have a built system, I want to modify a given library and test it out, what do I do' | 06:05 |
| * gtristan looks forward to another very long build, after adding --sysconfdir=/etc to many packages | 06:06 | |
| Walkerdine | Does morph still have that capability | 06:07 |
| Walkerdine | At least with whatever comes with 15.25 | 06:07 |
| paulsherwood | Walkerdine: try 'morph edit <chunkname>' | 06:08 |
| Walkerdine | I sure thought it was unless it goes somewhere else | 06:09 |
| paulsherwood | Walkerdine: are you confident with git? | 06:12 |
| Walkerdine | No I've only used it intermittently | 06:12 |
| paulsherwood | ok. | 06:13 |
| Walkerdine | But yes that is where the repo is at | 06:13 |
| paulsherwood | so in /src/geniviwork/baserock/james/genivi-demo-platform-0.1-rebase/upstream/linux what does 'git branch' and 'git status' tell you, please? | 06:14 |
| Walkerdine | Oh no do I have to commit in that repo first | 06:15 |
| paulsherwood | it shouldn't be necessary, but you could try it to be sure | 06:15 |
| * paulsherwood has to 'go to gate' unfortunately | 06:15 | |
| Walkerdine | detached and modified files | 06:16 |
| *** petefoth has joined #baserock | 06:25 | |
| Walkerdine | ERROR: Git directory /src/cache/gits/git___git_baserock_org_delta_linux has no commit at ref baserock/james/genivi-demo-platform-0.1-rebase^{commit}. | 06:47 |
| Walkerdine | Thats the error that I don't understand | 06:48 |
| *** zoli___ has quit IRC | 07:03 | |
| *** zoli__ has joined #baserock | 07:04 | |
| *** tlsa_ is now known as tlsa | 07:05 | |
| Walkerdine | Yay I think I figured out waht I was doing wrong | 07:23 |
| *** zoli__ has quit IRC | 07:25 | |
| gtristan | Walkerdine, enlighten us, I am at least curious :) | 07:26 |
| Walkerdine | Well I'm completely at fault here for misinterpreting what the guide was saying to do | 07:26 |
| Walkerdine | When it was making a branch it wasn't doing it in the main repo but in the repo I was modifying | 07:27 |
| gtristan | hmmm, ok and what is the 'main repo' ? | 07:28 |
| gtristan | you have a /src/cache/gits ... and a clone of that in your home dir somewhere, and you neglected to push your change to /src/cache/gits ? | 07:29 |
| Walkerdine | There is a definitions repo full of the morphologies | 07:30 |
| Walkerdine | I need to get better at terminology cause I'm not sure what the right wording would be | 07:32 |
| *** petefoth has left #baserock | 07:45 | |
| *** toscalix has joined #baserock | 08:00 | |
| toscalix | SotK check the UI The changes has been introduced by Pedro | 08:09 |
| *** mariaderidder has joined #baserock | 08:24 | |
| *** paulwaters_ has joined #baserock | 08:25 | |
| *** bashrc has joined #baserock | 08:26 | |
| gtristan | any idea why x-common.morph does not include xauth ? | 08:32 |
| gtristan | I see one ancient commit which adds xorg-app-xauth... to the older json files, and no subsequent mention of it | 08:33 |
| pedroalvarez | gtristan: radiofree and jjardon are the graphics stack guys :) | 08:33 |
| Walkerdine | Do I need to do anything special with the deploy command to use a local build? | 08:34 |
| gtristan | seems it should be there, while it does not cause startup to fail, startx complains while trying to invoke xauth several times during startup | 08:34 |
| jjardon | Gtristan: It was probably removed when we moved to xwayland only: add it back if you need it | 08:45 |
| gtristan | ok well, while I wait for ~60 more steps to complete, can someone here explain to me exactly how 'system-integration' hooks work ? | 08:45 |
| gtristan | jjardon, I see, another question I've had is... lets say we have 'gnome-system-*' which desire X to be compiled in one way, and another system desires compilation of the same strata in a different way, how is that organized in the definitions/ repo ? | 08:47 |
| jjardon | gtristan: or you can try to run a Wayland session instead | 08:47 |
| jjardon | gtristan: not possible at the moment | 08:48 |
| gtristan | also, any objection to --sysconfdir=/etc across the board ? | 08:48 |
| jjardon | Until definitions support conditionals | 08:48 |
| gtristan | is that the way forward ? or rather, should the strata be extended/namespaced for different systems ? | 08:49 |
| * gtristan could imagine also the possibility of declaring separate .morphs for the same package but different systems (that's what I meant sort of) | 08:50 | |
| *** jonathanmaw has joined #baserock | 08:51 | |
| Walkerdine | If I wanted to put some pin inits during boot what would I have to modify to do so | 08:52 |
| wdutch | which branch of ciat-ui is being used? | 08:55 |
| wdutch | pedroalvarez/forth-version looks right | 08:56 |
| gtristan | What is the preferred method of customizing config data installed by stratum ? | 09:13 |
| gtristan | custom install hooks which say... use sed to modify the installed default config ? | 09:13 |
| gtristan | or perhaps, a 'system' wide repository of config data to install/overwrite whatever is there at the last step ? | 09:14 |
| gtristan | definitions/install-files I suppose | 09:16 |
| *** rjek_ is now known as rjek | 09:38 | |
| *** gary_perkins has joined #baserock | 09:53 | |
| pedroalvarez | wdutch: yes, forth-version | 09:53 |
| richard_maw | pedroalvarez: you wrote ciat-ui in Forth? https://www.flickr.com/photos/joeljohnson/1396636973 | 10:01 |
| *** mariaderidder has quit IRC | 10:04 | |
| wdutch | can confirm. that guy is pedro | 10:04 |
| Walkerdine | I cant find what baserock uses to boot up on the jetson | 10:04 |
| *** edcragg_ has joined #baserock | 10:05 | |
| Walkerdine | It is now 6am and I still haven't been able to wiggle a pin | 10:05 |
| edcragg_ | hi, am i able to submit branches to any repo on gbo via gerrit? or do they need to be specifically set up? | 10:06 |
| *** edcragg_ is now known as edcragg | 10:06 | |
| edcragg | i have tried to submit to the linux delta repo using 'ssh://edwardcragg@gerrit.baserock.org:29418/baserock/baserock/linux' which apparently doesn't exist | 10:07 |
| richard_maw | edcragg: no, the gerrit only allows stuff for baserock/ projects | 10:09 |
| richard_maw | edcragg: ideally we'd have the changes go upstream instead | 10:10 |
| richard_maw | edcragg: though if this isn't feasible, we generally accept mailing list or IRC reviews | 10:11 |
| *** mariaderidder has joined #baserock | 10:15 | |
| edcragg | richard_maw: ideally i would like to make a wip branch to support a particular board while upstream is not an option, since someone else is developing and upstreaming support | 10:15 |
| edcragg | mailing list it is then, i guess | 10:15 |
| richard_maw | edcragg: if it's not ready for review, and your issue is that you can't push your WIP branch there, we can sort out push access | 10:16 |
| pedroalvarez | wdutch: what are you planning to change? Let me know if you need anything. I'll be around. | 10:21 |
| wdutch | pedroalvarez: the url of the lanelinks, I can see how to do it but I don't know how to update ciat.baserock.org | 10:22 |
| pedroalvarez | It's been served from /var/www/ciat-ui[-dev] | 10:25 |
| edcragg | richard_maw: that would be very useful. it's in a state that wouldn't be particularly meaningful to review | 10:25 |
| richard_maw | pedroalvarez: can you set up an account for edcragg? I'm currently neck deep in documentation. | 10:27 |
| *** gary_perkins has quit IRC | 10:27 | |
| *** paulw has joined #baserock | 10:29 | |
| *** paulwaters_ has quit IRC | 10:30 | |
| *** ssam2 has joined #baserock | 10:30 | |
| *** ChanServ sets mode: +v ssam2 | 10:30 | |
| pedroalvarez | richard_maw: g.b.o gitano account? Sure | 10:30 |
| *** gary_perkins has joined #baserock | 10:34 | |
| edcragg | thanks richard_maw, pedroalvarez | 10:52 |
| * wdutch wonders how to restart ciat-ui | 10:58 | |
| bashrc | looks like it autorefreshes | 10:59 |
| pedroalvarez | wdutch: sudo service httpd restart | 11:00 |
| wdutch | ta | 11:00 |
| pedroalvarez | Not sure if it's needed though | 11:00 |
| edcragg | Walkerdine: what have you tried so far? | 11:13 |
| paulsherwood | i expect Walkerdine is sleeping | 11:14 |
| *** gary_perkins has quit IRC | 11:18 | |
| tlsa | all the titles on http://ciat.baserock.org/ seem a bit verbose | 11:34 |
| tlsa | | Integrate | Build | Image | Test | Publish | | 11:35 |
| tlsa | is what I'd have | 11:35 |
| tlsa | and also, s/C.I.A.T.: // | 11:35 |
| *** zoli__ has joined #baserock | 11:47 | |
| *** paulw has quit IRC | 11:48 | |
| pedroalvarez | tlsa: yup | 11:50 |
| pedroalvarez | i agree | 11:50 |
| tlsa | So I'd keep those titles to a minimum, like my suggestions above, and below the visuslisation, have a heading like "What is it?" and then a few sentences saying what it is, and why its useful. Because at the moment its not clear to any visitor that its actually demonstrating automated updating to latest kernel and systemd versions, and showing whether the tests still pass with those updates | 11:51 |
| *** paulw has joined #baserock | 11:51 | |
| toscalix | tlsa: I am willing to try that approach | 11:54 |
| toscalix | I would like to make sure though that we work on those changes in the dev instance: http://ciat.baserock.org:8888/#/ not directly in production | 11:54 |
| ssam2 | i didn't know it was doing that :-) | 11:54 |
| toscalix | wdutch: please work on the changes in the dev instance before pushing them into production | 11:55 |
| paulsherwood | s/Image/Deploy/ imo | 11:55 |
| toscalix | deploy is a word I would avoid | 11:55 |
| paulsherwood | i heard that. i don't know why | 11:56 |
| paulsherwood | it's a sensible choice imo. | 11:56 |
| toscalix | integration - delivery - deploy | 11:56 |
| toscalix | deployment | 11:57 |
| tlsa | paulsherwood: it creates images. Deploy could mean uploading images some to hardware/VMs somewhere | 11:57 |
| tlsa | which isn't what's happening | 11:57 |
| toscalix | if you add the word deploy in the integration stage, we are introducing confusion, in my opinion | 11:57 |
| paulsherwood | deploy means take the result of build, and put somewhere interesting, that's all | 11:58 |
| toscalix | for us, but for those who control a production process, it is the last stage of the production pipeline | 11:58 |
| paulsherwood | i think you just used 'integration' confusingly, though :) | 11:58 |
| paulsherwood | tlsa: maybe, for some people. all of these words are open to misuse. | 11:59 |
| paulsherwood | sorry, s/tlsa/toscalix/ | 11:59 |
| tlsa | paulsherwood: it doesn't put it anywhere intersting it puts it somewhere temporary so that the test code can get at it. After successful test it would "Publish" | 11:59 |
| paulsherwood | that's interesting in that it allows the test code to get at it :) | 11:59 |
| paulsherwood | but, whatever. | 12:00 |
| richard_maw | :D the names of the steps link to the sections in the wiki | 12:00 |
| tlsa | to me "Deploy" would be reserved for "Shove out to custormers" | 12:00 |
| paulsherwood | image is not better. provisioning is not better. deploy is what we've been calling this step for several years afaik | 12:00 |
| toscalix | wdutch: do you want to try tlsa approach on the UI? | 12:00 |
| paulsherwood | tlsa: all these words have multiple meanings | 12:01 |
| tlsa | paulsherwood: `morph deploy` can actually deploy to VM images on openstack or KVM though | 12:01 |
| tlsa | I would argue Image is less ambigious. It can't mean anything more than "To image" | 12:02 |
| paulsherwood | tlsa: yup. and deploy should be the command run in this step, i think? unless there's been some good reason to reinvent clusters+ deploy? | 12:02 |
| toscalix | we are not trying to solve the "naming problem" that the project might have but trying to reach a wide audience with the demo. So we should try to use those words that most people understand. | 12:03 |
| toscalix | and by Deploy most people will think about the last stage of the production pipeline, in my opinion | 12:03 |
| toscalix | now if we use it for a different thing.... fine. But I do not believe it is a matter of being right or wrong but about being understood | 12:04 |
| toscalix | I also think that is not a big issue since we are already using many words that are not widely used out there | 12:04 |
| toscalix | which increases the adoption barrier, by the way | 12:04 |
| toscalix | This is one of the areas in which we need to work on | 12:05 |
| paulsherwood | don't get me started :) | 12:05 |
| toscalix | jajajaja | 12:05 |
| toscalix | no no... it is not the right time | 12:05 |
| toscalix | :-) | 12:05 |
| *** jonathanmaw has quit IRC | 12:05 | |
| paulsherwood | i tagged ybd 15.40 if folks are interested... it should be slightly tidier and very slighlty faster than 15.38 | 12:06 |
| tlsa | paulsherwood: "deploy" being the command to run it (just in morph?) is not really relevant to a visulisation thing like that. It's an implementation detail of the back end | 12:06 |
| paulsherwood | tlsa: point is, i've had to explain what baserock does several hundred times. deploy is the best word to use imo. | 12:07 |
| paulsherwood | our naming problems are more at the morph/strata/morphologies level, imo | 12:07 |
| * paulsherwood gives up, shuts up, and contemplates how to be in a joyful place for his talk at ELCE | 12:08 | |
| tlsa | right, that makes sense when talking about baserock, because morph/ybd *can* deploy to particular targets. The point I'm making is only that that step of the ciat pipline is purely "glob the last build into an image", and not anything clever like deployment to something | 12:09 |
| paulsherwood | maybe currently... but in general, this step will have to deploy | 12:10 |
| paulsherwood | (eg to a test farm) | 12:10 |
| toscalix | This is something I gave some thought about | 12:11 |
| tlsa | I think you'd need a separate test controller to manage sheduling. E.g. are any test hosts free atm, if not queue the test up until something is avialable | 12:11 |
| toscalix | how to reflect what we are shoing tomorrow compared to where we want to go | 12:11 |
| toscalix | This is why CIAT description is divided in two sections in the wiki page: design and actual implementation | 12:12 |
| tlsa | so I'd still expect: create an image, let the test controller shedule appropriate testing of said image | 12:12 |
| toscalix | if currently is not clear, feel free to edit the wiki page. I am sure it can be improved | 12:12 |
| toscalix | hopefully, tomorrow, wed and thu we will be able to discuss what tasks should come next on ciat | 12:14 |
| toscalix | and describe them so somebody can evaluate its effort in the future (or maybe we can do it ourselves) | 12:15 |
| *** gary_perkins has joined #baserock | 12:16 | |
| Zara | what's the difference between the deploy/provisioning/image step and a completed 'build' step? is it necessary at the moment? seems like they're saying the same thing. | 12:16 |
| toscalix | VM creation | 12:17 |
| tlsa | Zara: Build compiles all the bits, Image sticks the built artifacts into a bootable disc image | 12:17 |
| richard_maw | Zara: at the moment it's not 100% necessary, but we need to be able to support heterogenous deployments later | 12:17 |
| richard_maw | Zara: so we need to build the systems on multiple architectures and store the artifacts centrally | 12:18 |
| richard_maw | Zara: then a later deployment can put something together made up of multiple systems | 12:18 |
| richard_maw | Zara: from different architectures | 12:18 |
| toscalix | we might event want to test on bare-metal at this stage | 12:18 |
| richard_maw | Zara: It's kept separate at the moment so that we can more easily see progress through the pipeline's stages, and so we don't implement ourselves into a corner by relying on the assumption that it's deployed and built together. | 12:19 |
| richard_maw | Zara: has my explanation made any sense ☺? | 12:20 |
| Zara | ah, okay, that makes sense. personally, I'd go with 'image' for now, since it seems like a separate step from deployment. (if the arguing continues then hide it. =D) | 12:20 |
| Zara | (there are bits I still don't understand fully but I think I get enough to know how to name steps on the GUI at this point.) | 12:21 |
| richard_maw | grand ☺ | 12:21 |
| Zara | I think it's a useful distinction to make (seems like you could deploy all sorts of combinations of images, which is cool), so it makes sense to preserve it in the UI-- the tradeoff, to me, is space | 12:22 |
| Zara | *GUI | 12:22 |
| Zara | (as in, space on the screen to show the information, nothing deeper than that) | 12:23 |
| *** zoli__ has quit IRC | 12:23 | |
| Zara | (sorry, not combinations of images; things that are currently stuck together to make an image) | 12:25 |
| toscalix | I am fine with changing Image creation for Image | 12:25 |
| toscalix | In the same line, Publish instead of publish candidate | 12:25 |
| toscalix | if we add some description text | 12:25 |
| toscalix | when we discussed this on Friday, we made the assumption that we would not have time to add that text | 12:26 |
| tlsa | use the headdings I suggested earlier :) | 12:26 |
| toscalix | in the UI | 12:26 |
| *** zoli__ has joined #baserock | 12:26 | |
| tlsa | (at 12:35) | 12:27 |
| toscalix | tlsa: I lost context, can you add again the proposal? | 12:27 |
| toscalix | ok | 12:27 |
| toscalix | Integrate | Build | Image | Test | Publish | I do not agree with the fourth one. And I think that publish candidate provides more context than just publish. I can live with Image instead of image creation | 12:28 |
| toscalix | we do not loose much and we simplify the text | 12:28 |
| toscalix | the word candidate is very relevant | 12:29 |
| toscalix | in terms of the process | 12:29 |
| toscalix | and we are not just testing....we have also to deal with the provisioning stage | 12:29 |
| richard_maw | yep, since without candidate it doesn't imply the human step | 12:29 |
| toscalix | currently we are creating a VM, deploying it in a VM fam (aka cloud). But we might also deploy it in a physical farm of ARM boards | 12:30 |
| * richard_maw filled out the text for Publish candidate with what he thinks it should do | 12:30 | |
| tlsa | what actually gets "published"? | 12:31 |
| toscalix | richard_maw: thanks | 12:32 |
| richard_maw | tlsa: nothing yet | 12:32 |
| richard_maw | tlsa: it's a stub | 12:32 |
| toscalix | Can we agree then in reducing Image creation for Image? | 12:32 |
| richard_maw | tlsa: eventually I think it should be a report describing what the change was and where to get all the artifacts for any manual testing | 12:33 |
| toscalix | it should also include the logs, potential metadata associated to the process, all of it signed, maybe encrypted....how to publish depends a lot on the context | 12:34 |
| toscalix | release notes, licenses... | 12:34 |
| *** gary_perkins has quit IRC | 12:35 | |
| toscalix | ideally, a candidate should include anything that requires verification and validation | 12:35 |
| tlsa | richard_maw: it that case its publishing a report, not publishing a candidate | 12:35 |
| richard_maw | tlsa: it's a report about the candidate | 12:35 |
| tlsa | the point is publish isn't special | 12:36 |
| tlsa | build, image, and test are all for the candidate too | 12:36 |
| toscalix | we need to assume that the integration is done by different people than the verification and validation. Potentially it can be done by a different provider | 12:36 |
| richard_maw | hm, so that makes part of the human pipeline afterwards then | 12:37 |
| tlsa | the pipeline manages candidates, so I don't like "Publish candidate" | 12:37 |
| *** paulw has quit IRC | 12:38 | |
| toscalix | tlsa: no, a candidate is the succesful outcome of the pipeline | 12:38 |
| toscalix | the pipeline can manage, for instance, partial integrations | 12:39 |
| toscalix | of specific changes | 12:39 |
| tlsa | I don't know what that means | 12:39 |
| toscalix | that would not be considered a candidate for those doing performance testing in the validation stage | 12:39 |
| toscalix | with real hardware | 12:40 |
| Zara | +1 for 'Publish'; if an audience is unlikely to assume it refers to the 'candidate' (a term I personally think should be avoided, since it's vague), it sounds complex enough that it will need explaining in a description and not in a heading. | 12:41 |
| toscalix | think about a release candidate from a current distro | 12:41 |
| toscalix | Zara: I think everything column requires some short explanation but in terms of effort, it was out of scope until Friday. I will talk to wdutch after lunch to evaluate if it is possible to include it | 12:42 |
| toscalix | what we decided was to link to the wiki page for context | 12:43 |
| tlsa | I'dd still title the thing "Publish" in the visulisation ... that's NOT the place for details. Add a pargaraph below to say "This pipleine publishes upgrade candidates that have successfully built and passed their tests." | 12:43 |
| toscalix | tlsa: I still do not agree | 12:43 |
| toscalix | :-) | 12:43 |
| tlsa | graph legends are not the place for essays | 12:43 |
| toscalix | the wiki is not the place for details: I agree | 12:44 |
| tlsa | you have descriptive text around a chart, not in it | 12:44 |
| toscalix | tlsa: let's do one thing, send an e-mail with your proposal. We will discuss tomorrow morning the alternatives we have for the future. We want to finish this project milestone with a description of what it should come next | 12:45 |
| wdutch | why is the wiki not the place for details? | 12:45 |
| toscalix | we all agree that the current UI is far from perfect | 12:45 |
| toscalix | wdutch: it wold be better to have a short description in the UI itself | 12:46 |
| Zara | if this needs a lot of words to explain, you still need short titles and a bigger explanation elsewhere (I am assuming whomever is giving this demo is going to explain it as they go along). The elsewhere can be anywhere at all, as long as it's easy to find. if it doesn't need a lot of words, you definitely don't need long titles. | 12:46 |
| toscalix | and provide the complete details in the wiki. Now we are kind of half way through | 12:46 |
| tlsa | wdutch: you need enough info on a page for a visitor to think "ooh, useful, I'll look for more info", rather than *boggle* | 12:46 |
| wdutch | toscalix: I agree with tlsa, that page is a view of the pipeline, like a graph | 12:46 |
| wdutch | tlsa: +1 | 12:47 |
| toscalix | and I agree with tlsa that we can do better than the current solution. I am just saying that we took decisions that led to this result based on the time and expertise we had, assuming the limitations we faced. | 12:48 |
| *** paulw has joined #baserock | 12:48 | |
| toscalix | so the question is, what can we do about it today. And what should we do in the near future to improve the UI | 12:48 |
| *** zoli__ has quit IRC | 12:48 | |
| wdutch | that seems irrelevent to the point of keeping lane headings short | 12:48 |
| Zara | :) | 12:49 |
| toscalix | Zara and tlsa has made good point about how things should look like. I am sure there are other suggestions too. The deadline of the project has been pushed 3 days forward to have these discussions and to document the next steps | 12:49 |
| toscalix | because we all agreed a few weeks ago that this was just a setp forward in the direction we all want | 12:50 |
| toscalix | wdutch: there is a compromise between keepoing the heading short and providing context. Pedro and I were aware of that | 12:51 |
| toscalix | and we agreed that providing a description on the UI or the dialogs was not the right approach given the time we had | 12:51 |
| wdutch | I don't see it as a case of context vs short headings. The point I am making is that the context should not be in the lane headings, it should be elsewhere | 12:51 |
| toscalix | so we decided to sacrifice the "short headings approach" | 12:52 |
| wdutch | who's 'we'? | 12:52 |
| toscalix | wdutch: but we all agree in the last meeting that the lack of context was the main weakness of the UI | 12:52 |
| toscalix | so that is the main argument we have tried to face | 12:52 |
| toscalix | you were in a meeting in which Bruce pointed at this as a weakness, and Daniel, Paul, Pedro and myself agreed. I said explicitely that Pedro and I would try to work it out | 12:53 |
| toscalix | so by we I refer....all of those directly involved in the project | 12:54 |
| toscalix | that attended to the deadline meeting | 12:54 |
| toscalix | last Thursday | 12:54 |
| wdutch | again, I am not saying we should have less context overall, just that headings are not the place to be verbose | 12:54 |
| toscalix | wdutch: I agree with you. But since we could do very little, we decided to work it out in the headings | 12:55 |
| wdutch | anyway I have better things to do than argue about this bikeshed | 12:55 |
| toscalix | if you can come with a better place that can be done before tomorrow at 12, I am open to discuss it | 12:55 |
| toscalix | Pedro did not find any better one, and me either | 12:56 |
| toscalix | wdutch: we all do | 12:56 |
| Zara | I thought this was for a demo? the context is the person explaining things.... unless it's going to be presented in silence? | 13:01 |
| *** gary_perkins has joined #baserock | 13:03 | |
| toscalix | Zara: it is a demo, but the service is live...and it will remain | 13:06 |
| toscalix | so we need a self-explanatory approach too | 13:06 |
| toscalix | in the near future | 13:06 |
| tlsa | that's why I suggested a "What is it?" section below the chart, with a quick description and link to wiki page for more info | 13:07 |
| wdutch | what's the process for ciat-ui dev moving to the not-dev one? | 13:08 |
| jjardon | gtristan: yeah, you can create different morph files, but that means you have to duplicate all the strata on top on top of that one :/ | 13:09 |
| gtristan | jjardon, I see, I was thinking one might be able to cascade that... only overriding bits of the 'general' one in a more specific morph | 13:10 |
| ssam2 | I think everyone would like the .morph format to allow some kinds of conditional substitution in future | 13:23 |
| ssam2 | i'm not so sure about overriding (you can use bitbake if you like being able to override everything at any time :-) | 13:24 |
| ssam2 | but certainly, having one .morph file that can build 2 or more variants of the same component would be super useful | 13:24 |
| *** zoli__ has joined #baserock | 13:27 | |
| edcragg | on a related note, i was thinking today, would there be any scope for includes in definitions? | 13:30 |
| edcragg | for base/build/devel systems, for example | 13:31 |
| edcragg | or sets of strata for particular purposes | 13:33 |
| edcragg | i know that's already kind of how it works, but | 13:36 |
| *** paulw has quit IRC | 13:37 | |
| gtristan | ssam2, sure... was just writing email intensely :-/ ... have to get dinner now hehe | 13:39 |
| *** paulwaters_ has joined #baserock | 13:44 | |
| *** gtristan has quit IRC | 13:50 | |
| toscalix | wdutch: I put an eye on it and approve if it is a relevant change. If it is something small we already agreed on, it is fine to move it into production | 13:50 |
| toscalix | tlsa: we dropped the idea on Thursday because of 1.- lack of time and 2.- design skills to do it right | 13:53 |
| *** paulwaters_ has quit IRC | 14:00 | |
| ssam2 | edcragg: it's been proposed more than once to 'flatten' the object heirarchy | 14:04 |
| ssam2 | edcragg: so that instead of 'strata include chunks, systems include strata', you can have 'thing with build instructions that is built from source code' and 'thing that is composed of other things that were already built' | 14:04 |
| ssam2 | which is just a more flexible equivalent of what we already have | 14:05 |
| ssam2 | i think it makes sense to do that. the hard part is agreeing on a better name than 'thing made from other things' and 'thing built from source code' :-) | 14:05 |
| ssam2 | is that what you were thinking of when you talked about 'includes', or something else? | 14:05 |
| *** petefoth has joined #baserock | 14:07 | |
| Zara | a nice feature of baserock is that the description of the location of the source is separate from the build instructions-- this generally makes it much quicker to update a component in definitions. I've wondered about how that would feature be preserved if strata were no more. | 14:07 |
| Zara | *feature would be | 14:07 |
| Zara | not sure how I switched that round, hehe | 14:08 |
| ssam2 | it could work the same way | 14:09 |
| ssam2 | we don't need to remove any existing functionality if we don't want to | 14:09 |
| ssam2 | but maybe now strata could include other strata as well, as a first step | 14:09 |
| Zara | cool, I like that. | 14:10 |
| paulsherwood | 'strata were no more' - my suggestion is to find better names, and support proper nesting, not scrap the grouping concept altogether | 14:12 |
| Zara | I'm probably out of date, then; I think this was floated at some point but it was a few months ago. | 14:12 |
| Zara | I wasn't thinking of the most recent email on reorganising definitions. | 14:13 |
| Zara | ... and it's always possible that I also got the wrong end of the stick a few months ago. :) | 14:13 |
| paulsherwood | i started attempting to scrap 'strata' as a word over a year ago :) | 14:14 |
| * pedroalvarez loves CIAT status bars | 14:16 | |
| paulsherwood | +1 | 14:17 |
| Zara | (I've been grumbling about baserock terminology for nearly a year myself, at this point! Though I think 'strata' is the nicest of the lot...) | 14:19 |
| paulsherwood | 'Provision and Test' is too long... wraps for me. choose a word. | 14:19 |
| paulsherwood | Zara: lol :) | 14:19 |
| *** gtristan has joined #baserock | 14:25 | |
| tlsa | it should just be "Test" | 14:30 |
| tlsa | I don't know what provision even means in that context, and I wrote the test stuff :) | 14:31 |
| Walkerdine | Does baserock complain if there is a syntax error? | 14:35 |
| paulsherwood | it should do | 14:35 |
| pedroalvarez | tlsa: before running any test, you have to provision the hardware, or VM or whatever with the image to be tested | 14:38 |
| tlsa | the chart label is not the place for implementation details | 14:38 |
| pedroalvarez | it may be a good idea to remove it, what we wanted to do is remove it from the (now) Image Creation lane, because that wasn't "provisioning" | 14:39 |
| pedroalvarez | tlsa: I agree | 14:39 |
| tlsa | and even with "provision" there, it's not clear that it refers to the provision of testing infrastructure | 14:39 |
| tlsa | it could equally be provisioning of thing to be testing | 14:39 |
| tlsa | *tested | 14:39 |
| edcragg | ssam2: yes, i think that fits with what i was thinking. So the current chunks, strata and systems fall into the first category of things derived from source, which could then be assembled into a higher order thing equivalent to a system? | 14:40 |
| tlsa | the chart should jus be showing whether its currently testing something and whether the last test passed or failed. Anything to do with provisioning of test infrastructure is not relevant and putting it in headings just adds to confusion | 14:41 |
| edcragg | ssam2: how about 'rocks' and... a 'rockery' :P | 14:41 |
| Walkerdine | I'm just trying to raw write a register at this point. I'm guessing I have to use a specific function/macro to do so? | 14:47 |
| toscalix | tlsa: you do not provision the testing infrastructure | 14:50 |
| toscalix | you provision the OS to a service | 14:50 |
| toscalix | the service in this case is testing | 14:51 |
| toscalix | it could be a different one. Provisiong = "making available, on demand and at scale" | 14:53 |
| tlsa | toscalix: it can be either, as pedroalvarez and I discussed earlier. The point is 1. its ambigious, 2. the chart legend is not the place for it | 14:53 |
| edcragg | Walkerdine: are you still trying to use gpio? where are you trying to do this from? | 14:58 |
| Walkerdine | In the init in linux | 14:59 |
| edcragg | Walkerdine: in kernel, or in userspace? or just at system startup? | 15:03 |
| Walkerdine | System start up I believe | 15:03 |
| edcragg | you could use device tree to set a start-up state for a particular gpio at startup | 15:04 |
| toscalix | I disagree with 1. I agree with 2. only in the context of a UI that provides a clear context of what is happening | 15:05 |
| toscalix | which is not the case | 15:05 |
| edcragg | Walkerdine: or build a kernel with CONFIG_GPIO_SYSFS enabled, so you can then use sysfs to set the gpio from userspace once the system has started | 15:06 |
| Walkerdine | Where would that be at | 15:07 |
| Walkerdine | I think I tried that but nothing showed up | 15:07 |
| edcragg | you mean the sysfs entry? | 15:07 |
| Walkerdine | Would that be the tegra_defconfig file? | 15:07 |
| Walkerdine | yeah gpio didn't show up in /sys/class/ | 15:08 |
| *** zoli__ has quit IRC | 15:08 | |
| paulsherwood | any ideas what could cause 'mknod: ‘/vagrant/src/tmp/tmpgfQezi/dev/null’: Operation not permitted' when run as root? | 15:09 |
| pedroalvarez | Walkerdine: that would be in "strata/bsp-jetson/linux-jetson-tk1.morph" in definitions.git | 15:10 |
| edcragg | Walkerdine: it may or may not be in the defconfig. you could grep the .config file generated when the kernel was built, i.e. `grep CONFIG_GPIO_SYSFS .config` | 15:10 |
| Walkerdine | I asked that because thats the file I changed | 15:11 |
| Walkerdine | Its doing another build right now so I will check in a bit | 15:12 |
| *** mariaderidder has quit IRC | 15:14 | |
| *** mariaderidder has joined #baserock | 15:14 | |
| edcragg | Walkerdine: add a '- scripts/config -e CONFIG_GPIO_SYSFS' to linux-jetson-tk1.morph and that should probably do the trick | 15:16 |
| Walkerdine | Wow you're probably right | 15:17 |
| Walkerdine | I should probably just scrap this current build | 15:18 |
| SotK | would an "About" page be useful in the CIAT UI, to provide the missing context? | 15:23 |
| toscalix | SotK: it is a good idea. The problem is to implement it at this point. | 15:26 |
| toscalix | tomorrow is the demo and we do not want to change anything tomorrow unles neccesary | 15:27 |
| Walkerdine | I feel like that should be enabled by default for the jetson | 15:28 |
| *** zoli__ has joined #baserock | 15:30 | |
| SotK | toscalix: simplest way would be to put some content in an "about.html" in the directory the UI is served from, and put a link to it on the main page somewhere | 15:31 |
| *** zoli__ has quit IRC | 15:31 | |
| toscalix | wdutch: will you be able to do that? | 15:31 |
| *** zoli__ has joined #baserock | 15:34 | |
| wdutch | I could put a link ... I can't guarantee I can design a good page or write any content | 15:35 |
| toscalix | thank you wdutch | 15:35 |
| wdutch | ... | 15:37 |
| toscalix | this is something we would need to talk about and it is too late at this point. We will stick to the plan and discuss tomorrow the alternatives that we have discussed today to improve the UI in the next round | 15:38 |
| toscalix | if tomorrow morning Kinnison wants to go for it, we might | 15:39 |
| *** zoli__ has quit IRC | 15:40 | |
| Zara | Ah, Kinnison's managing this? | 15:40 |
| toscalix | from the tech perspective, yes. He is not available today though | 15:40 |
| Zara | I'm just wondering whom to bill the team's doughnuts to. | 15:41 |
| *** zoli__ has joined #baserock | 15:43 | |
| *** zoli__ has quit IRC | 15:44 | |
| *** gary_perkins has quit IRC | 15:46 | |
| myself | I was not informed there would be doughnuts.. | 15:49 |
| *** gary_perkins has joined #baserock | 15:51 | |
| *** gary_perkins has quit IRC | 15:55 | |
| *** gary_perkins has joined #baserock | 15:57 | |
| *** mariaderidder has quit IRC | 15:58 | |
| *** gary_perkins has quit IRC | 16:09 | |
| *** ssam2 has quit IRC | 16:10 | |
| * paulsherwood neither | 16:30 | |
| Walkerdine | Finally I can control pins! | 16:57 |
| edcragg | \o/ | 16:57 |
| * myself cowers in fear as Walkerdine's robot army stirs | 16:58 | |
| SotK | Walkerdine: excellent :D | 16:58 |
| *** zoli__ has joined #baserock | 16:58 | |
| Walkerdine | I can't believe all I had to do was add a line to the morphology | 16:59 |
| myself | So I was on the right track with the sysfs, just not up to speed on morph. I only feel half clueless today! | 16:59 |
| Walkerdine | I knew I had to enable that somewhere I just didn't know I had to do it in the morph | 17:00 |
| *** bashrc has quit IRC | 17:02 | |
| pedroalvarez | Walkerdine: send it for review! | 17:05 |
| pedroalvarez | :) | 17:05 |
| pedroalvarez | Walkerdine: it's actually the same effort for doing a variety of things, like upgrade the version of a given component | 17:06 |
| Walkerdine | How do I do that | 17:14 |
| *** edcragg has quit IRC | 17:15 | |
| SotK | Walkerdine: In the stratum morphology that contains the component (should be pretty easy to find by grepping) there is an entry in the "chunks" list for the component. That entry has a SHA1 "ref" field which is the SHA of git repo defined by the "repo" field in the same entry. To update to a new version, you just change that SHA to point to the SHA of the version you want. | 17:19 |
| Walkerdine | I meant send it for review but that is also good to know | 17:22 |
| SotK | aha! sorry :) | 17:22 |
| SotK | Do you have an account on gerrit.baserock.org? | 17:23 |
| Walkerdine | I do not | 17:23 |
| SotK | OK, it uses OpenID but I believe only accepts our own instance of it as provider. You can make an account for that here: https://openid.baserock.org/accounts/register/ | 17:25 |
| SotK | Then just click sign in in the top-right of gerrit.baserock.org and it will ask you for your OpenID credentials | 17:26 |
| Walkerdine | what exactly is openid | 17:32 |
| SotK | federated authentication, so you can log in in a single place which can then verify your identity to other things I believe | 17:33 |
| * SotK has to head off, this link should help with sending stuff for review: http://wiki.baserock.org/contributing/ | 17:33 | |
| nowster | https://en.wikipedia.org/wiki/OpenID | 17:34 |
| jjardon | Hi, anyone around to review https://gerrit.baserock.org/#/c/1156 ? | 18:11 |
| *** zoli___ has joined #baserock | 18:40 | |
| *** zoli__ has quit IRC | 18:40 | |
| *** zoli__ has joined #baserock | 19:00 | |
| *** zoli___ has quit IRC | 19:00 | |
| *** zoli___ has joined #baserock | 19:35 | |
| *** zoli__ has quit IRC | 19:35 | |
| SotK | jjardon: +1 from me | 20:20 |
| jjardon | SotK: thanks! | 20:20 |
| jjardon | need that to upgrade pango so we not need the integration commands anymore | 20:21 |
| jjardon | (modules have been removed in the new pango release) | 20:21 |
| *** persia has quit IRC | 20:53 | |
| *** persia has joined #baserock | 20:54 | |
| *** persia has quit IRC | 20:54 | |
| *** persia has joined #baserock | 20:54 | |
| *** toscalix has quit IRC | 21:31 | |
| *** zoli___ has quit IRC | 21:40 | |
| *** zoli__ has joined #baserock | 21:41 | |
| *** zoli__ has quit IRC | 22:07 | |
| *** zoli__ has joined #baserock | 22:07 | |
| * SotK throws http://217.44.72.233/about.html together from the wiki | 23:04 | |
| pedroalvarez | SotK: oh! nice | 23:12 |
| pedroalvarez | wdutch, check with toscalix tomorrow if he likes this ^ and ponder cherry-picking the change: | 23:19 |
| pedroalvarez | https://github.com/ColdrickSotK/baserock-ciat-ui/commit/38811c2421a29f6e521629a04d7d3ac7905bf2c8 | 23:19 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!