| *** franred [~franred@host-78-144-152-178.as13285.net] has joined #baserock | 06:47 | |
| *** franred [~franred@host-78-144-152-178.as13285.net] has quit [Ping timeout: 272 seconds] | 07:11 | |
| *** franred [~franred@host-78-144-152-178.as13285.net] has joined #baserock | 07:14 | |
| *** franred [~franred@host-78-144-152-178.as13285.net] has quit [Client Quit] | 07:14 | |
| *** fay [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 07:24 | |
| fay is now known as Guest35049 | 07:24 | |
| *** Guest35049 [~fay@92.40.33.96.threembb.co.uk] has quit [Client Quit] | 07:27 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 07:27 | |
| paulsherwood | radiofree: i think others should be able to do that? | 07:38 |
|---|---|---|
| pedroalvarez | Bulding attr now fails: http://pastebin.com/RMBXcHZe | 07:56 |
| pedroalvarez | this is not good :* | 07:56 |
| pedroalvarez | :( | 07:56 |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:01 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Client Quit] | 08:01 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:02 | |
| paulsherwood | interesting... on x86? | 08:02 |
| paulsherwood | pedroalvarez: ^^ | 08:03 |
| paulsherwood | definitions master, or something else? | 08:03 |
| pedroalvarez | x86, arv7, and ppc64 | 08:08 |
| pedroalvarez | definitions master | 08:08 |
| pedroalvarez | this is the change we have to look at: http://git.baserock.org/cgi-bin/cgit.cgi/delta/attr.git/commit/?h=baserock/morph&id=6148f883107b1a1de18254aa9ffe2fb1be0e1121 | 08:09 |
| pedroalvarez | Well, I'm building from master with a couple of patches on the top, but I don't think they are the problem. | 08:10 |
| paulsherwood | master same result | 08:12 |
| paulsherwood | pedroalvarez: ok i confirm reverting that patch fixes it | 08:16 |
| paulsherwood | maybe SotK has to wear the rubber chicken and buy donuts? :) | 08:20 |
| paulsherwood | http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html | 08:21 |
| * SotK needs to stop breaking things | 08:22 | |
| paulsherwood | SotK: it's a talent, to be nurtured. i've used my uncanny knack for breaking things to terrify engineers on several continents :) | 08:23 |
| pedroalvarez | paulsherwood: reverting the patch break more things using master of 'morph' | 08:23 |
| pedroalvarez | :) | 08:23 |
| paulsherwood | not for me? | 08:24 |
| pedroalvarez | paulsherwood: using the latest morph? | 08:24 |
| paulsherwood | unless something changed in morph yesterday? | 08:24 |
| *** franred [~franred@92.41.109.23.threembb.co.uk] has joined #baserock | 08:24 | |
| pedroalvarez | paulsherwood: that's it | 08:24 |
| SotK | I updated morph yesterday and forgot about all these broken repos :/ | 08:25 |
| paulsherwood | i'm at b2786c73c0f4d4b76f824e309598ce57065e30ab | 08:25 |
| paulsherwood | hmmm | 08:25 |
| *** jonathanmaw [~jonathanm@188.29.25.148.threembb.co.uk] has joined #baserock | 08:26 | |
| pedroalvarez | SotK: can you take a look at what happens with attr now? the log I provided is the failure using master of defnintions and morph | 08:27 |
| pedroalvarez | I can't see any difference betwen the JSON and the YAML | 08:28 |
| SotK | neither can I, it is confusing to me | 08:31 |
| richard_maw | it's probably the \ escapes | 08:31 |
| richard_maw | previously JSON would be consuming them, but YAML doesn't need escaping there, so it isn't and they've getting through to the build | 08:32 |
| * paulsherwood proposes we revert that patch | 08:32 | |
| franred | pedroalvarez, it is '\t' in JSON which in YAML fails when load | 08:33 |
| richard_maw | yep, and re-do it starting from json.loading the file, then yaml.dumping it | 08:33 |
| richard_maw | franred: are you sure? In this case it gets as far as building it, so the yaml loads ok | 08:33 |
| pedroalvarez | he doesn't have any context | 08:34 |
| pedroalvarez | franred: I'm talking about this: http://pastebin.com/RMBXcHZe | 08:34 |
| pedroalvarez | richard_maw, paulsherwood: should we do that, or wait until we move chunks into definitions | 08:35 |
| pedroalvarez | ? | 08:35 |
| franred | pedroalvarez, oh, I've seen - no this is not the case that Im talking about | 08:36 |
| radiofree | pedroalvarez: if master isn't building then surely it should be resolved asap? | 08:37 |
| paulsherwood | i'm for reverting it now. then separately bleeding edge morph won't build definitions master, so that's technically a morph problem, but it would be resolved if/when fran's script gets run :) | 08:37 |
| franred | paulsherwood, hold on with this, the new version is failing not sure why (I've rebased the new branch with master :S ) | 08:39 |
| paulsherwood | new version of what? | 08:39 |
| franred | paulsherwood, definitions | 08:40 |
| franred | new version of the script | 08:40 |
| paulsherwood | that's a separate issue, imo | 08:40 |
| franred | ok | 08:41 |
| pedroalvarez | Makes sense to me. | 08:46 |
| * SotK will revert the patch then | 08:47 | |
| *** ssam2 [~ssam2@92.41.109.23.threembb.co.uk] has joined #baserock | 09:04 | |
| pedroalvarez | franred: your problem could be related to the patch i did to "fix" attr. The new yaml morphology could have problems. | 09:07 |
| pedroalvarez | franred: can you try your script with master of definitions once SotK has reverted that patch? | 09:07 |
| pedroalvarez | And it has already been reverted. Good. | 09:10 |
| ssam2 | wow, I'd missed the commit "Avoid creating and pushing temporary build branches when they aren't necessary" | 09:10 |
| ssam2 | what an excellent day August 8th was for Morph ! | 09:10 |
| richard_maw | February 2013 was better for Morph, a lot of reproducible build stuff landed in that month | 09:11 |
| franred | pedroalvarez, I will try. but minimal build fine before using organize-morphologies.py - and then it fails. So firstly it is changing something that makes minimal to build again (which is undesirable) and then building mini-utils-devel fails :S | 09:12 |
| pedroalvarez | franred: then I don't think it''s related | 09:13 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 245 seconds] | 09:25 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 09:27 | |
| persia | richard_maw: Why doesn't update-ref work for detached HEAD? It's not gc-safe, but it's presumably only local anyway (and should be tagged on push). | 09:50 |
| richard_maw | persia: I thought the idea was to update-ref and push, but I guess if you're suggesting that local builds work by changing the repo: field to a file:// URI then you might get away with just putting "HEAD" in the ref field | 10:09 |
| persia | Depends on whether one is distbuilding: if distbuilding, one needs to push a temporary branch at that ref (making it no longer detached), but that's not different than the general file:/// distbuild case. | 10:10 |
| persia | The key thing for me was 1) to have a ref for the tree that worked (rather than having to wonder which random files in the working set made things work), and 2) to always build what was in definitions (to avoid having to wonder what to do to definitions to make it continue to work) | 10:12 |
| persia | s/thing/things/ | 10:13 |
| richard_maw | well, the needing to match the ref thing is removed by my patch, replaced by needing to set a config option to say that this repository contains the source you should use for this chunk | 10:17 |
| richard_maw | but as I understand what you want | 10:17 |
| richard_maw | instead of making temporary build branches for uncommitted changes, we should refuse to build | 10:18 |
| persia | I'm rather uncomfortable with your patch doing that. | 10:18 |
| richard_maw | and offer tooling to update the ref to what we committed | 10:18 |
| richard_maw | and only do temporary build branches when distbuilding | 10:18 |
| persia | I agree about temporary branches and distbuilding, but I'm nervous when you write "what we committed": I don't think morph should commit anything. | 10:19 |
| richard_maw | I meant we as in the user | 10:19 |
| persia | Aha. Yes. | 10:20 |
| persia | And for the config option you mention: am I also misunderstanding that this could cause the build artifact to use source differing from that specified in the ref in definitions? | 10:21 |
| richard_maw | yes, as we need to do that when we make a temporary build branch | 10:22 |
| richard_maw | I'm not 100% through the thinking of what should happen to the ref field in the morphology | 10:23 |
| persia | Thanks for confirming my misunderstanding, but I don't see how it is related to temporary build branches. | 10:23 |
| * paulsherwood can't get his head round this... will try richard_maw's patches and see what they do :) | 10:25 | |
| richard_maw | When morph makes a temporary build branch, it makes branches for all your chunk repositories, and a branch for the definitions repository. To be able to use the temporary build branches of the chunk repositories it has to alter the morphologies to set ref to the temporary build branch for that repository | 10:25 |
| richard_maw | so what ref looks like when you open the file is different to what was used when building using a temporary build branch | 10:26 |
| paulsherwood | wow | 10:26 |
| ssam2 | it's a huge hole in our provenance tracking of artifacts. It has been raised on the mailing list before | 10:28 |
| persia | That's stunningly overly complex in ways that can only cause user confusion and pain. | 10:28 |
| ssam2 | that's why I'm very happy that we at least only make temporary build branches when there are actually local changes, now | 10:28 |
| persia | We should probably just remove all of that entirely, and instead, if we have local refs, ensure those are available to distbuilders (at that ref) in some entirely different way. | 10:29 |
| paulsherwood | +0.5 | 10:29 |
| ssam2 | I'm not sure that's a constructive suggestion unless "some entirely different way" is fleshed out a bit more | 10:29 |
| ssam2 | seems to me that there are many ways to reintroduce exactly the same problem | 10:30 |
| persia | Indeed, it's not constructive at all. | 10:30 |
| paulsherwood | richard_maw: did you just describe what morph master does now, or what your latest patches would make it do? | 10:30 |
| richard_maw | both, the latest patch just allows you to have a different branch checked out and it still work | 10:30 |
| * persia needs to think a lot more to come up with a constructive suggestion here, because it's a very hard problem | 10:30 | |
| ssam2 | the problem is discussed here: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-April/005430.html | 10:32 |
| persia | Indeed. Yet another reason to avoid morph edit, because then morph can't do that :) | 10:33 |
| paulsherwood | richard_maw: is there a branch somewhere i can get yout 'Always use current branch...' patch? | 10:34 |
| richard_maw | paulsherwood: not currently, I'll make one | 10:34 |
| paulsherwood | tvm | 10:37 |
| richard_maw | hm, actually, I can't ssh to git.baserock.org right now, so I can't push the branch | 10:37 |
| paulsherwood | no problem, i'll try git magic | 10:38 |
| * paulsherwood fails | 10:43 | |
| persia | git am? | 10:43 |
| paulsherwood | yup | 10:44 |
| persia | Sometimes when dealing with annoying circumstances, I get patches locally, and then run `git apply` on each one. | 10:45 |
| persia | (this only works if one has less than 5 patches to process: more than that quickly gets very annoying) | 10:45 |
| persia | SHAs don't match, and you have to rewrite commit messages if you don't squash them, but it can allow testing when other methods fail. | 10:46 |
| ssam2 | i find GNU Patch sometimes works where 'git am' has failed | 10:49 |
| radiofree | franred: did you merge [PATCH 0/3] Organize morphologies in definitions repository yet? | 10:51 |
| radiofree | i have changed bsp-jetson-devel | 10:51 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/richardmaw/always-use-current-branch | 10:52 |
| radiofree | ah it's been rebased :D | 10:52 |
| franred | radiofree, no, I didn't. Im doing the final test to submit the patch - but I have to rebuild minimal | 11:02 |
| radiofree | ok, i noticed in v2 it's been rebased to (mostly) current state | 11:02 |
| franred | yep :) | 11:03 |
| paulsherwood | "2014-08-15 10:55:58 Deciding on task order | 12:08 |
| paulsherwood | ERROR: Field comments not allowed in morphology string" | 12:08 |
| paulsherwood | in which morph, i wonder | 12:09 |
| SotK | attr probably, I think that is the only one with a comments field | 12:09 |
| pedroalvarez | paulsherwood: using latest version of morph, right? | 12:09 |
| * SotK fixes the reverted-back-to-JSON version to not have a comments field | 12:10 | |
| *** flatmush1 [~flatmush@92.41.124.24.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 12:11 | |
| SotK | hmm, should I also try converting it to YAML using json.load, yaml.dump as well? | 12:11 |
| paulsherwood | pedroalvarez: yes, with richard_maw's patches | 12:13 |
| persia | That's going to be safer in terms of confirming the parser, but shouldn't make a difference. | 12:13 |
| SotK | that should sort out all the \ escapes that richard_maw suggested were causing the earlier problem too | 12:14 |
| paulsherwood | so morph checkout b:b/d master; morph build base_system => ERROR: Field comments not allowed in morphology string | 12:16 |
| paulsherwood | (with morph master) | 12:18 |
| paulsherwood | can we just delete the comment? | 13:08 |
| paulsherwood | http://fpaste.org/125833/81082001/ | 13:09 |
| persia | I thought that was what SotK was doing, except in a manner that was more history-consistent | 13:10 |
| persia | (and also fixing the escaping issues) | 13:10 |
| paulsherwood | possibly | 13:12 |
| *** radiofree_ [radiofree@unaffiliated/radiofree] has joined #baserock | 13:13 | |
| franred | second version of the script works with the latest version of morph and 3 patches on top | 13:18 |
| franred | well at least build minimal without having to rebuild anything | 13:18 |
| franred | richard_maw, pedroalvarez ^^ | 13:19 |
| pedroalvarez | good news! | 13:19 |
| tlsa | cool | 13:19 |
| * franred is preparing the patches and sending to the mailing list | 13:20 | |
| *** flatmush [~flatmush@188.29.121.222.threembb.co.uk] has joined #baserock | 13:20 | |
| radiofree_ is now known as radiofree | 13:20 | |
| persia | franred: Be sure to mention *which* morph patches you need if you depend on some in your post (or retest with the morph in definitions). | 13:22 |
| radiofree | my quassel has gone bonkers | 13:23 |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Quit: Bye] | 13:23 | |
| franred | persia, I will | 13:23 |
| paulsherwood | quassel? | 13:29 |
| persia | It's an IRC client not usually known for going bonkers. | 13:29 |
| * paulsherwood confesses he just stole a jetson from a distbuild network | 13:29 | |
| Kinnison | Oh dear | 13:29 |
| paulsherwood | :-) | 13:30 |
| ssam2 | um, there are lots of them behind me | 13:32 |
| ssam2 | which aren't in use in working build networks ... | 13:32 |
| paulsherwood | ssam2: yup, i know :) | 13:33 |
| paulsherwood | i'm going to steal one of those too | 13:34 |
| radiofree | wasn't someone going to use the jetson distbuild network | 13:34 |
| paulsherwood | a build network should be able to cope with the disappearance of one minion | 13:34 |
| radiofree | does it? I used to see total failure when the controller couldn't connect to one worker at startup | 13:35 |
| paulsherwood | ouch, then | 13:35 |
| radiofree | hence why i put in my documentation "start the workers before the controller" | 13:35 |
| paulsherwood | aha. this is a different use-case - a worker has disappeared from a running network. i'd hope it can cope with that? | 13:36 |
| Kinnison | No | 13:37 |
| ssam2 | I don't think hotplug was part of the initial design | 13:37 |
| Kinnison | This is not a context we designed for | 13:37 |
| ssam2 | it was designed for ARM servers, I believe | 13:37 |
| ssam2 | where you'd have to power it off to remove a node anyway | 13:37 |
| rjek | Some brands of ARM server are not known for their reliability :) | 13:38 |
| pedroalvarez | :) the controller is sending build requests to the no-longer-available worker | 13:38 |
| persia | We should probably rethink this for elastic resources at some point. | 13:38 |
| Kinnison | Indeed | 13:39 |
| Kinnison | The current design is not good for elastic resource, but we have ideas on how to fix that. | 13:39 |
| persia | A publish and subscribe model, or something else? | 13:40 |
| Kinnison | more like a trad req/rep model I think | 13:41 |
| Kinnison | Since the workers ought to be interchangeable fleets | 13:41 |
| ssam2 | as a way of solving this today, Pedro has cooked up a couple of Ansible scripts which allow you to administer a whole distbuild network easily | 13:41 |
| ssam2 | allowing you to say "remove this worker from the config and restart everything" easily | 13:41 |
| Kinnison | phew | 13:42 |
| persia | That's more of a workaround than a solution, but it's nice to have it. | 13:42 |
| rjek | The order of parameters to morph branch seems slightly odd. | 13:42 |
| persia | Kinnison: So workers would spin up, find a controller (by preconfig or some other mechanism), and then ask to be told what to do? | 13:43 |
| rjek | "morph branch baserock:baserock/definitions robkendrick/mips64 robkendrick/mips32" did not do as I expected. | 13:43 |
| rjek | I am probably expecting wrong. | 13:43 |
| persia | rjek: Luckily it's a command you only ever need to run once. | 13:43 |
| pedroalvarez | the main goal of my script was to make the distbuild use the latest morph | 13:43 |
| rjek | (I wanted to branch the mips64 thing into a new thing called mips32, but apparently the parameters go the other way around) | 13:44 |
| SotK | this confuses me every time I do it too | 13:44 |
| straycat | I think that's because the last arg is optional. | 13:44 |
| persia | I think the idea was that the destination wasn't optional and the source was. | 13:44 |
| SotK | that is why | 13:44 |
| pedroalvarez | what's the default? | 13:44 |
| straycat | master | 13:45 |
| SotK | master | 13:45 |
| persia | But this could also be addressed with argument counting, rather than fixed positional arguments. | 13:45 |
| pedroalvarez | obvious :0 | 13:45 |
| pedroalvarez | :) | 13:45 |
| rjek | persia: +1 | 13:45 |
| rjek | I am used to saying with basically every VCS and cp/mv/ln tool that you specify what to copy first, and where you want the new thing second. | 13:45 |
| rjek | It is probably too late to change this for morph, though | 13:45 |
| persia | No, morph is flexible. | 13:46 |
| rjek | Changing it will confuse everybody who it doesn't confuse in order to not confuse those it does :) | 13:46 |
| Kinnison | persia: indeed, that's my ideal approach | 13:46 |
| persia | But before I'd be interested in fixing it, someone would have to convince me that it's more useful to do this than `git checkout -b robkendrick/mips32 robkendrick/mips64` | 13:46 |
| richard_maw | rjek: I doubt this will surprise you or change your mind, but it's the way git does it as well | 13:46 |
| rjek | madness! | 13:47 |
| paulsherwood | http://fpaste.org/125843/40811042/ | 13:47 |
| paulsherwood | so the distbuild network i've sabotaged is at least still alive | 13:47 |
| persia | Kinnison: I suppose the main difference between that and publish/subscribe is just that there is still a SPOF on the controller? | 13:47 |
| radiofree | " ERROR: Field comments not allowed in morphology string " that's a new one | 13:48 |
| Kinnison | persia: Aye, and I'm not sure what to do about that beyond having every initiator be a controller and having the SPOF be the pubsub bus | 13:48 |
| paulsherwood | radiofree: blame SotK i think | 13:48 |
| Kinnison | It probably means a morphology somewhere has 'comments:' instead of 'description:' | 13:48 |
| persia | Kinnison: And then you do pubsub over MQ, and that goes away too, but this ends up requiring more infrastructure than may be useful. | 13:49 |
| straycat | rjek, It's a similar thing, the last arg (thing to branch from) in git branch is optional. | 13:49 |
| paulsherwood | i've proposed a fix, here already. but i believe others are working on a real solution | 13:49 |
| Kinnison | persia: aye. There's nanomsg which is by the øMQ guy, but it's not enough to get us going I don't think | 13:49 |
| paulsherwood | SotK: ^^ ? | 13:49 |
| persia | ZeroMQ is probably a closer fit, although I'm partial to rabbitMQ | 13:50 |
| Kinnison | nanomsg is an MQish thing but much lighter weight | 13:50 |
| Kinnison | with lots of language bindings | 13:50 |
| pedroalvarez | paulsherwood: as I said before, is alive but the controller is sending build requests to a dead worker | 13:50 |
| Kinnison | But I fear it would still have SPOFs | 13:50 |
| rjek | OK, now I'm very confused. | 13:51 |
| paulsherwood | pedroalvarez: that's amazingly frail | 13:51 |
| Kinnison | paulsherwood: It's a known frailty | 13:51 |
| paulsherwood | :) | 13:51 |
| SotK | paulsherwood: this is the issue caused by reverting the commit that broke attr | 13:51 |
| Kinnison | and known frailties can be guarded against until they can be fixed | 13:51 |
| rjek | So, I did "morph branch baserock:baserock/definitions robkendrick/mips64"; this gave me robkendrick/mips64/baserock/baserock/definiations/ that claims to be on the robkendrick/mips64 branch according to git branch -v, but none of my changes are there and git log show changes from today. | 13:52 |
| SotK | paulsherwood: we knew that this would happen with master of morph | 13:52 |
| SotK | it was my understanding we weren't going to update these broken chunks since they should be fixed by chunks-in-definitions soon enough | 13:52 |
| Kinnison | rjek: You created a new "local-only" (since you've not pushed) branch called the same as something which already existed | 13:52 |
| persia | rjek: I believe it's just created you a *new* local robkendrick/mips64 branch from master. | 13:53 |
| Kinnison | rjek: If you wanted to get your extant mips64 branch you probably wanted to do "morph checkout baserock:baserock/definitions baserock/robkendrick/mips64" | 13:53 |
| rjek | Oh. | 13:53 |
| * persia would like morph branch and morph checkout to go away, as they are confusing | 13:53 | |
| pedroalvarez | wrt: chunks in definitons: I was hoping that to happen today, there is a related patch in the ML | 13:53 |
| * rjek finds the simplist of things confusing. | 13:54 | |
| rjek | /src/workspace # morph branch baserock:baserock/definitions baserock/robkendrick/mips64 | 13:55 |
| rjek | 2014-08-15 13:53:45 Updating git repository baserock:baserock/definitions in cache | 13:55 |
| persia | rjek: Unfortunately, the precise behaviours of `morph branch` and `morph checkout` neither match the semantics from git nor have documentation outside the morph source code, so you aren't able to use your super powers today. | 13:55 |
| * rjek taps foot | 13:55 | |
| rjek | persia: Sadface. Still, the situation appears to be getting better. | 13:56 |
| persia | How? | 13:56 |
| rjek | Documenting how things should be done. | 13:56 |
| persia | I don't things should be done that way. I think the commands are confusing, and the results of having run them more confusing. | 13:57 |
| persia | think | 13:57 |
| * persia is still working on constructive suggestions to replace this | 13:57 | |
| SotK | does `morph branch --help` or `morph checkout --help` not help? | 13:57 |
| persia | Not really. It doesn't explain the difference in a way I understood, at least. | 13:58 |
| paulsherwood | meanwhile the sabotaged distbuild network appears to be happily distbuilding, without being affected by the absence of (dead) worker Pris | 13:59 |
| rjek | Anybody have any ideas? | 14:00 |
| rjek | /src/workspace # morph branch baserock:baserock/definitions baserock/robkendrick/mips64 | 14:00 |
| rjek | 2014-08-15 13:53:45 Updating git repository baserock:baserock/definitions in cache | 14:00 |
| rjek | ERROR: Failed to update cached version of repo git://git.baserock.org/baserock/baserock/definitions | 14:00 |
| rjek | Command exited with non-zero status 1 | 14:00 |
| rjek | real | 14:00 |
| rjek | sorry for the paste, I should have pastebinned that. | 14:00 |
| persia | That's usually a connectivity issue. | 14:00 |
| ssam2 | sounds like flaky network to me | 14:00 |
| rjek | Hmm. | 14:00 |
| paulsherwood | it's been one of those weeks, rjek :) | 14:01 |
| rjek | It has. | 14:05 |
| pedroalvarez | franred: re: morphloader_tests.py, try to ron `./check --full` in morph.git | 14:18 |
| pedroalvarez | also run | 14:18 |
| *** jonathanmaw [~jonathanm@188.29.25.148.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 14:22 | |
| * rjek struggles to get this to do the right thing | 14:38 | |
| *** jonathanmaw [~jonathanm@188.29.121.222.threembb.co.uk] has joined #baserock | 14:40 | |
| rjek | Success! | 14:47 |
| rjek | Balls. | 14:50 |
| rjek | /src/workspace/baserock/robkendrick/mips32/baserock/baserock/definitions # morph edit morph | 14:50 |
| rjek | 2014-08-15 14:49:39 Loading in all morphologies | 14:50 |
| rjek | ERROR: Unknown architecture mips32el in morphology cross-bootstrap-system-mips32el-generic.morph | 14:50 |
| rjek | I suppose I should have made that change /after/ issueing "morph edit morph" | 14:51 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 14:54 | |
| Kinnison | You'll need to run a local morph too with your ips32el change in it | 15:02 |
| Kinnison | Do you recall how to do that? | 15:03 |
| rjek | I'm sure I will remember, after I've made a load of mistakes :) | 15:03 |
| Kinnison | :-) | 15:03 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 15:09 | |
| *** ssam2 [~ssam2@92.41.109.23.threembb.co.uk] has quit [Ping timeout: 255 seconds] | 15:45 | |
| *** fay [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 15:50 | |
| fay is now known as Guest2985 | 15:50 | |
| Kinnison | rjek: If you're having trouble with the uname stuff on mips, be aware we do have provision for looking at the elf data of the python interpreter to get further information | 15:58 |
| Kinnison | we have to do that for armv7l vs. armv7lhf | 15:58 |
| Kinnison | because the uname is the same in both cases | 15:59 |
| *** Guest2985 [~fay@92.40.33.96.threembb.co.uk] has quit [Quit: Leaving] | 15:59 | |
| *** ssam2 [~ssam2@188.29.121.222.threembb.co.uk] has joined #baserock | 16:24 | |
| rjek | Kinnison: Ta, I'll look at that. | 16:36 |
| *** jonathanmaw [~jonathanm@188.29.121.222.threembb.co.uk] has quit [Quit: Leaving] | 16:58 | |
| *** ssam2 [~ssam2@188.29.121.222.threembb.co.uk] has quit [Quit: Leaving] | 17:24 | |
| paulsherwood | is there any way to diagnose a distbuild fail? | 17:25 |
| pedroalvarez | paulsherwood: what's the failure? | 17:26 |
| paulsherwood | i don't know - it just says Build failed: patch-misc | 17:27 |
| pedroalvarez | I'm having the same result right now | 17:27 |
| persia | I've heard you can get the build log from the trove | 17:27 |
| persia | (this should be easier) | 17:27 |
| pedroalvarez | you should be able to do cat build-step-patch-misc.log | 17:27 |
| pedroalvarez | s/cat/less/ | 17:28 |
| paulsherwood | ah, ok | 17:28 |
| paulsherwood | tvm | 17:28 |
| persia | Oh, cool. It was made easier :) | 17:28 |
| pedroalvarez | in my case the log says that it has been build successfuly | 17:29 |
| pedroalvarez | s/build/built/ | 17:29 |
| paulsherwood | on jetson? | 17:29 |
| pedroalvarez | yup | 17:30 |
| paulsherwood | ok - maybe i need to catch up to master definitions :) | 17:30 |
| pedroalvarez | I've been talking with Sam, and he says that the problem could be transferring the artifact to the artifact cache | 17:39 |
| *** franred [~franred@92.41.109.23.threembb.co.uk] has quit [Quit: Leaving] | 18:01 | |
| *** flatmush [~flatmush@188.29.121.222.threembb.co.uk] has quit [Ping timeout: 255 seconds] | 18:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:50 | |
| *** tlsa [RayMWA4eTB@gateway/shell/pepperfish/x-xprqbbyrojlbfpkb] has quit [Ping timeout: 250 seconds] | 23:05 | |
| *** tlsa [H2txpBJigK@gateway/shell/pepperfish/x-obnqyodmpnjyatkf] has joined #baserock | 23:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!