| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 240 seconds] | 04:02 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 04:03 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: No Ping reply in 180 seconds.] | 04:51 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 04:54 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:13 | |
| *** fay_ [~fay@82-68-191-81.dsl.posilan.com] has quit [Client Quit] | 07:13 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has joined #baserock | 07:44 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:10 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:20 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:20 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has joined #baserock | 08:46 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving...] | 08:52 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 266 seconds] | 08:53 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 264 seconds] | 08:53 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 08:54 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 08:56 | |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:06 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has joined #baserock | 09:07 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has joined #baserock | 10:07 | |
| *** stetaylor [~stetaylor@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving...] | 11:26 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 264 seconds] | 12:23 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has joined #baserock | 12:45 | |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Read error: Connection reset by peer] | 13:06 | |
| persia | Could someone remind me why we need different mesa for wayland and X? | 13:10 |
|---|---|---|
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has joined #baserock | 13:11 | |
| radiofree | we probably don't | 13:44 |
| radiofree | we could just use the configuration options that we currently use for the genivi baseline for all of them | 13:45 |
| radiofree | any arm system we currently build for it will be quite slow anyway | 13:47 |
| radiofree | jjardon: i don't really like the idea of mesa being in the wayland-generic stratum | 13:49 |
| radiofree | but i can't think of any better place to put it | 13:49 |
| radiofree | i suppose it's fine to just copy wayland-generic to wayland-imx6 or something if you want to replace mesa | 13:50 |
| persia | If we can use the same mesa for wayland and X, it would make sense to put it in an underlying stratum. | 13:50 |
| persia | Is there anything else that provides similarly low-level services that only makes sense for headed systems? | 13:50 |
| radiofree | wherever you put it, still won't get around the need to have to make a copy of it for specific boards | 13:51 |
| persia | Hrm? Why? | 13:51 |
| radiofree | i.mx6 for example, if you actually wanted the system image to be useful on those boards you'd want to replace mesa with some proprietary blobs | 13:52 |
| persia | Do you mean selecting which drivers to use? | 13:52 |
| persia | Somehow I thought mesa was coinstallable with the blobs, with a shared API. | 13:53 |
| persia | But if mesa is to be considered HW-specific, perhaps it makes sense to put it in the BSP strata. | 13:54 |
| radiofree | the jetson, we want to build the nouveau driver | 13:54 |
| radiofree | no it's pretty generic, but there's no mesa drivers for the vivante gpu for example | 13:54 |
| radiofree | so the gpu binaries from freescale are just a drop in replacement for mesa (i.e it provides EGL, GLES etc..) | 13:54 |
| persia | Does it not have runtime detection such that if the nouveau driver is installed on i.mx6 it is silently ignored? | 13:54 |
| jjardon | persia: configuration option, --with-egl-platforms=x11,drm in one case --with-egl-platforms=wayland,drm in the other | 13:54 |
| persia | jjardon: What happens if we have --with-egl-platforms=x11,wayland,drm ? | 13:55 |
| radiofree | i suppose mesa would need a bit more x? | 13:55 |
| radiofree | i don't know why we're building the drm drivers either | 13:56 |
| jjardon | persia: you can, and you we would only need one mesa | 13:56 |
| persia | Then why don't we do it that way? | 13:57 |
| radiofree | actually x-generic builds mesa with only "x-common", so i guess we don't need to add any more stuff to the wayland stratum | 13:58 |
| persia | Also, for i.mx6, can we not use xf86-video-msm? | 13:58 |
| radiofree | i've never used x on an i.mx6, i was thinking more about weston | 13:58 |
| radiofree | jjardon: might it be a good idea to split weston out from the wayland stratum as well? | 13:59 |
| persia | Does anyone use weston without wayland, or want wayland systems without weston? | 14:00 |
| * persia thought they were inextricably linked in some way | 14:00 | |
| radiofree | you can't use weston without wayland | 14:00 |
| rjek | I thought one was an implementation of the other. | 14:00 |
| rjek | (one spec, one impl.) | 14:01 |
| radiofree | wayland is the protocol, weston is an implementation of a wayland compositor | 14:01 |
| radiofree | for genivi, you might want to replace weston with layermanager, for example | 14:01 |
| persia | No. Wayland is the underlying system, and weston is a wayland client | 14:01 |
| radiofree | or mutter | 14:01 |
| persia | Doesn't the GENIVI spec require weston to be present? | 14:02 |
| radiofree | i don't know, it might do know, this weston-ivi-shell stuff | 14:02 |
| persia | Right. | 14:02 |
| radiofree | s/know/now | 14:03 |
| ssam2 | but for example GNOME on Wayland doesn't use Weston at all. Mutter (gnome-shell) is the Wayland compositor. | 14:03 |
| persia | Hmm. So maybe weston belongs in some GENIVI stratum, and can be dropped from the wayland stratum? | 14:03 |
| radiofree | [15:01:44] <radiofree> or mutter | 14:03 |
| ssam2 | oh | 14:04 |
| radiofree | wayland might be slightly lonely by itself though | 14:07 |
| persia | What else belongs with wayland, meeting the criteria that it doesn't make sense to have a wayland system without it, and it doesn't make sense to have a system with it without wayland? | 14:07 |
| radiofree | things like cairo, pango etc.. don't really belong in a "wayland stratum", since you don't need them to build wayland | 14:07 |
| persia | strata aren't just about build-depends. | 14:08 |
| radiofree | i don't know, it depends on what your wayland clients/compositor need | 14:11 |
| radiofree | i don't really like the idea of cairo, pixman etc.. being in the "wayland" stratum | 14:11 |
| jjardon | lets move them to a new graphics-common stratum? | 14:12 |
| radiofree | there are plenty of x projects that need them | 14:12 |
| radiofree | jjardon: +1 | 14:12 |
| jjardon | persia: weston is the reference implementation, genivi uses a modify version of weston. GNOME, KDE, enlighment ... have their own compositor implementation | 14:25 |
| rjek | Why? | 14:26 |
| rjek | (ie, why is there a need for more than one implementation?) | 14:26 |
| radiofree | genivi are, at least, implementing their stuff via weston plugins, so not reinventing the compositing side of it anymore | 14:29 |
| ssam2 | rjek: wrong channel, try #wayland :) | 14:32 |
| jjardon | rjek: good question, I dont know | 14:33 |
| ssam2 | probably the same reason we need multiple window managers, multiple desktop environments, multiple distros, multiple build systems | 14:33 |
| ssam2 | i.e. we don't. but life is messy | 14:33 |
| rjek | ssam2: There's only one X server, really... :) | 14:34 |
| jonathanmaw | rjek: really? by the name I expected 10 more to come before it :P | 14:34 |
| jjardon | I guess we do not need, but to support the current window managers in wayland (mutter, kwin) you have to convert them in compositors | 14:35 |
| * richard_maw wonders if there's any tiling wayland compositors | 14:36 | |
| Kinnison | richard_maw: http://www.reddit.com/r/linux/comments/1g7737/tiling_window_managers_for_wayland/ | 14:37 |
| richard_maw | so https://github.com/detomastah/adwc or a GNOME shell plugin according to that thread | 14:39 |
| richard_maw | http://gfxmonk.net/shellshape/ looks promising, and off topic | 14:40 |
| tlsa | initial mason CI/CD work posted to baserock-dev for review | 15:34 |
| paulsherwood | tlsa: do you mean you've just sent a series? i'm not seeing anything? | 15:40 |
| persia | I do | 15:40 |
| tlsa | I sent it to baserock-dev@baserock.org | 15:41 |
| paulsherwood | today? | 15:41 |
| persia | Yes. | 15:41 |
| tlsa | just a few mins ago | 15:41 |
| persia | from 1407339215-1906-1-git-send-email-michael.drake@codethink.co.uk | 15:41 |
| paulsherwood | aha... just got it. tvm | 15:41 |
| persia | tlsa: I don't understand 1/3: is this a missing part of the recent change to support UPSTREAM_TROVE_PROTOCOL, or something else? | 15:42 |
| tlsa | the previous change was to trove-setup.git to make it cabable of having that configurable | 15:43 |
| tlsa | the change there adds the config option to the trove cluster morphology stuff | 15:43 |
| persia | Ah, so this is the associated definitions change to use that. | 15:43 |
| tlsa | mm | 15:43 |
| paulsherwood | if i wanted to test this, are there instructions on what to do somewhere? | 15:44 |
| persia | Where is the definitions ref change? | 15:44 |
| persia | (to consume the updated trove-setup.git) | 15:44 |
| tlsa | paulsherwood: see morph-generator.sh's --help | 15:44 |
| paulsherwood | ok | 15:44 |
| paulsherwood | you mean mason-generator? | 15:45 |
| * persia suspects ./mason/mason-generator.sh --help` | 15:46 | |
| paulsherwood | +1 | 15:46 |
| paulsherwood | what's the policy on creating gbo repos now? i see deletion, not creation | 16:00 |
| * paulsherwood would like to add seL4, as a challenge :) | 16:01 | |
| Kinnison | what is sel4 ? | 16:06 |
| Kinnison | oh it'll be an L4 thing | 16:06 |
| richard_maw | you want to build an entirely different Kernel? | 16:08 |
| rjek | Kinnison: It uses Haskell to help prove its correctness. Might of interest to you | 16:10 |
| Kinnison | rjek: I'm horrified and yet strangely aroused | 16:12 |
| richard_maw | let's try to keep this channel work safe | 16:13 |
| paulsherwood | :) | 16:15 |
| rjek | seL4 is not only proven correct to its specification, I believe it's the only kernel ever to have its worst possible response time proven (and thus the only real time OS in existance :) | 16:15 |
| paulsherwood | yes, i want to build a completely different kernel. looks like it's only arm32 | 16:15 |
| rjek | paulsherwood: I think there's an x86 version too. | 16:15 |
| rjek | Although I've not looked that closely. | 16:15 |
| persia | I think the policy for repo creation is mostly about getting the lorry approved. | 16:15 |
| persia | So sel4 shouldn't be an issue. | 16:16 |
| paulsherwood | rjek: not from what i can see - https://github.com/seL4/seL4 | 16:17 |
| paulsherwood | persia: i normally sneak my lorries in while no-one is looking :) | 16:17 |
| rjek | paulsherwood: https://github.com/seL4/seL4/tree/master/src/arch/ia32 suggests it has x86 support. | 16:17 |
| rjek | or at least some | 16:17 |
| richard_maw | paulsherwood: which we all frown at you for | 16:18 |
| * paulsherwood can frown, too :) | 16:18 | |
| paulsherwood | most of my lorrying happens at weekends - having to get approval would kill my enthusiasm | 16:19 |
| paulsherwood | i've begun experimenting with forking on github, but it's not the same :) | 16:19 |
| * Kinnison suggests you spool up and run your own trove | 16:20 | |
| rjek | Can we have a github: shortcut like we have a baserock: one? | 16:20 |
| rjek | :) | 16:20 |
| persia | paulsherwood: You might find someone with whom to conspire: there are others who tend to be around weekends. | 16:20 |
| richard_maw | rjek: we already do | 16:20 |
| rjek | github:user/repo | 16:20 |
| Kinnison | repo-alias: github=git://github.com/%s#ssh://git@github.com/%s | 16:21 |
| Kinnison | yep | 16:21 |
| paulsherwood | Kinnison: should that be in morph.conf? | 16:22 |
| Kinnison | paulsherwood: it's part of the default repo aliases | 16:23 |
| Kinnison | i.e. unless you override it, it's there | 16:23 |
| paulsherwood | ah, ok | 16:23 |
| paulsherwood | probably it should say this somewhere on w.b.o? | 16:23 |
| paulsherwood | (maybe it does) | 16:23 |
| Kinnison | I doubt we discuss the default configuration values anywhere but morph's codebase :-( | 16:24 |
| paulsherwood | actually, i think i may have seen it in morph help | 16:24 |
| paulsherwood | bah - github: Name or service not known | 16:28 |
| *** jonathanmaw [~jonathanm@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 16:29 | |
| *** tiagogomes [~tiagogome@access.ducie-dc1.codethink.co.uk] has quit [Quit: Leaving] | 16:33 | |
| paulsherwood | anyone know what's the cure for "Problem with serialise-artifact: ERROR: Ref <foo> is an invalid reference for repo <trove>/baserock/baserock/definitions"? | 16:37 |
| persia | And you're sure you have that ref in that repo? | 16:37 |
| paulsherwood | i don't know why i should have it | 16:38 |
| persia | What are you trying to do? | 16:38 |
| paulsherwood | build sometihng on an arm disbuild network. unfortunately i don't think there's one in public | 16:38 |
| Kinnison | that normally implies something hasn't been pushed | 16:39 |
| paulsherwood | actually i've just pulled latest morph... now the error is different | 16:39 |
| persia | Right. You need to push the ref to the trove to use a distbuild network. | 16:39 |
| persia | But I thought morph did this automatically for `morph distbuild` | 16:39 |
| paulsherwood | yes, perhaps - i'll keep exploring ;) | 16:40 |
| persia | heh | 16:40 |
| persia | Note that although there aren't any public arm distbuild networks, radiofree did explain how to generate one. I haven't sorted out support for my arm boards yet, but imagine folk who are less distractable have them. | 16:41 |
| * persia should probably give up and get a tegra | 16:41 | |
| paulsherwood | i believe i'm using the original one that radiofree setup, complete with all the bladerunner names - but no deckard iiuc :) | 16:43 |
| paulsherwood | persia: just one? :) | 16:43 |
| paulsherwood | so for distbuild, i have to actually push my edits to trove? | 16:44 |
| persia | Yes, because the workers need to get them from somewhere. | 16:44 |
| paulsherwood | i thought morph would do that - silly me :) | 16:44 |
| persia | It should. | 16:45 |
| persia | Oh, hrm. Maybe morph only pushes the definitions to the trove, so one has to push changed repos indepedently. | 16:46 |
| Kinnison | it *ought* to push everything necessary | 16:46 |
| ssam2 | 'morph distbuild' should push your code to the Trove | 16:46 |
| persia | Kinnison: How can it tell? | 16:46 |
| ssam2 | however, it actually pushes it to whatever is 'origin' in your repo checkouts, I think | 16:47 |
| persia | Ah. That's unfortunate. | 16:47 |
| ssam2 | indeed. | 16:47 |
| Kinnison | persia: It's in charge of your workspace, it can tell for things it looks after | 16:47 |
| Kinnison | persia: this does not extend to things not on the trove :-( | 16:47 |
| * persia fails to have sufficient baserock-specific vocabulary to understand. | 16:48 | |
| paulsherwood | so i push my branch to github, distbuild doesn't find it afaict? | 16:48 |
| persia | Does it do something like check to see if the refs in definitions happen to be present in the associated git repos on the trove? | 16:49 |
| persia | paulsherwood: You'd need to have a lorry for it. | 16:49 |
| * persia suddenly begins to wonder about the distbuild architecture at a deep level: it all seemed sane before today | 16:50 | |
| Kinnison | It is quite sane | 16:50 |
| paulsherwood | normally i would. but i was just advised that github wold be ok :) | 16:50 |
| Kinnison | paulsherwood: Can your ARM workers see github? | 16:50 |
| paulsherwood | Kinnison: i don't know - i'm just a user :) | 16:50 |
| Kinnison | paulsherwood: You're a pretty special user if you have an ARM distbuild cluster, very few people do :-) | 16:51 |
| paulsherwood | lol | 16:51 |
| paulsherwood | i happen to know radiofree :) | 16:51 |
| persia | It's trivial to construct them, if one has the hardware. | 16:51 |
| Kinnison | paulsherwood: I suggest you ask the person who set up your distbuild to help you work out why your build is failing | 16:51 |
| * Kinnison can't easily diagnose without context :-( | 16:51 | |
| * Kinnison is a bear of little brain | 16:51 | |
| ssam2 | paulsherwood: could you paste the actual error that you have now? | 16:53 |
| persia | So, if one has definitions referencing arbitrary located repos (e.g. github), and one distbuilds, this should push the defintions ref, and the workers should be able to access the arbitrary locations. | 16:53 |
| persia | ? | 16:53 |
| ssam2 | depending on your network configuration, yes | 16:53 |
| ssam2 | some choose to firewall their workers so that they can't access arbitrary locations | 16:53 |
| ssam2 | and I'm agreeing because you used the word "should". I haven't tried this so I don't know if it *does*. | 16:54 |
| paulsherwood | ssam2: http://pastebin.com/fwvznFZL | 16:54 |
| persia | ssam2: "should" is what concerns me today :) If the "should" is wrong, then I get disturbed, If the "does" is wrong, it's just a bug. | 16:55 |
| paulsherwood | my branch exists, with a sel4.morph https://github.com/devcurmudgeon/seL4/tree/ct-mcr-1-sel4 | 16:56 |
| persia | Why did you put the morph in the chunk repo? | 16:56 |
| paulsherwood | do you want the honest answer, persia ? | 16:57 |
| persia | Is there anything in the distbuild model that requires anything but definitions.git on the trove? | 16:57 |
| persia | paulsherwood: Perhaps not :) I just thought it would be more complicated than putting it in definitions. | 16:57 |
| paulsherwood | because i couldn't get m.i.d to work last time i tried, so am waiting for that to land in mainline definiitions :) | 16:58 |
| Kinnison | OOooh i just had a thought | 16:58 |
| * paulsherwood has been unable to get software to work for decades :) | 16:58 | |
| persia | Kinnison: Please share | 16:58 |
| radiofree | how does m.i.d work with definitions, does the distbuild network have to be upgraded to support that? | 16:58 |
| Kinnison | I'm not sure this will work | 16:58 |
| Kinnison | because I think the distbuild controller offloads all git operations in batches to the trove | 16:58 |
| Kinnison | so it'll never be able to resolve the github stuff during graph computation | 16:58 |
| persia | Oh ugh. | 16:59 |
| ssam2 | also, i don't believe the particular distbuild network in question has been upgraded to support morphologies in definitions. | 16:59 |
| * paulsherwood considers sneaking his lorry into g.b.o and ducking | 16:59 | |
| Kinnison | paulsherwood: less sneaking, more asking nicely | 16:59 |
| Kinnison | I'm sure your trove admin for your trove (ct-mcr-1 in your example here?) would be happy to add sel4 for you | 17:00 |
| persia | paulsherwood: Seriously, if you send mail to baserock-dev, I'm sure someone will approve it fast. Lorry requests seem to only get stuck when there are hundreds of them, they are duplicate, or the syntax is wrong. | 17:00 |
| paulsherwood | my point is that having to go through a review when all i'm doing is experimenting is rather a waste of my time and those whom i burden with the task of reviewing | 17:00 |
| persia | Oh, right, you're not admin of your local trove. | 17:01 |
| persia | Hmm. I think there is an assumption in the model that developers are admins of their local troves, which probably doesn't work so well for troves deployed in organisations. | 17:01 |
| Kinnison | persia: there's certainly an assumption that troves in organisations are managed by responsive people | 17:02 |
| paulsherwood | Kinnison: and that's a fair assumption, particularly for folks that acrtually want what trove gives them | 17:02 |
| persia | I'm not sure that's safe at all. Most of the organisations with which I've been involved have strict separation between development and operations, and the operations team tends to give the development team lowest priority. | 17:02 |
| paulsherwood | but in this use-case i just want to fiddle with building sel4 | 17:02 |
| persia | Right. Were it not for the issue Kinnison raised above, I think it wouldn't really matter. | 17:04 |
| persia | So let's call that a bug. | 17:05 |
| *** locallycompact [~lc@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 250 seconds] | 17:17 | |
| *** franred [~franred@82-68-191-81.dsl.posilan.com] has quit [Quit: Leaving] | 17:19 | |
| *** ssam2 [~ssam2@82-68-191-81.dsl.posilan.com] has quit [Remote host closed the connection] | 17:31 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has quit [Ping timeout: 260 seconds] | 17:37 | |
| *** flatmush [~flatmush@82-68-191-81.dsl.posilan.com] has joined #baserock | 17:38 | |
| *** locallycompact [~lc@146.200.27.158] has joined #baserock | 19:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!