IRC logs for #baserock for Friday, 2014-08-29

*** flatmush [] has quit [Ping timeout: 245 seconds]00:06
*** flatmush [] has joined #baserock00:16
*** flatmush [] has quit [Ping timeout: 250 seconds]00:25
*** flatmush [] has joined #baserock00:26
*** thecorconian [] has quit [Quit: Leaving.]00:33
*** flatmush [] has quit [Ping timeout: 260 seconds]00:34
*** flatmush [] has joined #baserock00:47
*** flatmush [] has quit [Ping timeout: 260 seconds]00:53
*** flatmush [] has joined #baserock00:55
*** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer]06:11
*** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock06:13
petefoth /who07:08
*** fay [] has joined #baserock07:31
fay is now known as Guest7141207:31
Guest71412 is now known as fay_07:56
*** ssam2 [] has joined #baserock08:13
*** jonathanmaw [] has joined #baserock08:24
*** franred [] has joined #baserock08:29
petefothInteresting article on improving User Experience We should bear these in mind when we are looking at improving the exprience of using Baserock tools08:31
tlsacan somone review: ?09:14
persiaIf you put it somewhere I can see it :)09:15
ssam2looks obviously correct09:18
richard_maw+1 to the second change, I forgot to update those variables, since I was only looking at mason.sh09:18
franredlooks fine to me too09:18
richard_mawI'm surprised the beginning / is needed, as the subprocess doesn't need an abolute path09:19
*** rjek [~rjek@gateway/shell/pepperfish/x-xydhdwovyyidywvd] has joined #baserock09:22
*** cyndis_ [] has joined #baserock09:47
*** cyndis [] has quit [Ping timeout: 272 seconds]09:50
*** straycat [] has quit [Ping timeout: 272 seconds]09:50
*** straycat [] has joined #baserock09:51
*** petefoth [] has quit [Ping timeout: 272 seconds]09:51
*** petefoth [] has joined #baserock09:51
*** jjardon_ [sid723@gateway/web/] has joined #baserock09:54
*** persia__ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock09:56
*** jjardon [sid723@gateway/web/] has quit [Ping timeout: 240 seconds]09:57
jjardon_ is now known as jjardon09:57
*** persia__ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]09:57
*** persia__ [quassel@ubuntu/member/persia] has joined #baserock09:57
*** persia [quassel@ubuntu/member/persia] has quit [Killed ( (Nickname regained by services))]09:57
persia__ is now known as persia09:57
*** inara [~inara@] has joined #baserock10:12
*** inara [~inara@] has quit [Excess Flood]10:12
*** inara [~inara@] has joined #baserock10:14
*** petefoth_ [] has joined #baserock10:28
*** petefoth [] has quit [Ping timeout: 244 seconds]10:33
franredI can not build my branch after checkout master definitions and use latest morph -->
*** gallit [] has joined #baserock10:42
liw-orcfranred, please use a public pastebin instead of the Codethink internal one, on #baserock10:42
franredliw-orc, yes, sorry. --- I mean, I followed the step in and I've got the following -->
liw-orcuse the path (relative to definitions.git) to the system morphology: prefix it with systems/10:44
franred2014-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
franredliw-orc, I did - if you see the build command it does use it10:45
franredliw-orc, morph --verbose build systems/gerrit-x86_64.morph10:45
liw-orcI was looking at line 610:45
franredyes, sorry, I've replaced the webpage's steps and I've forgotten to add systems - but the error is not this10:46
pedroalvarezfranred: I believe this is a morph bug.10:47
pedroalvarezfranred: could be great if you can try with a different version of morph to see if it was introduced recently10:47
pedroalvarezmenwhile, you can try to `morph checkout` your branch instead of master and then git checkout10:48
franredpedroalvarez, which version do you suggest me?10:48
pedroalvarezfranred: please, paste here your current version `morph --version`10:49
franredpedroalvarez, baserock-14.26-104-g9c0011410:49
*** bjdooks_ [] has joined #baserock10:50
*** jjardon_ [sid723@gateway/web/] has joined #baserock10:51
franredbut this is not also my version of morph because I've followed the instructions for using the latest morph10:52
*** vmesons [~quassel@] has joined #baserock10:52
franredso my morph should be pointed to: master - 9c0011417081326ebb72d9ed02fcbbc456946dc410:53
pedroalvarezthat's better10:53
pedroalvarezfranred: can you go to: 4cce5cfb5ec6b092bf6411cb2cd375aa40898882 ?10:54
*** flatmush [] has quit [Ping timeout: 240 seconds]10:55
*** bjdooks [] 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/] has quit [Ping timeout: 240 seconds]10:55
*** vmeson [~quassel@] has quit [Ping timeout: 240 seconds]10:55
franredpedroalvarez, it's still failing due the same error10:56
*** tlsa [GAJ2RkPGHr@gateway/shell/pepperfish/x-draikeasjskuayhm] has joined #baserock10:56
franredI think that key question here is why morph try to collect my morphologies from master when Im using my branch10:56
franredand yes, my morphology is not in master10:57
jjardon_ is now known as jjardon10:58
ssam2franred: did you check out master and then check out something else using `git` ?11:01
franredssam2, yes11:01
ssam2right, morph will continue to build whatever branch you originally checked out11:01
ssam2it stores that info in the top of the system branch directory in a hidden dir called .morph-system-branch11:02
ssam2richard_maw wrote a patch which changes that, but we decided against merging it for now11:02
*** flatmush [] has joined #baserock11:02
ssam2but maybe we should, if the current behaviour continues to confuse ...11:02
pedroalvarezssam2: I've been doing things like that always11:02
franredssam2, also I've done this woth baserock-14.29 as a checkout and it works fine11:03
franredI've done right now11:03
pedroalvarezand I've seen it11:03
ssam2what `morph build` will build is whatever is specified in .morph-system-branch/config11:04
pedroalvarezso doing: morph checkout b:b/definitions baserock-14.29; [...] git checkout branch-name; morph build system-on-my-branch; worked11:04
pedroalvarezfranred: please compare them11:05
ssam2really ? I just did 'git checkout baserock/sam/chef' in a checkout of master/baserock/baserock/definitions11:05
ssam2then morph build, and saw: Collecting morphologies involved in building systems/devel-system-x86_64-generic.morph from master11:05
franredthe 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
pedroalvarezssam2: using the tag you can see:  Collecting morphologies involved in building systems/foo from  TAG11:06
pedroalvarezbut it build11:06
ssam2oh, I didn't check more than the message. I assumed it was building master, as it said ..11:06
ssam2pedroalvarez: are there uncommited changes in your repo ?11:06
ssam2in this case, morph will build whatever is in your working tree on disk11:06
ssam2if 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
pedroalvarezthis is very confusing11:07
pedroalvarezso you can modify a file, and then the morph is going to build, and then commit the change and then crash!11:08
ssam2franred maybe try out baserock/richardmaw/always-use-current-branch and see if it works more how you want it to11:09
pedroalvarezthat did't work11:14
pedroalvarezafter remove the uncommited changes and removed the "upstream" folder, it failed in the workspace checked out from a tag11:15
pedroalvarezssam2: so yeah, you were right11: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
franredssam2, pedroalvarez, thanks for your help11:18
* persia is confused by backscroll11:20
persiaFor me, morph build always builds whichever branch of definitions I have checked out, regardless of morph config.11:20
franredalthough that morph checkout + morph build only that branch is against git processes11:20
persiaDid this change recently in a way that causes me to have to attend to some other configuration file?11:20
*** benbrown2 [] has joined #baserock11:21
franredpersia, 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 changes11:21
*** benbrown1 [] has quit [Ping timeout: 255 seconds]11:22
* persia has never used `morph checkout` and adds that to the list of dangerous commands to avoid11:22
pedroalvarezI'd like the workspace just to be a `git clone` of definitions.git11:23
franredpersia, you have to have used because it is the step after create the workspace11:23
persiaI also11:23
persiafranred: I used morph branch twice.11:23
persiaThe second time was an experiement, and I'm still trying to recover11:23
franredI've never used morph branch11:23
persiaIf you only ever run it once, between morph init and actually doing work, it appears to be safe11:24
franredI've used morph checkout and then I branch my definitions11:24
persiapedroalvarez: 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
persiaSo 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
persiaa) 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
persiab) is just lots of extra typing, which everyone wants to avoid11:27
*** jonathanmaw_ [] has joined #baserock11:28
pedroalvarezIf we are going to rid of `morph edit` then we don't care about a)11:28
*** JPohlman1 [] has joined #baserock11:29
*** robtaylo1 [] has joined #baserock11:29
persiaSo, 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
pedroalvarezbreaking workflows involvinf editing something outside  definitions11:29
*** jonathanmaw [] has quit [Ping timeout: 255 seconds]11:30
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 255 seconds]11:30
*** robtaylor [] has quit [Ping timeout: 255 seconds]11:30
persiaI want to have a command that updates definitions to my current HEAD, and another than builds the system.11:30
persiaI 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
pedroalvareza lot of things to think about the workflow11:32
persiaLots of things people want to do with the tools :)11:33
pedroalvarezI was just wondering if something like: "git clone definitions.git; cd definitions; git operations (including checkout -b or branch); morph build11:33
persiaAside 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
persias/well /when /11:34
jonathanmaw_ is now known as jonathanmaw11:42
paulsherwoodi *really* wish we didn't need to specify relative paths12:05
persiaDidn't we previously agree on locally-unique nomenclature?12:05
paulsherwoodimo would be better just to require that each morph be uniquely named12:05
paulsherwoodi vaguely remember the discussion, but i assume that the implementation reflects the outcome?12:06
persiaBut, didn't we already require that, for morph edit to work?12:06
persiaI don't use morph edit, but I did like this requirement.12:06
paulsherwoodto 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 paths12:08
paulsherwood(either on command line, or in cluster morph files, for exmple)12:08
pedroalvarezpaulsherwood: so morph knows where to look for them?12:08
persiaUsing paths is faster, as otherwise morph has to understand everything.12:08
paulsherwoodistm it has to understand everything anyway12:09
persiaThat 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
persiaBut 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
paulsherwoodthat would depend on the speed :)12:12
richard_mawloading yaml is not quick12:12
*** ratmice__ [] has quit [Ping timeout: 245 seconds]12:12
persiaI 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___ [] has joined #baserock12:13
*** fay_ [] has quit [Ping timeout: 246 seconds]12:13
richard_mawgit operations are slower, but a comparably distant third place is starting the python interpreter itself12:13
persiaSo, we need less YAML parsing and fewer git operations.12:15
persiaBut I blame YAML more, because morph seems fairly chatty when it's doing git operations, so I don't feel ignored.12:16
*** ratmice___ [] has quit [Ping timeout: 246 seconds]12:18
*** ratmice___ [] has joined #baserock12:22
*** fay_ [] has joined #baserock12:26
tlsai think I prefer relative paths12:36
tlsaif you don't do the directory name, you can't tab-complete the system/cluster morphology name12:37
tlsaand without including the directory you can't have system/foo.morh and cluster/foo.morph12:39
*** thecorconian [] has joined #baserock12:54
persiatlsa: 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
persiaFor 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
persiaIn 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
* petefoth_ notes that OpenStack are talking about using Task Lists in Storyboard to implement a Kanban view
paulsherwoodpetefoth_: that is interesting13:48
petefoth_paulsherwood: agreed. I'm not sure whether they went any further with it - I'll see if I can find out13:49
persiaThey have not yet13:49
paulsherwoodi'm discussing this same topic with other colleagues soon. the linked cantas project is also interesting :)13:51
persia ?13:52
paulsherwoodsame thing13:54
* persia glares at whoever considered the github delivery model sane13:55
persiaSo, I've been considering non-bootable systems and upgrades, and realise I don't know how they are intended to interact.13:56
persiaDoes anyone happen to know much about this area?  For example, if I have a development chroot, how am I to upgrade it?13:56
tlsaI don't think you can upgrade a chroot13:57
persiaThat's annoying.13:57
persiaThe 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
paulsherwoodby non-bootable systems, are you also  meaning non-system outputs from baserock? eg a stratum?13:58
persiaNo.  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 [] has quit [Quit: Leaving]14:00
persiaEssentially, 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
ssam2persia: you add a new chroot using `manage-baserock`, and /src is shared14:06
ssam2persia: the missing piece is content in /etc, /home, /root14:06
ssam2currently every time I upgrade my chroot I have to rewrite morph.conf, my git config, etc.14:06
persiassam2: Do we have a trivially quick way to do this?14:06
persiaOh, ah, yeah, that's likely to be frustrating.14:06
ssam2we could make it more like the Btrfs upgradable system layout we use by making /home, /root, etc. shared directories as well14:07
ssam2we could even get manage-baserock to run baserock-system-config-sync with a bit of work, which would at least be consistent14:07
ssam2although  baserock-system-config-sync is not the smartest tool on Earth14:08
persiaHmm.  That might be interesting.14:08
persiaAnd 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 JPohlmann14:09
*** JPohlmann [] has quit [Changing host]14:09
*** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock14:09
ssam2persia: have have such a tool already, named `manage-baserock`, living in git://
ssam2*have have have14:14
richard_maws/(have )+/have /14:14
persiaAh, lovely.  So most of the pieces are there, but we have have have have have not yet polished the interface.14:15
paulsherwoodok, i can't resist...14:15
paulsherwoodwho can punctuate this...14:15
persiaAnyone who has read Flowers for Algernon, I presume14:16
paulsherwoodtom where bill had had had had had had had had had had pleased the examiner better14:16
ssam2Tom, where Bill had had 'had', had had 'had had'. 'Had had' had pleased the examiner better14:19
ssam2Buffalo buffalo buffalo Buffulo buffalo14:20
richard_mawand then there's the classic
persiassam2: 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
paulsherwoodssam2: you get a gold star :)14:21
persiaLooking 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
*** thecorconian [] has quit [Quit: Leaving.]14:45
*** thecorconian [] has joined #baserock15:01
*** fay_ [] has quit [Remote host closed the connection]15:01
*** thecorconian [] has quit [Ping timeout: 264 seconds]15:05
pedroalvarezrichard_maw: may I ask you why now ARTIFACT_CACHE_SERVER is mandatory in mason.configure?15:25
pedroalvarezI mean, shouldn't be optional defaulting to TROVE_HOST?15:28
persiaI think it can't ever be right for the values to differ.15:37
persiaBecause 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
tlsapedroalvarez: ARTIFACT_CACHE_SERVER is for the mason's local trove15:40
pedroalvarezright, just becasue now with mason you can use a Trove for the sources and another one as artifact-cache-server15:42
pedroalvarezI'm pretty confused with all the variables :?15:43
tlsaso your artifact cache server is my-mason-trove, and your sources from from, for example15:43
pedroalvareztlsa: right15:43
pedroalvarezso what should I put in MASON_UPSTREAM_TROVE_ADDRES15:43
tlsais it used?15:44
* pedroalvarez cries15:45
pedroalvarez[mason.configure]Not configuring as Mason, some options not defined15:45
pedroalvarezI see, is not used anymore?15:45
tlsaI don't know where you got MASON_UPSTREAM_TROVE_ADDRES from15:46
tlsait doesn't show in a grep of definitions.git15:47
pedroalvarezI see dead code <fx:the-sixth-sense-boy>15:47
pedroalvareztlsa: I'm not crazy:
pedroalvarezIt was there when I started15:48
*** jonathanmaw [] has quit [Quit: Leaving]16:37
*** genii [~quassel@ubuntu/member/genii] has joined #baserock16:48
richard_mawssam2: I tried out your logging patch, I was impressed17:10
richard_mawas my mail which was stuck in my inbox when I wrote that last IRC message will attest to17:10
richard_mawI also have a patch to make it use asyncore, rather than the non-blocking read then sleep loop17:11
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]17:17
*** genii [~quassel@ubuntu/member/genii] has joined #baserock17:26
ssam2richard_maw: me too :)17:27
ssam2I couldn't resist17:27
ssam2although looking at yours, seems I used asyncore wrong a bit17:27
ssam2still, the important thing is we'll soon be able to debug failed deployments, which is nice !17:28
ssam2however, having stayed an extra hour to learn more about sockets, now I'm off for the weekend17:29
*** ssam2 [] has quit [Quit: Leaving]17:29
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]17:32
*** franred [] has quit [Ping timeout: 260 seconds]18:24
*** franred [] has joined #baserock18:26
*** flatmush [] has quit [Ping timeout: 245 seconds]18:27
*** flatmush [] has joined #baserock18:28
*** franred [] has quit [Ping timeout: 255 seconds]18:36
*** franred [] has joined #baserock18:36
*** flatmush [] has quit [Ping timeout: 244 seconds]18:39
*** franred [] has quit [Ping timeout: 260 seconds]18:43
*** franred [] has joined #baserock18:43
*** flatmush [] has joined #baserock18:47
*** franred [] has quit [Ping timeout: 240 seconds]18:59
*** franred [] has joined #baserock19:03
*** flatmush [] has quit [Ping timeout: 255 seconds]19:04
*** franred [] has quit [Ping timeout: 260 seconds]19:08
*** franred [] has joined #baserock19:09
*** franred [] has quit [Ping timeout: 255 seconds]19:21
*** franred [] has joined #baserock19:25
*** flatmush [] has joined #baserock19:30
*** franred [] has quit [Ping timeout: 255 seconds]19:33
*** flatmush [] has quit [Ping timeout: 265 seconds]19:35
*** franred [] has joined #baserock19:35
*** franred [] has quit [Ping timeout: 260 seconds]19:40
*** flatmush [] has joined #baserock19:46
*** flatmush [] has quit [Ping timeout: 246 seconds]19:53
*** flatmush [] has joined #baserock19:57
*** thecorconian [] has joined #baserock20:00
*** flatmush [] has quit [Ping timeout: 260 seconds]20:02
*** franred [] has joined #baserock20:07
*** flatmush [] has joined #baserock20:08
*** franred [] has quit [Ping timeout: 240 seconds]20:12
*** flatmush [] has quit [Ping timeout: 260 seconds]20:12
*** franred [] has joined #baserock20:18
*** flatmush [] has joined #baserock20:19
*** franred [] has quit [Ping timeout: 264 seconds]20:24
*** franred [] has joined #baserock20:24
*** franred [] has quit [Ping timeout: 244 seconds]20:30
*** flatmush [] has quit [Ping timeout: 246 seconds]20:31
*** flatmush [] has joined #baserock20:40
*** flatmush [] has quit [Ping timeout: 244 seconds]20:44
*** flatmush [] has joined #baserock20:44
*** flatmush [] has quit [Ping timeout: 260 seconds]20:53
* paulsherwood wonders how morph deploy can fail with "ERROR: Command failed: git ls-remote git://
paulsherwoodfatal: read error: Connection reset by peer"21:07
paulsherwoodi'm running deploy locally... why is it asking gbo for anything?21:07
richard_mawpaulsherwood: 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/origin21:26
paulsherwoodrichard_maw: tvm. any ideas how i can hack it to continue?21:28
paulsherwoodnever mind, it's late...21:29
richard_mawyeah, I can have a quick look and see if there's an easy fix, but I won't have time to implement it21:29
paulsherwoodi wonder why it checks for pushed changes at all? i'm deploying, not building21:30
richard_mawdeploy also uses temporary build branches, since you may have built your system on one21:31
richard_mawI guess a quick win would be to make it not check whether everything has been pushed if it doesn't care about the answer21:32
paulsherwood+1 :)21:32
paulsherwoodi guess there's a separate problem causing g.b.o to hangup at me at this point - i've never seen this on previous deploys21:33
richard_mawI think all the people doing ls-remote on it is gumming up its git-daemon process21:34
richard_mawI think it may work better for the moment if you switch to http:// URLs21:34
richard_mawbut it's too late for me to describe how21:35
paulsherwoodok i'll send this conversation to the list as an issue...21:36
paulsherwoodthank you21:36
richard_mawI've spend my evening playing with asyncore, working out how to shoe-horn subprocess output processing into its socket-based event model21:37
paulsherwoodooh, cool! :)21:39
richard_mawthe 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 Coroutines21:43
paulsherwoodat times i really hate python :)21:48
richard_mawmy 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 readability21:55
paulsherwoodmy problem is that i can't understand the codebase21:57
paulsherwoodeverything seems very complicated21:57
paulsherwoodbut then, my own code on other projects no doubt would provoke similar reactions21:58
*** flatmush [] has joined #baserock22:07
*** thecorconian [] has joined #baserock22:10
*** flatmush [] has quit [Ping timeout: 260 seconds]22:11
*** flatmush [] has joined #baserock22:12
*** flatmush [] has quit [Ping timeout: 245 seconds]22:32
*** flatmush [] has joined #baserock22:37
*** flatmush [] has quit [Ping timeout: 246 seconds]22:41
*** flatmush [] has joined #baserock22:42
paulsherwoodlooks 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 [] has quit [Ping timeout: 255 seconds]23:05
*** flatmush [] has joined #baserock23:09
*** flatmush [] has quit [Ping timeout: 246 seconds]23:33
*** flatmush [] has joined #baserock23:36
*** flatmush [] has quit [Ping timeout: 246 seconds]23:41
*** flatmush [] has joined #baserock23:41
*** flatmush [] has quit [Ping timeout: 240 seconds]23:51
*** flatmush [] has joined #baserock23:52

Generated by 2.15.3 by Marius Gedminas - find it at!