| *** pacon has joined #baserock | 00:51 | |
| *** petefoth has quit IRC | 01:00 | |
| *** pacon has quit IRC | 01:07 | |
| *** petefoth has joined #baserock | 01:09 | |
| *** pacon has joined #baserock | 01:59 | |
| *** pacon has quit IRC | 02:12 | |
| *** pacon has joined #baserock | 02:14 | |
| *** pacon has quit IRC | 03:53 | |
| *** pacon has joined #baserock | 03:55 | |
| *** pacon has quit IRC | 04:41 | |
| *** pacon has joined #baserock | 04:41 | |
| *** zoli__ has joined #baserock | 04:51 | |
| *** zoli__ has joined #baserock | 04:53 | |
| *** zoli__ has quit IRC | 06:43 | |
| *** zoli__ has joined #baserock | 06:44 | |
| *** zoli__ has joined #baserock | 07:04 | |
| *** bjdooks has joined #baserock | 08:00 | |
| *** bashrc_ has joined #baserock | 08:00 | |
| *** bashrc_ has quit IRC | 08:03 | |
| *** bashrc_ has joined #baserock | 08:03 | |
| *** gary_perkins has joined #baserock | 08:28 | |
| *** jonathanmaw has joined #baserock | 08:34 | |
| *** mariaderidder has joined #baserock | 08:35 | |
| perryl | is there anything defined for how morph utilises parameters set in morph.conf? is it via cliapp and self.app.settings['parameter']? | 08:36 |
|---|---|---|
| *** mwilliams_ct has left #baserock | 08:36 | |
| *** ssam2 has joined #baserock | 08:37 | |
| *** ChanServ sets mode: +v ssam2 | 08:37 | |
| Kinnison | perryl: yes, the config file (and command line parsing) is all handled by cliapp | 08:44 |
| *** edcragg has joined #baserock | 09:12 | |
| *** lachlanmackenzie has joined #baserock | 09:18 | |
| paulsherwood | jonathanmaw: would it make sense for you to join #automotive? | 09:44 |
| paulsherwood | i think that's where agl folks hang out | 09:44 |
| jonathanmaw | couldn't hurt | 09:44 |
| paulsherwood | and i don't want to distract #baserockers with too much exciting yocto discussion | 09:44 |
| paulsherwood | :) | 09:44 |
| rjek | Did somebody say Yocto? | 09:44 |
| * rjek gets excited. | 09:44 | |
| paulsherwood | rjek: it's all happening in #automotive :-) | 09:45 |
| *** zoli__ has quit IRC | 10:52 | |
| *** zoli__ has joined #baserock | 11:15 | |
| *** zoli__ has quit IRC | 11:21 | |
| *** zoli__ has joined #baserock | 11:21 | |
| persia | Thinking about the tarball problem, I wonder if it makes sense to have some way to describe *how* to generate the tarballs. | 12:12 |
| persia | The idea being that given a reference build system artifact, we can build a reference development system. Then, given a reference development system, we can generate the bootstrap tarballs from git repos. | 12:12 |
| persia | Then we can use the bootstrap tarballs from an arbitrary system to bootstrap the build system. | 12:12 |
| *** tiagogomes_ has quit IRC | 12:13 | |
| persia | The reason I think this would be nice is that we don't always know precisely what happens in the upstream release process, some of which is sometimes done by humans, meaning that it may be tricky to ensure that we can perfectly replicate something starting from a tarball (as a source change may potentially cause a generated tarball to change, which would differ from that same source change being done against a completed tarball tree, without | 12:14 |
| persia | regenerating tarball artifacts). | 12:14 |
| richard_maw | persia: That's in `prep-commands` with different dependencies for each of the set of commands territory as I understand the problem. | 12:14 |
| richard_maw | unless you want to prep your source trees in bootstrap mode | 12:15 |
| persia | I don't understand your terminology, but I'm willing to trust your description. | 12:15 |
| persia | What I mostly want is to go from upstream source repo to blob in some way that allows me to be certain I can repeat it. | 12:16 |
| persia | When I start from upstream tarball, while I may be able to document cryptographic trust that upstream blessed the tarball, I have no view of the magic by which this is done, making certain sorts of source transformations unsafe. | 12:16 |
| persia | If this is already a solved problem, then I'm happy. | 12:17 |
| persia | In the distro model, it gets solved by publishing the constructed artifacts in such a way that one never needs to bootstrap. | 12:17 |
| persia | But since Baserock considers most artifacts to be disposable, with caching only as optimisation, I want to make sure that for anything that differs from upstream VCS that isn't a patch-under-review, we have a means to bootstrap *including* those modifications, even if it is painful, or requires starting with a binary blob (e.g. the build system artifact). | 12:18 |
| persia | Actually, that's not the example: that's the *only* artifact I'm comfortable having be a blob. | 12:19 |
| persia | But, as I understand it, for that to work, we need to have a way to be able to generate the bootstrap trees from a complete system, so that we can build the build system. | 12:20 |
| *** tiagogomes has joined #baserock | 12:20 | |
| persia | And if this is `prep-commands`, then this is a solved problem. | 12:20 |
| radiofree | paulsherwood: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/genivi-demo-platform-0.1-rebase | 12:22 |
| radiofree | is the cache server stuff working? if you build that with morph it's cached on gbo | 12:23 |
| radiofree | s/cache server stuff/cache server stuff in ybd/ | 12:23 |
| paulsherwood | sadly no... i've not seen any interest in morph changing its naming or cache code, so i fear i'll need to set up ybd cache server separately | 12:24 |
| richard_maw | persia: we don't have prep-commands, it's just an idea I'd had previously to solve the problem. We either need to trust that the bootstrap-mode prep-commands don't leak too much stuff from the host environment, or that a trustworthy person has done the prep externally to the build and checked the result in, which AIUI is the usual process for release tarballs. | 12:25 |
| persia | richard_maw: Right. I don't trust humans, making me like the former solution. That said, there are other things that need sorting before it becomes too important. | 12:26 |
| radiofree | paulsherwood: the code to request is already there right? | 12:26 |
| paulsherwood | yes, and to upload (but not hammered in a serious environment so far) | 12:26 |
| persia | I like `prep-commands`, but I think we also need something to automate the process of processing `prep-commands`, such that given a build system and a definitions working tree, if one has push access to a git repo, one can commit the bootstrap trees. | 12:27 |
| paulsherwood | i've been wondering about git-lfs, before settling on a soln | 12:27 |
| radiofree | not sure it needs that, wouldn't the cache key in the filename be good enough? | 12:28 |
| paulsherwood | yes, it would. i'm just not sure what the simplest soln is | 12:28 |
| * richard_maw doesn't like soln as the contraction of solution | 12:30 | |
| richard_maw | that's pretty off topic | 12:30 |
| richard_maw | but I'd be amused if people started contracting it to s6n | 12:30 |
| * persia was very tempted to provide a half-complete set of vowels and a 't' in which to carry then upon reading 'soln' | 12:31 | |
| persia | I was just thinking about cache servers: is there anything special about the cache server that is unsupported by traditional object storage systems like Ceph or Swift? | 13:15 |
| richard_maw | persia: I don't believe the Artifact Cache server needs anything, but the git cache server requires some methods that we haven't recently seen if we can't implemement on top of a regular git operation. | 13:17 |
| persia | That makes sense. My thought was to reduce the amount of code we need to maintain to provide infrastructure. For now, I think we need specialised git servers (it would be nice to only have one, rather than two), but if we can depend on another project for the cache server, it may reduce our maintenance overhead. | 13:18 |
| persia | I suspect I'm thinking about this because of the mention of developing a new cache server for ybd ,which seems to add more to be maintained without adding much value over what we have. | 13:19 |
| ssam2 | the current morph-cache-server is an almost trivial amount of code | 13:24 |
| ssam2 | exposing the same functionality on top of an existing object store would gain us better storage management, but probably not less code | 13:25 |
| persia | What functionality do we have beyond "store this object", "get this object", and "show me metadata for this object"? | 13:26 |
| ssam2 | not much | 13:26 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morph-cache-server | 13:26 |
| ssam2 | that handles both the Git cache and the artifact cache | 13:27 |
| ssam2 | it doesn't summarise the API in one place, it's spread thru the code | 13:27 |
| ssam2 | but the entire server is 400 lines | 13:27 |
| ssam2 | less | 13:27 |
| ssam2 | it's basically 'glue' code on top of the filesystem | 13:28 |
| ssam2 | i'm not saying we shouldn't change it, just that I don't think it'd make anything simpler if we did | 13:28 |
| persia | I'd like to be able to separate git and object functions more, but yeah, on reading that code, I think I agree with you for now. | 13:29 |
| richard_maw | We could do the ls_files functionality by turning on git-archive support on the git server and requesting a tarball of all the files we usually look at to see which build-system to attempt. We could do the cat-file with it too, for reading morphologies out of the repo (though we should migrate away from being able to do that), but the resolve_ref stuff is more difficult. | 13:32 |
| richard_maw | We can do ref -> commit sha1 easily by inspecting the result of ls-remote. | 13:32 |
| richard_maw | However to get the tree sha1 we'd have to do the first part of the fetch protocol like ls-remote does, plus request a shallow copy of the commit, parse the pack for the commit object, read the tree sha1 out of it, then abort the rest of the fetch. | 13:34 |
| richard_maw | at which point we may as well just always cache locally, but only request the refs we are known to care about, and request shallow trees. | 13:35 |
| persia | I don't want to change the local caching stuff more than necessary: that seems to work well. I'm only thinking about remote artifact caches to optimise the case where multiple developers are working on similar trees. | 13:36 |
| *** pacon has quit IRC | 14:33 | |
| ssam2 | some of us are doing research into Cloud Foundry and BOSH and how they can work with Baserock | 15:05 |
| ssam2 | i've created a couple of wiki pages for this project... | 15:06 |
| ssam2 | http://wiki.baserock.org/projects/bosh/ | 15:06 |
| ssam2 | http://wiki.baserock.org/projects/cloud-foundry/ | 15:06 |
| paulsherwood | ssam2: cool! | 15:15 |
| rdale | "ERROR: Components build are not in systems/minimal-system-x86-64-openwrt.morph." - shouldn't that be 'to be built'? | 15:30 |
| paulsherwood | rdale: is that morph? i can't find that string in the codebase? | 15:32 |
| paulsherwood | ssam2: nise bosh looks interesting! | 15:32 |
| radiofree | bosh is pretty big | 15:33 |
| paulsherwood | nise is tiny | 15:33 |
| SotK | rdale: what was the command you used? | 15:34 |
| rdale | just morph build | 15:34 |
| SotK | so `morph build systems/minimal-system-x86-64-openwrt.morph`? | 15:34 |
| SotK | if so that looks really odd, one sec | 15:35 |
| rdale | http://paste.baserock.org/enoxebiret | 15:36 |
| rdale | may 13th morph | 15:36 |
| paulsherwood | dodgy commandline | 15:36 |
| SotK | aha, its not weird then | 15:36 |
| rdale | ah right :) | 15:37 |
| SotK | its looking for a component called `build`, because of the extra build on the commandline | 15:37 |
| rdale | yes | 15:37 |
| SotK | that error should probably print the components in quotes to avoid that confusion | 15:37 |
| *** CTtpollard has quit IRC | 15:47 | |
| *** ssam2 has quit IRC | 16:01 | |
| paulsherwood | radiofree: is there anything for the wiki regarding how to build/deploy GENIVI Demo Platform yet? | 16:07 |
| radiofree | paulsherwood: there's http://wiki.projects.genivi.org/index.php/GENIVI_Demo_Platform | 16:11 |
| radiofree | http://wiki.projects.genivi.org/index.php/Hardware_Setup_and_Software_Installation/Jetson even | 16:11 |
| radiofree | use the -rebase branch though | 16:11 |
| *** jonathanmaw has quit IRC | 16:35 | |
| *** zoli__ has quit IRC | 16:37 | |
| *** bashrc_ has quit IRC | 16:55 | |
| *** mariaderidder has quit IRC | 16:56 | |
| *** zoli__ has joined #baserock | 17:14 | |
| *** zoli__ has quit IRC | 17:23 | |
| *** gary_perkins has quit IRC | 17:25 | |
| *** zoli__ has joined #baserock | 17:31 | |
| *** zoli__ has quit IRC | 17:36 | |
| *** edcragg has quit IRC | 17:49 | |
| *** lachlanmackenzie has quit IRC | 18:09 | |
| *** edcragg has joined #baserock | 19:48 | |
| *** zoli__ has joined #baserock | 20:26 | |
| *** zoli___ has joined #baserock | 20:52 | |
| *** zoli__ has quit IRC | 20:54 | |
| *** zoli___ has quit IRC | 22:10 | |
| *** edcragg has quit IRC | 23:50 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!