IRC logs for #baserock for Thursday, 2014-08-14

*** robtaylo1 [~robtaylor@floopily.codethink.co.uk] has joined #baserock03:51
*** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock03:51
*** rjek_ [~rjek@gateway/shell/pepperfish/x-ipgqvfnrjfrdfdsy] has joined #baserock03: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 #baserock03:52
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]03:52
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock03:52
*** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 250 seconds]04:07
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock04:07
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]04:07
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock04:07
*** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock06:50
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock07:24
*** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 260 seconds]08:12
richard_mawmorning all08:23
KinnisonIt is.08:24
*** fay_ [~fay@92.40.108.42.threembb.co.uk] has joined #baserock08:27
*** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock08:34
*** jonathanmaw [~jonathanm@188.31.135.43.threembb.co.uk] has joined #baserock08:54
paulsherwoodwhat's the chance of getting franred's morph-in-definitions reviewed and applied this week?08:54
* paulsherwood ducks08:54
*** ssam2 [~ssam2@188.29.105.39.threembb.co.uk] has joined #baserock08:55
KinnisonI think it's possible, but given we'll want to be very very careful about this, it might be early next week08:55
*** jonathanmaw [~jonathanm@188.31.135.43.threembb.co.uk] has quit [Ping timeout: 260 seconds]08:58
paulsherwoodok - 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 #baserock09:00
richard_mawone interesting test would be to build a system, run franred's script for converting, and see if you still need to rebuild09:01
straycatWhat is morph-in-definitions?09:01
Kinnisonrichard_maw: given we include morphology text for strata etc in the artifacts, wouldn't we be guaranteed rebuilds?09:01
richard_mawKinnison: 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 key09:02
persiastraycat: moving all the chunk morphologies to the definitions repository.09:03
franredstraycat, all the morphologies will be placed in the definitions repository09:04
straycatOh you mean chunks in definitions?09:04
Kinnisonrichard_maw: aah09:04
persiaYes09:04
* straycat nods09:05
paulsherwoodfranred: how did you test your chunks in definitions script so far?09:06
franredpaulsherwood, 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 built09:09
franredand cached09:09
KinnisonThat's a good basic test.  Ideally we'd build everything from release.morph09:10
Kinnisonfranred: did you also confirm that deployment worked?09:10
persiaWouldn't we ideally build all defined systems and deploy all defined deployments?09:11
* persia isn't advocating this, just thinking about idealism09:11
franredKinnison, no, I didn't test deployment - just morph build09:11
Kinnisontsk09:11
KinnisonYour script moved clusters09:11
Kinnisonand systems09:11
Kinnisonpls. to test that and append results onto thread09:12
franredKinnison, yes, all the morphologies will be classified09:12
franredKinnison, ok, I will do09:12
*** jonathanmaw [~jonathanm@92.40.192.133.threembb.co.uk] has joined #baserock09: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 #baserock10: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 #baserock10:05
richard_mawSotK: finished looking at your changes, I'd prefer a couple of tweaks to the morphloader, but it's ok in its current form10:29
SotKrichard_maw: thanks :) I'll make that s/iterkeys/iteritems/ change and other style change and merge then10:35
SotKis there a reason morph3 subclasses UserDict.IterableUserDict rather than just dict btw?10:36
SotKUserDict is an old style class, so type(morph) just returned 'instance' rather than 'Morphology'10:36
richard_mawgood point, I guess it's because Lars wrote it and he's used to writing code to work on old versions of python10: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 #baserock11:20
pedroalvarezWould be useful for distbuild to report what is building  sometimes, but I can't imagine yet how could it be11:37
pedroalvarezMaybe every minute it can show a report saying:11:40
pedroalvarezStill building 'foo' in wokrer3: (13m 43s)11:40
pedroalvarezStill building 'bar' in wokrer1: (1m 12s)11:40
ssam2you can 'tail -f' the build-step-*.log files11:44
ssam2not ideal, but useful11:44
pedroalvarezthat's useful, but I was suggesting that as a way to show the user that the system is still working11:46
pedroalvarezsometimes when you are in a bottleneck like llvm, distbuild looks like it's doing nothing11:46
*** fay_ [~fay@92.40.33.96.threembb.co.uk] has quit [Ping timeout: 272 seconds]11:51
paulsherwoodmaybe the controller could publish a live webpage11:58
paulsherwoodfranred: i ran your script - it fell over with http://fpaste.org/125537/17564140/11:59
richard_mawpaulsherwood: `export PYTHONPATH=/src/morph`12:00
richard_mawI had to do that to get it to work in baserock 14.2612:00
paulsherwoodrichard_maw: thanks. it seems to be a bit happier now12:02
franredummm, Im using the latest version of morph http://wiki.baserock.org/using-latest-morph/ ... shouldn't I suppose to do it?12:03
paulsherwoodfranred: are you speaking spanglish todfay? :-)12:03
paulsherwoodsorry - what did you mean?12:03
richard_mawfranred: the issue is that your script loads morphlib from /usr/lib/python2.7, since it doesn't have a morphlib right next to it12:04
paulsherwoodi could be wrong, but i think situations where there is no morph file should not be flagged as 'WARNING'12:05
paulsherwoodeg  Downloading libtiff.morph from ssh://git@git.baserock.org/delta/libtiff into strata/gtk-deps/libtiff.morph12:06
paulsherwoodWARNING: libtiff.morph not found in ssh://git@git.baserock.org/delta/libtiff.Expected autodetection at build time12:06
paulsherwood?12:06
KinnisonI think it's fine for it to be a warning12:06
KinnisonNot least, I still want rid of autodetect12:07
paulsherwoodughh :)12:07
paulsherwoodi propose it's just INFO12:07
pedroalvarezautodetect is awesome (when the build doesn't fail)12:07
paulsherwood+112:08
paulsherwoodcan we safely move *.configure and *.write into a subdir too?12:09
franredpaulsherwood, 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 why12:09
richard_mawnot yet12:09
paulsherwoodi'm confused, franred - approx 50% of the chunks have no morph file. that's a 'normal' case12:10
richard_mawhm, the HEAD of the branch we use for lua is not the same as the commit listed, the top one was converted to yaml12:10
paulsherwoodi 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
Kinnisonrichard_maw: yay, more missed updates :-(12:11
franredpaulsherwood, they are auto fixed12:11
richard_mawpaulsherwood: franred has been through the common ones and auto fixed12:11
Kinnisonrichard_maw: was it me this time?12:12
paulsherwoodperfect12:12
richard_mawKinnison: I don't know if you were supposed to be responsible for the update, but SotK is listed as having made the commit12:12
Kinnison:-(12:12
franredpaulsherwood, 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 any12:13
SotKI 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 them12:14
paulsherwoodfranred: all i'm saying is i'd like th WARNING to be INFO, so less expert users don't panic12:14
*** fay_ [~fay@92.40.33.96.threembb.co.uk] has joined #baserock12:14
* pedroalvarez panics with WARNINGs12:14
* Kinnison carefully reads warnings, realises what they say and then decides whether to treat them as INFO or ERROR12:14
* Kinnison tends to ignore INFO12:14
paulsherwoodand maybe also change the ERROR so it's clear that the script is fixed12:14
richard_mawalso, unset the default fields12:15
paulsherwoodin this case the INFO would be entirely ignorable. that's the right thing for the user to do12:15
franredpaulsherwood, the following message after the ERROR should tell you that it is fixed12:15
KinnisonERROR really should only happen in cases where the stuff stops having failed12:16
KinnisonIMO12:16
franredrichard_maw, yes, I've missed unset default fields12:16
KinnisonWARNING is for things which might be an issue but the script works around12:16
franredKinnison, 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 too12:17
paulsherwoodas 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 case12:17
paulsherwoodbut i can be wrong as always12:18
KinnisonWARNING means "something was bad, but I worked around it"12:18
KinnisonIn almost every project I've ever worked on12:18
KinnisonBut I've been known to assume too much of my users, so I'll defer to someone more in touch with normal people12:19
richard_mawhm, I just got a rebuild for the system artifact12:19
richard_mawfranred: -1, it needs to add the "name" field to the strata list in system morphologies12:20
paulsherwoodi confirm that after running the script, build found my existing artifacts, and deploy found the same system12:20
richard_mawit doesn't yet work for systems that use artifact splitting12:20
paulsherwoodok12:21
paulsherwoodi confess i haven't had much luck with stratum splitting myself12:21
franredrichard_maw, I've just built devel-system-x86_64-generic.morph and I don't have a rebuild12:22
richard_mawfranred: I built a minimal-system-x86_64-generic and I did12:22
richard_mawbecause you need to set the name field, or the artifact splitting rules go wrong12:23
franredumm I lied you12:23
franredrichard_maw, why I have to add name field to the strata list?12:26
paulsherwoodprobably best to put this on the ml?12:27
* paulsherwood apologises for starting it here12:27
franredok, please send all the reviews to the mailing list, so we can discuss them there12:30
KinnisonI have done12:31
paulsherwoodme too12:31
franredthanks :)12:36
* Kinnison is apparently a grumpygit today. I blame the brain-trying-to-escape-through-nose issue12:37
paulsherwoodewww :)12:38
Kinnisonaye :-(12:38
paulsherwoodfranred: the minimal* systems are examples with stratum-splitting12:39
paulsherwoodone 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
franredpaulsherwood, 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 stratum12:41
rjek_ is now known as rjek12:42
franredrichard_maw, ^^12:42
richard_mawfranred: the morph field tells you where in the repository you put it, it doesn't tell you what its name is12:43
Kinnisonrichard_maw: should we not, ideally, read that out of the stratum morphology?12:43
Kinnisonrichard_maw: or is this a double-check thing?12:43
richard_mawit's currently a double-check thing12:44
franredrichard_maw, but before my changes that name field didn't exists either12:44
richard_mawthough I'm currently pondering if we could get rid of names in morphologies12:44
Kinnison+1 for MOAR DOUBLE CHECKS12:44
franredat least not in minimal12:44
richard_mawfranred: yes, but that's because the morph field was being used instead12:45
richard_mawbut now the morph field is referring to the file path12:45
persiaI'd actually like *less* double-checks, because it's annoying to have to add data in two places to make something work.12:46
paulsherwoodomg :)12:46
* franred think that we should think about the definition of the "morph" field - it is confusing....12:47
franreds/franred think/franred thinks/12:47
richard_mawit's confusing for legacy issues that we can get rid of once all the morphs are in definitions12:47
persiafranred: So there are legacy issues that need to be supported, but what do you propose it should mean?12:47
franredpersia, 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 stratum12:50
franredif that makes sense12:50
richard_mawfranred: 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_mawThe morph field in both systems and strata refer to another morphology file12:51
persiaAh good, I feared it was just my limited understanding of morph.12:51
richard_mawthe strata already have a name field, since it's used for dependencies12:52
richard_mawthough it's also used for strata to say which chunk artifacts they include (it's how stratum splitting works)12:52
richard_mawfor 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 name12:52
persiaWhich "it" is also used by strata to say which chunk artifacts they include?12:53
richard_mawpersia: the name field12:53
persiaAh, so one could say something like mystratum-bins and get just the *-bins chunks?12:54
richard_mawyour stratum can say that mystratum-bins only gets chunks called .*-bins12:55
* persia is confused, but doesn't need to know now, as it's not that relevant to franred's issue12:56
radiofreepaulsherwood: will have to wait until after 3, updating morph and tbdiff in the test image require a lot of things to be rebuilt12:56
richard_mawthe 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 artifact12:57
radiofreewhich i can't do at the moment because i need to video interview someone12:57
persiaAh, right.12:58
franredpersia, richard_maw, I was confused before, sorry to confused you.13:00
persiafranred: Are you unconfused now?13:00
franredpersia, no, now it is clear.13:01
franredrichard_maw, do clusters also need the name of the systems morphologies?13:02
richard_mawno13:02
franredrichard_maw, ok, thanks for the explanation13:04
*** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock13:08
paulsherwoodradiofree: 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 #baserock14: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 #baserock14:33
*** flatmush1 [~flatmush@92.41.124.24.threembb.co.uk] has joined #baserock14:45
*** flatmush [~flatmush@92.41.124.24.threembb.co.uk] has quit [Ping timeout: 245 seconds]14:45
pedroalvarezSotK: does your last merge modify the cache-keys?15:06
SotKit 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
persiaWe should know if it changed, and set the compatibility flag appropriately.15:18
* persia isn't sure how to test whether it changed or not15:18
pedroalvarezSotK: with the latest morph and latest definitons I get this: http://pastebin.com/vPiiZ0F115:18
richard_mawpersia: nothing's changed how artifacts are constructed, so the compatibility flag shouldn't need changing15:19
persiarichard_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_mawI 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 contents15:21
pedroalvarezseems like we failed to update some ref when we did the chunk morphology fixes15:21
pedroalvarezI'm going to try to fix that and send a patch15:22
persiaMy 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
paulsherwoodpersia: 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 today15:29
persiaShould 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
pedroalvarezhmpf.. I'm building from scratch after updating morph15:30
*** jonathanmaw [~jonathanm@188.29.25.148.threembb.co.uk] has quit [Quit: Leaving]15:31
paulsherwoodpersia: i used to think that, but it really depends on what users are doing15:37
pedroalvarezwe assumed in the past that the users only were using morph from baserock releases15:38
pedroalvarezand also creating systems based on the definitions of a release15:38
paulsherwoodyes, and if they've made a fork of definitions to do their work, they are not hit by anything we do to master15:39
paulsherwooduntil/unless they choose to track it15:39
persiaI have a fork of definitions, but I rebase it every time I want to get new shiny stuff, so always notice changes to master15:39
persiaI suppose I could wait for releases, but 1) there's no way I understand to consume them, and 2) the release schedule is opaque15:40
paulsherwood:-)15:41
persiaBut 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
pedroalvarezthis changes are needed to build master of definitions with master of morph15:45
pedroalvarezhttp://pastebin.com/gSp33Umk15:45
pedroalvarezI've tested devel system, trove, and a distbuild15:45
pedroalvarezI've also tried the qt5 devel system and it fails to biuld. The freefont chunk needs fixing15:45
persiapedroalvarez: Did you change attr, lua, and lrexlib-pcre, or did something get lost in a merge recently?15:46
pedroalvarezpersia: they got lost15:46
persiaThen +115:46
SotK+1 from me too15:47
paulsherwoodand me :)15:49
persiaMight 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 delvers15: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
radiofreeok, 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
radiofreethe test to deploy to the same image had the new tbdiff updates in + new morph15:52
persiaradiofree: Is that with a rebased definitions?15:53
radiofreethen 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
radiofreepersia: new version of baserock + my tbdiff branch + richard_maw merge branch15:53
radiofrees/merge branch/merge branch of morph15:54
radiofreeall for x86, so it doesn't look like it has broken anything15:54
paulsherwoodradiofree: so you had +2 anyway, iirc?15:54
radiofreeyep, but needed to be tested for x8615:54
persiaIf you tested against latest definitions, I'd really like to see that merged.15:54
paulsherwoodso 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
paulsherwoodheh15:55
* paulsherwood knows where there are more jetsons15:55
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds]15:56
radiofreeoh 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 versions15:56
radiofreeneed to try that later15:56
paulsherwoodjust merge, already :)15:57
persiaVersion discrepancies seem to confuse morph15:57
paulsherwoodbefore someone else beats you to it15:57
persiaIndeed: without automated merges, missing a window means manually rebasing/remerging15:58
bjdooksI've got the front-panel PCB sorted for the jetson carriers16:04
bjdookswull sort out the control one next week16:04
Kinnisonnice16:07
paulsherwoodbjdooks: cool!16:07
bjdookstime to go and do something else for a bit16:08
pedroalvarezSotK, persia and paulsherwood: thanks for the reviews, merged16:09
persiapedroalvarez: Thanks for catching that.16:10
radiofreerichard_maw: i might need a bit of help merging your branch to master16:12
radiofreeyour changes are in the merge commit, when i rebase it gets rid of them (even with --preserve-merges)16:13
radiofreehmm hold on16:14
radiofreenope, dunno how!16:17
richard_mawwhy not just merge the merge?16:18
paulsherwoodwow, radiofree stumped by a git operation :)16:18
radiofreewell i can, i just wanted to keep the tree pretty16:18
KinnisonYour understanding of pretty and mine clearly differ16:20
* Kinnison values the merge commits16:20
radiofreeyes so do i, there would have been one16:21
radiofreei have, however, found a problem16:22
radiofreeif 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 work16:22
Kinnisonboo :-(16:22
paulsherwoodwhat would change the name of the device tree?16:23
radiofreedifferent kernel version16:23
paulsherwoodbah16:23
radiofreehowever, we can just copy it to the same device tree name in the morph16:23
paulsherwoodwell - 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
radiofreeno, it doesn't matter what you call the device tree16:25
radiofreefilename wise16:25
radiofreeright, 15 minutes to check this16:25
persiaSo the key thing would be to develop a best-practice to have DT nomenclature be statically board-specific16:26
radiofreeoh actually, maybe it's not actually on there16:27
richard_mawradiofree: name of device tree as in file path, or is there some internal thing we would need to worry about?16:28
radiofreerichard_maw: file path16:28
radiofreebut i just tried deploying to an image and i have the same problem, i don't think i copied it correctly16: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 #baserock16:29
*** ssam2_ [~ssam2@92.41.109.23.threembb.co.uk] has joined #baserock16:29
richard_mawthe write extension gets the file path of the device tree from the user at deployment time, and that gets copied to /systems/$version/dtb16:29
radiofreeyeah i mean that's what i do in my linux morph, this has worked before so i'm guessing i did something wrong16:30
richard_mawoh, so it's a problem with the linux chunk rather than the deployment config?16:31
radiofreei think so, i don't think the dtb is actually there in the image... trying a tar now16:31
richard_maw~that's a head scratcher, since your build should fail if that dtb doesn't exist, since your cp command would fail16: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
radiofreehmm it is in the /boot/ directory16:33
radiofreehmm "try_path" is just /boot/te.... looks like the os.path.join failed16:45
richard_mawradiofree: if a rightmost component to os.path.join starts with /, then it replaces everything to the left of it16:46
richard_mawI know it's bananas, but that's what it does16:46
richard_mawso either only pass it a relative path in the morphology, or do `device_tree_path = self.get_dtb_path().lstrip('/')`16:47
radiofreelol16:49
radiofreeok will try that16:49
pedroalvarezI need a review and suggestions on this patch: http://pastebin.com/1KQRkdsU16:57
radiofreeok that worked, is it ok to add that "add lstrip(/)" commit to the top of your branch richard_maw, then merge it16:57
pedroalvarezrepo: upstream:freefont-otf16:57
radiofree(i can rebase the tbdiff branch and merge that)16:57
pedroalvarezI can't confirm that it builds16:57
richard_mawradiofree: fine by me16:57
persiapedroalvarez: Is there any reason not to migrate that to definitions whilst updating it?16:58
richard_mawpedroalvarez: I can confirm that the morphology is at least logically equivalent, with the exception that variables are properly quoted now, so +116:58
pedroalvarezrichard_maw: I knew you will like that ;)16:59
pedroalvarezpersia: nope, but I guess that it can happen with all of them at the same time with the script that Fran is doing17:00
persiaI 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
radiofreeoh i get "unicode object has no attribute 'lsplit' when doing it in system-version-manager :\17:01
persiaIt makes the experience of looking at refs in a clone less nice.17:01
radiofreei think i'll just use relative paths17:01
pedroalvarezI can confirm now that this patch builds http://pastebin.com/1KQRkdsU17:03
persiaMy 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
pedroalvarezI'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 scratch17:06
persiaEntirely understood.  The process seems to have had a failure recently.  One hopes Mason will help prevent this in the future.17:07
pedroalvarezWe believe in mason :)17:07
radiofreeyay it worked17:08
persiaAs 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
persiaradiofree: \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
radiofreeok, 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 mangling17:09
radiofreeMERGED!17:17
pedroalvarezKABOOM!17:18
richard_mawI don't suppose there's any extensions to Gerrit that prevent it doing commit mangling?17:19
pedroalvarezpersia: I'm not going to merge the patch of freefont-otf. I will better watit until Fran changes the world17:19
radiofreeonly think that needs merging now is http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/james/jetson-devel-update17:19
radiofreeincidentally 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" buttons17:20
radiofreehttp://31.media.tumblr.com/3f58e1c9ba1860227498951d448917be/tumblr_moqd6lZalm1qbnleeo1_400.gif17:20
paulsherwoodradiofree: w00t! :)17:30
*** franred_ [~franred@92.41.109.23.threembb.co.uk] has quit [Ping timeout: 245 seconds]17:32
paulsherwoodradiofree: you have +2 - please merge before others here accuse me of overstepping my competence grade :)17:55
paulsherwoodradiofree: can you fix your branch-name, otherwise it'll be set in stone17:59
paulsherwoodshould be baserock/arm/tegra-3.16 i expect?18:00
radiofreeok, i'll change it to baserock/arm/linux-tegra-3.1618:01
paulsherwoodcool18:02
radiofreepaulsherwood: 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 pain18:26
radiofreepaulsherwood: are there any "how to upgrade baserock systems" instructions anyway, the only one i can find is for a trove18:26
richard_mawpaulsherwood: I've sent some patches as a reply to your workflow tweaks RFC.18:40
richard_mawpersia 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 case18:41
richard_mawI'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 useful18:42
richard_mawhm, I've been looking through the history of morph, and a lot of the important features landed in February 2013.19:20
richard_mawwe 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 artifact19:21
* straycat wonders if a trivial patch to distbuild would be appreciated19:21
richard_mawnormally yes, though at this time of day I don't think there's anyone with a distbuild cluster at hand to test it on19:23
straycatThat's a good point, I don't have any hardware to test it.19:24
straycatIt'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_mawif you can send an e-mail about it to the list, I'll try to take a look at it tomorrow19:26
* straycat nods19:28
straycatwill do :)19:28
pedroalvarezstraycat: I probably won't understand the patch, but I can test it19:35
straycatpedroalvarez, oh hai :) you will easily, it just removes a function. :)19:37
richard_mawwere we in a less dynamic language I'd be 100% happy to use git grep to decide whether it had no side-effects19:38
pedroalvarezrichard_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 called19:39
richard_mawsome days I want to ban getattr19:39
straycatHrm, it would be good to get those serialise tests working again too.22:16
radiofreeinstructions updated http://wiki.baserock.org/guides/jetson_distbuild_cluster/23:22
radiofreei suppose the next step is adding the genivi baseline for jetson23:23
radiofreeand then writing some generic "how to update a baserock system" instructions23:24
*** bjdooks [~ben@trinity.fluff.org] has joined #baserock23:41

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!