IRC logs for #baserock for Wednesday, 2014-08-06

*** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 240 seconds]04:02
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock04:03
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: No Ping reply in 180 seconds.]04:51
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock04:54
*** fay_ [] has joined #baserock07:13
*** fay_ [] has quit [Client Quit]07:13
*** stetaylor [] has joined #baserock07:44
*** franred [] has joined #baserock08:10
*** jonathanmaw [] has joined #baserock08:20
*** tiagogomes [] has joined #baserock08:20
*** ssam2 [] has joined #baserock08:46
*** stetaylor [] has quit [Quit: Leaving...]08:52
*** tiagogomes [] has quit [Ping timeout: 266 seconds]08:53
*** vmeson [~quassel@] has quit [Ping timeout: 264 seconds]08:53
*** tiagogomes [] has joined #baserock08:54
*** vmeson [~quassel@] has joined #baserock08:56
*** locallycompact [] has joined #baserock09:06
*** flatmush [] has joined #baserock09:07
*** stetaylor [] has joined #baserock10:07
*** stetaylor [] has quit [Quit: Leaving...]11:26
*** tiagogomes [] has quit [Ping timeout: 264 seconds]12:23
*** tiagogomes [] has joined #baserock12:45
*** jonathanmaw [] has quit [Read error: Connection reset by peer]13:06
persiaCould someone remind me why we need different mesa for wayland and X?13:10
*** jonathanmaw [] has joined #baserock13:11
radiofreewe probably don't13:44
radiofreewe could just use the configuration options that we currently use for the genivi baseline for all of them13:45
radiofreeany arm system we currently build for it will be quite slow anyway13:47
radiofreejjardon: i don't really like the idea of mesa being in the wayland-generic stratum13:49
radiofreebut i can't think of any better place to put it13:49
radiofreei suppose it's fine to just copy wayland-generic to wayland-imx6 or something if you want to replace mesa13:50
persiaIf we can use the same mesa for wayland and X, it would make sense to put it in an underlying stratum.13:50
persiaIs there anything else that provides similarly low-level services that only makes sense for headed systems?13:50
radiofreewherever you put it, still won't get around the need to have to make a copy of it for specific boards13:51
persiaHrm?  Why?13:51
radiofreei.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 blobs13:52
persiaDo you mean selecting which drivers to use?13:52
persiaSomehow I thought mesa was coinstallable with the blobs, with a shared API.13:53
persiaBut if mesa is to be considered HW-specific, perhaps it makes sense to put it in the BSP strata.13:54
radiofreethe jetson, we want to build the nouveau driver13:54
radiofreeno it's pretty generic, but there's no mesa drivers for the vivante gpu for example13:54
radiofreeso the gpu binaries from freescale are just a drop in replacement for mesa (i.e it provides EGL, GLES etc..)13:54
persiaDoes it not have runtime detection such that if the nouveau driver is installed on i.mx6 it is silently ignored?13:54
jjardonpersia: configuration option, --with-egl-platforms=x11,drm in one case --with-egl-platforms=wayland,drm in the other13:54
persiajjardon: What happens if we have --with-egl-platforms=x11,wayland,drm ?13:55
radiofreei suppose mesa would need a bit more x?13:55
radiofreei don't know why we're building the drm drivers either13:56
jjardonpersia: you can, and you we would only need one mesa13:56
persiaThen why don't we do it that way?13:57
radiofreeactually x-generic builds mesa with only "x-common", so i guess we don't need to add any more stuff to the wayland stratum13:58
persiaAlso, for i.mx6, can we not use xf86-video-msm?13:58
radiofreei've never used x on an i.mx6, i was thinking more about weston13:58
radiofreejjardon: might it be a good idea to split weston out from the wayland stratum as well?13:59
persiaDoes anyone use weston without wayland, or want wayland systems without weston?14:00
* persia thought they were inextricably linked in some way14:00
radiofreeyou can't use weston without wayland14:00
rjekI thought one was an implementation of the other.14:00
rjek(one spec, one impl.)14:01
radiofreewayland is the protocol, weston is an implementation of a wayland compositor14:01
radiofreefor genivi, you might want to replace weston with layermanager, for example14:01
persiaNo.  Wayland is the underlying system, and weston is a wayland client14:01
radiofreeor mutter14:01
persiaDoesn't the GENIVI spec require weston to be present?14:02
radiofreei don't know, it might do know, this weston-ivi-shell stuff14:02
ssam2but for example GNOME on Wayland doesn't use Weston at all. Mutter (gnome-shell) is the Wayland compositor.14:03
persiaHmm.  So maybe weston belongs in some GENIVI stratum, and can be dropped from the wayland stratum?14:03
radiofree[15:01:44] <radiofree> or mutter14:03
radiofreewayland might be slightly lonely by itself though14:07
persiaWhat 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
radiofreethings like cairo, pango etc.. don't really belong in a "wayland stratum", since you don't need them to build wayland14:07
persiastrata aren't just about build-depends.14:08
radiofreei don't know, it depends on what your wayland clients/compositor need14:11
radiofreei don't really like the idea of cairo, pixman etc.. being in the "wayland" stratum14:11
jjardonlets move them to a new graphics-common stratum?14:12
radiofreethere are plenty of x projects that need them14:12
radiofreejjardon: +114:12
jjardonpersia: weston is the reference implementation, genivi uses a modify version of weston. GNOME, KDE, enlighment ... have their own compositor implementation14:25
rjek(ie, why is there a need for more than one implementation?)14:26
radiofreegenivi are, at least, implementing their stuff via weston plugins, so not reinventing the compositing side of it anymore14:29
ssam2rjek: wrong channel, try #wayland :)14:32
jjardonrjek: good question, I dont know14:33
ssam2probably the same reason we need multiple window managers, multiple desktop environments, multiple distros, multiple build systems14:33
ssam2i.e. we don't. but life is messy14:33
rjekssam2: There's only one X server, really... :)14:34
jonathanmawrjek: really? by the name I expected 10 more to come before it :P14:34
jjardonI guess we do not need, but  to support the current window managers in wayland (mutter, kwin) you have to convert them in compositors14:35
* richard_maw wonders if there's any tiling wayland compositors14:36
richard_mawso or a GNOME shell plugin according to that thread14:39
richard_maw looks promising, and off topic14:40
tlsainitial mason CI/CD work posted to baserock-dev for review15:34
paulsherwoodtlsa: do you mean you've just sent a series? i'm not seeing anything?15:40
persiaI do15:40
tlsaI sent it to baserock-dev@baserock.org15:41
tlsajust a few mins ago15:41
paulsherwoodaha... just got it. tvm15:41
persiatlsa: 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
tlsathe previous change was to trove-setup.git to make it cabable of having that configurable15:43
tlsathe change there adds the config option to the trove cluster morphology stuff15:43
persiaAh, so this is the associated definitions change to use that.15:43
paulsherwoodif i wanted to test this, are there instructions on what to do somewhere?15:44
persiaWhere is the definitions ref change?15:44
persia(to consume the updated trove-setup.git)15:44
tlsapaulsherwood: see's --help15:44
paulsherwoodyou mean mason-generator?15:45
* persia suspects ./mason/ --help`15:46
paulsherwoodwhat's the policy on creating gbo repos now? i see deletion, not creation16:00
* paulsherwood would like to add seL4, as a challenge :)16:01
Kinnisonwhat is sel4 ?16:06
Kinnisonoh it'll be an L4 thing16:06
richard_mawyou want to build an entirely different Kernel?16:08
rjekKinnison: It uses Haskell to help prove its correctness.  Might of interest to you16:10
Kinnisonrjek: I'm horrified and yet strangely aroused16:12
richard_mawlet's try to keep this channel work safe16:13
rjekseL4 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
paulsherwoodyes, i want to build a completely different kernel. looks like it's only arm3216:15
rjekpaulsherwood: I think there's an x86 version too.16:15
rjekAlthough I've not looked that closely.16:15
persiaI think the policy for repo creation is mostly about getting the lorry approved.16:15
persiaSo sel4 shouldn't be an issue.16:16
paulsherwoodrjek: not from what i can see -
paulsherwoodpersia: i normally sneak my lorries in while no-one is looking :)16:17
rjekpaulsherwood: suggests it has x86 support.16:17
rjekor at least some16:17
richard_mawpaulsherwood: which we all frown at you for16:18
* paulsherwood can frown, too :)16:18
paulsherwoodmost of my lorrying happens at weekends - having to get approval would kill my enthusiasm16:19
paulsherwoodi've begun experimenting with forking on github, but it's not the same :)16:19
* Kinnison suggests you spool up and run your own trove16:20
rjekCan we have a github: shortcut like we have a baserock: one?16:20
persiapaulsherwood: You might find someone with whom to conspire: there are others who tend to be around weekends.16:20
richard_mawrjek: we already do16:20
Kinnisonrepo-alias: github=git://
paulsherwoodKinnison: should that be in morph.conf?16:22
Kinnisonpaulsherwood: it's part of the default repo aliases16:23
Kinnisoni.e. unless you override it, it's there16:23
paulsherwoodah, ok16:23
paulsherwoodprobably it should say this somewhere on w.b.o?16:23
paulsherwood(maybe it does)16:23
KinnisonI doubt we discuss the default configuration values anywhere but morph's codebase :-(16:24
paulsherwoodactually, i think i may have seen it in morph help16:24
paulsherwoodbah - github: Name or service not known16:28
*** jonathanmaw [] has quit [Quit: Leaving]16:29
*** tiagogomes [] has quit [Quit: Leaving]16:33
paulsherwoodanyone 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
persiaAnd you're sure you have that ref in that repo?16:37
paulsherwoodi don't know why i should have it16:38
persiaWhat are you trying to do?16:38
paulsherwoodbuild sometihng on an arm disbuild network. unfortunately i don't think there's one in public16:38
Kinnisonthat normally implies something hasn't been pushed16:39
paulsherwoodactually i've just pulled latest morph... now the error is different16:39
persiaRight.  You need to push the ref to the trove to use a distbuild network.16:39
persiaBut I thought morph did this automatically for `morph distbuild`16:39
paulsherwoodyes, perhaps - i'll keep exploring ;)16:40
persiaNote 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 tegra16:41
paulsherwoodi believe i'm using the original one that radiofree setup, complete with all the bladerunner names - but no deckard iiuc :)16:43
paulsherwoodpersia: just one? :)16:43
paulsherwoodso for distbuild, i have to actually push my edits to trove?16:44
persiaYes, because the workers need to get them from somewhere.16:44
paulsherwoodi thought morph would do that - silly me :)16:44
persiaIt should.16:45
persiaOh, hrm.  Maybe morph only pushes the definitions to the trove, so one has to push changed repos indepedently.16:46
Kinnisonit *ought* to push everything necessary16:46
ssam2'morph distbuild' should push your code to the Trove16:46
persiaKinnison: How can it tell?16:46
ssam2however, it actually pushes it to whatever is 'origin' in your repo checkouts, I think16:47
persiaAh.  That's unfortunate.16:47
Kinnisonpersia: It's in charge of your workspace, it can tell for things it looks after16:47
Kinnisonpersia: this does not extend to things not on the trove :-(16:47
* persia fails to have sufficient baserock-specific vocabulary to understand.16:48
paulsherwoodso i push my branch to github, distbuild doesn't find it afaict?16:48
persiaDoes 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
persiapaulsherwood: 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 today16:50
KinnisonIt is quite sane16:50
paulsherwoodnormally i would. but i was just advised that github wold be ok :)16:50
Kinnisonpaulsherwood: Can your ARM workers see github?16:50
paulsherwoodKinnison: i don't know - i'm just a user :)16:50
Kinnisonpaulsherwood: You're a pretty special user if you have an ARM distbuild cluster, very few people do :-)16:51
paulsherwoodi happen to know radiofree :)16:51
persiaIt's trivial to construct them, if one has the hardware.16:51
Kinnisonpaulsherwood: I suggest you ask the person who set up your distbuild to help you work out why your build is failing16:51
* Kinnison can't easily diagnose without context :-(16:51
* Kinnison is a bear of little brain16:51
ssam2paulsherwood: could you paste the actual error that you have now?16:53
persiaSo, 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
ssam2depending on your network configuration, yes16:53
ssam2some choose to firewall their workers so that they can't access arbitrary locations16:53
ssam2and I'm agreeing because you used the word "should". I haven't tried this so I don't know if it *does*.16:54
persiassam2: "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
paulsherwoodmy branch exists, with a sel4.morph
persiaWhy did you put the morph in the chunk repo?16:56
paulsherwooddo you want the honest answer, persia ?16:57
persiaIs there anything in the distbuild model that requires anything but definitions.git on the trove?16:57
persiapaulsherwood: Perhaps not :)  I just thought it would be more complicated than putting it in definitions.16:57
paulsherwoodbecause 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
KinnisonOOooh i just had a thought16:58
* paulsherwood has been unable to get software to work for decades :)16:58
persiaKinnison: Please share16:58
radiofreehow does m.i.d work with definitions, does the distbuild network have to be upgraded to support that?16:58
KinnisonI'm not sure this will work16:58
Kinnisonbecause I think the distbuild controller offloads all git operations in batches to the trove16:58
Kinnisonso it'll never be able to resolve the github stuff during graph computation16:58
persiaOh ugh.16:59
ssam2also, 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 ducking16:59
Kinnisonpaulsherwood: less sneaking, more asking nicely16:59
KinnisonI'm sure your trove admin for your trove (ct-mcr-1 in your example here?) would be happy to add sel4 for you17:00
persiapaulsherwood: 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
paulsherwoodmy 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 reviewing17:00
persiaOh, right, you're not admin of your local trove.17:01
persiaHmm.  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
Kinnisonpersia: there's certainly an assumption that troves in organisations are managed by responsive people17:02
paulsherwoodKinnison: and that's a fair assumption, particularly for folks that acrtually want what trove gives them17:02
persiaI'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
paulsherwoodbut in this use-case i just want to fiddle with building sel417:02
persiaRight.  Were it not for the issue Kinnison raised above, I think it wouldn't really matter.17:04
persiaSo let's call that a bug.17:05
*** locallycompact [] has quit [Ping timeout: 250 seconds]17:17
*** franred [] has quit [Quit: Leaving]17:19
*** ssam2 [] has quit [Remote host closed the connection]17:31
*** flatmush [] has quit [Ping timeout: 260 seconds]17:37
*** flatmush [] has joined #baserock17:38
*** locallycompact [~lc@] has joined #baserock19:59

Generated by 2.15.3 by Marius Gedminas - find it at!