| *** robtaylo1 [~robtaylor@floopily.codethink.co.uk] has joined #baserock | 03:51 | |
| *** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 03:51 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/x-ipgqvfnrjfrdfdsy] has joined #baserock | 03:52 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 03:52 | |
| *** robtaylor [~robtaylor@floopily.codethink.co.uk] has quit [Ping timeout: 250 seconds] | 03:52 | |
| *** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 250 seconds] | 03:52 | |
| *** rjek [~rjek@gateway/shell/pepperfish/x-izqmpjdsidvxpmry] has quit [Ping timeout: 250 seconds] | 03:52 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 03:52 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 03:52 | |
| *** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 03:52 | |
| *** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 250 seconds] | 04:07 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 04:07 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 04:07 | |
| *** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 04:07 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 06:50 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:24 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 260 seconds] | 08:12 | |
| richard_maw | morning all | 08:23 |
|---|---|---|
| Kinnison | It is. | 08:24 |
| *** fay_ [~fay@92.40.108.42.threembb.co.uk] has joined #baserock | 08:27 | |
| *** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock | 08:34 | |
| *** jonathanmaw [~jonathanm@188.31.135.43.threembb.co.uk] has joined #baserock | 08:54 | |
| paulsherwood | what's the chance of getting franred's morph-in-definitions reviewed and applied this week? | 08:54 |
| * paulsherwood ducks | 08:54 | |
| *** ssam2 [~ssam2@188.29.105.39.threembb.co.uk] has joined #baserock | 08:55 | |
| Kinnison | I think it's possible, but given we'll want to be very very careful about this, it might be early next week | 08:55 |
| *** jonathanmaw [~jonathanm@188.31.135.43.threembb.co.uk] has quit [Ping timeout: 260 seconds] | 08:58 | |
| paulsherwood | ok - does franred show up on here? maybe he could explain how he's tested it? | 08:58 |
| *** franred [~franred@188.29.105.39.threembb.co.uk] has joined #baserock | 09:00 | |
| richard_maw | one interesting test would be to build a system, run franred's script for converting, and see if you still need to rebuild | 09:01 |
| straycat | What is morph-in-definitions? | 09:01 |
| Kinnison | richard_maw: given we include morphology text for strata etc in the artifacts, wouldn't we be guaranteed rebuilds? | 09:01 |
| richard_maw | Kinnison: not completely, the stratum and chunk list is excluded because that is already covered by the build dependency information that was added to the cache key | 09:02 |
| persia | straycat: moving all the chunk morphologies to the definitions repository. | 09:03 |
| franred | straycat, all the morphologies will be placed in the definitions repository | 09:04 |
| straycat | Oh you mean chunks in definitions? | 09:04 |
| Kinnison | richard_maw: aah | 09:04 |
| persia | Yes | 09:04 |
| * straycat nods | 09:05 | |
| paulsherwood | franred: how did you test your chunks in definitions script so far? | 09:06 |
| franred | paulsherwood, I've built base-system-x86_64-generic.morph in the normal definitions repository, I run my script, (commit the changes - not needed) and then built systems/base-system-x86_64-generic.morph. This shouldn't take time because all the chunks are already built | 09:09 |
| franred | and cached | 09:09 |
| Kinnison | That's a good basic test. Ideally we'd build everything from release.morph | 09:10 |
| Kinnison | franred: did you also confirm that deployment worked? | 09:10 |
| persia | Wouldn't we ideally build all defined systems and deploy all defined deployments? | 09:11 |
| * persia isn't advocating this, just thinking about idealism | 09:11 | |
| franred | Kinnison, no, I didn't test deployment - just morph build | 09:11 |
| Kinnison | tsk | 09:11 |
| Kinnison | Your script moved clusters | 09:11 |
| Kinnison | and systems | 09:11 |
| Kinnison | pls. to test that and append results onto thread | 09:12 |
| franred | Kinnison, yes, all the morphologies will be classified | 09:12 |
| franred | Kinnison, ok, I will do | 09:12 |
| *** jonathanmaw [~jonathanm@92.40.192.133.threembb.co.uk] has joined #baserock | 09:13 | |
| *** fay_ [~fay@92.40.108.42.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 09:32 | |
| *** fay_ [~fay@188.31.135.43.threembb.co.uk] has joined #baserock | 10:01 | |
| *** fay_ [~fay@188.31.135.43.threembb.co.uk] has quit [Client Quit] | 10:01 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 10:05 | |
| richard_maw | SotK: finished looking at your changes, I'd prefer a couple of tweaks to the morphloader, but it's ok in its current form | 10:29 |
| SotK | richard_maw: thanks :) I'll make that s/iterkeys/iteritems/ change and other style change and merge then | 10:35 |
| SotK | is there a reason morph3 subclasses UserDict.IterableUserDict rather than just dict btw? | 10:36 |
| SotK | UserDict is an old style class, so type(morph) just returned 'instance' rather than 'Morphology' | 10:36 |
| richard_maw | good point, I guess it's because Lars wrote it and he's used to writing code to work on old versions of python | 10:38 |
| *** jonathanmaw [~jonathanm@92.40.192.133.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 11:01 | |
| *** jonathanmaw [~jonathanm@188.29.25.148.threembb.co.uk] has joined #baserock | 11:20 | |
| pedroalvarez | Would be useful for distbuild to report what is building sometimes, but I can't imagine yet how could it be | 11:37 |
| pedroalvarez | Maybe every minute it can show a report saying: | 11:40 |
| pedroalvarez | Still building 'foo' in wokrer3: (13m 43s) | 11:40 |
| pedroalvarez | Still building 'bar' in wokrer1: (1m 12s) | 11:40 |
| ssam2 | you can 'tail -f' the build-step-*.log files | 11:44 |
| ssam2 | not ideal, but useful | 11:44 |
| pedroalvarez | that's useful, but I was suggesting that as a way to show the user that the system is still working | 11:46 |
| pedroalvarez | sometimes when you are in a bottleneck like llvm, distbuild looks like it's doing nothing | 11:46 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 272 seconds] | 11:51 | |
| paulsherwood | maybe the controller could publish a live webpage | 11:58 |
| paulsherwood | franred: i ran your script - it fell over with http://fpaste.org/125537/17564140/ | 11:59 |
| richard_maw | paulsherwood: `export PYTHONPATH=/src/morph` | 12:00 |
| richard_maw | I had to do that to get it to work in baserock 14.26 | 12:00 |
| paulsherwood | richard_maw: thanks. it seems to be a bit happier now | 12:02 |
| franred | ummm, Im using the latest version of morph http://wiki.baserock.org/using-latest-morph/ ... shouldn't I suppose to do it? | 12:03 |
| paulsherwood | franred: are you speaking spanglish todfay? :-) | 12:03 |
| paulsherwood | sorry - what did you mean? | 12:03 |
| richard_maw | franred: the issue is that your script loads morphlib from /usr/lib/python2.7, since it doesn't have a morphlib right next to it | 12:04 |
| paulsherwood | i could be wrong, but i think situations where there is no morph file should not be flagged as 'WARNING' | 12:05 |
| paulsherwood | eg Downloading libtiff.morph from ssh://git@git.baserock.org/delta/libtiff into strata/gtk-deps/libtiff.morph | 12:06 |
| paulsherwood | WARNING: libtiff.morph not found in ssh://git@git.baserock.org/delta/libtiff.Expected autodetection at build time | 12:06 |
| paulsherwood | ? | 12:06 |
| Kinnison | I think it's fine for it to be a warning | 12:06 |
| Kinnison | Not least, I still want rid of autodetect | 12:07 |
| paulsherwood | ughh :) | 12:07 |
| paulsherwood | i propose it's just INFO | 12:07 |
| pedroalvarez | autodetect is awesome (when the build doesn't fail) | 12:07 |
| paulsherwood | +1 | 12:08 |
| paulsherwood | can we safely move *.configure and *.write into a subdir too? | 12:09 |
| franred | paulsherwood, the script expected to download that file, if after running the script you don't have the chunk morphologies that your stratum said, I would expect that my script tells me why | 12:09 |
| richard_maw | not yet | 12:09 |
| paulsherwood | i'm confused, franred - approx 50% of the chunks have no morph file. that's a 'normal' case | 12:10 |
| richard_maw | hm, the HEAD of the branch we use for lua is not the same as the commit listed, the top one was converted to yaml | 12:10 |
| paulsherwood | i see quite a few ERRORs reported too (which is probably a good thing, but i wonder how/when is best to fix them) | 12:11 |
| Kinnison | richard_maw: yay, more missed updates :-( | 12:11 |
| franred | paulsherwood, they are auto fixed | 12:11 |
| richard_maw | paulsherwood: franred has been through the common ones and auto fixed | 12:11 |
| Kinnison | richard_maw: was it me this time? | 12:12 |
| paulsherwood | perfect | 12:12 |
| richard_maw | Kinnison: I don't know if you were supposed to be responsible for the update, but SotK is listed as having made the commit | 12:12 |
| Kinnison | :-( | 12:12 |
| franred | paulsherwood, regarding to the autodetected chunks - I don't really know - I couldn't go one by one - I trust the script when it checks that there aren't any | 12:13 |
| SotK | I think it was probably when I was working on my chunks in definitions stuff, I converted some of the morphologies to YAML before I decided to not use morphloader and cause all the validation to be run on them | 12:14 |
| paulsherwood | franred: all i'm saying is i'd like th WARNING to be INFO, so less expert users don't panic | 12:14 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 12:14 | |
| * pedroalvarez panics with WARNINGs | 12:14 | |
| * Kinnison carefully reads warnings, realises what they say and then decides whether to treat them as INFO or ERROR | 12:14 | |
| * Kinnison tends to ignore INFO | 12:14 | |
| paulsherwood | and maybe also change the ERROR so it's clear that the script is fixed | 12:14 |
| richard_maw | also, unset the default fields | 12:15 |
| paulsherwood | in this case the INFO would be entirely ignorable. that's the right thing for the user to do | 12:15 |
| franred | paulsherwood, the following message after the ERROR should tell you that it is fixed | 12:15 |
| Kinnison | ERROR really should only happen in cases where the stuff stops having failed | 12:16 |
| Kinnison | IMO | 12:16 |
| franred | richard_maw, yes, I've missed unset default fields | 12:16 |
| Kinnison | WARNING is for things which might be an issue but the script works around | 12:16 |
| franred | Kinnison, I can remove the ERROR message, I planned to do it but it does not remove the fact that in the repositories the morphology is wrong - I could add them as a INFO too | 12:17 |
| paulsherwood | as a user, if i see ERROR i assume something broke. and as an experienced developer, i see WARNING as a flag that something hasn't been cleaned up properly. i'd like both to be INFO in this case | 12:17 |
| paulsherwood | but i can be wrong as always | 12:18 |
| Kinnison | WARNING means "something was bad, but I worked around it" | 12:18 |
| Kinnison | In almost every project I've ever worked on | 12:18 |
| Kinnison | But I've been known to assume too much of my users, so I'll defer to someone more in touch with normal people | 12:19 |
| richard_maw | hm, I just got a rebuild for the system artifact | 12:19 |
| richard_maw | franred: -1, it needs to add the "name" field to the strata list in system morphologies | 12:20 |
| paulsherwood | i confirm that after running the script, build found my existing artifacts, and deploy found the same system | 12:20 |
| richard_maw | it doesn't yet work for systems that use artifact splitting | 12:20 |
| paulsherwood | ok | 12:21 |
| paulsherwood | i confess i haven't had much luck with stratum splitting myself | 12:21 |
| franred | richard_maw, I've just built devel-system-x86_64-generic.morph and I don't have a rebuild | 12:22 |
| richard_maw | franred: I built a minimal-system-x86_64-generic and I did | 12:22 |
| richard_maw | because you need to set the name field, or the artifact splitting rules go wrong | 12:23 |
| franred | umm I lied you | 12:23 |
| franred | richard_maw, why I have to add name field to the strata list? | 12:26 |
| paulsherwood | probably best to put this on the ml? | 12:27 |
| * paulsherwood apologises for starting it here | 12:27 | |
| franred | ok, please send all the reviews to the mailing list, so we can discuss them there | 12:30 |
| Kinnison | I have done | 12:31 |
| paulsherwood | me too | 12:31 |
| franred | thanks :) | 12:36 |
| * Kinnison is apparently a grumpygit today. I blame the brain-trying-to-escape-through-nose issue | 12:37 | |
| paulsherwood | ewww :) | 12:38 |
| Kinnison | aye :-( | 12:38 |
| paulsherwood | franred: the minimal* systems are examples with stratum-splitting | 12:39 |
| paulsherwood | one thing - i believe radiofree is very close to pushing his latest jetson things... could we get that in before the m.i.d, to avoid re-work? | 12:41 |
| franred | paulsherwood, oh, I see, but Im still don't know why we have to add the name field of the strata if the morph field gives you the enough information about the name of the stratum | 12:41 |
| rjek_ is now known as rjek | 12:42 | |
| franred | richard_maw, ^^ | 12:42 |
| richard_maw | franred: the morph field tells you where in the repository you put it, it doesn't tell you what its name is | 12:43 |
| Kinnison | richard_maw: should we not, ideally, read that out of the stratum morphology? | 12:43 |
| Kinnison | richard_maw: or is this a double-check thing? | 12:43 |
| richard_maw | it's currently a double-check thing | 12:44 |
| franred | richard_maw, but before my changes that name field didn't exists either | 12:44 |
| richard_maw | though I'm currently pondering if we could get rid of names in morphologies | 12:44 |
| Kinnison | +1 for MOAR DOUBLE CHECKS | 12:44 |
| franred | at least not in minimal | 12:44 |
| richard_maw | franred: yes, but that's because the morph field was being used instead | 12:45 |
| richard_maw | but now the morph field is referring to the file path | 12:45 |
| persia | I'd actually like *less* double-checks, because it's annoying to have to add data in two places to make something work. | 12:46 |
| paulsherwood | omg :) | 12:46 |
| * franred think that we should think about the definition of the "morph" field - it is confusing.... | 12:47 | |
| franred | s/franred think/franred thinks/ | 12:47 |
| richard_maw | it's confusing for legacy issues that we can get rid of once all the morphs are in definitions | 12:47 |
| persia | franred: So there are legacy issues that need to be supported, but what do you propose it should mean? | 12:47 |
| franred | persia, I though what richard_maw's said before - morph is the path to the morphology - but in chunks they refers to the local definitions of the stratum chunks and not to the morphology chunks for the stratum | 12:50 |
| franred | if that makes sense | 12:50 |
| richard_maw | franred: I'm afraid it doesn't to me. | 12:51 |
| *** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has quit [Ping timeout: 240 seconds] | 12:51 | |
| richard_maw | The morph field in both systems and strata refer to another morphology file | 12:51 |
| persia | Ah good, I feared it was just my limited understanding of morph. | 12:51 |
| richard_maw | the strata already have a name field, since it's used for dependencies | 12:52 |
| richard_maw | though it's also used for strata to say which chunk artifacts they include (it's how stratum splitting works) | 12:52 |
| richard_maw | for systems we didn't need the name field, since we used to be able to use the morph field for both the file path and the name | 12:52 |
| persia | Which "it" is also used by strata to say which chunk artifacts they include? | 12:53 |
| richard_maw | persia: the name field | 12:53 |
| persia | Ah, so one could say something like mystratum-bins and get just the *-bins chunks? | 12:54 |
| richard_maw | your stratum can say that mystratum-bins only gets chunks called .*-bins | 12:55 |
| * persia is confused, but doesn't need to know now, as it's not that relevant to franred's issue | 12:56 | |
| radiofree | paulsherwood: will have to wait until after 3, updating morph and tbdiff in the test image require a lot of things to be rebuilt | 12:56 |
| richard_maw | the upshot of not including the name field, is that when it's calculating dependencies for the system it thinks that there's a strata/build-essential.morph-minimal artifact, but the dependency code is looking for a build-essential-minimal artifact | 12:57 |
| radiofree | which i can't do at the moment because i need to video interview someone | 12:57 |
| persia | Ah, right. | 12:58 |
| franred | persia, richard_maw, I was confused before, sorry to confused you. | 13:00 |
| persia | franred: Are you unconfused now? | 13:00 |
| franred | persia, no, now it is clear. | 13:01 |
| franred | richard_maw, do clusters also need the name of the systems morphologies? | 13:02 |
| richard_maw | no | 13:02 |
| franred | richard_maw, ok, thanks for the explanation | 13:04 |
| *** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock | 13:08 | |
| paulsherwood | radiofree: you are a very busy person :) | 14:05 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 240 seconds] | 14:16 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 14:32 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Client Quit] | 14:32 | |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock | 14:33 | |
| *** flatmush1 [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock | 14:45 | |
| *** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has quit [Ping timeout: 245 seconds] | 14:45 | |
| pedroalvarez | SotK: does your last merge modify the cache-keys? | 15:06 |
| SotK | it unmodifies them from my previous commit, but I don't know that that should have changed the cache key... perhaps morphloader sets something to a default value that morph2 didn't :/ | 15:08 |
| *** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Remote host closed the connection] | 15:08 | |
| persia | We should know if it changed, and set the compatibility flag appropriately. | 15:18 |
| * persia isn't sure how to test whether it changed or not | 15:18 | |
| pedroalvarez | SotK: with the latest morph and latest definitons I get this: http://pastebin.com/vPiiZ0F1 | 15:18 |
| richard_maw | persia: nothing's changed how artifacts are constructed, so the compatibility flag shouldn't need changing | 15:19 |
| persia | richard_maw: Hrm? I may have used the wrong term. I mean the key we use to determine which variant of cache key creation we're using. | 15:20 |
| richard_maw | I got what you meant, we only need to change that field if we make changes that won't be reflected in the rest of the fields. SotK's change makes tweaks before it gets to the cache key comptuation, and it doesn't change the logical contents | 15:21 |
| pedroalvarez | seems like we failed to update some ref when we did the chunk morphology fixes | 15:21 |
| pedroalvarez | I'm going to try to fix that and send a patch | 15:22 |
| persia | My concern here is that we have a change that could potentially cause rebuilding the world, but 1) we don't seem to know if we need to rebuild the world, 2) we don't have any indicator to users if we do have to rebuild the world, and 3) we don't have any marker we can use to dual-populate the cache so that everyone isn't inconvenienced. | 15:23 |
| paulsherwood | persia: that's a fair concern, but our process so far has been that way. i believe the aim is to improve it soon, but not today | 15:29 |
| persia | Should be soon: unless people have some magic sauce, it means every single user is spending at least several hours rebuilding everything every time we do this. | 15:30 |
| pedroalvarez | hmpf.. I'm building from scratch after updating morph | 15:30 |
| *** jonathanmaw [~jonathanm@188.29.25.148.threembb.co.uk] has quit [Quit: Leaving] | 15:31 | |
| paulsherwood | persia: i used to think that, but it really depends on what users are doing | 15:37 |
| pedroalvarez | we assumed in the past that the users only were using morph from baserock releases | 15:38 |
| pedroalvarez | and also creating systems based on the definitions of a release | 15:38 |
| paulsherwood | yes, and if they've made a fork of definitions to do their work, they are not hit by anything we do to master | 15:39 |
| paulsherwood | until/unless they choose to track it | 15:39 |
| persia | I have a fork of definitions, but I rebase it every time I want to get new shiny stuff, so always notice changes to master | 15:39 |
| persia | I suppose I could wait for releases, but 1) there's no way I understand to consume them, and 2) the release schedule is opaque | 15:40 |
| paulsherwood | :-) | 15:41 |
| persia | But even aside from me, I'd think that active baserock developers would feel the most pain from this, essentially losing a day or two a week to rebuild-the-world moments (based on the last couple weeks) | 15:43 |
| pedroalvarez | this changes are needed to build master of definitions with master of morph | 15:45 |
| pedroalvarez | http://pastebin.com/gSp33Umk | 15:45 |
| pedroalvarez | I've tested devel system, trove, and a distbuild | 15:45 |
| pedroalvarez | I've also tried the qt5 devel system and it fails to biuld. The freefont chunk needs fixing | 15:45 |
| persia | pedroalvarez: Did you change attr, lua, and lrexlib-pcre, or did something get lost in a merge recently? | 15:46 |
| pedroalvarez | persia: they got lost | 15:46 |
| persia | Then +1 | 15:46 |
| SotK | +1 from me too | 15:47 |
| paulsherwood | and me :) | 15:49 |
| persia | Might be nice to mention the SHA of the merge that lost them in the commit message (if it's not too late), just to help future history delvers | 15:51 |
| * persia hopes the Mason stuff that has been landing recently will allow us to use Mason as a gate for automated fast-forward-only merges, preventing this sort of thing in the future. | 15:52 | |
| radiofree | ok, tested building x86 image with the branch - works (tested in vm), tested deploying to the same image (local upgrade with rawdisk.write) - works (host name updated, tested in vm) | 15:52 |
| persia | (it's especially tricky with developers using-latest-morph, because they might update morph and definitions, not has part of an full system update) | 15:52 |
| radiofree | the test to deploy to the same image had the new tbdiff updates in + new morph | 15:52 |
| persia | radiofree: Is that with a rebased definitions? | 15:53 |
| radiofree | then tested doing a ssh update (so it calls the updated system version manager), works (new menu, VERSION_LABEL is there etc.. tested in vm) | 15:53 |
| radiofree | persia: new version of baserock + my tbdiff branch + richard_maw merge branch | 15:53 |
| radiofree | s/merge branch/merge branch of morph | 15:54 |
| radiofree | all for x86, so it doesn't look like it has broken anything | 15:54 |
| paulsherwood | radiofree: so you had +2 anyway, iirc? | 15:54 |
| radiofree | yep, but needed to be tested for x86 | 15:54 |
| persia | If you tested against latest definitions, I'd really like to see that merged. | 15:54 |
| paulsherwood | so given that's passed, i don't see anyone standing in your way... | 15:54 |
| persia | (mind you, merging that will probably cost me 384USD, but that's my own lack of self-control) | 15:54 |
| paulsherwood | heh | 15:55 |
| * paulsherwood knows where there are more jetsons | 15:55 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds] | 15:56 | |
| radiofree | oh btw i did a full build using the a vm with a jetson board as my build server, had a problem deploying it but that might be down to different morph versions | 15:56 |
| radiofree | need to try that later | 15:56 |
| paulsherwood | just merge, already :) | 15:57 |
| persia | Version discrepancies seem to confuse morph | 15:57 |
| paulsherwood | before someone else beats you to it | 15:57 |
| persia | Indeed: without automated merges, missing a window means manually rebasing/remerging | 15:58 |
| bjdooks | I've got the front-panel PCB sorted for the jetson carriers | 16:04 |
| bjdooks | wull sort out the control one next week | 16:04 |
| Kinnison | nice | 16:07 |
| paulsherwood | bjdooks: cool! | 16:07 |
| bjdooks | time to go and do something else for a bit | 16:08 |
| pedroalvarez | SotK, persia and paulsherwood: thanks for the reviews, merged | 16:09 |
| persia | pedroalvarez: Thanks for catching that. | 16:10 |
| radiofree | richard_maw: i might need a bit of help merging your branch to master | 16:12 |
| radiofree | your changes are in the merge commit, when i rebase it gets rid of them (even with --preserve-merges) | 16:13 |
| radiofree | hmm hold on | 16:14 |
| radiofree | nope, dunno how! | 16:17 |
| richard_maw | why not just merge the merge? | 16:18 |
| paulsherwood | wow, radiofree stumped by a git operation :) | 16:18 |
| radiofree | well i can, i just wanted to keep the tree pretty | 16:18 |
| Kinnison | Your understanding of pretty and mine clearly differ | 16:20 |
| * Kinnison values the merge commits | 16:20 | |
| radiofree | yes so do i, there would have been one | 16:21 |
| radiofree | i have, however, found a problem | 16:22 |
| radiofree | if the name of the device tree has changed between the version you are upgrading, and the version you want to upgrade to, it won't work | 16:22 |
| Kinnison | boo :-( | 16:22 |
| paulsherwood | what would change the name of the device tree? | 16:23 |
| radiofree | different kernel version | 16:23 |
| paulsherwood | bah | 16:23 |
| radiofree | however, we can just copy it to the same device tree name in the morph | 16:23 |
| paulsherwood | well - given we currently have nil dt support, isn't an imperfect start better than nothing? | 16:24 |
| paulsherwood | (i'm assuming you don't *break* anything that was already working) | 16:24 |
| radiofree | no, it doesn't matter what you call the device tree | 16:25 |
| radiofree | filename wise | 16:25 |
| radiofree | right, 15 minutes to check this | 16:25 |
| persia | So the key thing would be to develop a best-practice to have DT nomenclature be statically board-specific | 16:26 |
| radiofree | oh actually, maybe it's not actually on there | 16:27 |
| richard_maw | radiofree: name of device tree as in file path, or is there some internal thing we would need to worry about? | 16:28 |
| radiofree | richard_maw: file path | 16:28 |
| radiofree | but i just tried deploying to an image and i have the same problem, i don't think i copied it correctly | 16:28 |
| radiofree | cp arch/arm/boot/dts/tegra124-jetson-tk1.dtb "$DESTDIR"/boot/ is correct? | 16:29 |
| *** franred_ [~franred@92.41.109.23.threembb.co.uk] has joined #baserock | 16:29 | |
| *** ssam2_ [~ssam2@92.41.109.23.threembb.co.uk] has joined #baserock | 16:29 | |
| richard_maw | the write extension gets the file path of the device tree from the user at deployment time, and that gets copied to /systems/$version/dtb | 16:29 |
| radiofree | yeah i mean that's what i do in my linux morph, this has worked before so i'm guessing i did something wrong | 16:30 |
| richard_maw | oh, so it's a problem with the linux chunk rather than the deployment config? | 16:31 |
| radiofree | i think so, i don't think the dtb is actually there in the image... trying a tar now | 16:31 |
| richard_maw | ~that's a head scratcher, since your build should fail if that dtb doesn't exist, since your cp command would fail | 16:32 |
| *** franred [~franred@188.29.105.39.threembb.co.uk] has quit [Ping timeout: 246 seconds] | 16:32 | |
| *** ssam2 [~ssam2@188.29.105.39.threembb.co.uk] has quit [Ping timeout: 244 seconds] | 16:33 | |
| radiofree | hmm it is in the /boot/ directory | 16:33 |
| radiofree | hmm "try_path" is just /boot/te.... looks like the os.path.join failed | 16:45 |
| richard_maw | radiofree: if a rightmost component to os.path.join starts with /, then it replaces everything to the left of it | 16:46 |
| richard_maw | I know it's bananas, but that's what it does | 16:46 |
| richard_maw | so either only pass it a relative path in the morphology, or do `device_tree_path = self.get_dtb_path().lstrip('/')` | 16:47 |
| radiofree | lol | 16:49 |
| radiofree | ok will try that | 16:49 |
| pedroalvarez | I need a review and suggestions on this patch: http://pastebin.com/1KQRkdsU | 16:57 |
| radiofree | ok that worked, is it ok to add that "add lstrip(/)" commit to the top of your branch richard_maw, then merge it | 16:57 |
| pedroalvarez | repo: upstream:freefont-otf | 16:57 |
| radiofree | (i can rebase the tbdiff branch and merge that) | 16:57 |
| pedroalvarez | I can't confirm that it builds | 16:57 |
| richard_maw | radiofree: fine by me | 16:57 |
| persia | pedroalvarez: Is there any reason not to migrate that to definitions whilst updating it? | 16:58 |
| richard_maw | pedroalvarez: I can confirm that the morphology is at least logically equivalent, with the exception that variables are properly quoted now, so +1 | 16:58 |
| pedroalvarez | richard_maw: I knew you will like that ;) | 16:59 |
| pedroalvarez | persia: nope, but I guess that it can happen with all of them at the same time with the script that Fran is doing | 17:00 |
| persia | I suppose. I just have mixed feelings about more disposable commits to the upstream repos, especially when we don't expect to maintain them very long. | 17:01 |
| radiofree | oh i get "unicode object has no attribute 'lsplit' when doing it in system-version-manager :\ | 17:01 |
| persia | It makes the experience of looking at refs in a clone less nice. | 17:01 |
| radiofree | i think i'll just use relative paths | 17:01 |
| pedroalvarez | I can confirm now that this patch builds http://pastebin.com/1KQRkdsU | 17:03 |
| persia | My only objection is the noise in the tree: it's not a huge one, so merge if not merging blocks other work, but I don't really like it. | 17:04 |
| pedroalvarez | I'm just worried about that I can't build genivi systems right now. And the cache key has changed, and I have to rebuild everything from scratch | 17:06 |
| persia | Entirely understood. The process seems to have had a failure recently. One hopes Mason will help prevent this in the future. | 17:07 |
| pedroalvarez | We believe in mason :) | 17:07 |
| radiofree | yay it worked | 17:08 |
| persia | As I said, I've reviewed it, and it looks perfectly sane, and aside from my complaint about location, I'm fine with merging. I'd be excited if the chunk morphology moved, but that's arguably separable. | 17:08 |
| persia | radiofree: \o/ | 17:08 |
| *** bjdooks [~ben@trinity.fluff.org] has quit [Ping timeout: 272 seconds] | 17:08 | |
| *** ssam2_ [~ssam2@92.41.109.23.threembb.co.uk] has quit [Remote host closed the connection] | 17:09 | |
| radiofree | ok, will merge, put in documentation "usr relative paths for device tree file" | 17:09 |
| * persia hears about https://github.com/berrange/gerrymander and likes gerrit more, except for the annoyances of commit mangling | 17:09 | |
| radiofree | MERGED! | 17:17 |
| pedroalvarez | KABOOM! | 17:18 |
| richard_maw | I don't suppose there's any extensions to Gerrit that prevent it doing commit mangling? | 17:19 |
| pedroalvarez | persia: I'm not going to merge the patch of freefont-otf. I will better watit until Fran changes the world | 17:19 |
| radiofree | only think that needs merging now is http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-devel-update | 17:19 |
| radiofree | incidentally i just upgraded my jetson board from a 3.10 stock kernel to the 3.16 kernel in those definitions, using baserock, and without having to touch the "recovery mode" buttons | 17:20 |
| radiofree | http://31.media.tumblr.com/3f58e1c9ba1860227498951d448917be/tumblr_moqd6lZalm1qbnleeo1_400.gif | 17:20 |
| paulsherwood | radiofree: w00t! :) | 17:30 |
| *** franred_ [~franred@92.41.109.23.threembb.co.uk] has quit [Ping timeout: 245 seconds] | 17:32 | |
| paulsherwood | radiofree: you have +2 - please merge before others here accuse me of overstepping my competence grade :) | 17:55 |
| paulsherwood | radiofree: can you fix your branch-name, otherwise it'll be set in stone | 17:59 |
| paulsherwood | should be baserock/arm/tegra-3.16 i expect? | 18:00 |
| radiofree | ok, i'll change it to baserock/arm/linux-tegra-3.16 | 18:01 |
| paulsherwood | cool | 18:02 |
| radiofree | paulsherwood: the distbuild instructions only need a couple of changes for this brave new baserock world, i need to change the kernel image in the initial tarball they have to download, but i'll upload that from home since it's a bit of pain | 18:26 |
| radiofree | paulsherwood: are there any "how to upgrade baserock systems" instructions anyway, the only one i can find is for a trove | 18:26 |
| richard_maw | paulsherwood: I've sent some patches as a reply to your workflow tweaks RFC. | 18:40 |
| richard_maw | persia has a good point about it being useful to have an update-ref command, and if you did update-ref and push, you wouldn't need the temporary build branch in that case | 18:41 |
| richard_maw | I'm currently thinking we need both though, as the update-ref would be very useful for publishing the branch, but can't be made to work for detached head, and I still think that use-case is useful | 18:42 |
| richard_maw | hm, I've been looking through the history of morph, and a lot of the important features landed in February 2013. | 19:20 |
| richard_maw | we replaced our shell-script generated staging-filler with a native Baserock bootstrap, started using linux-user-chroot to ensure builds were restricted in their capabilities, and started recording which version of morph was used to build every artifact | 19:21 |
| * straycat wonders if a trivial patch to distbuild would be appreciated | 19:21 | |
| richard_maw | normally yes, though at this time of day I don't think there's anyone with a distbuild cluster at hand to test it on | 19:23 |
| straycat | That's a good point, I don't have any hardware to test it. | 19:24 |
| straycat | It's basically removing some dead code I left behind and kept forgetting to send a patch for, so by definition it shouldn't have an effect. | 19:26 |
| richard_maw | if you can send an e-mail about it to the list, I'll try to take a look at it tomorrow | 19:26 |
| * straycat nods | 19:28 | |
| straycat | will do :) | 19:28 |
| pedroalvarez | straycat: I probably won't understand the patch, but I can test it | 19:35 |
| straycat | pedroalvarez, oh hai :) you will easily, it just removes a function. :) | 19:37 |
| richard_maw | were we in a less dynamic language I'd be 100% happy to use git grep to decide whether it had no side-effects | 19:38 |
| pedroalvarez | richard_maw: true, I found one of those dynamic calls in the morph codebase, and took me a while to find from where was it being called | 19:39 |
| richard_maw | some days I want to ban getattr | 19:39 |
| straycat | Hrm, it would be good to get those serialise tests working again too. | 22:16 |
| radiofree | instructions updated http://wiki.baserock.org/guides/jetson_distbuild_cluster/ | 23:22 |
| radiofree | i suppose the next step is adding the genivi baseline for jetson | 23:23 |
| radiofree | and then writing some generic "how to update a baserock system" instructions | 23:24 |
| *** bjdooks [~ben@trinity.fluff.org] has joined #baserock | 23:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
