| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 00:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 00:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:48 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 00:52 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 01:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 01:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 01:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 01:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 02:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:16 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 02:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:29 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 02:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:35 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 02:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:42 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 02:46 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 02:57 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 03:17 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:22 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 03:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 03:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 04:19 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 05:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 05:48 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:52 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 05:57 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:58 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 06:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 06:23 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:27 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 06:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:41 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:21 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:39 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| richard_maw | some time between 6PM last night and now the git service on git.baserock.org started failing to start new connections | 09:25 |
|---|---|---|
| richard_maw | the issue was that it had far too many git-upload-pack and git-daemon --serve processes running | 09:25 |
| richard_maw | restarting the git-daemon has fixed this issue for now | 09:25 |
| ssam2 | could be a lighttpd problem ? | 09:27 |
| ssam2 | I suppose most of use git:/// protocol directly rather than http:// | 09:27 |
| richard_maw | this wasn't a lighttpd service, this was the git protocol | 09:27 |
| ssam2 | right | 09:27 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 11:03 | |
| paulsherwood | very quiet here lately.... has morphs-in-definitions made it so easy we have nothing left to do? :0 | 12:06 |
| paulsherwood | :-) | 12:06 |
| richard_maw | I think it's just people either being on holiday or very busy | 12:08 |
| paulsherwood | fair enough :) | 12:09 |
| paulsherwood | i was thinking last night about how we can tidy up refs for chunks where we've added a morph file... | 12:12 |
| paulsherwood | and came up with a mechanism may address significant fraction of them... | 12:13 |
| paulsherwood | http://fpaste.org/127684/87095261/ | 12:13 |
| paulsherwood | my problem is i don't understand the morph codebase, not sure how best to approach implementing this kind of thing | 12:13 |
| paulsherwood | i wonder if there may be other similar use-cases - where a user wants to run some assessment on all chunks/strata/systems, then implmement processing on some subset | 12:14 |
| franred | paulsherwood, if Im not wrong what you want to do is modify the reference of one stratum if someone modify one chunk? does not morph edit do this? | 12:19 |
| richard_maw | Potentially, yes. The important bits you need for your script is read-only access to the chunk repository, a writable working tree of the definitions repository and enough information that you could locate the right chunk spec in the stratum | 12:21 |
| paulsherwood | franred: no - i want to run through all morphs, check if our only difference vs mainline is adding a .morph file, if so, put our ref back to mainline (since we now have morphs in definitions) | 12:21 |
| * persia isn't sure why it would be useful and/or interesting to take the churn from doing that to definitions. | 12:21 | |
| richard_maw | It would be possible to provide functionality similar in some ways to `git foreach` | 12:21 |
| paulsherwood | i want to do morph brach, run my script on definitions, publish the resuting diff as a patch for potential inclusion | 12:22 |
| richard_maw | a suitably flexible `morph for-each-chunk` command would allow you to write your script, but I can't say I think it's worth putting time into at the moment | 12:23 |
| persia | richard_maw: That does sound useful indeed: it overrides my uncertainty for the initial use case. | 12:24 |
| paulsherwood | richard_maw: i'm mainlg asking for guidance on how to do this - what datastructures would help etc. i'm not asking anyone else to write it :) | 12:27 |
| franred | could I fear that if you update the git repositories to the mainline you may will need to update the lorry files for the repos which are managed by svn and tarballs? | 12:27 |
| persia | franred: From the morph user perspective, I think we should pretend that lorry happens never to have that particular issue. | 12:28 |
| paulsherwood | franred: for this particular example, i'm suggesting las-common-ancestor, not mailnine yet | 12:28 |
| franred | paulsherwood, if you have a look to the script which change the definitions, you can see how to load morphologies and then you could work with python dictionaries - checking for the field that you need and updating the fields easily | 12:29 |
| paulsherwood | franred: ok, i'll look at that thanks | 12:29 |
| persia | The right solution is probably 1) to fake a git repo with history, tags, etc. for tarball lorries (which may be done), and 2) automate import of new tarballs or report issues (some of which may already be partially done) | 12:29 |
| * paulsherwood disappears | 12:29 | |
| richard_maw | paulsherwood: there's a SystemBranchDir class, you can create one with a file path, or tell it to use the system branch it can find from the current directory. | 12:31 |
| richard_maw | That can be used to tell you which is the root repository | 12:31 |
| richard_maw | you can pass that to the MorphologyFinder class, which will list all the morphology files you need to think about | 12:31 |
| richard_maw | the file paths can be passed to the MorphologyLoader class, to load morphology objects | 12:32 |
| richard_maw | if you put all the morphology objects in a MorphologySet, there's helper methods to manipulate the chunk specs, which are what you want to read and alter | 12:32 |
| richard_maw | the MorphologySet takes a couple of callbacks, one to filter out which specs you want to look at, another for actually making the change | 12:33 |
| richard_maw | To work out the merge base, you'll need to interface with the local repository cache. | 12:33 |
| richard_maw | I don't remember the details involved there off the top of my head, but I think you can give it a repository url, and it'll give you an object of what you have in the cache | 12:35 |
| richard_maw | you can run git operations on this object, so you can do your merge-base command | 12:35 |
| richard_maw | that would go into your filter callback | 12:35 |
| richard_maw | changing the ref would fo in the other callback you pass to the traverse method of MorphologySet | 12:35 |
| richard_maw | after the traverse method exits, it will have set a ".dirty" flag on morphologies that were changed, and you need to write back out again | 12:36 |
| richard_maw | the MorphologyLoader has methods for writing out morphologies in non-ugly formats, so you should use that, rather than just yaml.dump | 12:37 |
| richard_maw | This is roughly the processing that petrify and unpetrify did, and edit does | 12:38 |
| richard_maw | just, they don't need to look at the chunk repository, while you do | 12:38 |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 13:03 | |
| jjardon | hi, how is genivi-baseline-system-x86_64-generic configured to access the graphical interface? weston-launch doesnt seems to be available | 14:22 |
| jjardon | also, any idea why the drm backend is disabled? | 14:23 |
| richard_maw | jjardon: hm, I think you'll need a SotK or a pedroalvarez to answer that one | 14:25 |
| * jjardon wanted to test a series of patches to reorganize the wayland stratum and want to check they do not break anything | 14:29 | |
| jjardon | what checks should be done in these cases? | 14:29 |
| richard_maw | we care about Wayland for the genivi baseline and Jetson. On x86 genivi I think we may be using mesa, I'm not sure about Jetson | 14:40 |
| richard_maw | if you can launch weston on any backend after your changes it may be enough | 14:42 |
| jjardon | richard_maw: if I run "weston" in te terminal it fails complaining that /usr/lib/weston/drm-backend.so is not available.I took a look to the morph file and we disable this backend, thats why I asked | 14:45 |
| richard_maw | I think we set an environment variable to tell it to use a different backend | 14:45 |
| richard_maw | but I'm afraid I don't know which one | 14:45 |
| richard_maw | I'll see if it's documented on the wiki | 14:46 |
| jjardon | ah, ok. I will try to dig around, thanks! | 14:46 |
| ssam2 | jjardon: see the bottom of http://wiki.baserock.org/genivi/ | 14:46 |
| *** _nick [~nick@85.199.252.88] has joined #baserock | 14:49 | |
| *** _nick [~nick@85.199.252.88] has quit ["WeeChat 1.0"] | 14:49 | |
| jjardon | ssam2: thanks! that seems to work but now complains abou a non existant fame buffer device (/dev/fb0) Do you know if the x86 image is configured to use fb? | 15:03 |
| richard_maw | I recall something about needing a kernel command line | 15:05 |
| ssam2 | jjardon: hmm, I believe Pedro made the framebuffer work | 15:08 |
| jjardon | still, looking to the documentation (http://cgit.freedesktop.org/wayland/weston/tree/man/weston.man#n28) seems drm is the native backend, it would be good to know why it has been disabled | 15:09 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/tree/linux-x86-64-generic.morph?h=baserock/morph enables CONFIG_FB_VESA | 15:09 |
| ssam2 | jjardon: don't have a clue why we disable DRM and use FBDEV instead ... would DRM ever work under QEMU? | 15:10 |
| ssam2 | I believe some kernel arg is required to enable fbdev, in fact. | 15:10 |
| jjardon | no idea, will try next ;) | 15:10 |
| ssam2 | from http://wiki.baserock.org/genivi/: 'Note: We add KERNEL_ARGS: vga=788 to use the framebuffer with 16 bit colour depth at a resolution of 800x600. You can use vga=ask to to see all the possibilities and select a different one when booting the system.' | 15:11 |
| ssam2 | seems that when you deploy the x86 GENIVI baseline using the release.morph cluster morph it adds the required kernel args so the framebuffer works | 15:11 |
| jjardon | ssam2: will try but seems thats it, thanks. I will try to read the page more carefully next time | 15:14 |
| paulsherwood | are we doing the GENIVI baseline releases on tegra yet? | 15:25 |
| ssam2 | no, we don't do releases on Tegra yet :( | 15:32 |
| ssam2 | mainly because the tegra stuff isn't merged to master, I think | 15:33 |
| ssam2 | just a matter of someone spending a day to merge and test that branch, I think | 15:34 |
| paulsherwood | ssam2: it is merged | 15:34 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=e424935744d9faf27327ee40987620412c41716f | 15:35 |
| ssam2 | oh, so it is! | 15:37 |
| ssam2 | I missed that. | 15:37 |
| paulsherwood | we sneaked it in while you weren't looking :) | 15:37 |
| ssam2 | that includes all of the x components etc. and the wayland patch necessary to get Wayland running on Tegra ? | 15:37 |
| ssam2 | *x component updates | 15:38 |
| paulsherwood | i do not know, but radiofree has a devel system built that way | 15:38 |
| ssam2 | the devel system is good, but for GENIVI we really want Weston to work, no? | 15:39 |
| ssam2 | no reason we can't other than a little time, anyway, we should definitely do so for the next release | 15:39 |
| paulsherwood | well radiofree has the wyaland stuff working, for sure | 15:40 |
| ssam2 | I think the pain point actually is that Wayland etc. needs the 3.15 kernel | 15:40 |
| ssam2 | but the devel system needs the 3.10 NVIDIA kernel, because otherwise SATA, USB, and ethernet don't work | 15:40 |
| ssam2 | that's my understanding, it may be wrong :) | 15:41 |
| paulsherwood | ssam2: i think they all work on latest kernel, but there are some timing issues - compilations were oopsing | 15:42 |
| paulsherwood | so hence the braining of jetson as a devel system at http://wiki.baserock.org/guides/baserock-jetson/ is 3.10 | 15:43 |
| paulsherwood | but for folks interested in the exciting graphics stuff, they should be going for latest | 15:44 |
| paulsherwood | (as target) | 15:46 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:56 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:00 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:03 | |
| cyndis | usb2 should work, sata works if the device tree entry is added to the jetson device tree, pcie ethernet requires applying a patch series | 17:27 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:39 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:07 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 19:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:14 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 19:18 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:08 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 20:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:24 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 20:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:31 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 20:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 20:59 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 21:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 21:18 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 21:39 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 21:54 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 22:15 | |
| persia | I don't really understand the state of mason, but would it be possible to run a named test from an arbitrary repo in an instance? | 22:16 |
| persia | Essentially, I'd like to build a system, and then run my tests against it, whereas I have the impression the current script only runs the test to build new systems. | 22:17 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 23:07 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 23:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!