IRC logs for #baserock for Thursday, 2015-05-14

*** fay_ has joined #baserock01:32
*** fay__ has quit IRC01:32
*** tpollard_ has quit IRC01:32
*** nowster has quit IRC01:32
*** flatmush has quit IRC01:32
*** paulw has quit IRC01:32
*** nowster has joined #baserock01:32
*** paulw has joined #baserock01:32
*** franred has quit IRC01:32
*** tpollard_ has joined #baserock01:33
*** franred has joined #baserock01:33
*** flatmush has joined #baserock01:33
*** sambishop has quit IRC03:57
*** petefoth has joined #baserock05:50
*** Albert has joined #baserock07:22
*** a1exhughe5 has joined #baserock07:26
*** rdale has joined #baserock07:26
*** Albert has quit IRC07:33
*** Albert has joined #baserock07:34
*** jonathanmaw has joined #baserock07:50
*** sambishop has joined #baserock07:54
*** bashrc has joined #baserock08:02
*** gary_perkins has joined #baserock08:12
*** Kinnison_ is now known as Kinnison08:16
*** De|ta_ is now known as De|ta08:40
*** mariaderidder has joined #baserock08:49
radiofreeis it ok for me to put a load of genivi specific systemd units in rather than adding them to various chunk files08:58
KinnisonIs there a reason you don't want to make a genivi-support chunk?09:00
KinnisonAnd wouldn't it be better to upstream the units?09:00
radiofreeKinnison: genivi-support chunk was what i was getting at with adding the repo in bsp-support09:01
*** tiagogomes has joined #baserock09:01
radiofreeyes, ideally upstream the units, however that's in the future, need something for now09:01
richard_mawI belive install-files is our usual hack for that then09:02
* Kinnison nods09:02
radiofreeyeah, but i didn't really want to dirty definitions anymore09:02
radiofreei thought bsp-support was our way around needing to do install-files09:02
KinnisonWhat systems is bsp-support used in?09:05
radiofreeonly the jetson, and it's not really needed there anymore :\09:05
radiofreeadded a systemd unit09:05
*** ssam2 has joined #baserock09:05
*** ChanServ sets mode: +v ssam209:05
KinnisonWhat a bizarre tiny chunk09:06
richard_mawit's even smaller than the initramfs, since that requires a moderately complicated shell script09:08
radiofreeit's a perfectly formed chunk09:08
richard_mawit is09:08
KinnisonWell, it has a redundant .morph in it09:09
richard_mawit's a bit old09:10
radiofreei think bsp-support has a purpose though, a chunk you can throw into a system without adding loads more system specific stuff to the definitions repo09:18
radiofreein the case systemd units for the genivi-demo-platform09:19
richard_mawit would be weird for it to be stuff unrelated to the particular hardware though09:21
radiofreeit's not going to be jetson only, it's x86+arm09:23
radiofreeso just a branch in there called "genivi-demo-platform" or something09:23
radiofreethen both the x86 and arm g-d-p systems will add it09:24
richard_mawit's not really the BSP then is it? it's there to provide app functionality, rather than stuff essential for the hardware that it's running on09:28
radiofreeit's essentially board support functionality for genivi-demo-platform systems09:29
richard_mawwhat exactly needs to be added?09:30
radiofreesystemd user service files for the apps in the GDP, dbus user session (though i'm going to add that to essential-files since it's pretty useful for everything), system units for weston09:31
richard_mawnone of that seems hadware specific, so I'm skeptical that it belongs in anything named BSP09:32
* radiofree will just keep the generation in the chunk files then09:36
*** edcragg has joined #baserock09:38
jjardonssam2: maybe you have some free time to take a second look to and ?09:50
ssam2oh yeah09:53
ssam2oh, I still don't get it09:57
ssam2we should bump definitions VERSION before merging #580 so old versions of Morph don't try to build something that will cause them to crash09:58
ssam2#531 either09:58
ssam2s/build/deploy/ as well10:03
ssam2I think due to the way `morph deploy` is implemented, versioning is a lot more complicated there than with `morph build`10:04
ssam2the interface between Morph and definitions.git that we need to version is totally ad-hoc and undefined for `morph deploy`, but all our workflows that we suggest people use depend on being able to use `morph deploy` as well as `morph build`10:05
ssam2I think moving .configure extensions into definitions.git is a good first step. But it'd be nice if they could live in a subdirectory rather than all being in the toplevel10:05
paulsherwoodssam2: the whole deployment situation is in need of some cleanup. it's a bit of a rat's nest10:06
KinnisonUntil and unless extensions can live in a subtree, I wouldn't want to move everything in10:06
ssam2Kinnison: but you haven't tried to make changes to a .configure extension recently10:06
paulsherwoodextensionsh should be in definitions10:06
KinnisonHowever, we're *still* in the position of making changes to a surface we haven't properly mapped10:06
ssam2it's a nightmare10:06
paulsherwoodKinnison: i'm willing to help map it myself, but only if folks agree to minimising the surface10:07
Kinnisonpaulsherwood: mapping it would be the first step to minimising it10:07
Kinnisonpaulsherwood: But it's not a one-shot operation10:07
ssam2there are 10 .configure extensions in morph.git/morphlib/exts, fyi10:07
ssam2so not too many to have temporarily living in the top level of definitions.git10:08
paulsherwoodi think i disagree on that too, Kinnison :)10:08
paulsherwoodbut i may be wrong10:08
Kinnisonpaulsherwood: You are wrong10:08
Kinnisonpaulsherwood: but that's your perogative10:08
paulsherwoodi've been wrong before :)10:08
paulsherwoodbut often, when folks told me i'm wrong, i proved to be right10:09
ssam2Kinnison: I'm pretty confused on the form such a map might take10:09
paulsherwoodand i think i'm getting to the point where i grok this as well as many of the folks here10:09
ssam2if you have something in mind, it'd be useful if you could show an example of what you want10:09
paulsherwoodssam2: you mean me?10:09
ssam2no, Kinnison10:09
* paulsherwood shuts up, then :)10:10
ssam2but same to you if you can demonstrate it easily10:10
Kinnisonssam2: I'd like to see a proper specification document with testable assertions detailing the interaction between the physical model in definitions, the logical model it represents, and the results produced (along with all the appropriately abstracted behaviours en-route) so that reimplementation of any or all of the tooling would be safe10:10
ssam2ok. I have no idea how I'd ever do that, so I doubt I will, i'm afraid10:10
KinnisonI have an approach in mind, but no time to do it, sadly :(10:10
ssam2sounds like something on the order of complexity of the ANSI C specification10:10
ssam2which wasn't the product of 1 day a week's hacking10:11
KinnisonI imagine it might end up slightly more complex than that to begin with10:11
Kinnisonand then it offers a basis for simplification10:11
*** pacon has joined #baserock10:11
* Kinnison has been advocating this approach for around six months now though10:13
Kinnisonand it hasn't received much traction10:13
Kinnisonso perhaps I should give up10:14
* SotK thinks that is partly because no-one has enough time to do it10:14
Kinnisonnor any ability to guarantee ongoing bandwidth (which IMO is essential)10:14
ssam2honestly, if you are advocating an approach that involves producing something more complex than the ANSI C specification, I don't see how it will ever happen10:15
KinnisonWe already produce something more complex than that -- full Linux systems10:16
KinnisonBut I'm giving up10:16
KinnisonClearly there's no desire to approach this the way I feel would be best10:16
Kinnisonso I'll stop10:16
richard_mawKinnison: you have agreement from me that it would be the best way to go10:16
ssam2it may well be the best approach, I just don't see how it's possible10:17
*** rdale_ has joined #baserock10:17
ssam2I can produce a full Linux system from scratch in a few days, by hand (following linux-from-scratch)10:17
ssam2it's totally different from trying to produce a complete, machine-comprehensible, watertight specification of something10:18
paulsherwoodactually, I think we *can* produce a machine-comprehensible watertight specification of these linux systems - we already do10:18
KinnisonI think you're missing a level of meta10:19
paulsherwoodno, i get it.10:19
* Kinnison was talking about producing a specification of how we specify systems10:19
paulsherwoodas i said, i get it.10:19
KinnisonHowever I said I'd stop, and I shall10:19
* Kinnison apologises10:19
*** rdale has quit IRC10:20
paulsherwoodKinnison: no need to stop, or apologise. i agree that what you want to get to is required. i'm just interested in finding the shortest/leastwork route to that goal10:20
radiofreelooking at what is needed for the gdp, would people be happy suggesting "use this branch of definitions" rather than us submitting this to master?10:21
paulsherwoodradiofree: it's not ideal, but ok10:21
paulsherwood(by me)10:21
radiofreethere's so many hacks and obsolete versions of these (e.g we have to use an entirely different version of weston from the weston system *and* the genivi-baseline system)10:21
Kinnisonradiofree: If you're waiting on features or upstreaming before you can cleanly merge to master then I think it's reasonable providing you can commit to regular updates to that branch10:22
paulsherwoodreally? what is *wrong* with these people?!!!10:22
radiofreewe're not using mainline qtmultimedia, *or* anything close to mainline qtwayland...10:22
radiofreeKinnison: ok, i'll commit to keeping track and maintaining if for a merge to master10:22
paulsherwoodradiofree: nothing to stop you creating such a branch, irrespective of whether you choose to maintain it? :)10:23
radiofreewell we need to document it somewhere, i.e "morph checkout baserock:baserock/definitions genivi-demo-platform10:23
paulsherwoodhow hard can that be? :)10:24
radiofreemandatory video anyway, jetson, kernel 4.0, nouveau
Kinnisonpaulsherwood: one-shot -- trivial -- something useful for people in an ongoing way -- harder10:24
ssam2the media player is terrifying10:24
paulsherwoodKinnison: false dichotomy10:25
ssam2radiofree: if you want to be able to merge changes to 'genivi-demo-platform' in gerrit and have them replicated to, it will need a config tweak10:25
* SotK wonders how the media player is actually a media player10:25
SotKit looks like two googly eyes10:25
ssam2radiofree: i'm happy to do that if you want, request it via the mailing list if so in order that there's a record10:26
paulsherwoodradiofree: can you get someone to put that on the baserock vimeo channel please?10:26
SotKssam2: do you have time to fix btw?10:26
radiofreessam2: can i version the branches then, e.g genivi-demo-platform-0.1, 0.2, until it's ready for master?10:27
radiofreei'd rather not have to go through any review process to get this up to scratch before submitting to master10:27
ssam2radiofree: it's totally up to you, i'm not trying to force any process on you10:28
paulsherwoodradiofree: just go ahead with that. i'll take up this conversation with other genivi folks. i mean, *wtf*!!!?10:28
ssam2radiofree: it's just that if you want people to be able to submit patches for the 'genivi-demo-platform' branch, it won't work as you expect because 'master' is treated specially10:29
ssam2radiofree: so we'd need to tell it to 'genivi-demo-platform' the same as 'master', rather than treating it as a personal branch10:29
paulsherwoodssam2: or folks could use ybd :)10:29
ssam2paulsherwood: ybd can fix gerrit config now? I think i'm missing something10:30
radiofreessam2: i see what you mean, but i'm not expecting anyone to submit patches for this, maybe document use the mailing list and cc me?10:30
ssam2radiofree: yes, that makes sense10:31
radiofreei want to get it to a state that's reasonable for merging to master (when the review will happen) first, and that will need some serious changes in how upstream is implementing these components10:31
paulsherwoodssam2: no, it's me misunderstanding. i'm an idiot someteimes as you know :) sorry10:32
ssam2SotK: I'll get to it today, but feel free to do so first10:32
ssam2I need to repair my chroot setup, `manage-baserock rm` destroyed a bunch of stuff because I ran it on a chroot that still had stuff mounted10:33
SotKheh, I'll fix it up then :)10:33
jmacsWas doffm's flang patch merged into definitions? It seemed to get a +2 in January, but I can't see it in master.11:01
nowster~ # ls /etc/localtime  -l11:05
nowsterlrwxrwxrwx    1 root     root            25 Jan  1  1970 /etc/localtime -> ../usr/share/zoneinfo/UTC11:05
nowsterBut there's no /usr/share/zoneinfo...11:05
ssam2nowster: is this inside a system build with Baserock? perhaps you're missing whatever stratum contains time-zone-database11:07
ssam2nowster: which I believe is 'foundation'11:07
nowsterah, right... that's build-system11:07
ssam2built from what commit?11:08
nowstersome time in February11:08
ssam2oh, I think that's before time-zone-database was added, then11:08
*** pacon has quit IRC11:48
*** pacon has joined #baserock11:49
*** sambishop has quit IRC12:10
*** sambishop has joined #baserock12:13
*** pacon has quit IRC12:55
ssam2does anyone have a minute to review ?13:04
ssam2it fixes a bug that is present in the version of Morph included in the Baserock 15.19.1 release of definitions.git13:04
richard_mawssam2: reviewing13:15
richard_mawssam2: +2, I'll leave submitting it for merge to you, as I made some small suggestions that are pretty much just cosmetic13:18
ssam2ok, I'll tag and announce a 15.19.2 release of the Baserock reference definitions...13:29
ssam2with just the last 2 commits to Morph as changes13:29
*** a1exhughe5 has quit IRC13:38
tiagogomescan we stop using busybox13:41
bashrcbusybox < gnu13:43
ssam2tiagogomes: what exactly do you want?13:43
ssam2most of the GNU tools are present in Baserock, you can use them13:43
ssam2I don't want to get involved in preventing people from using Busybox, however13:43
tiagogomesssam2 today, it would be a proper brctl tool13:45
ssam2ok, so find what package provides GNU brctl, and add it to Baserock13:45
KinnisonUnder Debian it comes from bridge-utils13:47
KinnisonAmusingly enough apparently written by Lennart13:48
KinnisonHowever, Lennart Buytenhek :)13:48
KinnisonApparently git:// might be the current upstream13:56
* Kinnison looks13:56
KinnisonCertainly it's there, though there haven't been commits for 14 months13:57
Kinnisonperhaps it's simply stable13:57
Kinnisontiagogomes: did that help?14:27
tiagogomesKinnison didn't have a look, I copied the brctl binary from a debian system to baserock as a short fix14:28
*** sambishop has quit IRC14:33
pedroalvarezfranred: just found this:
pedroalvarezcan you please change them to use upstream: the next time please?14:36
pedroalvarezfranred: see policies for more info:
franredpedroalvarez, yep, apologies for forgetting to use the full URL (when I was testing git didn't know what upstream was so it fails)14:38
pedroalvarezalso, ssam2, shouldn't mason be failing because of this?14:39
franredpedroalvarez, why? it does point to git.baserock.org14:39
pedroalvarezfranred: he was trying to isolate mason from internet14:40 is the public address14:40
pedroalvarezI think mason is using as a local trove, setting trove-host to the internal IP14:41
pedroalvarezif something uses, it should fail14:41
pedroalvarezif it uses upstream: that will be converted to the internal IP14:41
pedroalvarezand it should work14:41
pedroalvarezthat was the idea14:41
franredpedroalvarez, ohh, I see14:41
pedroalvarezi think I know why mason hasn't detected this yet14:43
pedroalvarezIt was already built when Sam restricted the internet on them14:44
ssam2that would make sense14:44
pedroalvarezlooking forward to see a full rebuild :)14:44
*** sambishop has joined #baserock14:45
franredpedroalvarez, clean the cache so we can fix anything is pointing to something external and we can fix it14:46
pedroalvarezfranred: I don't think people want me to clean cache :)14:47
pedroalvarezalhough I could remove it's artifact, which is less disruptive14:48
*** jonathanmaw has quit IRC15:18
radiofreehi everyone15:58
SotKhi radiofree15:58
radiofreeam i correct in thinking will export an environment variable called WESTON_DEFAULT_BACKEND15:58
radiofreeWESTON_NATIVE_BACKEND even15:58
radiofreethat'll be available to configure15:59
radiofreeor would i have to do something like WESTON_NATIVE_BACKEND=$WHATEVER_I_SET_UP_THERE and call it something else?15:59
richard_mawradiofree: no, it won't export that variable16:00
richard_mawit *needs* the explicit export command16:00
radiofreeok, so either do export WESTON_NATIVE_BACKEND or do something like ?16:00
radiofreeok, thanks16:01
*** Albert has quit IRC16:09
ssam2I think that my 'optional workspaces' branch will be really awkward unless we first change sourcepools to allow containing multiple systems16:17
ssam2as I understand it, the main thing that'd need to be fixed for that is that Source objects have a 'cache_key' and 'cache_id' attribute16:17
ssam2but in fact it's the Artifact object that should track its cache identity16:18
richard_mawdiscussed it out of band16:24
richard_mawthat would be a reversion to a previous conflation16:24
richard_mawwhen what I'd like is a reduction of the conflation of concepts in the Source object16:24
ssam2I think i'd better avoid basing the 'optional workspaces' branch on such a change, and just work around the problem for now16:33
ssam2I'd like to fix this, but I don't want that branch to turn into a huge monster16:33
* jjardon learns today that you can fit systemd in a 7MB image system:
robtaylorjjardon: nice16:37
robtaylorjjardon: ah, i gave jdub some pointers :)16:38
robtaylorjjardon: he'll probably be interested in rdale_ 's work to make systemd work with musl16:38
rdale_i haven't actually started that, as i got a bit frightened of the size of the patch series on the mailing list for musl/systemd16:39
jjardonunfortunately the smallest system I manage to produce in baserock is ~35MB  :/ This is the system:
jjardonAny idea how can I make it smaller?16:40
rdale_you can build a system like that with musl that uses busybox init16:42
jjardonrobtaylor: I was really impressed that you can put systemd in such small system:
*** ssam2 has quit IRC16:43
*** mariaderidder has quit IRC16:44
jjardonrdale_: Thanks for the suggestion. Although Yocto is able to generate a smaller image without using musl, so it should be posible in some way16:46
rdale_we need to use strip16:47
jjardonrdale_: Are the musl chunk in current definitions?16:47
jjardonor in a branch somewhere?16:47
rdale_no, in baserock/rdale/musl16:47
rdale_nowster has just found it doesn't work with ipv4 though, so that really needs fixing16:48
jjardonmmm, Anyone know what would be needed to strip in baserock? is it anyone working on it?16:49
radiofreejjardon: i think sam was16:50
nowsterThe devices are there in the kernel, but musl doesn't seem to be able to do "inet" sockets.16:51
rdale_i haven't looked at it yet, but is it possibly a busybox build problem, rather than musl itself?16:55
*** bashrc has quit IRC16:58
nowstermaybe... can't easily tell16:59
ratmice__jjardon: was this a fairly standard yocto build or something e.g. compiled with -Os and other tricks to create a minimal footprint?17:00
jjardonratmice__: I do not think so, at least I do not see anything like that in the machine layer:
jjardonmmm, seems they are using "'image-mklibs' to reduce shared library files size for an image" .  Not sure what that does though17:06
nowsteris configure "set-hostname" built into morph?17:07
ratmice__so is there currently a 1:1 source->artifact for a given build/cache id thing?17:07
Zarajjardon: I did find this, which is in the 'common' files: I don't know that it's relevant right this second but might be worth bearing in mind if we have perl in the system currently17:08
Zarasince it suggests they don't have perl in there. but you may be aware of that, sorry if so! :P17:09
jjardonZara: thanks for the hint; we use perl (wich is in core) to build the bsp stratum (as linux build depends on perl), but we do not inclide the core stratum in the final system definition17:11
ratmice__jjardon: ahh, seems it strips out functions/symbols in libraries which go unused by a set of executables17:12
*** gary_perkins has quit IRC17:12
* ratmice__ isn't sure baserock is a closed enough system to do that17:13
robtaylorjjardon: istr that there was a plan post chunk-splitting to have a way to strip the debug into a seperate artifact17:24
ratmice__robtaylor: does that not mean the cache server will have multiple copies of debug info?17:31
ratmice__e.g. one in the combined/one split out artifact?17:32
robtaylorratmice__: well, i'd always split17:34
robtaylorratmice__: and if you want an image with debug info, assemble with the debuginfo artefacts17:34
robtaylorone nice sideeffect of this appraoch is you could have debug images for production images, asswing in-field debugging17:35
ratmice__robtaylor: oh right, chunk splitting happens before artifact, so it is avoiding this 2x size increase17:37
robtaylorratmice__: yup17:40
ratmice__for some reason 'separate artifact' had me confused as though there were an initial combined artifact17:40
*** mwilliams_ct has quit IRC18:12
*** pdar has quit IRC18:12
*** Zara has quit IRC18:12
*** perryl has quit IRC18:12
*** DavePage has quit IRC18:12
*** paulsherwood has quit IRC18:12
*** kejiahu has quit IRC18:12
*** benbrown_ has quit IRC18:12
*** petefotheringham has quit IRC18:12
*** bwh has quit IRC18:12
*** jmacs has quit IRC18:12
*** SotK has quit IRC18:12
*** rjek has quit IRC18:13
*** rjek has joined #baserock18:13
*** bwh has joined #baserock18:19
*** petefotheringham has joined #baserock18:19
*** SotK has joined #baserock22:05

Generated by 2.15.3 by Marius Gedminas - find it at!