| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 01:29 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds] | 02:02 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 02:06 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 256 seconds] | 02:39 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 02:42 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 06:18 | |
| *** abdul_ [~abdul@202.0.77.198] has quit [Quit: Leaving] | 06:19 | |
| *** madhu [~madhu@202.0.77.198] has joined #baserock | 06:35 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: No route to host] | 07:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 07:21 | |
| *** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 07:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:22 | |
| *** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:22 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:22 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:00 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:12 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:12 | |
| persia | nomenclature is hard: while I agree with the desire for the name->chunk mapping to be unique, and to never have a chunk name used as a stratum name, I don't think it possible to determine the correct values in advance. This is something where appropriate naming should emerge as conflicts develop. | 08:55 |
|---|---|---|
| dutch is now known as wdutch | 08:55 | |
| *** abdul [~abdul@202.0.77.198] has joined #baserock | 08:55 | |
| paulsherwood | fair enough. but we could settle on a general approach for 'foo and the stuff foo typicall requires'? | 08:56 |
| paulsherwood | i don't think calling it foo is correct | 08:56 |
| persia | I'd rather restructure things to allow embedding and dependencies, so "foo" includes the chunk definition directly, and only requires subsidiary files in the special case where the subsidiary is a shared depedency for different things. | 08:57 |
| persia | Otherwise we end up with N sets of "foo-stratum", an "foo-chunk" for values of foo, stratum, and chunk. | 08:58 |
| persia | My understanding of the advantage of the multicomponent specification was to ease system design, so I don't want to have to think more than "I want foo", and get everything (and if I want to know what "foo" means, I want that it one place, excepting when DRY concerns apply). | 08:59 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:05 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| *** abdul__ [uid49809@gateway/web/irccloud.com/x-xkjuupqnaeocbudn] has quit [Quit: Connection closed for inactivity] | 09:09 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:09 | |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 09:23 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:26 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:28 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 09:31 | |
| *** aananth [~caananth@74.112.167.117] has joined #baserock | 09:31 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:32 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:34 | |
| petefoth | Are we | 09:59 |
| straycat | yes | 09:59 |
| * petefoth starts again | 09:59 | |
| straycat | we are | 09:59 |
| petefoth | Have we decoded to deprecate the geological terminology? I’m updating the project Glossary and have reached the word ‘morphology’. I was thinking of changing its entry to deprecated - see *definition* | 10:02 |
| Kinnison | I imagine we need a consensus-like decision on the ML before we deprecate terminology | 10:03 |
| Kinnison | BICBW | 10:03 |
| Kinnison | In the pub last night, richard_maw was still using 'stratum', 'morphology' etc. | 10:03 |
| petefoth | I wasn’t planning to chamge ‘stratum’ or ‘chunk’ (at least not yet). But in most of the conversations / emails I notice, we seem to use ‘definition’ more than ‘morphology’ | 10:06 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:09 | |
| Mode #baserock +v ssam2 by ChanServ | 10:09 | |
| ssam2 | anyone know whether build system autodetection works even if build-commands or something is specified in a chunk morph ? | 10:12 |
| ssam2 | I think it only works if there's no chunk morph, right? | 10:12 |
| petefoth | For now I wont use the word ‘deprecated’ - I will make the entry ‘See *Definition*’ | 10:12 |
| ssam2 | I think 'morphology' could be useful as a technical name for the language/format of the definitions | 10:13 |
| franred | ssam2, I think if you don't specify the morph field on the stratum it will try to autodetect the build system | 10:15 |
| ssam2 | franred: yes, but what if you do specify the morph field ? | 10:16 |
| ssam2 | I think suddenly it stops working. I hope so, because then it explains the problem that someone has mailed me about :) | 10:16 |
| ssam2 | by 'stops working' I mean, assumes 'build-system: manual' | 10:16 |
| Kinnison | Autodetection only happens in the absence of a morphology file yes | 10:17 |
| franred | I though that you should specify the build-system if you are using the morph file | 10:17 |
| petefoth | ssam2: as in ‘the way in which a system or other artifact is defined in a *definition*’ - That does work I think *but* i know/believe that paulsherwood wants (wanted?) to do away with the geological terminology completely | 10:17 |
| ssam2 | Kinnison, franred: I thought so | 10:17 |
| ssam2 | we may need to communicate that more clearly in our documentation | 10:18 |
| Kinnison | franred: yes | 10:19 |
| * Kinnison is all for requiring that the build system always be declared | 10:19 | |
| Kinnison | and removing autodetection entirely | 10:19 |
| Kinnison | it'll help speed up the early stages pre-build | 10:19 |
| ssam2 | I think we can speed that up without introducing regressions :) | 10:20 |
| ssam2 | I may be wrong though | 10:20 |
| franred | Kinnison, Im not sure about that, we will end up with loads of *chunk definitions* specifying only the build-system which is not ideal either | 10:21 |
| franred | petefoth, defined and definition in the same sentence sounds at least weird | 10:21 |
| Kinnison | franred: I also think we should be able to embed chunk morphology content into the stratum morphology | 10:21 |
| jmacs | It's a tautology. | 10:21 |
| petefoth | franred: true - I will rephrase | 10:22 |
| Kinnison | ssam2: My hope is to remove the need to look outside of the definitions repository at all, to know how to build a system | 10:22 |
| franred | Kinnison, could work, or add the chunk information from the stsratum into the chunk and only add the chunk name to the stratum | 10:23 |
| * Kinnison doesn't really want a proliferation of tiny files if we can get away without them | 10:24 | |
| franred | but they are more readable and manageable than have a master piece with all the info which is difficult to read or follow | 10:25 |
| Kinnison | Hmm | 10:26 |
| franred | Imagine have a stratum, with all chunks, pre-configured/configure/build/{pre,post}install commands, system integration scripts and build dependencies.... | 10:28 |
| richard_maw | our current dependency model is lacking in some respects, but we could get to explicit global build and runtime depends (as opposed to the restricted local build-depends we currently have) with a few steps | 10:28 |
| Kinnison | franred: Oh those would clearly end up split out | 10:29 |
| Kinnison | franred: but most chunks don't need them | 10:29 |
| richard_maw | 1. get rid of stratum artifacts 2. allow in-line chunks 3. add stratum runtime-depends | 10:29 |
| * richard_maw may write an rfc some time this week to describe it | 10:32 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:32 | |
| Krin | morning all. | 10:33 |
| richard_maw | mornin' | 10:33 |
| Krin | do we have or know any strata for baserock that have pre-populated a download from maven in their construction? or am i treading on completely new ground with this twisted insanity? | 10:34 |
| Kinnison | Completely new, unless a non-contributing user has done it | 10:34 |
| Krin | alternativly is there a way of stopping a build part way through so that i can let the build get to the point where all the items have been downloaded from maven and upload said files to the git repo so that they are already pressent and thus cut out maven? | 10:35 |
| ssam2 | Krin: there are hacky ways to do either of those things | 10:35 |
| franred | petefoth, also "definition" is a pretty vague term - definition of what? what does it contain/define? change "morphology" for "definition" does not make the concept easy to understand and make it more undetermined, OMHO | 10:36 |
| paulsherwood | Krin: would setting build-command: exit 1 help you? | 10:36 |
| Krin | i'm also pondering making a script that runs the first time the system is turned on that sets up the zookeeper, so that the maven can be accessed | 10:36 |
| ssam2 | Krin: if Maven functions as a packaging system, the best thing to do is probably find a way to import metadata from Maven using the baserock-import framework we've been working on | 10:37 |
| ssam2 | I know nothing about Maven, and can't really provide assistance in a few lines of IRC | 10:37 |
| Krin | paulsherwood, hmm, not sure, because i'd need to get half waty through the build first, and there isnt realy a break in the maven download and the installation of zookeeper, Unless i actualy work with the install script and make a customised version of that, i suppose that could work. hmmm | 10:37 |
| ssam2 | KrinL but it might make sense for us to chat about it in person at some point | 10:37 |
| ssam2 | paulsherwood: that would cause Morph to exit with failure :) | 10:38 |
| richard_maw | ssam2: that generally assumes source for the packages is available, Maven works in a world of binary only packages | 10:38 |
| ssam2 | richard_maw: hmm, OK | 10:38 |
| ssam2 | Morph generally assumes the source for the packages is available, too | 10:38 |
| petefoth | franred: I take your point: in Baserock, and for the purposes of the Glossary a ‘definition’ is a .morph file in the ‘definitions’ repo. I think that the discussions over terminology are not completed yet (and I will add a note to that effect in the Glossary) | 10:38 |
| ssam2 | so maybe this isn't something Morph is suited for at all? | 10:39 |
| paulsherwood | ssam2: i know. i use it to debug builds all the time. i thought it might help, is all | 10:40 |
| Krin | ssam2, i'm starting to think that more and more, i can get the dependancies for zookeeper onto baserock with little trouble, but i'm not so sure about zookeeper itself as part of it's install process is to actualy download things from maven, which obviusly cant be done during the build | 10:40 |
| Krin | not to my knowledge anyway XD | 10:40 |
| richard_maw | ssam2: there's still value in tracing imported binaries, but rather than building, we'd have to import the binaries into repositories and install them into the maven cache somehow | 10:40 |
| paulsherwood | Krin: i think you may have to override some part of its install process, then | 10:41 |
| ssam2 | paulsherwood: actually that is a neat debugging tool :) | 10:41 |
| paulsherwood | ssam2: thank you :) | 10:41 |
| ssam2 | Krin: does it download the same things each time? | 10:42 |
| Krin | ssam2, yes yes it does. | 10:42 |
| ssam2 | OK. so not too hard to second-guess it a bit | 10:42 |
| paulsherwood | key point is it allows you to stop morph at some point in the process, and look around to see what the chunk commands have done, what's available etc | 10:42 |
| ssam2 | I remember with the RubyGems work one of the ideas we looked at was importing .gem files directly from rubygems.org into the Morph build process | 10:42 |
| ssam2 | and adding a RubyGems server to Trove for those who want to mirror them locally | 10:43 |
| ssam2 | it seemed a much better idea to use the source directly | 10:43 |
| Kinnison | Krin: If I were you, I'd be looking to see if ant offers a target for 'download dependencies and stop' | 10:43 |
| ssam2 | but given that we can't use the source directly for Maven, I guess revisiting those ideas would make sense | 10:43 |
| Krin | Kinnison, i dont even know how i'd look for that, do you mean in the install script? | 10:44 |
| Kinnison | Sadly maven doesn't always provide source content | 10:44 |
| Kinnison | Krin: see if ant has a way to list its targets | 10:44 |
| Kinnison | Krin: e.g. gradle has a 'tasks' command | 10:44 |
| persia | Please be careful about how much tools are modified or worked around. If possible, it's better to discuss strategies with upstream. The goal is to make sure folk familiar with a given tool can be comfortable with using that tool with the Baserock build system. | 10:44 |
| Krin | also, oh so thats what maven is! *first google hit = Mars Atmosphere and Volatile EvolutioN* | 10:44 |
| persia | Lack of source is a common case in Java: the idea being to compile once, run everywhere. | 10:45 |
| Kinnison | persia: ant, as a direct build tool, seems to be being deprecated in favour of gradle | 10:45 |
| persia | I've read that, but I'm not sure how widely this is accepted | 10:45 |
| * persia hasn't been to JavaOne in decades | 10:45 | |
| Kinnison | persia: all I know is that all the java things I see right now seem to be at, or moving toward, gradle | 10:48 |
| Kinnison | persia: I imagine larger projects with investment in maven or ant will not move, or won't move for a while | 10:48 |
| Kinnison | Interestingly, I think gradle can import ant projects | 10:48 |
| jjardon | +1 for inline chunks; almost al of them are tiny and makes move chunks between stratum more difficult (you have to change 3 different files) | 10:49 |
| persia | I thought everyone liked the *idea* of inline chunks, but it required massive changes to the parser and graph generators. | 10:50 |
| persia | There's been some work on this, but I haven't seen anyone show something that worked entirely for that yet. | 10:51 |
| *** sherm_ [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 11:11 | |
| paulsherwood | persia: i have something that mostly works for that. it just doesn't do anything else yet :) | 11:14 |
| paulsherwood | (ie can parse and build-walk for inline chunks, non-inline chunks, nested content etc, no need for 'stratum' specialness) | 11:15 |
| jjardon | ah, ok: didnt know the details: I think the conditionals work is more important though | 11:17 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 11:37 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:42 | |
| dutch is now known as wdutch | 11:42 | |
| Krin | hmm, it seems that the download part of maven actualy all just goes into a nice neat little folder that other parts of the installation refferance, would it be possible to put said folder into a git repo and have the build, instead of calling 'ant compile_jute' call 'git clone jute_build' ? this seems like far too easy a work around so it's probebly not going to work. | 11:46 |
| ssam2 | Krin: it probably makes sense for you to prototype a couple of these approaches and see | 11:46 |
| ssam2 | will help for learning too | 11:46 |
| Krin | i'm intending to prototype this, i just dont know where to upload the folder to git. | 11:47 |
| ssam2 | there's a wide variety of Git servers you can use | 11:47 |
| ssam2 | one of the free git hosting services, like github, might be sufficient while prototyping | 11:47 |
| ssam2 | or you could deploy your own Trove, how to do that is documented on the wiki | 11:48 |
| Krin | is there a reccomended fo this comapny? a known one to use or something along those lines? | 11:48 |
| ssam2 | Krin: Trove ? | 11:48 |
| ssam2 | that's what makes sense for the Baserock project | 11:48 |
| Krin | ok i'll look into making my own trove, after lunch though BF wants to meet up in town for noms. so. i shal look after that. | 11:49 |
| ssam2 | an OpenStack deployment is the simplest, if you have an OpenStack cloud available | 11:49 |
| ssam2 | it's simplest if it has the generic Trove image already there, anyway :) | 11:50 |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:52 | |
| mike is now known as Guest27389 | 11:53 | |
| persia | paulsherwood: Indeed. Yours is one of the things to which I refer :) But until it actually does builds and populates caches, it's hard to use as a replacement :) | 11:54 |
| paulsherwood | persia: agreed. will see what i can do :-) | 11:55 |
| jmacs | What's the smallest amount of RAM we can reasonably run a baserock system in? | 12:07 |
| straycat | The smallest system we have is just a busybox system, so our minimum requirements should be similar to busybox. | 12:09 |
| straycat | I am not awake though | 12:10 |
| paulsherwood | jmacs: i'm assuming you mean a baserock *Linux* system? it would be possible to use baserock to build a simple RTOS or bare-metal scheduler system for example | 12:13 |
| jmacs | Yes, linux | 12:14 |
| paulsherwood | i think straycat is correct, then. but rjek and others may be able to comment on how small a linux system can be these days | 12:16 |
| robtaylor | Kinnison: looks like ssam2 has already looked a bit at scratchbox-in-baserock, might be worth chatting with him as well https://maemo.gitorious.org/scratchbox2 | 12:18 |
| paulsherwood | i thought scratchbox was deceased? an ex-project? :) | 12:18 |
| robtaylor | paulsherwood: Mer (and Jolla) still use it | 12:19 |
| robtaylor | iirc | 12:20 |
| * petefoth flashes back to his *vetry* early days at Codethink :) | 12:21 | |
| robtaylor | (nb scratchbox2, not scratchbox) | 12:27 |
| paulsherwood | oh, cool | 12:34 |
| pedroalvarez | ssam2: yeah! the same patch that you backported to gcc 4.6 to fix big endian, works in gcc 4.7.3 :) | 12:40 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 12:41 | |
| *** thecorconian [~jte@wsip-70-165-186-188.lv.lv.cox.net] has joined #baserock | 12:41 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:42 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 12:42 | |
| *** thecorconian [~jte@wsip-70-165-186-188.lv.lv.cox.net] has quit [] | 12:45 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 12:49 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 12:49 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:49 | |
| robtaylor | Kinnison: lots of good useful stuff here btw https://wiki.merproject.org/wiki/SB2 | 12:52 |
| franred | pedroalvarez, \o/ | 12:57 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 13:03 | |
| Kinnison | ta | 13:12 |
| petefoth | The old “Baserock System Glossary” mentions ‘the `bootstrap-baserock` script in the Morph source code.’ No sigh of this script in the mproh repo. Has it been superceded / removed? | 13:19 |
| richard_maw | yep, it went the way of the dodo a while back | 13:19 |
| richard_maw | it was before we could bootstrap natively in morph | 13:19 |
| petefoth | richard_maw: ta! | 13:19 |
| Kinnison | It looks like even if SB or SB2 are in active use, they're not under active development | 13:27 |
| Kinnison | and considering SB2 has a set of known issues, that is "not good"(tm) | 13:27 |
| persia | It's more the lack of anything else folk are happy about to replace them, rather than anything else. | 13:27 |
| Kinnison | I see | 13:28 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:31 | |
| Kinnison | SB2 does look significantly more interesting than S B | 13:32 |
| * Kinnison pokes at it | 13:32 | |
| richard_maw | there's a big section in http://www.merproject.org/~lbt/SB2_internals_1st_ed_20120425.pdf about how difficult it was for them to handle targets that are of a compatible architecture to the host… | 13:39 |
| * richard_maw wonders if this is just because they wanted to allow it to not need root | 13:39 | |
| Kinnison | there's a lot of interesting LD_PRELOAD going on in SB2 | 13:39 |
| richard_maw | since presumably you ought to be able to just chroot | 13:39 |
| * Kinnison was shocked to discover an embedded lua interpreter | 13:39 | |
| richard_maw | lots of glibc patches to the linker | 13:41 |
| madhu | ssam2, I face segfault when I build gdbm package when I "morph build systems/devel-system-x86_64-generic.morph --verbose" | 13:43 |
| madhu | http://fpaste.org/147407/41502221/ | 13:43 |
| paulsherwood | ouch! | 13:44 |
| paulsherwood | madhu: i assume you're running that on a baserock x86_64 system? | 13:44 |
| madhu | yes | 13:45 |
| madhu | it is same as http://wiki.baserock.org/guides/no-frills/ but I did "morph build" instead of running scripts/cycle.sh | 13:47 |
| Krin | hmm, trying to set up a trove, does anyone have any idea what i should use for my trove host? or if i need to somehow make one for the experiment? | 13:48 |
| Krin | i dont think i understand trove much >.< | 13:49 |
| Kinnison | You're setting up a fresh trove? | 13:49 |
| paulsherwood | madhu: are you building just one of the standard baserock system definitions? | 13:49 |
| Krin | i dont know what i should be doing, i just want a place to store a folder full of things that i can clone into zookeeper later | 13:49 |
| Kinnison | Hmm | 13:50 |
| Kinnison | There's a number of approaches there | 13:50 |
| madhu | yes it is the default devel-system-x86_64-generic.morph file. | 13:50 |
| Kinnison | perhaps the easiest is to make a branch in the zookeeper repository and add the things directly there | 13:50 |
| Kinnison | krin: ^^ | 13:50 |
| Krin | so just make a git branch? when i look at git status it shows that no changes are around even though the folder is new... | 13:51 |
| Krin | oh wait it's showing the difference now | 13:52 |
| paulsherwood | madhu: strange - my version of that shows 166 chunks, not 151? | 13:52 |
| petefoth | Krin: the Trove Refernce Manual on the wiki is based on an original which is pretty old and, while it almost certainly has some useful content, it may be hard to separate that from the outdated stuff. A web user called Michael - tlsa maybe - did a bit of work on it but I don't knw how far he got | 13:54 |
| petefoth | Krin: we (I?) should prpobably add some warning text to this effect at the top of the doc | 13:54 |
| petefoth | tlsa: can you tell me the current state of the document? | 13:55 |
| Kinnison | Krin: empty folders are not stored in git, so you'd need content in there first | 13:55 |
| Krin | Kinnison: so if i add the build file to the git, then morph will clone that file during the build process? hopefully allowing me to bypass the maven download part? petefoth: this time it was an error between keyboard and chair | 13:56 |
| paulsherwood | madhu: i think you must be building something else? or maybe using a different trove? if i run that here, gdbm is fetched from cache on git.baserock.org | 13:56 |
| Krin | also Kinnison, yes the folder has items in it | 13:56 |
| Kinnison | Krin: well I can't be certain, because I've not tried maven, but yes in theory | 13:57 |
| Krin | time to put theory to the test :) *cracks knucles and points menacingly at the computer* | 13:58 |
| madhu | paulsherwood, I did not change the trove, do you think I am using different definitions | 13:59 |
| Krin | wait no, i needed it seperate so i could pull it in midway through the build... hmm, is there a way of telling it to clone a folder into a location that does not exist until halfway through? or knowing where th file will be copied into so i can move it? it's currently in with the .morph's in the ../strata/zookeeper folder. | 14:00 |
| paulsherwood | madhu: so to confirm you don't have a different trove, cat /etc/morph.conf and check no trove-host or trove-id lines active | 14:01 |
| richard_maw | no, you have no control over where morph clones things to, you just get told where it did | 14:01 |
| richard_maw | Krin: but, you could have a separate chunk which provides the files, and then in your zookeeper chunk copy the files where you need them | 14:01 |
| Kinnison | Also, all cloning (all networking) happens before the build starts | 14:01 |
| paulsherwood | madhu: to confirm what commands you actually ran, cat ~/.ash_history | 14:01 |
| ssam2 | madhu: that's rather unexpected! | 14:03 |
| ssam2 | madhu: what hardware is this on? it's likely to be hardware-specific, I think, because we build gdbm on x86_64 lots and have never seen that | 14:03 |
| Krin | so to make a chunk i would need to push the files up to the baserock.git? they are not source files but neither are they obtainable, they are created midway through the build in a weird maven way >.< | 14:04 |
| paulsherwood | ssam2: i'm mystified so far :) but note that 166 != 151 | 14:04 |
| ssam2 | Krin: there's a few confusing uses of terminology in that sentence ! | 14:05 |
| ssam2 | Krin: there's no "baserock.git". We do have a Trove (which hosts Git repositories, amongst other things) running at http://git.baserock.org/ | 14:05 |
| ssam2 | but we have other Trove instances too that mirror the repos from http://git.baserock.org/, and can host their own content | 14:06 |
| * Krin gives up ever learning terminology as every time he think's he's got it it turns out he's saying the wrong thing | 14:06 | |
| ssam2 | don't give up now ! it makes it difficult to discuss things if we speak different languages | 14:07 |
| ssam2 | although we get by with jjardon, I guess ;) | 14:07 |
| Krin | could someone come to my desk so i can talk face to face and show what it is i'm trying to acheive, ether i'm not explaining myself right or i'm failing to understand the responses >.< | 14:08 |
| ssam2 | sure, let's have a chat about this | 14:08 |
| madhu | paulsherwood, it does not have trove-host and trove-id in that. BTW thats for locataing the ash_history, it looks like I have done something in busybox in my last session which might lead to this. | 14:10 |
| madhu | s/thats for locataing/ thanks for locating | 14:10 |
| madhu | I did "morph edit busybox --verbose", and "git merge origin/master" inside /src/workspace/test-madhu/upstream/busybox | 14:11 |
| madhu | let me revert this, git-status shows me the updated "ref" and "unpetrify-ref"for busybox in strata/build-essential.morph | 14:13 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 14:16 | |
| paulsherwood | ok | 14:16 |
| paulsherwood | i'm still confused about the 151 total, though? was your command definitely 'morph build systems/devel-system-x86_64-generic.morph'? | 14:16 |
| madhu | exactly | 14:17 |
| petefoth | Is the word ‘pebble’ (in the Baserock context) now obsolete? | 14:17 |
| paulsherwood | petefoth: yes | 14:17 |
| petefoth | paulsherwood: ta! | 14:17 |
| paulsherwood | petefoth: the word is now 'Jetson' :) | 14:17 |
| petefoth | :) | 14:18 |
| petefoth | And the phrase ‘staging filler’? | 14:18 |
| richard_maw | yep | 14:18 |
| paulsherwood | dead | 14:19 |
| paulsherwood | richard_maw: i continue to ponder cache_keys... | 14:19 |
| petefoth | but we do still have a ‘staging area’? | 14:19 |
| paulsherwood | and have arrived at a tail-chasing scenario in my head | 14:19 |
| madhu | paulsherwood, I used "morph branch baserock:baserock/definitions test-madhu baserock-14.40.1 --verbose", is that the reason for 151? | 14:20 |
| paulsherwood | ideally, it seems to me that i could calculate a notional cache-key for a whole system from a version definitions.git | 14:20 |
| paulsherwood | madhu: ah, yes. | 14:20 |
| paulsherwood | we added cloudstuff to devel since then | 14:21 |
| madhu | ah | 14:21 |
| paulsherwood | richard_maw: but then it occursr to me that an actual cache-key needs to trace actual tree-refs for things. and that info is not in definitions.git | 14:22 |
| paulsherwood | so it's not possible to calculate cache-keys without probing the component git repos. is that correct? | 14:22 |
| ssam2 | paulsherwood: with the current deisgn of morph, yes | 14:23 |
| petefoth | ssam2: ‘design’ or ‘implementation’? | 14:23 |
| ssam2 | answer unclear, ask again later | 14:23 |
| petefoth | :) | 14:23 |
| richard_maw | paulsherwood: currently, yes. Which is why one of Kinnison's proposed changes is to put information like that in, but also verify that the tree matches the commit when the tree is unpacked for building | 14:24 |
| paulsherwood | this then led me to wonder if trove should have an api to tell me tree for given repo/ref | 14:24 |
| richard_maw | it already does IIRC | 14:24 |
| paulsherwood | ah? | 14:24 |
| ssam2 | that's one of the things morph-cache-server does | 14:24 |
| robtaylor | can someone remind me what cases are optimised for by using the tree rather than the commit? | 14:24 |
| paulsherwood | not rebuild for someone tagging the tree | 14:25 |
| richard_maw | rebases and reverts | 14:25 |
| ssam2 | and merges | 14:25 |
| robtaylor | paulsherwood: a tag doesnt change a commit as such | 14:25 |
| robtaylor | ssam2: ah, fast forward merge commits? | 14:25 |
| paulsherwood | there can be multiple commits leading to the same tree | 14:25 |
| robtaylor | paulsherwood: there can, just not sure how often that matters | 14:26 |
| paulsherwood | one of our customers has specifically identified 'dealing better with a merg-based workflow' | 14:26 |
| ssam2 | robtaylor: it's the non-fastforward merges where there are new commits that point to an identical tree that you probably already built and tested | 14:27 |
| robtaylor | paulsherwood: do they mean using merge --no-ff ? | 14:27 |
| robtaylor | ssam2: not sure i understand what you mean | 14:28 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:30 | |
| * robtaylor rereads that last line a few more times | 14:30 | |
| ssam2 | robtaylor: I create a branch of definitions, build it, decide that it works. I then send it for review, it gets merged with '--no-ff', and now I have to rebuild 'master' of definitions.git, despite it being the same tree that I sent for review | 14:30 |
| robtaylor | ssam2: ah, so you do mean a fast-forward merge | 14:31 |
| ssam2 | I guess for definitions.git that doesn't actually matter, because definitions.git is a meta-repo anyway | 14:31 |
| ssam2 | robtaylor: I thought 'no-ff' meant 'non-fastforward' ? | 14:31 |
| robtaylor | ssam2: --no-ff means 'don't fast forward and create a merge commit' | 14:31 |
| robtaylor | lets call it a single parent merge for clarity ;) | 14:32 |
| ssam2 | The scenario where a merge commit is created is the scenario which that optimisation (using tree sha instead of commit) was done for | 14:32 |
| robtaylor | understood | 14:33 |
| richard_maw | plus, it helps if you revert your change to the compiler, so you don't have to rebuild the world on a revert | 14:33 |
| robtaylor | richard_maw: thats quite a low frequency occurance though, probably not worth specifically optimising for | 14:34 |
| robtaylor | ssam2: if you have CI, would you care less about optimisation for your specific case there? | 14:36 |
| paulsherwood | is the morph-cache-server api specified anywhere (apart from in the code)? | 14:36 |
| ssam2 | robtaylor: I've not got a strong position on this specific optimisation. CI might well mitigate the need for it | 14:37 |
| ssam2 | paulsherwood: no, only in the code (morph-cache-server is considered an implementation detail) | 14:38 |
| ssam2 | the code is more or less 1 file of Python, though, it's simple enough | 14:38 |
| paulsherwood | heh | 14:41 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:47 | |
| madhu | paulsherwood, it seems the build is going smoothly now, thanks for the help. | 14:49 |
| paulsherwood | madhu: great news! :) | 14:50 |
| * paulsherwood sometimes wonders what 'is considered an impelementation detail' actually means | 14:52 | |
| ssam2 | paulsherwood: i doubt I use it in a consistent way. Here I meant "the user isn't meant to interact with it directly" | 14:53 |
| ssam2 | hence, I feel less bad for it lacking any kind of API specification | 14:54 |
| paulsherwood | oh, i see :) | 14:56 |
| * paulsherwood gives up on trying to understand the 'simple enough' python :) | 14:56 | |
| pedroalvarez | paulsherwood: are you trying to achieve anything particular? | 14:57 |
| pedroalvarez | in particular* | 14:58 |
| paulsherwood | pedroalvarez: just get tree from a ref for a given repo, without having to clone the repo | 14:59 |
| paulsherwood | i was assuming this was impossible, til someone said that morph-cache-server has an api | 14:59 |
| pedroalvarez | hm... | 15:00 |
| pedroalvarez | who told you that? | 15:00 |
| pedroalvarez | I mean, I think that morph-cache-server can't do that | 15:00 |
| pedroalvarez | I can be wrong, though | 15:00 |
| paulsherwood | pedroalvarez: see 14:25 in backscroll | 15:00 |
| * pedroalvarez opens the morph-cache-server code | 15:03 | |
| ssam2 | it's this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morph-cache-server#n194 | 15:03 |
| ssam2 | I guess you do have to understand the Bottle framework a bit for the code to make sense | 15:04 |
| pedroalvarez | I was wrong :) | 15:06 |
| * ssam2 tries and fails to manually construct an example request for the http://git.baserock.org/1.0/sha1s endpoint | 15:07 | |
| ssam2 | oh, because it's on port 8080 | 15:08 |
| ssam2 | http://git.baserock.org:8080/1.0/sha1s?repo=git%3A%2F%2Fgit.baserock.org%2Fbaserock%2Fbaserock%2Fdefinitions&ref=master | 15:08 |
| ssam2 | resolves master of definitions.git to commit SHA1 and tree SHA1 | 15:08 |
| paulsherwood | you did that manually? :) | 15:08 |
| ssam2 | with a little help from Python's urllib.urlencode() | 15:09 |
| ssam2 | i have not memorised the URL escape sequences :) | 15:09 |
| paulsherwood | what do they mean? | 15:10 |
| paulsherwood | but thanks, i can hack what i want from that :) | 15:11 |
| paulsherwood | incidentally, what did you do exactly to create that? | 15:11 |
| * paulsherwood is always on the lookout for cool tricks :) | 15:12 | |
| ssam2 | import urllib; urllib.urlencode(('repo', 'http://git.baserock.org/baserock/baserock/definitions')) | 15:12 |
| ssam2 | no, sorry, not that one | 15:13 |
| ssam2 | urllib.urlencode({'repo': 'http://git.baserock.org/baserock/baserock/definitions'}) | 15:13 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:34 | |
| *** aananth [~caananth@74.112.167.117] has quit [Quit: Leaving] | 15:38 | |
| ssam2 | can anyone clear up what the following means in a Trove's journal ? | 15:53 |
| ssam2 | http://fpaste.org/147458/14150300/ | 15:53 |
| ssam2 | the Trove seems to work fine | 15:54 |
| paulsherwood | possible break in attempt? | 16:00 |
| richard_maw | it may just be missing reverse-dns entries | 16:00 |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-hhzujylmdusfoekc] has quit [Ping timeout: 255 seconds] | 16:08 | |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-ipohiqaowqtrqqyr] has joined #baserock | 16:08 | |
| robtaylor | ssam2: it 's your ./etc/hosts | 16:09 |
| robtaylor | (probably) | 16:09 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 16:10 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 16:10 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:10 | |
| robtaylor | ssam2: looks like you've got two entries for ct-training (or maybe one entry for ct-training and another for ct-training.localdomain/ct-training.<something in your search> | 16:11 |
| robtaylor | ssam2: basically the message means - <ip address> maps to <foo> but when i reverse-dns <foo> I don't get the same ip address | 16:12 |
| ssam2 | robtaylor: ok, thanks ... | 16:14 |
| ssam2 | seems like we have a problem with the defaults for Trove deployments then | 16:14 |
| robtaylor | possibly | 16:14 |
| pedroalvarez | if this is running in our datacentred tenant i think that the reverse-dns doesn't work | 16:14 |
| ssam2 | ah, OK | 16:15 |
| ssam2 | that may well be true for Aananth too (who sees the same message) | 16:15 |
| pedroalvarez | easy to check in python: import socket; socket.getfqdn("IP ADDRESS") | 16:17 |
| ssam2 | that's useful, thanks | 16:18 |
| paulsherwood | maybe this goes in 'Other common errors' ? | 16:18 |
| ssam2 | this trove doesn't have a /etc/hosts | 16:18 |
| ssam2 | maybe if it did it'd be happier | 16:18 |
| ssam2 | although in fact, reverse DNS does seem to work here ... | 16:19 |
| ssam2 | >>> socket.getfqdn('192.168.222.19') | 16:19 |
| ssam2 | 'ct-training' | 16:19 |
| ssam2 | >>> socket.getfqdn('127.0.0.1') | 16:19 |
| ssam2 | 'localhost' | 16:19 |
| ssam2 | >>> | 16:19 |
| ssam2 | this is without even adding a /etc/hosts file | 16:20 |
| pedroalvarez | >>> socket.getfqdn("85.199.252.86") | 16:20 |
| pedroalvarez | 'no-reverse-dns.metronet-uk.com' | 16:20 |
| ssam2 | so maybe it's conflicting entries instead like Rob says | 16:20 |
| ssam2 | pedroalvarez: ah, true | 16:20 |
| pedroalvarez | but indeed, I don't know if in this case is using the public ip or the private one | 16:21 |
| ssam2 | actually the log shows: 'Address ::1 maps to ct-training, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!' | 16:21 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:21 | |
| ssam2 | I believe ::1 is the IPv6 localhost | 16:21 |
| Kinnison | it is | 16:21 |
| ssam2 | but, I can resolve that to localhost in Python too ... | 16:21 |
| Kinnison | does ct-training on that box resolve to ::1 ? | 16:22 |
| robtaylor | ssam2: localhost != ct-training | 16:22 |
| ssam2 | robtaylor: heh! good point | 16:22 |
| ssam2 | now I understand :) | 16:22 |
| robtaylor | :D | 16:23 |
| franred | does someone knows if nbd is in the kernel tree? I mean if it is an out of tree kernel module or not? | 16:33 |
| Kinnison | nbd is in-kernel I think | 16:33 |
| Kinnison | there's some userland apps too | 16:34 |
| Kinnison | which I don't think are in the kernel tree | 16:34 |
| pedroalvarez | Kinnison: does that mean that by default it should be installed in every baserock system? | 16:34 |
| pedroalvarez | (if it's in-kernel) | 16:34 |
| Kinnison | Oh, it's in-kernel-tree | 16:34 |
| Kinnison | i.e. we could build it in if we wanted | 16:34 |
| pedroalvarez | good | 16:35 |
| pedroalvarez | franred: I think is: CONFIG_BLK_DEV_NBD | 16:37 |
| Kinnison | http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/tree/drivers/block/nbd.c | 16:37 |
| franred | http://fpaste.org/147470/32743141/ | 16:38 |
| Kinnison | So we've not *built* it | 16:38 |
| pedroalvarez | franred: yeah, you have to enable it in the kernel morphology | 16:39 |
| Kinnison | http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/tree/drivers/block/Makefile#n30 | 16:39 |
| Kinnison | confirms pedroalvarez's belief of CONFIG_BLK_DEV_NBD | 16:39 |
| ssam2 | at the bottom of http://wiki.baserock.org/guides/configuring-a-trove/ it says 'To make the Trove use the changes you make, push them to the local-config repository on the Trove.' | 16:44 |
| ssam2 | so if I push a proxy.conf to local-config/lorries.git does that get used straight away automatically ? | 16:45 |
| Kinnison | It should | 16:45 |
| ssam2 | OK | 16:45 |
| ssam2 | I pushed an invalid proxy.conf as a test and I don't see any errors | 16:45 |
| ssam2 | but it maybe that it silently ignores errors, rather than that it's missing the update | 16:45 |
| Kinnison | Check l-c's source? | 16:45 |
| ssam2 | I shall | 16:45 |
| pedroalvarez | worth noting that node doesn't build in big-endain | 16:53 |
| franred | Kinnison, pedroalvarez, cheers | 16:53 |
| pedroalvarez | wait, I'm wrong, node is not in this system I think | 16:54 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:57 | |
| pedroalvarez | it actually is | 16:58 |
| * pedroalvarez removes it for now | 16:58 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:08 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:10 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:19 | |
| pedroalvarez | sigh.. | 17:24 |
| straycat | meow? | 17:24 |
| pedroalvarez | :) | 17:25 |
| pedroalvarez | I'm trying to call the baserock-installer script as the init script (init=/myscript in the kernel args) | 17:25 |
| pedroalvarez | I don't know what to do when the system is installed | 17:26 |
| pedroalvarez | I think that I should reboot, and I tried to do that, but something is different when I run this script as an init script, and I can't reboot the system | 17:26 |
| pedroalvarez | :/ | 17:26 |
| straycat | Why can't you reboot? | 17:28 |
| pedroalvarez | not sure, it fails, I was trying to do it with subprocess.call(['reboot')]. I'm trying now with os.system('reboot') | 17:31 |
| pedroalvarez | and this time it fails with: Failed to talk to init daemon. | 17:32 |
| pedroalvarez | which makes sense | 17:32 |
| * straycat nods | 17:32 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:34 | |
| straycat | reboot -f maybe? | 17:34 |
| pedroalvarez | I think that `reboot..` talks to the init deamon, and then the init daemon decides to reboot | 17:35 |
| straycat | I think using -f skips over that init stuff iirc | 17:36 |
| pedroalvarez | aha | 17:36 |
| pedroalvarez | then I will try | 17:36 |
| straycat | It's not a safe way to bring the system down though, you probably need to sync and unmount stuff first. | 17:37 |
| *** hari_ [uid49867@gateway/web/irccloud.com/x-frypqlabymmvoexm] has quit [Quit: Connection closed for inactivity] | 17:37 | |
| pedroalvarez | straycat: that just worked, thank you | 17:39 |
| straycat | :) | 17:41 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:54 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:02 | |
| pedroalvarez | urgh... http://pastebin.com/abWLDAC5 | 18:06 |
| pedroalvarez | this is scary | 18:06 |
| radiofree | is that u-boot? | 18:10 |
| radiofree | yes it is make: *** [u-boot] Error 139 | 18:12 |
| radiofree | you don't need to recompile that be? | 18:12 |
| *** Guest27389 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:20 | |
| pedroalvarez | radiofree: i guess so. I will reuse the armv7lhf one | 18:23 |
| pedroalvarez | I was doing it just copying the existing system, changing the architecture, and morph build. | 18:27 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:51 | |
| jjardon | almost there and now I need a new version of sqlite :/ time to some fresh air | 19:15 |
| pedroalvarez | jjardon: for gnome? | 19:17 |
| pedroalvarez | That should be easy, but it will trigger a full rebuild | 19:18 |
| jjardon | pedroalvarez: evolution-data-server, yes | 19:18 |
| jjardon | pedroalvarez: we do not track the git repo but seems we only lorried a tarball | 19:18 |
| jjardon | and also: full rebuild for a new version of sqlite? crazyness :) | 19:19 |
| pedroalvarez | Not full, but I believe that is in core. Don't ask me why | 19:20 |
| jjardon | pedroalvarez: python | 19:21 |
| jjardon | well cython | 19:21 |
| * jjardon would split python from core | 19:21 | |
| pedroalvarez | jjardon: I want to see that running! :) | 19:26 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:00 | |
| *** cosm [~Unknown@us2x.mullvad.net] has joined #baserock | 20:02 | |
| cosm | hi, it's been suggested I might find people hacking jetson tk1s here | 20:04 |
| cosm | is anyone familiar with the memory controller? | 20:04 |
| cosm | I've replaced the RAM on my board with 1 GB chips, but I'm having trouble finding stable settings for a 4GB configuration | 20:07 |
| pedroalvarez | Hi cosm! radiofree has been playing hard with the tk1, maybe he knows something... | 21:10 |
| robtaylor | hey cosm | 22:09 |
| robtaylor | don't think anyone's been hardware hacking them yet here, i'm afraid | 22:09 |
| robtaylor | cosm: tried steve warren? that's the sort of thing he might know | 22:10 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!