| *** donbrown has quit IRC | 02:40 | |
| *** donbrown has joined #cip | 03:45 | |
| *** patersonc has joined #cip | 05:00 | |
| *** rajm has joined #cip | 07:19 | |
| *** toscalix has joined #cip | 07:30 | |
| toscalix | good morning rajm | 07:47 |
|---|---|---|
| toscalix | where do you think we should place the howto created by donbrown ? | 07:48 |
| *** bananadev has joined #cip | 07:52 | |
| rajm | maybe we need a page on building advice which can cover more than just this? | 07:52 |
| toscalix | for somebody that approach the tool and our docu for the first time, is this howto a "must read" or the tool can be used without going through these steps? | 07:57 |
| rajm | it depends whether we are going to provide an initramfs in a consistent location | 07:59 |
| toscalix | I believe you are in favour of doing so | 08:00 |
| toscalix | right? | 08:00 |
| rajm | which our provided tests link to (can argue that the BBB kernel also needs building) | 08:00 |
| rajm | I think but am open to being proved wrong(!) that we could put a version of all the artifacts within the provisioned box so that 'just works' (TM) | 08:01 |
| rajm | but that doesn't solve it for the folk building from git | 08:02 |
| toscalix | and we need to assume that the building process will be done with bitbake and debian tool externally | 08:02 |
| toscalix | so based on this, my original question still remains | 08:04 |
| toscalix | [09:56] <toscalix> for somebody that approach the tool and our docu for the first time, is this howto a "must read" or the tool can be used without going through these steps? | 08:04 |
| rajm | yes I think it's going to need to be a building page somewhere as part of the installing process which will need adding to with more building processes, maybe the kernel build from the testing page should be hived off there | 08:06 |
| toscalix | and which step should be this one in our critical path? Should these instructions be executed before connecting the board to the laptop or right before the user start testing? | 08:08 |
| rajm | before the user starts testing I think | 08:10 |
| toscalix | so 1.- deployment 2.- set up 3.- connect the board 4.- initiramfs 5.- test | 08:11 |
| rajm | yes though I think the kernel build should also go in (new) step 4 | 08:12 |
| toscalix | we will need to provide in our download service the kernel built | 08:12 |
| toscalix | yes, 4 should be about artifacts | 08:14 |
| rajm | so that both sets of users can access it - yes | 08:14 |
| toscalix | we will have the mailing list for sharing tests in a couple of days | 08:15 |
| rajm | \o/ | 08:15 |
| toscalix | I will create a new wiki page for step 4 so you can populate it and then modify the other wiki pages links to ensure the content critical path can be easily followed | 08:17 |
| rajm | thanks! | 08:18 |
| * rajm had 2 failing BBB health checks and then realised the USB cable was unplugged - HC then ran ok | 08:26 | |
| toscalix | rajm: can you go through https://gitlab.com/cip-project/cip-testing/testing/issues/105 and check if I missed something? | 08:35 |
| toscalix | poor david relow | 08:36 |
| * rajm reads | 08:37 | |
| rajm | *artifacts (in the text title is ok) thinks on whether adding a health check for the BBB is a good thing - it's now in step 2 and will need amendment depending on where the user puts initramfs - but I suppose it can link to our downloadable area so should be ok? | 08:41 |
| toscalix | ah, I forgot the titles must be changed | 08:41 |
| toscalix | checking what you mean... | 08:43 |
| toscalix | you mean that since the build now does not come by defect, it needs to be downloaded when using vagrant to build the VM? | 08:44 |
| rajm | the Configure the LAVA Health Check Jobs for both Devices section pastes in /vagrant/tests/bbb_debian_ramdisk_test.yaml it's all a question of what's in that file as urls | 08:44 |
| toscalix | step 11. | 08:44 |
| rajm | yes - though if we redo the health check links it should be ok | 08:45 |
| toscalix | keep an eye on that. I am crewating the page and adding links to it in several places | 08:46 |
| toscalix | artifacts or artefacts ? | 08:48 |
| toscalix | https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto new wiki page | 08:49 |
| *** kristerman has joined #cip | 08:54 | |
| rajm | artifacts - as the b@d uses that spelling elsewhere http://grammarist.com/spelling/artefact-artifact/ says we should use the 'e' variety but that makes the usages different | 08:54 |
| toscalix | ok, thanks | 09:00 |
| * rajm checks that the non local new BBB HC runs ok (so the one with fixed links to linaro rather than that using a local build) runs ok | 09:09 | |
| rajm | so toscalix at the moment I have a tests.tgz which I can checksum and sign - should I name it differently for uploading to the download area? | 09:10 |
| toscalix | I think so yes | 09:11 |
| rajm | tests-0.9.1-fix.tgz ? | 09:11 |
| rajm | ..and where to upload it to a new tests directory? | 09:12 |
| rajm | under the 0.9.1 hierarchy | 09:12 |
| toscalix | hummmm | 09:13 |
| toscalix | do you want to link the test number to the tool number? | 09:14 |
| toscalix | to me they are independent outcomes | 09:14 |
| rajm | Yes was about to say that, they should *just work* whatever the version | 09:14 |
| toscalix | I would start with 0,1 | 09:15 |
| toscalix | since it will change more often than the tool version | 09:15 |
| toscalix | or maybe by date | 09:15 |
| toscalix | thinking.... | 09:16 |
| rajm | so a version 'number' embedded in the file name - dates maybe a problem with americans getting confused if we use yyyy-mm-dd | 09:17 |
| toscalix | yyyy-mm-dd is a iso standard, I think | 09:17 |
| toscalix | so no confusion theree | 09:17 |
| toscalix | but the date works well with predictable releases | 09:18 |
| toscalix | but this is not | 09:18 |
| toscalix | predictable and frequent | 09:18 |
| rajm | I'm going to remove the notional 0.9.1 version on the frontend-config reference in features I added yesterday as it isn't there | 09:18 |
| rajm | yes the name is tricky | 09:19 |
| toscalix | is tests.... linked somehow to the kernel? | 09:20 |
| rajm | not if they're accessing the linaro verion there's a template test for use with locally built kernels but that's got non version specific placeholders | 09:24 |
| toscalix | ok, 0.1 for now | 09:25 |
| rajm | so tests-0.1.tgz | 09:25 |
| toscalix | builsd or tests? | 09:26 |
| toscalix | builds or tests? | 09:26 |
| rajm | it just contains tests - not sure why you think builds is an option? | 09:27 |
| toscalix | I find tests too generic | 09:27 |
| toscalix | can we be more specific? | 09:27 |
| toscalix | although I see the path /vagrant/tests/ | 09:28 |
| toscalix | fine then | 09:28 |
| rajm | yes that path was my logic - ok | 09:28 |
| toscalix | tests-0.1.tgz | 09:28 |
| rajm | d'accord! | 09:28 |
| toscalix | https://gitlab.com/cip-project/cip-testing/testing/boards/322796?&label_name[]=bug | 09:30 |
| rajm | and linked on the download page in a separate table? | 09:30 |
| toscalix | yes, different outcome | 09:31 |
| toscalix | different table | 09:31 |
| toscalix | in fact, different section | 09:31 |
| toscalix | let me check | 09:31 |
| toscalix | ah, no, we have the release column | 09:31 |
| toscalix | we can use that column to reflect a different outcome | 09:32 |
| toscalix | for now | 09:32 |
| rajm | not sure what you mean, add a new set of headers within that table? just before the public key link? | 09:35 |
| * rajm edits feature page to remove k-f-c version (that's an acronym with associations ;-) ) | 09:38 | |
| toscalix | yes, the left column would not be B@D but a different thing like tests | 09:39 |
| toscalix | I have added the link to the new bug board in several pages like the landing page and the known issues page | 09:52 |
| * rajm has added tests to the download page, now to add the text to known issues | 10:34 | |
| rajm | I've amended and added to the section in known issues - I will re-read and review after lunch! | 10:59 |
| *** bananadev has quit IRC | 11:25 | |
| rajm | and that review, and a few corrections , have been done | 12:07 |
| rajm | Unfortunately #103 has diverged into 2 streams, the initramfs and the provision of a tests download, redo the acceptance criteria? removing 0.9.2 and add boxes that can be ticked to mark what has been done? | 12:13 |
| rajm | though the initramfs has now been taken over or as a dependency by #105 | 12:14 |
| rajm | I've created a MR #30 so that the tests changes get back into git | 12:24 |
| toscalix | rajm: go ahead please. The ticket needs to reflect to task | 12:27 |
| toscalix | great about the MR | 12:27 |
| rajm | ok will fix it | 12:30 |
| *** patersonc has quit IRC | 15:07 | |
| *** rajm has quit IRC | 16:00 | |
| *** toscalix has quit IRC | 16:18 | |
| *** kristerman has quit IRC | 16:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!