| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 00:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:16 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 00:25 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:26 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Quit: Leaving.] | 00:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 00:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:47 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 00:53 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:55 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 06:11 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 06:13 | |
| petefoth | /who | 07:08 |
|---|---|---|
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:31 | |
| fay is now known as Guest71412 | 07:31 | |
| Guest71412 is now known as fay_ | 07:56 | |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has joined #baserock | 08:13 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:24 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:29 | |
| petefoth | Interesting article on improving User Experience http://developerblog.redhat.com/2014/08/27/5-ux-tips-for-developers/ We should bear these in mind when we are looking at improving the exprience of using Baserock tools | 08:31 |
| tlsa | can somone review: https://admin.codethink.co.uk/pnopaste/?1812 ? | 09:14 |
| persia | If you put it somewhere I can see it :) | 09:15 |
| richard_maw | http://pastebin.com/LCBvv0TE | 09:17 |
| ssam2 | looks obviously correct | 09:18 |
| richard_maw | +1 to the second change, I forgot to update those variables, since I was only looking at mason.sh | 09:18 |
| franred | looks fine to me too | 09:18 |
| richard_maw | I'm surprised the beginning / is needed, as the mason.sh subprocess doesn't need an abolute path | 09:19 |
| *** rjek [~rjek@gateway/shell/pepperfish/x-xydhdwovyyidywvd] has joined #baserock | 09:22 | |
| *** cyndis_ [cyndis@lakka.kapsi.fi] has joined #baserock | 09:47 | |
| *** cyndis [cyndis@lakka.kapsi.fi] has quit [Ping timeout: 272 seconds] | 09:50 | |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [Ping timeout: 272 seconds] | 09:50 | |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 09:51 | |
| *** petefoth [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 09:51 | |
| *** petefoth [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 09:51 | |
| *** jjardon_ [sid723@gateway/web/irccloud.com/x-vwuruzkdnqjghoyx] has joined #baserock | 09:54 | |
| *** persia__ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 09:56 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-ommkyklbkmlbpqei] has quit [Ping timeout: 240 seconds] | 09:57 | |
| jjardon_ is now known as jjardon | 09:57 | |
| *** persia__ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 09:57 | |
| *** persia__ [quassel@ubuntu/member/persia] has joined #baserock | 09:57 | |
| *** persia [quassel@ubuntu/member/persia] has quit [Killed (sendak.freenode.net (Nickname regained by services))] | 09:57 | |
| persia__ is now known as persia | 09:57 | |
| *** inara [~inara@192.241.198.49] has joined #baserock | 10:12 | |
| *** inara [~inara@192.241.198.49] has quit [Excess Flood] | 10:12 | |
| *** inara [~inara@192.241.198.49] has joined #baserock | 10:14 | |
| *** petefoth_ [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:28 | |
| *** petefoth [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 244 seconds] | 10:33 | |
| franred | I can not build my branch after checkout master definitions and use latest morph --> https://admin.codethink.co.uk/pnopaste/?1814 | 10:41 |
| *** gallit [~gallit@ANice-651-1-447-85.w83-197.abo.wanadoo.fr] has joined #baserock | 10:42 | |
| liw-orc | franred, please use a public pastebin instead of the Codethink internal one, on #baserock | 10:42 |
| franred | liw-orc, yes, sorry. --- I mean, I followed the step in baserock.org and I've got the following --> http://fpaste.org/129560/40930897/ | 10:43 |
| liw-orc | use the path (relative to definitions.git) to the system morphology: prefix it with systems/ | 10:44 |
| franred | 2014-08-29 10:39:47 Collecting morphologies involved in building systems/gerrit-x86_64.morph from master --> this sounds bad - why doesn't collect the morphologies from my branch? | 10:44 |
| franred | liw-orc, I did - if you see the build command it does use it | 10:45 |
| franred | liw-orc, morph --verbose build systems/gerrit-x86_64.morph | 10:45 |
| liw-orc | I was looking at line 6 | 10:45 |
| franred | yes, sorry, I've replaced the webpage's steps and I've forgotten to add systems - but the error is not this | 10:46 |
| pedroalvarez | franred: I believe this is a morph bug. | 10:47 |
| pedroalvarez | franred: could be great if you can try with a different version of morph to see if it was introduced recently | 10:47 |
| pedroalvarez | menwhile, you can try to `morph checkout` your branch instead of master and then git checkout | 10:48 |
| pedroalvarez | s/menwhile/meanwhile/ | 10:48 |
| franred | pedroalvarez, which version do you suggest me? | 10:48 |
| pedroalvarez | franred: please, paste here your current version `morph --version` | 10:49 |
| franred | pedroalvarez, baserock-14.26-104-g9c00114 | 10:49 |
| *** bjdooks_ [~ben@trinity.fluff.org] has joined #baserock | 10:50 | |
| *** jjardon_ [sid723@gateway/web/irccloud.com/x-ajacjnyyjuarwwad] has joined #baserock | 10:51 | |
| franred | but this is not also my version of morph because I've followed the instructions for using the latest morph | 10:52 |
| *** vmesons [~quassel@128.224.252.2] has joined #baserock | 10:52 | |
| franred | so my morph should be pointed to: master - 9c0011417081326ebb72d9ed02fcbbc456946dc4 | 10:53 |
| pedroalvarez | that's better | 10:53 |
| pedroalvarez | franred: can you go to: 4cce5cfb5ec6b092bf6411cb2cd375aa40898882 ? | 10:54 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 10:55 | |
| *** bjdooks [~ben@trinity.fluff.org] has quit [Ping timeout: 240 seconds] | 10:55 | |
| *** tlsa [uE4xqvWPxI@gateway/shell/pepperfish/x-snbyfqmeobckntpr] has quit [Ping timeout: 240 seconds] | 10:55 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-vwuruzkdnqjghoyx] has quit [Ping timeout: 240 seconds] | 10:55 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 240 seconds] | 10:55 | |
| franred | pedroalvarez, it's still failing due the same error | 10:56 |
| *** tlsa [GAJ2RkPGHr@gateway/shell/pepperfish/x-draikeasjskuayhm] has joined #baserock | 10:56 | |
| franred | I think that key question here is why morph try to collect my morphologies from master when Im using my branch | 10:56 |
| pedroalvarez | indeed | 10:56 |
| franred | and yes, my morphology is not in master | 10:57 |
| jjardon_ is now known as jjardon | 10:58 | |
| ssam2 | franred: did you check out master and then check out something else using `git` ? | 11:01 |
| franred | ssam2, yes | 11:01 |
| ssam2 | right, morph will continue to build whatever branch you originally checked out | 11:01 |
| ssam2 | it stores that info in the top of the system branch directory in a hidden dir called .morph-system-branch | 11:02 |
| ssam2 | richard_maw wrote a patch which changes that, but we decided against merging it for now | 11:02 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:02 | |
| ssam2 | but maybe we should, if the current behaviour continues to confuse ... | 11:02 |
| pedroalvarez | ssam2: I've been doing things like that always | 11:02 |
| franred | ssam2, also I've done this woth baserock-14.29 as a checkout and it works fine | 11:03 |
| franred | I've done right now | 11:03 |
| pedroalvarez | and I've seen it | 11:03 |
| ssam2 | what `morph build` will build is whatever is specified in .morph-system-branch/config | 11:04 |
| pedroalvarez | so doing: morph checkout b:b/definitions baserock-14.29; [...] git checkout branch-name; morph build system-on-my-branch; worked | 11:04 |
| pedroalvarez | franred: please compare them | 11:05 |
| ssam2 | really ? I just did 'git checkout baserock/sam/chef' in a checkout of master/baserock/baserock/definitions | 11:05 |
| ssam2 | then morph build, and saw: Collecting morphologies involved in building systems/devel-system-x86_64-generic.morph from master | 11:05 |
| franred | the difference between both things are that baserock-14.29 is a tag and master is a branch - could be that what is causing the error? | 11:05 |
| pedroalvarez | ssam2: using the tag you can see: Collecting morphologies involved in building systems/foo from TAG | 11:06 |
| pedroalvarez | but it build | 11:06 |
| pedroalvarez | builds* | 11:06 |
| ssam2 | oh, I didn't check more than the message. I assumed it was building master, as it said .. | 11:06 |
| ssam2 | pedroalvarez: are there uncommited changes in your repo ? | 11:06 |
| ssam2 | in this case, morph will build whatever is in your working tree on disk | 11:06 |
| ssam2 | if there's no uncommited changes, it'll build whatever ref was checked out with 'morph checkout' or 'morph branch' | 11:07 |
| * ssam2 starts to think more and more that we should merge the patch to always build whatever is checked out :) | 11:07 | |
| pedroalvarez | this is very confusing | 11:07 |
| pedroalvarez | indeed | 11:07 |
| pedroalvarez | so you can modify a file, and then the morph is going to build, and then commit the change and then crash! | 11:08 |
| pedroalvarez | heheh | 11:08 |
| ssam2 | franred maybe try out baserock/richardmaw/always-use-current-branch and see if it works more how you want it to | 11:09 |
| pedroalvarez | that did't work | 11:14 |
| pedroalvarez | after remove the uncommited changes and removed the "upstream" folder, it failed in the workspace checked out from a tag | 11:15 |
| pedroalvarez | ssam2: so yeah, you were right | 11:15 |
| franred | +1 to add always-use-current-branch --> and update the error message telling the user that maybe is trying to build some local branch which does not match with the morph checkout branch? | 11:17 |
| franred | ssam2, pedroalvarez, thanks for your help | 11:18 |
| * persia is confused by backscroll | 11:20 | |
| persia | For me, morph build always builds whichever branch of definitions I have checked out, regardless of morph config. | 11:20 |
| franred | although that morph checkout + morph build only that branch is against git processes | 11:20 |
| persia | Did this change recently in a way that causes me to have to attend to some other configuration file? | 11:20 |
| *** benbrown2 [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 11:21 | |
| franred | persia, it builds whatever branch in definitions you "morph checkout" if you don't have uncommited changes - it builds whatever is in your definitions if it has uncommited changes | 11:21 |
| *** benbrown1 [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 255 seconds] | 11:22 | |
| * persia has never used `morph checkout` and adds that to the list of dangerous commands to avoid | 11:22 | |
| pedroalvarez | I'd like the workspace just to be a `git clone` of definitions.git | 11:23 |
| franred | persia, you have to have used because it is the step after create the workspace | 11:23 |
| persia | I also | 11:23 |
| persia | franred: I used morph branch twice. | 11:23 |
| persia | The second time was an experiement, and I'm still trying to recover | 11:23 |
| franred | I've never used morph branch | 11:23 |
| persia | If you only ever run it once, between morph init and actually doing work, it appears to be safe | 11:24 |
| franred | I've used morph checkout and then I branch my definitions | 11:24 |
| persia | pedroalvarez: So, my understanding is that the blockers for this are 1) that morph complains if it's not in a workspace, and 2) that morph doesn't know where to find definitions when you run morph build if you don't have a workspace (as it hides the path to definitions in a config file) | 11:25 |
| persia | So in order to get to that point, we'd have to either a) declare that morph can only be run in definitions, or b) pass morph the path to definitions for each command. | 11:26 |
| persia | a) breaks a lot of workflows involving editing something outside definitions and generating a system, although folk could be encouraged to use two terminal windows. | 11:26 |
| persia | b) is just lots of extra typing, which everyone wants to avoid | 11:27 |
| *** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:28 | |
| pedroalvarez | If we are going to rid of `morph edit` then we don't care about a) | 11:28 |
| persia | What? | 11:29 |
| *** JPohlman1 [~jannis@m65s13.vlinux.de] has joined #baserock | 11:29 | |
| *** robtaylo1 [~robtaylor@floopily.codethink.co.uk] has joined #baserock | 11:29 | |
| persia | So, I'm working on my project in my git repo, and I change it, and commit my change, and want to build a system with that change. | 11:29 |
| pedroalvarez | breaking workflows involvinf editing something outside definitions | 11:29 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 11:30 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 255 seconds] | 11:30 | |
| *** robtaylor [~robtaylor@floopily.codethink.co.uk] has quit [Ping timeout: 255 seconds] | 11:30 | |
| persia | I want to have a command that updates definitions to my current HEAD, and another than builds the system. | 11:30 |
| persia | I can put up with two terminals for this, but it's annoying, as I probably want the same definitions (presumably my chunk ref is a branch in such a situation) | 11:31 |
| pedroalvarez | a lot of things to think about the workflow | 11:32 |
| persia | Lots of things people want to do with the tools :) | 11:33 |
| pedroalvarez | I was just wondering if something like: "git clone definitions.git; cd definitions; git operations (including checkout -b or branch); morph build | 11:33 |
| pedroalvarez | "! | 11:33 |
| persia | Aside from morph whining about workspaces, that should work today. | 11:34 |
| persia | (well, well told not to whine, morph also has to be told to look in PWD for definiitions) | 11:34 |
| persia | s/well /when / | 11:34 |
| jonathanmaw_ is now known as jonathanmaw | 11:42 | |
| paulsherwood | i *really* wish we didn't need to specify relative paths | 12:05 |
| persia | Didn't we previously agree on locally-unique nomenclature? | 12:05 |
| paulsherwood | imo would be better just to require that each morph be uniquely named | 12:05 |
| paulsherwood | i vaguely remember the discussion, but i assume that the implementation reflects the outcome? | 12:06 |
| persia | But, didn't we already require that, for morph edit to work? | 12:06 |
| persia | I don't use morph edit, but I did like this requirement. | 12:06 |
| paulsherwood | to be clear, i agree with tidying up to have systems/ strata/ chunks/ - i just wish morph could handle things without me needing to specify the paths | 12:08 |
| paulsherwood | (either on command line, or in cluster morph files, for exmple) | 12:08 |
| pedroalvarez | paulsherwood: so morph knows where to look for them? | 12:08 |
| persia | Using paths is faster, as otherwise morph has to understand everything. | 12:08 |
| paulsherwood | istm it has to understand everything anyway | 12:09 |
| persia | That morph does try to understand everything anyway makes this annoying, but I think morph shouldn't bother, making all morph commands faster. | 12:09 |
| persia | (really, why do I care about malformed YAML in some cluster morphology unrelated to my actual work) | 12:09 |
| paulsherwood | agreed | 12:09 |
| persia | But if morph doesn't try to understand, you'll get stuck with relative paths forever. We can't have it both ways. Are you happy enough with the potential to make it faster to put up with relative paths? | 12:11 |
| persia | (actually, I'd like to be able to specify either relative or absolute paths, but that's a separate thing) | 12:11 |
| paulsherwood | that would depend on the speed :) | 12:12 |
| richard_maw | loading yaml is not quick | 12:12 |
| *** ratmice__ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 245 seconds] | 12:12 | |
| persia | I haven't profiled it, but suspect that most of the delay between running morph and it appearing to do anything is involved in loading YAML. | 12:13 |
| *** ratmice___ [bosshog@nightfall.forlorn.net] has joined #baserock | 12:13 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 12:13 | |
| richard_maw | git operations are slower, but a comparably distant third place is starting the python interpreter itself | 12:13 |
| persia | So, we need less YAML parsing and fewer git operations. | 12:15 |
| persia | But I blame YAML more, because morph seems fairly chatty when it's doing git operations, so I don't feel ignored. | 12:16 |
| *** ratmice___ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 246 seconds] | 12:18 | |
| *** ratmice___ [bosshog@nightfall.forlorn.net] has joined #baserock | 12:22 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:26 | |
| tlsa | i think I prefer relative paths | 12:36 |
| tlsa | if you don't do the directory name, you can't tab-complete the system/cluster morphology name | 12:37 |
| tlsa | and without including the directory you can't have system/foo.morh and cluster/foo.morph | 12:39 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 12:54 | |
| persia | tlsa: It's probably poor practice to name systems and clusters identically, because this causes confusion to the developers, although in some cases the names are similar. | 13:32 |
| persia | For example, if I have a system "development", and I want to typically deploy to libvirt with no initramfs, I probably want to name my cluster "devel-libvirt" or similar. | 13:33 |
| persia | In practice, except when developing for very resource-constrained environments, it's probably better to use an initramfs, so I wouldn't have a one-to-one mapping between systems and clusters anyway. | 13:33 |
| tlsa | true | 13:37 |
| * petefoth_ notes that OpenStack are talking about using Task Lists in Storyboard to implement a Kanban view https://wiki.openstack.org/wiki/StoryBoard/Task_Lists#Visual_implementation | 13:39 | |
| paulsherwood | petefoth_: that is interesting | 13:48 |
| petefoth_ | paulsherwood: agreed. I'm not sure whether they went any further with it - I'll see if I can find out | 13:49 |
| persia | They have not yet | 13:49 |
| paulsherwood | i'm discussing this same topic with other colleagues soon. the linked cantas project is also interesting :) | 13:51 |
| persia | https://github.com/xiaods/nodejs-cantas ? | 13:52 |
| paulsherwood | https://github.com/onepiecejs/nodejs-cantas | 13:53 |
| paulsherwood | same thing | 13:54 |
| * persia glares at whoever considered the github delivery model sane | 13:55 | |
| persia | So, I've been considering non-bootable systems and upgrades, and realise I don't know how they are intended to interact. | 13:56 |
| persia | Does anyone happen to know much about this area? For example, if I have a development chroot, how am I to upgrade it? | 13:56 |
| tlsa | I don't think you can upgrade a chroot | 13:57 |
| persia | That's annoying. | 13:57 |
| persia | The use case in question is a distributed development team that wants to use chroots, and wants to be able to update some components once in a while without needing every developer to restart the preparation of their working area from scratch. | 13:58 |
| paulsherwood | by non-bootable systems, are you also meaning non-system outputs from baserock? eg a stratum? | 13:58 |
| persia | No. I don't think we have semantics for what "upgrade" would mean for anything other than a "system", because the set of files is non-deterministic. | 13:59 |
| *** gallit [~gallit@ANice-651-1-447-85.w83-197.abo.wanadoo.fr] has quit [Quit: Leaving] | 14:00 | |
| persia | Essentially, to do that we'd have to have some way to regenerate the effects of deployment on the client, and since we're running the same operation many times in parallel in differing environments, it is hard to be confident we always get the same result. | 14:00 |
| paulsherwood | nod | 14:03 |
| ssam2 | persia: you add a new chroot using `manage-baserock`, and /src is shared | 14:06 |
| ssam2 | persia: the missing piece is content in /etc, /home, /root | 14:06 |
| ssam2 | currently every time I upgrade my chroot I have to rewrite morph.conf, my git config, etc. | 14:06 |
| persia | ssam2: Do we have a trivially quick way to do this? | 14:06 |
| persia | Oh, ah, yeah, that's likely to be frustrating. | 14:06 |
| ssam2 | we could make it more like the Btrfs upgradable system layout we use by making /home, /root, etc. shared directories as well | 14:07 |
| ssam2 | we could even get manage-baserock to run baserock-system-config-sync with a bit of work, which would at least be consistent | 14:07 |
| ssam2 | although baserock-system-config-sync is not the smartest tool on Earth | 14:08 |
| persia | Hmm. That might be interesting. | 14:08 |
| persia | And I presume we could have a tool that kept track of one's chroots, and allowed removal of ones that were no longer needed. | 14:09 |
| JPohlman1 is now known as JPohlmann | 14:09 | |
| *** JPohlmann [~jannis@m65s13.vlinux.de] has quit [Changing host] | 14:09 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 14:09 | |
| ssam2 | persia: have have such a tool already, named `manage-baserock`, living in git://git.baserock.org/baserock/baserock/baserock-chroot | 14:14 |
| ssam2 | *have have have | 14:14 |
| richard_maw | s/(have )+/have / | 14:14 |
| persia | Ah, lovely. So most of the pieces are there, but we have have have have have not yet polished the interface. | 14:15 |
| paulsherwood | ok, i can't resist... | 14:15 |
| paulsherwood | who can punctuate this... | 14:15 |
| persia | Anyone who has read Flowers for Algernon, I presume | 14:16 |
| paulsherwood | tom where bill had had had had had had had had had had pleased the examiner better | 14:16 |
| ssam2 | Tom, where Bill had had 'had', had had 'had had'. 'Had had' had pleased the examiner better | 14:19 |
| pedroalvarez | ??? | 14:20 |
| ssam2 | Buffalo buffalo buffalo Buffulo buffalo | 14:20 |
| pedroalvarez | :) | 14:20 |
| richard_maw | and then there's the classic www.youtube.com/watch?v=EIyixC9NsLI | 14:20 |
| persia | ssam2: You can do that one with 8, much as one can use "had" instead of "pleased" in the had series to reach 11. | 14:21 |
| paulsherwood | ssam2: you get a gold star :) | 14:21 |
| persia | Looking through my IRC logs, it appears that the the Task_List page petefoth linked matches current thinking in the area, and all the prior models have been deprecated (as they can be expressed in terms of task lists and tags). | 14:27 |
| paulsherwood | cool | 14:35 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Quit: Leaving.] | 14:45 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 15:01 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:01 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Ping timeout: 264 seconds] | 15:05 | |
| pedroalvarez | richard_maw: may I ask you why now ARTIFACT_CACHE_SERVER is mandatory in mason.configure? | 15:25 |
| pedroalvarez | I mean, shouldn't be optional defaulting to TROVE_HOST? | 15:28 |
| persia | I think it can't ever be right for the values to differ. | 15:37 |
| persia | Because generally speaking one doesn't want to upload test artifacts to a central location until after the test, but one wants to use a central location for git, to avoid latency. | 15:37 |
| tlsa | pedroalvarez: ARTIFACT_CACHE_SERVER is for the mason's local trove | 15:40 |
| tlsa | iirc | 15:41 |
| pedroalvarez | right, just becasue now with mason you can use a Trove for the sources and another one as artifact-cache-server | 15:42 |
| tlsa | yeah | 15:42 |
| pedroalvarez | I'm pretty confused with all the variables :? | 15:43 |
| tlsa | so your artifact cache server is my-mason-trove, and your sources from from git.baserock.org, for example | 15:43 |
| pedroalvarez | tlsa: right | 15:43 |
| pedroalvarez | so what should I put in MASON_UPSTREAM_TROVE_ADDRES | 15:43 |
| tlsa | is it used? | 15:44 |
| * pedroalvarez cries | 15:45 | |
| pedroalvarez | [mason.configure]Not configuring as Mason, some options not defined | 15:45 |
| pedroalvarez | I see, is not used anymore? | 15:45 |
| tlsa | I don't know where you got MASON_UPSTREAM_TROVE_ADDRES from | 15:46 |
| tlsa | it doesn't show in a grep of definitions.git | 15:47 |
| pedroalvarez | I see dead code <fx:the-sixth-sense-boy> | 15:47 |
| pedroalvarez | tlsa: I'm not crazy: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=f45695be540c58314ab30847318ab3cb9b861524 | 15:48 |
| pedroalvarez | It was there when I started | 15:48 |
| tlsa | heh | 15:49 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:37 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 16:48 | |
| richard_maw | ssam2: I tried out your logging patch, I was impressed | 17:10 |
| richard_maw | as my mail which was stuck in my inbox when I wrote that last IRC message will attest to | 17:10 |
| richard_maw | I also have a patch to make it use asyncore, rather than the non-blocking read then sleep loop | 17:11 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 17:17 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 17:26 | |
| ssam2 | richard_maw: me too :) | 17:27 |
| ssam2 | I couldn't resist | 17:27 |
| ssam2 | although looking at yours, seems I used asyncore wrong a bit | 17:27 |
| ssam2 | still, the important thing is we'll soon be able to debug failed deployments, which is nice ! | 17:28 |
| ssam2 | however, having stayed an extra hour to learn more about sockets, now I'm off for the weekend | 17:29 |
| *** ssam2 [~ssam2@host86-159-251-35.range86-159.btcentralplus.com] has quit [Quit: Leaving] | 17:29 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 17:32 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 18:24 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:27 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:28 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 18:36 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 18:39 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 18:43 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:47 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 18:59 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:03 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 19:04 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:08 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:09 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 19:21 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:25 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:30 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 19:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 19:35 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:35 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:46 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 19:53 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:57 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 20:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 20:02 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:07 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:08 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 20:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 20:12 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:18 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:19 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 20:24 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:24 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 20:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 20:31 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 20:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 20:53 | |
| * paulsherwood wonders how morph deploy can fail with "ERROR: Command failed: git ls-remote git://git.baserock.org/delta/linux | 21:07 | |
| paulsherwood | fatal: read error: Connection reset by peer" | 21:07 |
| paulsherwood | i'm running deploy locally... why is it asking gbo for anything? | 21:07 |
| paulsherwood | http://fpaste.org/129700/93473451/ | 21:22 |
| richard_maw | paulsherwood: the check for if you have pushed changes currently does a ls-remote; in hindsight this is too problematic, so it should check its status based on refs/remotes/origin | 21:26 |
| paulsherwood | richard_maw: tvm. any ideas how i can hack it to continue? | 21:28 |
| paulsherwood | never mind, it's late... | 21:29 |
| richard_maw | yeah, I can have a quick look and see if there's an easy fix, but I won't have time to implement it | 21:29 |
| paulsherwood | i wonder why it checks for pushed changes at all? i'm deploying, not building | 21:30 |
| richard_maw | deploy also uses temporary build branches, since you may have built your system on one | 21:31 |
| richard_maw | I guess a quick win would be to make it not check whether everything has been pushed if it doesn't care about the answer | 21:32 |
| paulsherwood | +1 :) | 21:32 |
| paulsherwood | i guess there's a separate problem causing g.b.o to hangup at me at this point - i've never seen this on previous deploys | 21:33 |
| richard_maw | I think all the people doing ls-remote on it is gumming up its git-daemon process | 21:34 |
| richard_maw | I think it may work better for the moment if you switch to http:// URLs | 21:34 |
| richard_maw | but it's too late for me to describe how | 21:35 |
| paulsherwood | ok i'll send this conversation to the list as an issue... | 21:36 |
| richard_maw | thanks | 21:36 |
| paulsherwood | thank you | 21:36 |
| richard_maw | I've spend my evening playing with asyncore, working out how to shoe-horn subprocess output processing into its socket-based event model | 21:37 |
| richard_maw | successfully! | 21:37 |
| paulsherwood | ooh, cool! :) | 21:39 |
| richard_maw | the python 3.4 asyncio module is much cooler, as it's a lot more flexible, and gets as close as possible to lazy evaluation in python by letting you yield Futures and Coroutines | 21:43 |
| paulsherwood | at times i really hate python :) | 21:48 |
| richard_maw | my problem is that I've been using python long enough to get bored and look for the weird tools available in the language; liw-orc has been using python long enough that he's already been through that, and knows which python things are the best compromise between speed, size and readability | 21:55 |
| paulsherwood | my problem is that i can't understand the codebase | 21:57 |
| paulsherwood | everything seems very complicated | 21:57 |
| paulsherwood | but then, my own code on other projects no doubt would provoke similar reactions | 21:58 |
| paulsherwood | nite | 21:58 |
| richard_maw | 'nite | 21:58 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:07 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 22:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 22:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 22:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 22:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:42 | |
| paulsherwood | looks to me like g.b.o's git service is broken somehow... all builds failing unable to ls-remote. never seen this since gbo went live. can it be kicked/restarted? | 22:51 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 23:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 23:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 23:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 23:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!