| *** robtaylor has quit IRC | 02:07 | |
| *** robtaylor has joined #baserock | 02:08 | |
| *** paulw has quit IRC | 02:29 | |
| petefotheringham | if `morph deploy --upgrade` works, and is documented, then why deprecate it? Why not deprecate `morph upgrade` instead? | 05:46 |
|---|---|---|
| *** zoli__ has joined #baserock | 05:49 | |
| *** petefoth has joined #baserock | 06:53 | |
| straycat | so you're saying, if the docs are out of date why not revert patches that have been submitted to baserock-dev and merged? | 07:38 |
| petefoth | straycat: No. I am saying, if we have code that works but docs that don't match, then change the docs not the code | 07:39 |
| petefoth | Why deprecat workign functionality? | 07:40 |
| straycat | 05:46 petefotheringham$ if `morph deploy --upgrade` works, and is documented, then why deprecate it? Why not | 07:40 |
| straycat | deprecate `morph upgrade` instead? | 07:40 |
| * straycat has misunderstood | 07:41 | |
| straycat | the answer to that question would seem to be "because the patch that was submitted and merged to the list deprecated deploy --upgrade" | 07:42 |
| petefoth | I think the problem is, we have two ways of accomplishing the same thing. That isn't ideal, but I don't think removing (or even deprecating) one of them is the righ way to go. If we were to remove / deprecate one, then I would suggest it should be 'morph upgrade', because it adds another, unneeded command to morphs already crowded UI | 07:43 |
| petefoth | Easiest (and best IMHO) path is to change the code which says ' This is deprecated - use morph upgrade' to gIve help with the parameters as 'morph help upgrade' does | 07:45 |
| straycat | there is no problem, the docs just need to be updated, is all | 07:48 |
| petefoth | straycat: agreed. Will you do it, or shall I? :) | 07:49 |
| straycat | i'll do it, i was apparently too tired last night | 07:50 |
| petefoth | Thanks! | 07:50 |
| straycat | sam's patch says this: | 07:51 |
| straycat | The arguments to `morph deploy` can get quite long, any way we can make it | 07:51 |
| straycat | shorter and clearer is useful. We can also avoid having the strange | 07:51 |
| straycat | --no-upgrade flag in future. | 07:51 |
| petefoth | What does rhe --no-upgrade flag mean? 'Deploy this system only if there isn't already a system deployed / running there.'? Seems like we need to re-examine the logic associated with all of this (as paulsherwood talekd about on Friday) and work out how to 'do it right' | 07:53 |
| straycat | it's meaningless, a deployment that's not an upgrade is just an ordinary deployment | 07:54 |
| petefoth | so we should remove support for the --no-upgrade flag | 07:55 |
| straycat | well it's deprecated, so we just need to make sure the docs tell people to use the upgrade command | 07:56 |
| petefoth | Or the --upgrade flag to morph deploy? | 07:56 |
| straycat | well that's what's been deprecated | 07:57 |
| straycat | http://sprunge.us/GTQU | 07:57 |
| petefoth | I know but *****WHY***** ffs? It works, we use it in our examples on the wiki and in the cluster morphology quoted at the start of this discussion | 07:58 |
| straycat | i believe because having it as a flag to deploy means that we also get a meaningless --no-upgrade, and it's shorter, those were Sam's reasons | 08:00 |
| petefoth | Well we should just do whatever it says in the sepcification. Oh wait... :) | 08:01 |
| straycat | i can fix the examples, but i need tea first | 08:01 |
| paulsherwood | i believe that 'morph upgrade' is simpler to understand than 'morph deploy --upgrade' | 08:01 |
| paulsherwood | petefoth: you seem a little grumpy this morning :) | 08:02 |
| * petefoth goes to get on with something that doesn't involve the angel/pin terpsichory interface | 08:02 | |
| petefoth | paulsherwood: grumpy? Moi? Just trying to avoid doing unnecessary stuff (like removing fiunctionality that works) | 08:02 |
| petefoth | Besides, I've got a week's holiday comign up - what's to be grumpy about :) | 08:03 |
| paulsherwood | as a user, it seems to me that 'deploy a new thing' is different from 'upgrade an existing thing' | 08:04 |
| petefoth | but quite like 'deploy this upgrade to that thing' | 08:04 |
| SotK | petefoth: +1 | 08:04 |
| petefoth | SotK: you've got a holiday coming up too? ;) | 08:05 |
| * SotK likes the idea that to go from an artifact to a running system one uses `morph deploy`, and simply tells `morph deploy` that its upgrading an existing thing when that is what you want to do. | 08:05 | |
| *** a1exhughe5 has joined #baserock | 08:06 | |
| SotK | petefoth: nope :) | 08:06 |
| paulsherwood | well, 'morph deploy' could automagically upgrade | 08:06 |
| paulsherwood | but would that be better? | 08:07 |
| petefoth | Possibly no need to tell morph deploy anything? Just say 'morph deploy' and if somethign is already there, upgrade it? (That idea is not fully though through, in case you hadn't guessed' - just an attempt to simplify the interface further) | 08:07 |
| petefoth | paulsherwood: snap! But, actualy i don' think that would be better | 08:08 |
| petefoth | Too much internal morph 'magic' | 08:08 |
| paulsherwood | so i'm ok with deprecating 'morph deploy --upgrade', or 'morph upgrade', but we should have only one way to do this function, not two | 08:10 |
| petefoth | I think it would be worth having a discussion on improving / chanign /simplifying the morph UI which foucusses on the whole UI and the whole lifecycle, rather than tweaking bits of the interface isolation. | 08:10 |
| paulsherwood | such discussions tend to happen, but often do not lead to code-changes i fear | 08:11 |
| petefoth | If you just think about changing a, agree what needs to done, and make the change, then later, you look at b, and discover that for the changes you want to make to b to make sense, you need to revert the change you made to a. | 08:12 |
| petefoth | paulsherwood: that's a different problem I fear - and a very real one | 08:13 |
| *** gfinney has joined #baserock | 08:20 | |
| *** paulw has joined #baserock | 08:20 | |
| straycat | we don't seem to have a decision, i'll leave the docs as they are | 08:21 |
| petefoth | straycat: :) | 08:22 |
| *** De|ta has quit IRC | 08:30 | |
| *** De|ta has joined #baserock | 08:33 | |
| *** perryl_ has joined #baserock | 08:36 | |
| *** perryl_ has quit IRC | 08:39 | |
| *** perryl has joined #baserock | 08:39 | |
| *** mdizzle has joined #baserock | 08:41 | |
| straycat | aww now why can't i force push to master of the wiki >.> | 08:42 |
| straycat | i've finished off the upgrade section of http://wiki.baserock.org/quick-start/#index7h2 which Zara pointed out a while back | 08:43 |
| straycat | it's just a copy of what's in the upgrade cluster morph | 08:44 |
| petefoth | straycat: looks good - thanks | 08:44 |
| *** De|ta_ has joined #baserock | 08:46 | |
| petefoth | There is now a 'Rationalise morph upgrade v morph deploy --upgrade' task in the 'Improve morph user interface' story on Storyboard | 08:57 |
| *** bashrc_ has joined #baserock | 09:01 | |
| *** rdale has joined #baserock | 09:04 | |
| *** mwilliams_ct has joined #baserock | 09:12 | |
| *** gary_perkins has joined #baserock | 09:13 | |
| *** benbrown_ has joined #baserock | 09:20 | |
| *** jonathanmaw has joined #baserock | 09:21 | |
| *** franred has quit IRC | 09:23 | |
| *** franred has joined #baserock | 09:24 | |
| *** tiagogomes_ has joined #baserock | 09:28 | |
| *** Zara has joined #baserock | 09:50 | |
| *** edcragg has joined #baserock | 09:57 | |
| jjardon | IMHO, to move things forward, Its normally better send a patch and discuss over it | 10:01 |
| *** ssam2 has joined #baserock | 10:02 | |
| *** ChanServ sets mode: +v ssam2 | 10:02 | |
| petefoth | jjardon: I think, for some things, the code gets too big, so you need to discuss first (but you do more of this stuff than me) | 10:02 |
| petefoth | e.g. I'm looking at 'Improving the offline experience'. I beoieve we need to work out what we want to change, *before* we start changing the code | 10:03 |
| petefoth | In the 'upgrade' case we were discussing earlier, I *think* there is agreement that there should only be one way of doing it (though I may be wrong there), but we're not sure whether the 'correct' way is to remove / deprecate 'morph deploy --upgrade' and recommend 'morph upgrade', or the other way round. | 10:07 |
| petefoth | Better IMHO to have the dicusssion first and only make changes when we have agreed what to do | 10:08 |
| *** pdar has joined #baserock | 10:09 | |
| *** lachlanmackenzie has joined #baserock | 10:14 | |
| *** Krin has joined #baserock | 10:30 | |
| jjardon | ssam2: in case you didnt realize (happens to me before), Ive replied to your comment in http://gerrit.baserock.org/#/c/33/ | 10:38 |
| ssam2 | we need emails. i've replied | 10:39 |
| straycat | does my next patch to morph need to be gerrit or can we still use baserock-dev? | 10:40 |
| ssam2 | i'd prefer if you could use gerrit | 10:41 |
| petefoth | and gerrit is what the 'contributing' page says | 10:41 |
| straycat | how can i get it to notify me when something happens? | 10:42 |
| ssam2 | get a mail transfer agent working in Baserock so I can update the system to have one | 10:42 |
| ssam2 | I started getting exim4 in there, but then stopped | 10:42 |
| ssam2 | just because other things took priority | 10:43 |
| petefoth | straycat: do the 'Emails don't send' task in 'Remaining TODO for gerrit.baserock.org' story https://storyboard.baserock.org/#!/story/28 | 10:44 |
| straycat | okay, can you understand why i'd prefer to stick with the list until that's sorted? i'm not trying to be a pain and i'm willing to help get exim working, but i don't want to have to poll the site | 10:44 |
| *** wschaller has joined #baserock | 10:44 | |
| straycat | ssam2, ^ | 10:44 |
| bashrc_ | the amount of space to enter the details of a bug on storyboard.baserock.org seems very limited | 10:45 |
| pedroalvarez | well, is not a bug tracker | 10:45 |
| bashrc_ | oh well, maybe it was just a glitch | 10:47 |
| ssam2 | ok | 10:47 |
| jjardon | pedroalvarez: i thought the idea was to use storyboard as our bug tracker? | 10:49 |
| straycat | in other news a fix i'm working on seems to have pointed out a bug in definitions: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/python-cliapp.morph the morph 'strata/morph-utils/python-coveragepy.morph' doesn't exist | 10:50 |
| pedroalvarez | jjardon: we can track bugs there, but is not a bug tracker, no? | 10:50 |
| petefoth | jjardon: that si the idea. It's just that stroyboard isn't really a bug tracker. But wee're using it anyway | 10:50 |
| pedroalvarez | I'm fine with that. I was just pointing that it's not a bug tracker, that's why it doesn't let you add a lot of details for bugs | 10:51 |
| bashrc_ | I'm not really sure what the point is if it's not for tracking bugs | 11:03 |
| Kinnison | Storyboard is for tracking the implementation of stories i thought | 11:04 |
| bashrc_ | new features? | 11:04 |
| Kinnison | Features in general | 11:05 |
| Kinnison | Or rather, stories | 11:05 |
| Kinnison | stories are about use-cases for the most part | 11:05 |
| Kinnison | features are needed to implement use-cases | 11:05 |
| Kinnison | it's all a bit meta | 11:05 |
| *** brlogger` has joined #baserock | 11:19 | |
| *** brlogger has quit IRC | 11:21 | |
| straycat | could i have a quick review of http://sprunge.us/eTYP ? :) | 11:22 |
| straycat | doesn't seem worth sending to the list, but i can if you want | 11:22 |
| pedroalvarez | uh, were we building it without the chunk file? | 11:23 |
| bashrc_ | idea: maybe instead of stories just have issues which are #hashtaggable. Then the groupings can be emergent | 11:23 |
| straycat | petefoth, we were building it with the chunk morph file that's in the repo :) | 11:23 |
| straycat | sorry, pedroalvarez ^ | 11:23 |
| pedroalvarez | ha! | 11:24 |
| straycat | pedroalvarez, i'm working on a patch that will make in an error to specify paths to morphs in definitions that don't exist | 11:24 |
| straycat | *make it | 11:24 |
| pedroalvarez | straycat: that would be really nice | 11:24 |
| straycat | :) | 11:25 |
| pedroalvarez | straycat: +2 | 11:25 |
| straycat | heh :D | 11:25 |
| straycat | oh, i see, thanks >.> | 11:25 |
| pedroalvarez | straycat: if you implement it, and you find problems in the current definitions, fix the definitions before merging the patch to morph :P | 11:25 |
| pedroalvarez | we could end up in another situation where a version of definitions can't build itself | 11:26 |
| straycat | pedroalvarez, mmm, ssam2 suggested we might want to increment the version of definitions for this fix, since we're essentially changing morph's interpretation of definitions | 11:27 |
| pedroalvarez | hm.. true | 11:27 |
| *** paulwaters_ has joined #baserock | 11:31 | |
| straycat | merged thanks | 11:32 |
| *** paulw has quit IRC | 11:33 | |
| *** petefoth has quit IRC | 11:59 | |
| *** petefoth has joined #baserock | 12:01 | |
| straycat | okay this works, so we have definitions versions 0 and 1, what's the versioning scheme for this? | 12:08 |
| * straycat disappears | 12:09 | |
| pedroalvarez | afaict, with your patch we will be able to build version 0 an version 1 only if their "morph" paths exist | 12:10 |
| pedroalvarez | That's why I wasn't too sure about the version change | 12:11 |
| *** edcragg has quit IRC | 12:17 | |
| tiagogomes_ | hey, it turns out that I shouln't abandoned http://gerrit.baserock.org/#/c/37/, can someone merge this? | 12:30 |
| pedroalvarez | tiagogomes_: sure | 12:31 |
| pedroalvarez | tiagogomes_: just wondering, can you restore it from abandoned? | 12:31 |
| pedroalvarez | or is that something you don't have permissions for? | 12:32 |
| tiagogomes_ | pedroalvarez, I don't know. I am new to Gerrit | 12:32 |
| pedroalvarez | go to that page, can you see a red button saying "Restore"? | 12:33 |
| *** kejiahu has joined #baserock | 12:33 | |
| tiagogomes_ | on https://code.google.com/p/gerrit/issues/detail?id=312, "Not having this is like deploying a nuclear weapon and not being able to talk to the pilot. " | 12:33 |
| tiagogomes_ | pedroalvarez I don't see any restore | 12:34 |
| pedroalvarez | ok | 12:34 |
| pedroalvarez | then maybe people in the Mergers group can do that sort of things | 12:34 |
| * pedroalvarez restores the patch | 12:34 | |
| pedroalvarez | heh, merge conflict :) | 12:36 |
| tiagogomes_ | ¬_¬ | 12:36 |
| tiagogomes_ | do I need to resend it? | 12:36 |
| pedroalvarez | I'm going to try to click on "Rebase" | 12:36 |
| pedroalvarez | well, I'm going to read first what to do in these cases | 12:36 |
| * pedroalvarez reads this [1] but still wants to press the rebase button | 12:38 | |
| pedroalvarez | [1]: http://www.bn2vs.com/blog/2013/07/01/resolving-a-merge-conflict-on-gerrit/ | 12:38 |
| pedroalvarez | Anybody has opinions? | 12:39 |
| ssam2 | try the rebase button. what could possibly go wrong? | 12:42 |
| pedroalvarez | gerrit can't rebase it | 12:44 |
| *** pacon has joined #baserock | 12:46 | |
| *** pacon has quit IRC | 12:56 | |
| *** pacon has joined #baserock | 12:59 | |
| radiofree | "ImportError: No module named fs.tempfs" | 13:09 |
| radiofree | this is using latest morph on a really old version of baserock (8) | 13:09 |
| *** pacon has quit IRC | 13:09 | |
| Kinnison | radiofree: it's lacking pyfilesystem I think | 13:10 |
| radiofree | ta, i'll build that | 13:11 |
| *** pacon has joined #baserock | 13:11 | |
| Kinnison | there's *lots* of stuff which has changed in morph's deps since br8 | 13:11 |
| radiofree | yeah looks like this isn't going to be easy | 13:13 |
| radiofree | will morph from br8 be able to build 15.10? | 13:14 |
| ssam2 | no | 13:15 |
| radiofree | ok | 13:15 |
| pedroalvarez | radiofree: but you can try to "use latest morph"? | 13:18 |
| Kinnison | radiofree: I suggest re-bootstrapping your platform | 13:19 |
| radiofree | i believe bashrc_ is trying that | 13:19 |
| straycat | pedroalvarez, the patch changes morph's interpretation of definitions, so in some hypothetical situation where someone is relying on current behaviour, applying this patch without also incrementing the version will break their definitions | 13:24 |
| pedroalvarez | In that case, these definitions should be version 2 now, and morph shouldn be able to build version 0 and 1, just 2 | 13:25 |
| ssam2 | sounds correct | 13:25 |
| *** edcragg has joined #baserock | 13:25 | |
| ssam2 | also sounds a bit annoying, but we're going to have to get used to this process if we are actually going to make meaningful changes to the definitions format | 13:25 |
| straycat | are we definitely sure we want that versioning scheme? | 13:26 |
| * SotK wonders if indicating the last commit of morph which can build a given definitions version would be useful | 13:27 | |
| * straycat can imagine we could be on version 30 in 3 months | 13:27 | |
| pedroalvarez | I hope that at some point we don't need many changes | 13:27 |
| ssam2 | in the discussion at the meetup, we agreed that was likely and that that was what we wanted | 13:27 |
| * Kinnison would also suggest that if morph can be made to implement a *range* of versions then that would be valuable | 13:27 | |
| Kinnison | Obviously if it overly complicates the code then we shouldn't, but if possible, having morph support multiple versions would be valuable for people who don't follow master all the time | 13:28 |
| ssam2 | straycat: how difficult would it be to make your patch behaviour dependent on the contents of the VERSION file ? | 13:28 |
| ssam2 | that sounds like a nice solution, except it might overcomplicating the implementation | 13:28 |
| ssam2 | -ing | 13:29 |
| * Kinnison is one of those people who would like to say we shouldn't *use* version N in master until there's a release out which supports it, but it's a pain to do that | 13:29 | |
| * paulsherwood really needs to pubish his wip notes on this version thing | 13:29 | |
| Kinnison | as I said, overcomplication of implementation would be an argument against this | 13:29 |
| pedroalvarez | hm.. I don't like the idea of having the code full of "if version number >= X" | 13:29 |
| pedroalvarez | this is the "overcomplication of implementation argument" I guess :) | 13:29 |
| paulsherwood | my problem is i think we need to explicitly work through a karnaugh map to clarify our general policy here | 13:30 |
| Kinnison | In Debian, debhelper (a build assistant tool for debian packages) supports a number of "compatibility levels". This does complicate the code a bit, but so long as you're careful you can make it neat | 13:31 |
| Kinnison | paulsherwood: :) | 13:31 |
| * paulsherwood confesses he'd forgotten all about karnaugh maps until franred mentioned them recently | 13:31 | |
| straycat | ssam2, trivial my change happens to be in the file where the constant is defined | 13:31 |
| paulsherwood | i'll take the liberty of throwing up a partial wiki page... but the hard work remains to be done... | 13:31 |
| straycat | ssam2, sorry misread the code, but anyway it's still not difficult | 13:33 |
| *** pacon has quit IRC | 13:33 | |
| straycat | not sure about doing it though | 13:33 |
| straycat | paulsherwood, where is the wiki page? | 13:35 |
| straycat | sorry, misread that as well | 13:35 |
| paulsherwood | http://wiki.baserock.org/back-and-forth | 13:36 |
| * paulsherwood gets back to his day job | 13:37 | |
| straycat | cool thanks | 13:38 |
| jjardon | paulsherwood: i do not think forward compatibility with new versions of definition is possible | 13:39 |
| jjardon | You can not know how the format will be in the future | 13:40 |
| ssam2 | I know of a downstream consumer of definitions.git, and their policy is to be very conservative about merging changes in from upstream | 13:42 |
| ssam2 | from their point of view, if it's hard to keep up to date with 'master' of definitions (because you keep needing to update your build tools) it doesn't really matter because they don't do it anyway | 13:42 |
| radiofree | so using latest morph on baserock 13, i get http://fpaste.org/200529/58836142/ | 13:42 |
| radiofree | i'm using master of cliapp | 13:42 |
| ssam2 | radiofree: try baserock/morph of cliapp | 13:42 |
| ssam2 | we have effectively forked cliapp, at the moment | 13:42 |
| radiofree | worked, ta! | 13:43 |
| paulsherwood | jjardon: if current morph *can* do something useful with a (future) set of definitions i suggest that it would be better for it to warn and proceed, ignoring what it doesn't understand, rather than stopping. | 13:45 |
| SotK | how would morph know where it should warn? | 13:47 |
| paulsherwood | 'WARNING: i don't recognise Version 5' 'WARNING: skipping unrecognised field foobar:" | 13:48 |
| paulsherwood | jjardon: my document is not very clear, but i *think* that when you say 'i do not think forward compatibility with new versions of definition is possible'.... | 13:50 |
| SotK | I don't understand how that old morph could then expect to do anything useful with its partially-parsed definitions | 13:50 |
| paulsherwood | it's like saying 'i do not think that backward compatibility with old versions of morph is possible' | 13:50 |
| paulsherwood | SotK: it could build them. maybe it wouldn't include some fancy new features, but building might still be useful | 13:51 |
| rjek | If you wanted that, there's no reason for a VERSION file: just warn about unknown fields | 13:51 |
| paulsherwood | (eg if morph is in a distbuild network, and the new features relate to deployment) | 13:51 |
| bashrc_ | if morph ignores definitions which it doesn't understand then does that have implications for reproducibility? | 13:51 |
| ssam2 | our planned changes for definitions include more than just adding new features. we also want to remove some | 13:51 |
| straycat | ssam2, so we'd move definitions to version 2 and my patch would have a conditional so that it only runs for versions > 1. this seems okay to me | 13:52 |
| paulsherwood | true. i don't have *solutions* for all of this... but i'm trying to shine a light on some of the corners of the problem | 13:52 |
| SotK | paulsherwood: What if the change was to do with how we were supposed to understand the build-commands? | 13:53 |
| SotK | and that change causes the build to fail in a weird way | 13:53 |
| straycat | ssam2, and perhaps for < 1 we make it warn | 13:53 |
| paulsherwood | SotK: as i said, i don't have all the answers. if i did, i would have expressed them | 13:53 |
| jjardon | paulsherwood: yes, what I meant to say is that old version of morph will probably not be able to build new definitions formats | 13:53 |
| straycat | otoh, i think this might just be overkill, if anyone's relying on broken paths in their definitions then they shouldn't be, we should just merge the fix, if anyone complains then we tell them to remove the 'morph:' field from their chunk definitions, seems much simpler | 13:55 |
| paulsherwood | i still think morph should always by default warn and try, rather than stopping. the build-depends thing is a case in point. moprh should have always tried to assume build-depends: [] rather than stopping when it didn't find one. | 13:56 |
| persia | My worry with warn-and-try is that some operations can corrupt an entire team's work. | 13:57 |
| persia | I'd prefer if a given morph had a range of versions it knew how to process, and we took care to ensure that this always provided an upgrade path. | 13:58 |
| jjardon | ssam2: (about the downstream consumer) I would say the bug is "update the build tools is not trivially easy" | 13:59 |
| persia | How isn't it trivially easy? | 14:01 |
| Kinnison | we add dependencies to the tools | 14:01 |
| ssam2 | persia: this team have a 7 node build server which they use, plus each developer has a chroot | 14:01 |
| Kinnison | which makes the 'git pull' approach harder | 14:01 |
| persia | I think that it is easy to upgrade, but that the tooling fails to support being upgraded. | 14:02 |
| ssam2 | I don't think we can ever make it so that upgrading a build server isn't disruptive: it will always break people's running builds | 14:02 |
| persia | Having proper releases of morph and stable branches means that we ought be able to do something like: | 14:03 |
| persia | 1) upgrade to latest morph in your branch | 14:03 |
| persia | 2) Use that to migrate your system to one that consumes a more capable morph | 14:03 |
| persia | 3) Use that to process an updated definitions. | 14:03 |
| rjek | I have a fear that if a warning is temporary, then two morph runs of the same set of definitions may result in differing results. | 14:03 |
| ratmice__ | is morph supposed to function outside of baserock? could you just upon initial release install both morph and morph-latest where morph == morph-latest, and then update a deployment upon release of the next version? | 14:03 |
| persia | Note that by "upgrade to latest morph", I mean `morph upgrade ...`, not `git pull ...`+symlinks, which I think is broken from the start. | 14:04 |
| persia | ratmice__: At least some folk (like me) want morph to work on non-baserock systems. In the current state, it doesn't even work on all baserock-produced systems. | 14:04 |
| straycat | rjek, that's the point they will produce different results, the other point is that this only affects invalid definitions, so i think it's fair to not make this a new definitions version | 14:05 |
| paulsherwood | current example - the removal of build-depends:[] from definitions requires current morph. upgrading morph requires adding pylru - instructions for that were dropped when our current release system included pylru by default. result - existing user needs to update system, as well as morph, to work with latest definitions. | 14:08 |
| paulsherwood | i know that developers on the edge can cope with this, but i'm hoping we can find a way to minimise the wrinkles by default | 14:09 |
| Kinnison | Time was, that we said that release N+1 had to be buildable with release N | 14:09 |
| Kinnison | THen we stopped making 6-weekly releases | 14:09 |
| Kinnison | then it was hard | 14:09 |
| bashrc_ | release often | 14:10 |
| ssam2 | please do | 14:10 |
| paulsherwood | i'm not saying one or the other approach is better. we're aiming for continuous updates for all the things, though. so the machine needs to be as frictionless as possible | 14:10 |
| straycat | i don't really mind which way we go, i personally think it's overkill for this to be a new version of definitions. but it would be useful to have a decision so that i can submit the patch for review | 14:10 |
| Kinnison | I think we need to stop being afraid of new versions for definitions, so it should be a new version even if people think it shouldn't IYSWIM | 14:11 |
| ssam2 | I think it should be a new version, because otherwise we are never going to move forward with making changes to definitions | 14:11 |
| Kinnison | ssam2: snappish | 14:11 |
| straycat | Okay, new version, and code will only run for versions > 1 for < 1 it will warn | 14:11 |
| straycat | thanks | 14:11 |
| ssam2 | thank you for being willing to poke this hornets' nest :) | 14:12 |
| Kinnison | bzz bzz | 14:12 |
| paulsherwood | :-) | 14:12 |
| * paulsherwood wonders if anyone else understands his idea that working through a karnaugh map might help here | 14:13 | |
| * paulsherwood may be deluded | 14:14 | |
| Kinnison | I understand your statement | 14:14 |
| Kinnison | I have yet to decide the variables | 14:14 |
| paulsherwood | do you believe it's even worth spending some trying to clarify the variables? | 14:15 |
| paulsherwood | s/some/some time/ | 14:15 |
| Kinnison | I think exploring the implications of the options will help | 14:15 |
| Kinnison | E.g. the cost of making new morph support old definitions vs. the cost of making sure we don't change definitions incompatibly until a new release is out | 14:16 |
| *** locallycompact has joined #baserock | 14:19 | |
| flatmush | running demorgans on some things makes sense, karnaugh maps are a lot of effort and while they yield the most optimal result they may not yield the most readable result | 14:20 |
| paulsherwood | demorgans? | 14:20 |
| flatmush | a || b == ~(a & b) | 14:21 |
| flatmush | basically, it allows you to remove extra negations | 14:21 |
| flatmush | it's very quick, most programmers will do that in their heads anyway | 14:21 |
| paulsherwood | aha... there's a name for it! thanks very much. | 14:22 |
| flatmush | http://en.wikipedia.org/wiki/De_Morgan%27s_laws | 14:22 |
| paulsherwood | looking aty lots of code over the years, i must say it sometimes feels like 'most programmers' don't do it at all | 14:22 |
| persia | I don't think cost estimation is the right way. I think we ought assert that by policy, any morph supports at least three versions of definitions (if there exist three versions). | 14:23 |
| Kinnison | persia: the problem with that is that it places an arbitrary limit on how often we can plausibly change definitions and thus can stifle work | 14:23 |
| flatmush | paulsherwood: I wouldn't consider most "programmers" to be programmers tbh | 14:23 |
| persia | paulsherwood: Most programmers have internalised the laws, but it is also true that most programmers don't refine their code, so the overlap includes a lot of ugly code that even the author agrees could be cleaned. | 14:24 |
| * Kinnison thinks "morph will support a range of versions, and it will always be possible to move from A to Z via some overlapping B-Y" might be better | 14:24 | |
| persia | Kinnison: The key in my policy to avoid that is the "at least". | 14:24 |
| paulsherwood | flatmush: heh! | 14:24 |
| persia | Kinnison: I'm happy with your rewording | 14:24 |
| Kinnison | persia: it's too easy to miss the 'at least' | 14:24 |
| *** mdunford has joined #baserock | 14:25 | |
| straycat | Kinnison, confused, doesn't it already support a range? | 14:25 |
| persia | Kinnison: A common fault in my writing: I am concise to a degree that is not always clear on first gloss. | 14:25 |
| Kinnison | straycat: there's a difference between what currently happens and what is defined to happen :) | 14:25 |
| Kinnison | persia: For things like this, expressing the desired meaning in multiple ways may be beneficial | 14:25 |
| persia | Yep. | 14:26 |
| straycat | Kinnison, okay, i've only read the code | 14:26 |
| Kinnison | :) | 14:26 |
| ratmice__ | I always find this stuff very hairy with regards to reinterpretation of existing fields, because i find a common reaction is for people to add the field (before they use it, ignoring the field), in anticipation of using it in the next version and doing so somewhat incorrectly :/ | 14:35 |
| ratmice__ | then there is the question of wether a reinterpretion of a field requires a version bump (even though maybe the encoding _didn't_ change) | 14:37 |
| ratmice__ | er... whether :D | 14:38 |
| franred | flatmush, the good thing in Karnaugh maps is that you can even do || or && operations depending on how you define the input of your system so for me can be used in the same way as the De_morgan_laws | 14:43 |
| flatmush | yes, but it's more in-depth and it produces an optimal result which may not be the clearest way to think about things | 14:56 |
| tiagogomes_ | pedroalvarez, do I need to re-send the pysendfile patch? | 15:04 |
| pedroalvarez | tiagogomes_: yes, gerrit can't rebase that commit, sorry | 15:05 |
| tiagogomes_ | pedroalvarez, no worries | 15:05 |
| jjardon | tiagogomes_: just push to the same ref should work | 15:30 |
| tiagogomes_ | jjardon, how so? I need to rebase the commit wich will create another ref | 15:30 |
| jjardon | tiagogomes_: gerrit will take care of that | 15:31 |
| tiagogomes_ | jjardon, ok | 15:33 |
| * SotK wonders what happened to gerrit.baserock.org | 16:02 | |
| pedroalvarez | I wonder the same. Currently looking at it, but I don't want to touch it. | 16:11 |
| pedroalvarez | ssam2: can you please look at it too? | 16:11 |
| pedroalvarez | looks like it's failing to connect to the database | 16:12 |
| *** edcragg has quit IRC | 16:13 | |
| radiofree | can i run the cross-bootstrap command locally? | 16:14 |
| radiofree | or do i have to push it somewhere | 16:14 |
| radiofree | morph cross-bootstrap TARGET_ARCH baserock:baserock/definitions master systems/cross-bootstrap-system-TARGET_ARCH-generic.morph | 16:14 |
| SotK | radiofree: try `morph cross-bootstrap TARGET_ARCH . HEAD systems/cross-bootstrap-system-TARGET_ARCH-generic.morph` | 16:15 |
| radiofree | i think that worked, thanks! | 16:17 |
| ssam2 | sorry, I must have stopped the database without restarting it again | 16:19 |
| ssam2 | my fault, i'm a terrible admin | 16:19 |
| gary_perkins | Hi, I've booted the new trove and it went through it's initial configuring phase, but it had a problem, perhaps because I hadn't had the /home mounted at the time. Is there a way to manually re-run the initial setup? | 16:22 |
| rdale | i've built a linux kernel with gnu sed and musl, because i had an error with busybox sed. but i notice that baserock kernels are normally built with busybox sed - i wonder why it isn't a problem there too | 16:22 |
| pedroalvarez | gary_perkins: yes, `systemctl restart trove-setup` | 16:22 |
| pedroalvarez | gary_perkins: but i'd be interested in the failure logs | 16:23 |
| gary_perkins | pedroalvarez: Cheers! :) | 16:23 |
| richard_maw | rdale: it could be argument parsing, the glibc getopt behaves differently to musl's | 16:23 |
| pedroalvarez | gary_perkins: /var/log/ansible, can I see it? | 16:23 |
| rdale | ah ok thanks | 16:23 |
| gary_perkins | pedroalvarez: Sure... | 16:23 |
| pedroalvarez | gary_perkins: I think it doesn't have any private information | 16:24 |
| gary_perkins | pedroalvarez: there is no /var/log/ansible | 16:24 |
| gary_perkins | pedroalvarez: config.err? config.log? | 16:25 |
| pedroalvarez | oh | 16:26 |
| pedroalvarez | `systemctl status trove-setup` will give you some information about why you don't have /var/log/ansible | 16:26 |
| gary_perkins | pedroalvarez: okeedokee | 16:26 |
| pedroalvarez | :) | 16:26 |
| gary_perkins | Condition: start condition failed at Fri 2015-03-20 16:17:11 UTC; 9min ago | 16:27 |
| gary_perkins | ConditionPathExists=/etc/trove/trove.conf was not met | 16:27 |
| gary_perkins | Mar 20 16:17:11 ct-trove systemd[1]: Started Run trove-setup Ansible scripts. | 16:27 |
| straycat | ruroh | 16:28 |
| pedroalvarez | right, you haven't configured it yet then | 16:28 |
| gary_perkins | pedroalvarez: I'll go back to the docs... | 16:29 |
| pedroalvarez | gary_perkins: here is an example (in the cloud-config script) http://wiki.baserock.org/guides/deploy-trove-to-openstack/ | 16:29 |
| pedroalvarez | you can do it manually now | 16:29 |
| gary_perkins | pedroalvarez: Thanks, I had started the instance with nova boot ..... --user-data cloud-config.sh so I thought it would have worked with that | 16:31 |
| gary_perkins | I also had to specify the tenant network too, which wasn't in the docs | 16:31 |
| pedroalvarez | hm.. odd | 16:31 |
| pedroalvarez | yeah, that depends on the configuration of openstack | 16:32 |
| gary_perkins | ok, I'll just remove the instance and run it again | 16:32 |
| pedroalvarez | gary_perkins: I don't know why that has failed, but you can do it manually now. Is going to be the same thing | 16:32 |
| gary_perkins | ok | 16:32 |
| gary_perkins | cheers :) | 16:33 |
| Kinnison | Hi, anyone able to take a quick peek at http://paste.baserock.org/ufarinebif and suggest what might be causing the errors (which appear around line 680) | 16:37 |
| Kinnison | stage2 gawk is failing to build on our arm64 systems | 16:37 |
| persia | ssam2: An interesting way to not be a terrible admin is to never do any admin, rather cause automation to do the admin on your behalf. | 16:38 |
| pedroalvarez | it's trying to remove things from the read-only part of the staging area | 16:38 |
| pedroalvarez | Kinnison: ^ | 16:38 |
| *** mdunford has quit IRC | 16:38 | |
| * persia has a long history of being a terrible admin, and only manages to avoid all sorts of exploits thorough lots of automation | 16:38 | |
| Kinnison | pedroalvarez: I can see that -- what I don't understand is *why* :) | 16:38 |
| *** mdunford has joined #baserock | 16:39 | |
| pedroalvarez | Kinnison: I pointed out yesterday that this build is not using the steps definied in our stage2-gawk definition | 16:39 |
| Kinnison | pedroalvarez: Interesting, I didn't see that :( Must have skipped it in my backlog reading | 16:40 |
| richard_maw | it appears to be running the configure and make commands we define in the morphology | 16:42 |
| pedroalvarez | erm.. ops | 16:43 |
| richard_maw | hrm, looks like DESTDIR is not making it that far into the install commands | 16:43 |
| richard_maw | since the command in questoin is: | 16:44 |
| kejiahu | pedroalvarez, richard_maw, this error happens while we trying to build a build system using netbooted cross-bootstrap system. | 16:44 |
| richard_maw | install-data-hook: | 16:44 |
| richard_maw | for i in $(pkgextension_LTLIBRARIES) ; do \ | 16:44 |
| richard_maw | $(RM) $(DESTDIR)$(pkgextensiondir)/$$i ; \ | 16:44 |
| richard_maw | done | 16:44 |
| Kinnison | Could this be a change in the behaviour of Make ? | 16:45 |
| richard_maw | it would be a pretty broken one, since we're not even relying on it picking it up out of the environment, we run `make DESTDIR="$DESTDIR" install`, it's not supposed to be able to override DESTDIR there | 16:45 |
| Kinnison | make install-data-hook | 16:46 |
| Kinnison | no sign of DESTDIR on that commandline | 16:46 |
| Kinnison | interesting | 16:47 |
| richard_maw | that's not invoked directly by us | 16:47 |
| richard_maw | it's invoked by make itself | 16:47 |
| Kinnison | aah | 16:47 |
| * richard_maw suspects automake | 16:48 | |
| richard_maw | install-data-am: install-man install-pkgextensionLTLIBRARIES | 16:48 |
| richard_maw | @$(NORMAL_INSTALL) | 16:48 |
| richard_maw | $(MAKE) $(AM_MAKEFLAGS) install-data-hook | 16:48 |
| Kinnison | well $(MAKE) should have passed DESTDIR= if it needed to | 16:49 |
| richard_maw | $(MAKE) is supposed to be magic and include all the jazz to import variables from the parent make | 16:49 |
| Kinnison | yeah | 16:49 |
| Kinnison | and destdir was clearly in the bit above | 16:49 |
| richard_maw | if you've got a failed build-tree around, I'd be interested to see what goes in the generated makefile | 16:49 |
| Kinnison | kejiahu: do we have a failed build tree we can tar up and put somewhere for richard_maw ? | 16:50 |
| richard_maw | I'm wondering whether $(MAKE) is interpreted too early or something | 16:50 |
| kejiahu | Kinnison, I think so | 16:50 |
| *** CTtpollard has quit IRC | 16:58 | |
| kejiahu | richard_maw, it seems the staging area is cleaned up when the build fails, is there any way to extract the information you want? | 16:59 |
| *** a1exhughe5 has quit IRC | 17:00 | |
| radiofree | kejiahu: check /src/tmp/failed | 17:21 |
| kejiahu | radiofree, thanks, it is there | 17:24 |
| SotK | hm, I'm getting " ! [remote rejected] HEAD -> refs/for/master/baserock/adamcoldrick/partial-builds (no new changes)" when trying to push to Gerrit | 17:26 |
| SotK | any idea what that means? | 17:26 |
| ssam2 | missing change-id? | 17:27 |
| ssam2 | or duplicating an existing change-id ? | 17:27 |
| ssam2 | no, duplicating an existing change-id just creates a new version of the change | 17:27 |
| SotK | the commits have Change-Ids it seems | 17:27 |
| SotK | oh, I've done something weird, nevermind | 17:28 |
| SotK | hmm, maybe I haven't | 17:30 |
| SotK | made it work | 17:32 |
| *** Krin has quit IRC | 17:32 | |
| SotK | I'd got in a strange tangle and had my branch merged into my local master and rebased on top of that or similar I think | 17:33 |
| straycat | hrm, this warning flies past so won't be noticed | 17:39 |
| *** jonathanmaw has quit IRC | 17:39 | |
| straycat | hrm, well, for --no-verbose and --no-build-log-on-stdout it's reasonable, there should possible be some mechanism for collecting such warnings and displaying them at the end of the build | 17:41 |
| straycat | *possibly | 17:41 |
| *** zoli__ has quit IRC | 17:42 | |
| *** bashrc_ has quit IRC | 18:03 | |
| *** mdunford has quit IRC | 18:11 | |
| straycat | hrm, not sure about this the wiki (http://wiki.baserock.org/meetup/declarative-definitions/) seems to suggest treating a missing version file as version 0 but we don't seem to be doing this atm | 18:14 |
| straycat | would rather sort that before sending this series, so, to be continued... | 18:15 |
| * straycat disappears | 18:15 | |
| *** mdizzle has quit IRC | 18:18 | |
| *** zoli__ has joined #baserock | 18:20 | |
| *** zoli__ has quit IRC | 18:26 | |
| *** rdale has quit IRC | 18:31 | |
| *** franred has quit IRC | 18:34 | |
| *** tiagogomes_ has quit IRC | 18:36 | |
| *** lachlanmackenzie has quit IRC | 18:49 | |
| jjardon | straycat: do we not? | 18:58 |
| *** ssam2 has quit IRC | 19:00 | |
| *** gfinney has quit IRC | 19:16 | |
| *** wschaller has quit IRC | 19:18 | |
| *** gary_perkins has quit IRC | 19:22 | |
| *** zoli__ has joined #baserock | 20:05 | |
| *** zoli__ has joined #baserock | 20:29 | |
| *** zoli__ has quit IRC | 21:02 | |
| *** zoli__ has joined #baserock | 21:03 | |
| *** flatmush has quit IRC | 21:15 | |
| *** flatmush1 has joined #baserock | 21:16 | |
| *** pacon has joined #baserock | 21:22 | |
| *** zoli__ has quit IRC | 23:37 | |
| *** zoli__ has joined #baserock | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!