IRC logs for #baserock for Friday, 2015-03-20

*** robtaylor has quit IRC02:07
*** robtaylor has joined #baserock02:08
*** paulw has quit IRC02:29
petefotheringhamif `morph deploy --upgrade` works, and is documented, then why deprecate it? Why not deprecate `morph upgrade` instead?05:46
*** zoli__ has joined #baserock05:49
*** petefoth has joined #baserock06:53
straycatso 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
petefothstraycat: No. I am saying, if we have code that works but docs that don't match, then change the docs not the code07:39
petefothWhy deprecat workign functionality?07:40
straycat05:46  petefotheringham$ if `morph deploy --upgrade` works, and is documented, then why deprecate it? Why not07:40
straycat                         deprecate `morph upgrade` instead?07:40
* straycat has misunderstood07:41
straycatthe answer to that question would seem to be "because the patch that was submitted and merged to the list deprecated deploy --upgrade"07:42
petefothI 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 UI07:43
petefothEasiest (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' does07:45
straycatthere is no problem, the docs just need to be updated, is all07:48
petefothstraycat: agreed. Will you do it, or shall I? :)07:49
straycati'll do it, i was apparently too tired last night07:50
petefothThanks!07:50
straycatsam's patch says this:07:51
straycat    The arguments to `morph deploy` can get quite long, any way we can make it07:51
straycat    shorter and clearer is useful. We can also avoid having the strange07:51
straycat    --no-upgrade flag in future.07:51
petefothWhat 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
straycatit's meaningless, a deployment that's not an upgrade is just an ordinary deployment07:54
petefothso we should remove support for the --no-upgrade flag07:55
straycatwell it's deprecated, so we just need to make sure the docs tell people to use the upgrade command07:56
petefothOr the --upgrade flag to morph deploy?07:56
straycatwell that's what's been deprecated07:57
straycathttp://sprunge.us/GTQU07:57
petefothI 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 discussion07:58
straycati 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 reasons08:00
petefothWell we should just do whatever it says in the sepcification. Oh wait... :)08:01
straycati can fix the examples, but i need tea first08:01
paulsherwoodi believe that 'morph upgrade' is simpler to understand than 'morph deploy --upgrade'08:01
paulsherwoodpetefoth: you seem a little grumpy this morning :)08:02
* petefoth goes to get on with something that doesn't involve the angel/pin terpsichory interface08:02
petefothpaulsherwood: grumpy? Moi? Just trying to avoid doing unnecessary stuff (like removing fiunctionality that works)08:02
petefothBesides, I've got a week's holiday comign up - what's to be grumpy about :)08:03
paulsherwoodas a user, it seems to me that 'deploy a new thing' is different from 'upgrade an existing thing'08:04
petefothbut quite like 'deploy this upgrade to that thing'08:04
SotKpetefoth: +108:04
petefothSotK: 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 #baserock08:06
SotKpetefoth: nope :)08:06
paulsherwoodwell, 'morph deploy' could automagically upgrade08:06
paulsherwoodbut would that be better?08:07
petefothPossibly 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
petefothpaulsherwood: snap! But, actualy i don' think that would be better08:08
petefothToo much internal morph 'magic'08:08
paulsherwoodso i'm ok with deprecating 'morph deploy --upgrade', or 'morph upgrade', but we should have only one way to do this function, not two08:10
petefothI 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
paulsherwoodsuch discussions tend to happen, but often do not lead to code-changes i fear08:11
petefothIf 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
petefothpaulsherwood: that's a different problem I fear - and a very real one08:13
*** gfinney has joined #baserock08:20
*** paulw has joined #baserock08:20
straycatwe don't seem to have a decision, i'll leave the docs as they are08:21
petefothstraycat: :)08:22
*** De|ta has quit IRC08:30
*** De|ta has joined #baserock08:33
*** perryl_ has joined #baserock08:36
*** perryl_ has quit IRC08:39
*** perryl has joined #baserock08:39
*** mdizzle has joined #baserock08:41
straycataww now why can't i force push to master of the wiki >.>08:42
straycati've finished off the upgrade section of http://wiki.baserock.org/quick-start/#index7h2 which Zara pointed out a while back08:43
straycatit's just a copy of what's in the upgrade cluster morph08:44
petefothstraycat: looks good - thanks08:44
*** De|ta_ has joined #baserock08:46
petefothThere is now a 'Rationalise morph upgrade v morph deploy --upgrade' task in the 'Improve morph user interface' story on Storyboard08:57
*** bashrc_ has joined #baserock09:01
*** rdale has joined #baserock09:04
*** mwilliams_ct has joined #baserock09:12
*** gary_perkins has joined #baserock09:13
*** benbrown_ has joined #baserock09:20
*** jonathanmaw has joined #baserock09:21
*** franred has quit IRC09:23
*** franred has joined #baserock09:24
*** tiagogomes_ has joined #baserock09:28
*** Zara has joined #baserock09:50
*** edcragg has joined #baserock09:57
jjardonIMHO, to move things forward, Its normally better send a patch and discuss over it10:01
*** ssam2 has joined #baserock10:02
*** ChanServ sets mode: +v ssam210:02
petefothjjardon: 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
petefothe.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 code10:03
petefothIn 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
petefothBetter IMHO to have the dicusssion first and only make changes when we have agreed what to do10:08
*** pdar has joined #baserock10:09
*** lachlanmackenzie has joined #baserock10:14
*** Krin has joined #baserock10:30
jjardonssam2: in case you didnt realize (happens to me before), Ive replied to your comment in http://gerrit.baserock.org/#/c/33/10:38
ssam2we need emails. i've replied10:39
straycatdoes my next patch to morph need to be gerrit or can we still use baserock-dev?10:40
ssam2i'd prefer if you could use gerrit10:41
petefothand gerrit is what the 'contributing' page says10:41
straycathow can i get it to notify me when something happens?10:42
ssam2get a mail transfer agent working in Baserock so I can update the system to have one10:42
ssam2I started getting exim4 in there, but then stopped10:42
ssam2just because other things took priority10:43
petefothstraycat: do the 'Emails don't send' task in 'Remaining TODO for gerrit.baserock.org' story https://storyboard.baserock.org/#!/story/2810:44
straycatokay, 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 site10:44
*** wschaller has joined #baserock10:44
straycatssam2, ^10:44
bashrc_the amount of space to enter the details of a bug on storyboard.baserock.org seems very limited10:45
pedroalvarezwell, is not a bug tracker10:45
bashrc_oh well, maybe it was just a glitch10:47
ssam2ok10:47
jjardonpedroalvarez: i thought the idea was to use storyboard as our bug tracker?10:49
straycatin 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 exist10:50
pedroalvarezjjardon: we can track bugs there, but is not a bug tracker, no?10:50
petefothjjardon: that si the idea. It's just that stroyboard isn't really a bug tracker. But wee're using it anyway10:50
pedroalvarezI'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 bugs10:51
bashrc_I'm not really sure what the point is if it's not for tracking bugs11:03
KinnisonStoryboard is for tracking the implementation of stories i thought11:04
bashrc_new features?11:04
KinnisonFeatures in general11:05
KinnisonOr rather, stories11:05
Kinnisonstories are about use-cases for the most part11:05
Kinnisonfeatures are needed to implement use-cases11:05
Kinnisonit's all a bit meta11:05
*** brlogger` has joined #baserock11:19
*** brlogger has quit IRC11:21
straycatcould i have a quick review of http://sprunge.us/eTYP ? :)11:22
straycatdoesn't seem worth sending to the list, but i can if you want11:22
pedroalvarezuh, 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 emergent11:23
straycatpetefoth, we were building it with the chunk morph file that's in the repo :)11:23
straycatsorry, pedroalvarez ^11:23
pedroalvarezha!11:24
straycatpedroalvarez, i'm working on a patch that will make in an error to specify paths to morphs in definitions that don't exist11:24
straycat*make it11:24
pedroalvarezstraycat: that would be really nice11:24
straycat:)11:25
pedroalvarezstraycat: +211:25
straycatheh :D11:25
straycatoh, i see, thanks >.>11:25
pedroalvarezstraycat: if you implement it, and you find problems in the current definitions, fix the definitions before merging the patch to morph :P11:25
pedroalvarezwe could end up in another situation where a version of definitions can't build itself11:26
straycatpedroalvarez, mmm, ssam2 suggested we might want to increment the version of definitions for this fix, since we're essentially changing morph's interpretation of definitions11:27
pedroalvarezhm.. true11:27
*** paulwaters_ has joined #baserock11:31
straycatmerged thanks11:32
*** paulw has quit IRC11:33
*** petefoth has quit IRC11:59
*** petefoth has joined #baserock12:01
straycatokay this works, so we have definitions versions 0 and 1, what's the versioning scheme for this?12:08
* straycat disappears12:09
pedroalvarezafaict, with your patch we will be able to build version 0 an version 1 only if their "morph" paths exist12:10
pedroalvarezThat's why I wasn't too sure about the version change12:11
*** edcragg has quit IRC12:17
tiagogomes_hey, it turns out that I shouln't abandoned http://gerrit.baserock.org/#/c/37/, can someone merge this?12:30
pedroalvareztiagogomes_: sure12:31
pedroalvareztiagogomes_: just wondering, can you restore it from abandoned?12:31
pedroalvarezor is that something you don't have permissions for?12:32
tiagogomes_pedroalvarez, I don't know. I am new to Gerrit12:32
pedroalvarezgo to that page, can you see a red button saying "Restore"?12:33
*** kejiahu has joined #baserock12: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 restore12:34
pedroalvarezok12:34
pedroalvarezthen maybe people in the Mergers group can do that sort of things12:34
* pedroalvarez restores the patch12:34
pedroalvarezheh, merge conflict :)12:36
tiagogomes_¬_¬12:36
tiagogomes_do I need to resend it?12:36
pedroalvarezI'm going to try to click on "Rebase"12:36
pedroalvarezwell, I'm going to read first what to do in these cases12:36
* pedroalvarez reads this [1] but still wants to press the rebase button12:38
pedroalvarez[1]: http://www.bn2vs.com/blog/2013/07/01/resolving-a-merge-conflict-on-gerrit/12:38
pedroalvarezAnybody has opinions?12:39
ssam2try the rebase button. what could possibly go wrong?12:42
pedroalvarezgerrit can't rebase it12:44
*** pacon has joined #baserock12:46
*** pacon has quit IRC12:56
*** pacon has joined #baserock12:59
radiofree"ImportError: No module named fs.tempfs"13:09
radiofreethis is using latest morph on a really old version of baserock (8)13:09
*** pacon has quit IRC13:09
Kinnisonradiofree: it's lacking pyfilesystem I think13:10
radiofreeta, i'll build that13:11
*** pacon has joined #baserock13:11
Kinnisonthere's *lots* of stuff which has changed in morph's deps since br813:11
radiofreeyeah looks like this isn't going to be easy13:13
radiofreewill morph from br8 be able to build 15.10?13:14
ssam2no13:15
radiofreeok13:15
pedroalvarezradiofree: but you can try to "use latest morph"?13:18
Kinnisonradiofree: I suggest re-bootstrapping your platform13:19
radiofreei believe bashrc_ is trying that13:19
straycatpedroalvarez, 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 definitions13:24
pedroalvarezIn that case, these definitions should be version 2 now, and morph shouldn be able to build version 0 and 1, just 213:25
ssam2sounds correct13:25
*** edcragg has joined #baserock13:25
ssam2also 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 format13:25
straycatare 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 useful13:27
* straycat can imagine we could be on version 30 in 3 months13:27
pedroalvarezI hope that at some point we don't need many changes13:27
ssam2in the discussion at the meetup, we agreed that was likely and that that was what we wanted13:27
* Kinnison would also suggest that if morph can be made to implement a *range* of versions then that would be valuable13:27
KinnisonObviously 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 time13:28
ssam2straycat: how difficult would it be to make your patch behaviour dependent on the contents of the VERSION file ?13:28
ssam2that sounds like a nice solution, except it might overcomplicating the implementation13:28
ssam2-ing13: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 that13:29
* paulsherwood really needs to pubish his wip notes on this version thing13:29
Kinnisonas I said, overcomplication of implementation would be an argument against this13:29
pedroalvarezhm.. I don't like the idea of having the code full of "if version number >= X"13:29
pedroalvarezthis is the "overcomplication of implementation argument" I guess :)13:29
paulsherwoodmy problem is i think we need to explicitly work through a karnaugh map to clarify our general policy here13:30
KinnisonIn 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 neat13:31
Kinnisonpaulsherwood: :)13:31
* paulsherwood confesses he'd forgotten all about karnaugh maps until franred mentioned them recently13:31
straycatssam2, trivial my change happens to be in the file where the constant is defined13:31
paulsherwoodi'll take the liberty of throwing up a partial wiki page... but the hard work remains to be done...13:31
straycatssam2, sorry misread the code, but anyway it's still not difficult13:33
*** pacon has quit IRC13:33
straycatnot sure about doing it though13:33
straycatpaulsherwood, where is the wiki page?13:35
straycatsorry, misread that as well13:35
paulsherwoodhttp://wiki.baserock.org/back-and-forth13:36
* paulsherwood gets back to his day job13:37
straycatcool thanks13:38
jjardonpaulsherwood: i do not think forward compatibility with new versions of definition is possible13:39
jjardonYou can not know how the format will be in the future13:40
ssam2I know of a downstream consumer of definitions.git, and their policy is to be very conservative about merging changes in from upstream13:42
ssam2from 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 anyway13:42
radiofreeso using latest morph on baserock 13, i get http://fpaste.org/200529/58836142/13:42
radiofreei'm using master of cliapp13:42
ssam2radiofree: try baserock/morph of cliapp13:42
ssam2we have effectively forked cliapp, at the moment13:42
radiofreeworked, ta!13:43
paulsherwoodjjardon: 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
SotKhow would morph know where it should warn?13:47
paulsherwood'WARNING: i don't recognise Version 5' 'WARNING: skipping unrecognised field foobar:"13:48
paulsherwoodjjardon: 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
SotKI don't understand how that old morph could then expect to do anything useful with its partially-parsed definitions13:50
paulsherwoodit's like saying 'i do not think that backward compatibility with old versions of morph is possible'13:50
paulsherwoodSotK: it could build them. maybe it wouldn't include some fancy new features, but building might still be useful13:51
rjekIf you wanted that, there's no reason for a VERSION file: just warn about unknown fields13: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
ssam2our planned changes for definitions include more than just adding new features. we also want to remove some13:51
straycatssam2, 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 me13:52
paulsherwoodtrue. i  don't have *solutions* for all of this... but i'm trying to shine a light on some of the corners of the problem13:52
SotKpaulsherwood: What if the change was to do with how we were supposed to understand the build-commands?13:53
SotKand that change causes the build to fail in a weird way13:53
straycatssam2, and perhaps for < 1 we make it warn13:53
paulsherwoodSotK: as i said, i don't have all the answers. if i did, i would have expressed them13:53
jjardonpaulsherwood: yes, what I meant to say is that old version of morph will probably not be able to build new definitions formats13:53
straycatotoh, 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 simpler13:55
paulsherwoodi 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
persiaMy worry with warn-and-try is that some operations can corrupt an entire team's work.13:57
persiaI'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
jjardonssam2: (about the downstream consumer) I would say the bug is "update the build tools is not trivially easy"13:59
persiaHow isn't it trivially easy?14:01
Kinnisonwe add dependencies to the tools14:01
ssam2persia: this team have a 7 node build server which they use, plus each developer has a chroot14:01
Kinnisonwhich makes the 'git pull' approach harder14:01
persiaI think that it is easy to upgrade, but that the tooling fails to support being upgraded.14:02
ssam2I don't think we can ever make it so that upgrading a build server isn't disruptive: it will always break people's running builds14:02
persiaHaving proper releases of morph and stable branches means that we ought be able to do something like:14:03
persia1) upgrade to latest morph in your branch14:03
persia2) Use that to migrate your system to one that consumes a more capable morph14:03
persia3) Use that to process an updated definitions.14:03
rjekI 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
persiaNote that by "upgrade to latest morph", I mean `morph upgrade ...`, not `git pull ...`+symlinks, which I think is broken from the start.14:04
persiaratmice__: 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
straycatrjek, 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 version14:05
paulsherwoodcurrent 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
paulsherwoodi know that developers on the edge can cope with this, but i'm hoping we can find a way to minimise the wrinkles by default14:09
KinnisonTime was, that we said that release N+1 had to be buildable with release N14:09
KinnisonTHen we stopped making 6-weekly releases14:09
Kinnisonthen it was hard14:09
bashrc_release often14:10
ssam2please do14:10
paulsherwoodi'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 possible14:10
straycati 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 review14:10
KinnisonI 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 IYSWIM14:11
ssam2I think it should be a new version, because otherwise we are never going to move forward with making changes to definitions14:11
Kinnisonssam2: snappish14:11
straycatOkay, new version, and code will only run for versions > 1 for < 1 it will warn14:11
straycatthanks14:11
ssam2thank you for being willing to poke this hornets' nest :)14:12
Kinnisonbzz bzz14:12
paulsherwood:-)14:12
* paulsherwood wonders if anyone else understands his idea that working through a karnaugh map might help here14:13
* paulsherwood may be deluded14:14
KinnisonI understand your statement14:14
KinnisonI have yet to decide the variables14:14
paulsherwooddo you believe it's even worth spending some trying to clarify the variables?14:15
paulsherwoods/some/some time/14:15
KinnisonI think exploring the implications of the options will help14:15
KinnisonE.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 out14:16
*** locallycompact has joined #baserock14:19
flatmushrunning 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 result14:20
paulsherwooddemorgans?14:20
flatmusha || b == ~(a & b)14:21
flatmushbasically, it allows you to remove extra negations14:21
flatmushit's very quick, most programmers will do that in their heads anyway14:21
paulsherwoodaha... there's a name for it! thanks very much.14:22
flatmushhttp://en.wikipedia.org/wiki/De_Morgan%27s_laws14:22
paulsherwoodlooking aty lots of code over the years, i must say it sometimes feels like 'most programmers' don't do it at all14:22
persiaI 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
Kinnisonpersia: the problem with that is that it places an arbitrary limit on how often we can plausibly change definitions and thus can stifle work14:23
flatmushpaulsherwood: I wouldn't consider most "programmers" to be programmers tbh14:23
persiapaulsherwood: 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 better14:24
persiaKinnison: The key in my policy to avoid that is the "at least".14:24
paulsherwoodflatmush: heh!14:24
persiaKinnison: I'm happy with your rewording14:24
Kinnisonpersia: it's too easy to miss the 'at least'14:24
*** mdunford has joined #baserock14:25
straycatKinnison, confused, doesn't it already support a range?14:25
persiaKinnison: A common fault in my writing: I am concise to a degree that is not always clear on first gloss.14:25
Kinnisonstraycat: there's a difference between what currently happens and what is defined to happen :)14:25
Kinnisonpersia: For things like this, expressing the desired meaning in multiple ways may be beneficial14:25
persiaYep.14:26
straycatKinnison, okay, i've only read the code14: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 :D14:38
franredflatmush, 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_laws14:43
flatmushyes, but it's more in-depth and it produces an optimal result which may not be the clearest way to think about things14:56
tiagogomes_pedroalvarez, do I need to re-send the pysendfile patch?15:04
pedroalvareztiagogomes_: yes, gerrit can't rebase that commit, sorry15:05
tiagogomes_pedroalvarez, no worries15:05
jjardontiagogomes_: just push to the same ref should work15:30
tiagogomes_jjardon, how so? I need to rebase the commit wich will create another ref15:30
jjardontiagogomes_: gerrit will take care of that15:31
tiagogomes_jjardon, ok15:33
* SotK wonders what happened to gerrit.baserock.org16:02
pedroalvarezI wonder the same. Currently looking at it, but I don't want to touch it.16:11
pedroalvarezssam2: can you please look at it too?16:11
pedroalvarezlooks like it's failing to connect to the database16:12
*** edcragg has quit IRC16:13
radiofreecan i run the cross-bootstrap command locally?16:14
radiofreeor do i have to push it somewhere16:14
radiofreemorph cross-bootstrap TARGET_ARCH baserock:baserock/definitions master systems/cross-bootstrap-system-TARGET_ARCH-generic.morph16:14
SotKradiofree: try `morph cross-bootstrap TARGET_ARCH . HEAD systems/cross-bootstrap-system-TARGET_ARCH-generic.morph`16:15
radiofreei think that worked, thanks!16:17
ssam2sorry, I must have stopped the database without restarting it again16:19
ssam2my fault, i'm a terrible admin16:19
gary_perkinsHi, 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
rdalei'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 too16:22
pedroalvarezgary_perkins: yes, `systemctl restart trove-setup`16:22
pedroalvarezgary_perkins: but i'd be interested in the failure logs16:23
gary_perkinspedroalvarez: Cheers! :)16:23
richard_mawrdale: it could be argument parsing, the glibc getopt behaves differently to musl's16:23
pedroalvarezgary_perkins: /var/log/ansible, can I see it?16:23
rdaleah ok thanks16:23
gary_perkinspedroalvarez: Sure...16:23
pedroalvarezgary_perkins: I think it doesn't have any private information16:24
gary_perkinspedroalvarez: there is no /var/log/ansible16:24
gary_perkinspedroalvarez: config.err? config.log?16:25
pedroalvarezoh16:26
pedroalvarez`systemctl status trove-setup` will give you some information about why you don't have /var/log/ansible16:26
gary_perkinspedroalvarez: okeedokee16:26
pedroalvarez:)16:26
gary_perkinsCondition: start condition failed at Fri 2015-03-20 16:17:11 UTC; 9min ago16:27
gary_perkins           ConditionPathExists=/etc/trove/trove.conf was not met16:27
gary_perkinsMar 20 16:17:11 ct-trove systemd[1]: Started Run trove-setup Ansible scripts.16:27
straycatruroh16:28
pedroalvarezright, you haven't configured it yet then16:28
gary_perkinspedroalvarez: I'll go back to the docs...16:29
pedroalvarezgary_perkins: here is an example (in the cloud-config script) http://wiki.baserock.org/guides/deploy-trove-to-openstack/16:29
pedroalvarezyou can do it manually now16:29
gary_perkinspedroalvarez: Thanks, I had started the instance with nova boot ..... --user-data cloud-config.sh so I thought it would have worked with that16:31
gary_perkinsI also had to specify the tenant network too, which wasn't in the docs16:31
pedroalvarezhm.. odd16:31
pedroalvarezyeah, that depends on the configuration of openstack16:32
gary_perkinsok, I'll just remove the instance and run it again16:32
pedroalvarezgary_perkins: I don't know why that has failed, but you can do it manually now. Is going to be the same thing16:32
gary_perkinsok16:32
gary_perkinscheers :)16:33
KinnisonHi, 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
Kinnisonstage2 gawk is failing to build on our arm64 systems16:37
persiassam2: 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
pedroalvarezit's trying to remove things from the read-only part of the staging area16:38
pedroalvarezKinnison: ^16:38
*** mdunford has quit IRC16:38
* persia has a long history of being a terrible admin, and only manages to avoid all sorts of exploits thorough lots of automation16:38
Kinnisonpedroalvarez: I can see that -- what I don't understand is *why* :)16:38
*** mdunford has joined #baserock16:39
pedroalvarezKinnison: I pointed out yesterday that this build is not using the steps definied in our stage2-gawk definition16:39
Kinnisonpedroalvarez: Interesting, I didn't see that :( Must have skipped it in my backlog reading16:40
richard_mawit appears to be running the configure and make commands we define in the morphology16:42
pedroalvarezerm.. ops16:43
richard_mawhrm, looks like DESTDIR is not making it that far into the install commands16:43
richard_mawsince the command in questoin is:16:44
kejiahupedroalvarez, richard_maw, this error happens while we trying to build a build system using netbooted cross-bootstrap system.16:44
richard_mawinstall-data-hook:16:44
richard_maw        for i in $(pkgextension_LTLIBRARIES) ; do \16:44
richard_maw                $(RM) $(DESTDIR)$(pkgextensiondir)/$$i ; \16:44
richard_maw        done16:44
KinnisonCould this be a change in the behaviour of Make ?16:45
richard_mawit 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 there16:45
Kinnisonmake  install-data-hook16:46
Kinnisonno sign of DESTDIR on that commandline16:46
Kinnisoninteresting16:47
richard_mawthat's not invoked directly by us16:47
richard_mawit's invoked by make itself16:47
Kinnisonaah16:47
* richard_maw suspects automake16:48
richard_mawinstall-data-am: install-man install-pkgextensionLTLIBRARIES16:48
richard_maw        @$(NORMAL_INSTALL)16:48
richard_maw        $(MAKE) $(AM_MAKEFLAGS) install-data-hook16:48
Kinnisonwell $(MAKE) should have passed DESTDIR= if it needed to16:49
richard_maw$(MAKE) is supposed to be magic and include all the jazz to import variables from the parent make16:49
Kinnisonyeah16:49
Kinnisonand destdir was clearly in the bit above16:49
richard_mawif you've got a failed build-tree around, I'd be interested to see what goes in the generated makefile16:49
Kinnisonkejiahu: do we have a failed build tree we can tar up and put somewhere for richard_maw ?16:50
richard_mawI'm wondering whether $(MAKE) is interpreted too early or something16:50
kejiahuKinnison, I think so16:50
*** CTtpollard has quit IRC16:58
kejiahurichard_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 IRC17:00
radiofreekejiahu: check /src/tmp/failed17:21
kejiahuradiofree, thanks, it is there17:24
SotKhm, I'm getting " ! [remote rejected] HEAD -> refs/for/master/baserock/adamcoldrick/partial-builds (no new changes)" when trying to push to Gerrit17:26
SotKany idea what that means?17:26
ssam2missing change-id?17:27
ssam2or duplicating an existing change-id ?17:27
ssam2no, duplicating an existing change-id just creates a new version of the change17:27
SotKthe commits have Change-Ids it seems17:27
SotKoh, I've done something weird, nevermind17:28
SotKhmm, maybe I haven't17:30
SotKmade it work17:32
*** Krin has quit IRC17:32
SotKI'd got in a strange tangle and had my branch merged into my local master and rebased on top of that or similar I think17:33
straycathrm, this warning flies past so won't be noticed17:39
*** jonathanmaw has quit IRC17:39
straycathrm, 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 build17:41
straycat*possibly17:41
*** zoli__ has quit IRC17:42
*** bashrc_ has quit IRC18:03
*** mdunford has quit IRC18:11
straycathrm, 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 atm18:14
straycatwould rather sort that before sending this series, so, to be continued...18:15
* straycat disappears18:15
*** mdizzle has quit IRC18:18
*** zoli__ has joined #baserock18:20
*** zoli__ has quit IRC18:26
*** rdale has quit IRC18:31
*** franred has quit IRC18:34
*** tiagogomes_ has quit IRC18:36
*** lachlanmackenzie has quit IRC18:49
jjardonstraycat: do we not?18:58
*** ssam2 has quit IRC19:00
*** gfinney has quit IRC19:16
*** wschaller has quit IRC19:18
*** gary_perkins has quit IRC19:22
*** zoli__ has joined #baserock20:05
*** zoli__ has joined #baserock20:29
*** zoli__ has quit IRC21:02
*** zoli__ has joined #baserock21:03
*** flatmush has quit IRC21:15
*** flatmush1 has joined #baserock21:16
*** pacon has joined #baserock21:22
*** zoli__ has quit IRC23:37
*** zoli__ has joined #baserock23:37

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