| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 00:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 00:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:46 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 00:58 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:14 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 01:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 01:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 02:02 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 02:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 02:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 02:45 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:46 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 02:52 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:54 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 03:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 03:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:13 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 03:24 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 03:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 04:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 04:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 04:47 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:58 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 05:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 05:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 05:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 05:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 05:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:52 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 05:56 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:58 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 06:03 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 06:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 06:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:42 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:47 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 06:59 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 07:06 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 07:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:13 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 07:17 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:20 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:27 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:29 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 07:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:39 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 07:42 | |
| *** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:42 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:06 | |
| pedroalvarez | paulsherwood: I'm interested about what did you try to do with http://85.199.252.93/cgi-bin/cgit.cgi/ | 08:14 |
|---|---|---|
| pedroalvarez | I want to make it work | 08:14 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:24 | |
| pedroalvarez | I see, `morph checkout` doesn't work | 08:29 |
| pedroalvarez | seems to be working now | 08:31 |
| pedroalvarez | morph checkout tries to `git clone` using git:// protocol, but never falls back to http:// | 08:32 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:42 | |
| richard_maw | bah, I'll go restart the git-daemon then | 08:48 |
| pedroalvarez | richard_maw: you mean that g.b.o should be working? | 08:55 |
| richard_maw | yes | 08:55 |
| pedroalvarez | oh yeah! | 08:55 |
| franred | great!! | 08:59 |
| pedroalvarez | I'm lookin forward to add ca-certificates to baserock if that solves the problems I'm having to use https:// from baserock | 09:02 |
| richard_maw | I think the plan is that today we're going to sort out the issues with the git.baserock.org VM | 09:02 |
| pedroalvarez | that's the plan, yes | 09:03 |
| franred | pedroalvarez, I can add them as part of the gerrit works | 09:03 |
| persia | franred: I thought java ca-certificates was different from regular ca-certificates | 09:04 |
| franred | persia, that's what I think too...and because of that Im using its ca-certificates, maybe worth try regular ca-certificates once again in case that I did something wrong | 09:06 |
| pedroalvarez | I can't say anything about ca-certificates. I was raising the point because I know we did some research. | 09:09 |
| pedroalvarez | And we never integrate them. | 09:11 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:21 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:24 | |
| paulsherwood | i integrated them. but maybe not in an acceptable way... | 09:50 |
| paulsherwood | https://github.com/devcurmudgeon/wheezy-certs | 09:51 |
| pedroalvarez | paulsherwood: did you use the ca-certificates repo that we have in g.b.o? | 09:51 |
| pedroalvarez | ahhh! ok | 09:51 |
| paulsherwood | this was enough for the docker integration i did | 09:52 |
| paulsherwood | note i didn't propose the docker work for mainline because i'm assuming my certs approach is not ok | 09:57 |
| ssam2 | I'm not sure what would be OK | 09:58 |
| bjdooks_ is now known as bjdooks | 09:58 | |
| ssam2 | maybe lorry should be responsible for updating a Git repo containing the certificates themselves | 09:58 |
| ssam2 | the alternative is this sort of approach: http://git.buildroot.org/buildroot/tree/package/ca-certificates | 09:58 |
| ssam2 | where the 'build' of the ca-certificates chunk downloads them | 09:59 |
| ssam2 | but that seems wrong for Baserock | 09:59 |
| ssam2 | effectively we're going to mirror Debian's or Mozilla's certificates, so why not use our mirroring tool, Lorry ? | 09:59 |
| paulsherwood | ok by me | 10:00 |
| ssam2 | (disclaimer: I'm dumb, liw-orc and Kinnison no doubt no more :) | 10:00 |
| ssam2 | and persia | 10:00 |
| liw-orc | ssam2, how dare you say you're dumb?! | 10:00 |
| richard_maw | we can't download certs at build-time | 10:01 |
| persia | I believe I already had an approved lorry for ca-certificates, which ought be on g.b.o | 10:02 |
| paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/tree/ | 10:03 |
| persia | The only blocker I had was getting the system integration script to be robust enough. | 10:03 |
| persia | That would be it. | 10:03 |
| persia | Essentially, one needs to capture the set of certificates on a system, stick that in an enablement configuration file, and then run `update-ca-certificates`. | 10:03 |
| liw-orc | lorrying from Debian, building in chunk, integrating in the suitable place -- sounds good to me | 10:04 |
| persia | I seem to remember there being a missing part in the ca-certificates upstream Makefile that mattered for Baserock but not for Debian, but I don't remember the details at the moment (I'll dig it out of my vm in a bit) | 10:11 |
| liw-orc | I would like to increase the disk space on git.baserock.org, but that requires a short service break due to a reboot: is now a good time to do that? I expect it'll take less than half an hour, but will enable people to push again | 10:29 |
| tlsa | fine by me | 10:29 |
| fay__ is now known as fay_ | 10:30 | |
| franred | liw-orc, works for me | 10:30 |
| liw-orc | paulsherwood, richard_maw, ssam2, SotK_, franred, pedroalvarez, persia: ^ (I hope I didn't forget anyone) | 10:30 |
| SotK_ | go for it | 10:30 |
| SotK_ is now known as SotK | 10:30 | |
| pedroalvarez | liw-orc: go ahead | 10:31 |
| ssam2 | please do! | 10:31 |
| petefoth_ | liw-orc: I don't mind either :) | 10:31 |
| liw-orc | petefoth_, oops, I forgot you | 10:32 |
| pedroalvarez | persia: wrt ca-certificates. Running make and make install. Then populate /etc/ca-certificates.conf with a list of all the files installed in /usr/share/ca-certificates/ and run update-ca-certificates , made the glance client work against an https:/ openstack server | 10:35 |
| liw-orc | git.baserock.org going down in a moment | 10:35 |
| pedroalvarez | persia: but Ican't clone a repo using a https/ url, so yeah, there is a missing part | 10:39 |
| persia | pedroalvarez: Right. My memory is that we needed git to have working ssl at build time to get ssl support, but I ran into issues with stratum layering, and never got back to it. | 10:50 |
| paulsherwood | liw-orc: fine by me too, i assume you've done it by now :) | 11:16 |
| ssam2 | $ morph branch baserock:baserock/definitions rubytest --no-git-update | 11:17 |
| ssam2 | 2014-09-02 11:17:18 Updating git repository baserock:baserock/definitions in cache | 11:17 |
| ssam2 | :( | 11:17 |
| ssam2 | each code path has to handle settings['no-git-update'] itself I guess | 11:17 |
| liw-orc | paulsherwood, it's happening :) the data copying takes longer than I expected, though | 11:18 |
| persia | Is it possible to consolidate those? Otherwise we end up with an extending list of things that any new feature needs to support, making changes hard. | 11:18 |
| ssam2 | sure, and it partially is | 11:18 |
| ssam2 | on closer investigation the code in question should be handling no-git-update | 11:19 |
| richard_maw | it depends on how it's used currently, if you're creating a source pool, e.g. for building, then it already reacts to no-git-update | 11:19 |
| ssam2 | seems what it's trying to do in this case is actually clone the repo, because I told it not to update | 11:19 |
| ssam2 | pdb in Python 2.7 deals with generators in a confusing way | 11:30 |
| richard_maw | how so? | 11:30 |
| ssam2 | I was trying to work out why a function that did almost nothing was blocking, but it turned out that the code was actually in __exit__() way up somewhere else | 11:31 |
| ssam2 | oh, I mean context managers, not generators | 11:31 |
| richard_maw | so the function had exited, and jumped to the __exit__, but since it wasn't part of the function you were inspecting, pdb paused execution? | 11:32 |
| ssam2 | yes | 11:32 |
| ssam2 | or something like that | 11:32 |
| ssam2 | i'd moan at pdb, but we are several versions behind | 11:33 |
| paulsherwood | ssam2: i that is correct behaviour - but --no-git-upfdate is a confusing name | 11:44 |
| ssam2 | it turns out that the actual problem was somewhere else: a call to `git remote update --prune` that ran unconditionally | 11:45 |
| paulsherwood | --no-git-update refers to checking for uptdatesd to chunks etc on building | 11:45 |
| liw-orc | status update: my gbo disk copy is still running and the break may take a good while more, since file copying turns out to be slow due to a very large number of small files | 11:45 |
| ssam2 | yes, the name is confusing, I'd sometimes like to have a '--no-network' option | 11:45 |
| richard_maw | or --local | 11:46 |
| paulsherwood | for pulling, maybe one of pedroalvarez' new troves would be usable while awaiting the return of gbo | 11:46 |
| pedroalvarez | indeed, I believe this one is usable: http://85.199.252.93/ | 11:47 |
| ssam2 | wow we have an army of imitators | 11:48 |
| richard_maw | ssam2: pardon? | 11:48 |
| ssam2 | well one imitator | 11:48 |
| ssam2 | and by "we" I mean git.baserock.org | 11:48 |
| ssam2 | that trove clone is helping, thanks! | 11:57 |
| paulsherwood | cool | 11:57 |
| paulsherwood | i confess, i want my own. | 11:58 |
| paulsherwood | and i'd prefer to set my own lorrying policies :) | 11:58 |
| * persia wants lorry on devel machines : "troves" use too much bandwidth uselessly for single developers | 12:01 | |
| paulsherwood | i second that. i actually did that, and wrote it up :) | 12:02 |
| persia | I missed that. Where is the writeup? | 12:03 |
| paulsherwood | it was last year on the ml, i believe | 12:03 |
| petefoth_ | And the possibility to do at least CI on devel machines too? So a devel machine could have the functionality of Trove and Mason | 12:04 |
| persia | petefoth_: I'm not sure what "CI on devel machines" means, and folk have their devel in all sorts of environments, from memory-limited bare-metal to managed clouds, so it's hard to know where to deploy the test machines. | 12:05 |
| persia | I'd be delighted with a means to trivially run a test suite against a remote machine that I had just deployed. | 12:06 |
| * ssam2 would like it if Trove and Mason were lightweight enough that they could be run on a developer machine | 12:06 | |
| ssam2 | but either approach is an improvement | 12:06 |
| petefoth_ | persia: "automated build and running (some sub-set) of system tests" | 12:07 |
| persia | I actively don't want automated builds on devel machines. | 12:07 |
| persia | As a developer, I know better than any automation when to perform a build. | 12:07 |
| petefoth_ | persia: really? | 12:08 |
| persia | Yes. Any automation just means I have to know the magic to trigger it, and it's conceptually easier to just type `morph build` | 12:09 |
| petefoth_ | persia: so you build the system you are wrking on. Might you not want to build other systems to check your changes haven't broken them? | 12:10 |
| petefoth_ | Why should you have to have another machine to do that? | 12:11 |
| persia | Only in the rare case that I happened to be building a development system, and in such a case, I'd want to do that by deploying it, and running a test suite against it (which test suite might involve building clusters, etc.) | 12:11 |
| persia | But I never want to wonder whether something is going to try to magically deploy something (probably in the wrong place) or consume resources testing it (probably at the wrong time). | 12:12 |
| petefoth_ | persia: I'm not suggesting that the automated build and test happen without you triggering it. But I am arguiant that you shoyuld be able to trigger it without having to have another machine to do it on | 12:13 |
| persia | I don't need another machine to do that: I need a way to host an environment. I can use a VM on baserock, a VM hosted on the same machine or in the same cloud as a devel VM, a second piece of target hardware (if I only have 1G RAM, I *really* don7t want to run a VM in there and try to build stuff inside), etc. | 12:13 |
| persia | Yes, but that flexibility belongs in `morph deploy`. | 12:13 |
| persia | So my workflow is something like `morph build ${SYSTEM}`, morph deploy ${CLUSTER};, morph test ${INSTANCE}` | 12:14 |
| paulsherwood | persia: turns out i published my work, but not the discussion | 12:14 |
| persia | There's no need for automation to achieve this. | 12:14 |
| persia | paulsherwood: Ah, which may be why I missed it :) Is it as simple as just adding a lorry chunk to a devel environment? | 12:14 |
| paulsherwood | i also added a morrph lorry command http://85.199.252.93/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=baserock/ps/add-lorry | 12:15 |
| petefoth_ | MY use case is: I am modifying a component that is used in many BAserock systems. I want to be able to check that all affected systems can a: still build andd b: pass some subset of tests | 12:15 |
| persia | petefoth_: Can you not use the workflow I just described to do that, where your test suite happens to build systems and test them? | 12:16 |
| petefoth_ | persia: yes, but isn't that Mason functionality - or a useful sub-set thereof? | 12:17 |
| persia | I don't have sufficient semantics attached to "Mason" to consider things in relation to it. | 12:17 |
| petefoth_ | OK | 12:18 |
| persia | But I don't want any automation or overhead on my devel machines. | 12:18 |
| * petefoth_ gives up | 12:18 | |
| persia | From what I understand about Mason, I suspect there's a lot of parallels between what I want on a developer machine and what Mason does, but the architecture may differ significantly. | 12:18 |
| persia | paulsherwood: Looking at that: do we need to wrap lorry in morph? Seems quite a lot of changes to morph, as opposed to my naive believe we might be able to just run some `lorry` command. | 12:21 |
| *** gallit [~gallit@ANice-651-1-352-32.w86-205.abo.wanadoo.fr] has joined #baserock | 12:24 | |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 12:37 | |
| paulsherwood | you may be right. | 12:58 |
| *** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [] | 12:58 | |
| persia | That it needs to be in morph, or that it doesn't need to be in morph? | 12:59 |
| * persia hadn't intended to express either as a declarative statement | 12:59 | |
| paulsherwood | heh | 12:59 |
| paulsherwood | 'we might be able to just run some lorry command' | 13:00 |
| persia | Does such a command exist already? | 13:00 |
| persia | e.g. `lorry ${FILE}` to pull something into some known location? | 13:01 |
| paulsherwood | yes. just not in devel. there was discussion on our internal list when i did this is there a 'normal' way to introduce historical private discussion to a public list (assuming participants agree to the publication) | 13:02 |
| persia | I don't know of any good ones (that preserve threading, etc.). I generally see people summarise things, inviting futher comment. | 13:03 |
| paulsherwood | ok | 13:03 |
| paulsherwood | i'll just restart as a new topic, then | 13:08 |
| paulsherwood | lots has changed | 13:08 |
| persia | Probably makes more sense | 13:11 |
| paulsherwood | done | 13:22 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 13:38 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:39 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 13:49 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:50 | |
| straycat | Though we tend to lorry with lorry controller because lorrying manually is too dangerous with the current tools. | 13:55 |
| paulsherwood | straycat: dangerous? | 13:55 |
| persia | How so? | 13:55 |
| paulsherwood | all i'm suggesting is user can use it to efficiently get a git repo of non-git upstream | 13:55 |
| persia | The alternative being to install git-svn, git-hg, git-cvs, etc. | 13:56 |
| straycat | lorry, run as it stands on a trove is destructive | 13:57 |
| paulsherwood | this wold be on a devel machine | 13:57 |
| paulsherwood | for occasional use by integrators needing jrandom nongit upstream | 13:57 |
| persia | For both integration and for testing lorry files before submission to a lorry-controller instance. | 13:59 |
| persia | But that lorry run on a trove is destructive worries me: how do we ensure that refs we care about aren't clobbered? | 14:00 |
| liw-orc | straycat, what do you mean by destructive? | 14:00 |
| straycat | liw-orc, iirc refs from the new repo overwrite any matching refs in the current repo. | 14:01 |
| persia | You mean in case of collision? | 14:03 |
| liw-orc | how is this a problem when a developer runs lorry on the devel system to create git repos that are _not_ pushed by lorry to a trove? | 14:03 |
| straycat | It's not | 14:04 |
| straycat | I didn't realise you were planning to run lorry on a devel machine, sorry | 14:05 |
| liw-orc | no worries, then :) | 14:05 |
| ssam2 | Nothing makes my day more than a library which fails to build in Morph, but succeeds to build when I try to build it manually | 14:55 |
| ssam2 | hmm, it definitely seems to be running the tests before it's finished building the library | 14:55 |
| ssam2 | but it also definitely seems to be setting 'MAKEFLAGS=-j 1', as I told it to | 14:56 |
| ssam2 | and I just can't make it break outside morph, even running the identical commands | 14:57 |
| ssam2 | maybe identical environment will make it break | 14:57 |
| persia | Have you tried to build it in the chroot in the failed/ directory? | 14:58 |
| paulsherwood | ssam2: maybe it needs network? | 15:00 |
| ssam2 | i'm trying in the chroot and using linux-user-chroot | 15:00 |
| paulsherwood | (go runs tests which need network, which fail in morph) | 15:01 |
| richard_maw | you don't even get loopback network in linux-user-chroot | 15:01 |
| paulsherwood | (because we turn of network) | 15:01 |
| paulsherwood | off | 15:01 |
| ssam2 | I get test failures interspersed with the building status messages when Morph builds it | 15:02 |
| ssam2 | but manually, I get all the building messages, followed by all the tests succeeding | 15:02 |
| richard_maw | it's concievable that we could enable loop-back networking in builds, which would probably be sufficient for go's tests | 15:02 |
| ssam2 | ah! if I do `MAKEFLAGS='-j 6' make` then I can reproduce the failure. | 15:03 |
| richard_maw | hooray for non-deterministic build failures(!) | 15:03 |
| paulsherwood | richard_maw: i opted for building witohut the tests | 15:05 |
| ssam2 | i realise now that when I added a chunk morph, I didn't add the 'morph: strata/chef/yajl.morph' entry necessary to make Morph actually look at my chunk morphology | 15:06 |
| richard_maw | ssam2: out of interest: do you think you would have made that mistake if you could have in-lined the max-jobs into the stratum morphology? | 15:06 |
| ssam2 | no, i'd definitely have inlined it :) | 15:07 |
| paulsherwood | i see the way this discussion is going :/ | 15:13 |
| persia | Does morph output advise whether it's using a local morphology or discovering one? | 15:14 |
| richard_maw | persia: not directly, it may output information related to the fact that it is updating git repositories so it can find the morphology | 15:15 |
| liw-orc | git.baserock.org should be back online | 15:15 |
| richard_maw | web UI is | 15:16 |
| richard_maw | and snappy | 15:16 |
| liw-orc | could someone try to push something? | 15:16 |
| persia | liw-orc: Thanks! | 15:16 |
| persia | richard_maw: Hrm. I think we probably want to know more directly, so that one can see the output and understand why the build fails miserably more quickly than ssam2 took today. | 15:17 |
| richard_maw | liw-orc: push ok | 15:17 |
| liw-orc | yay | 15:17 |
| liw-orc | i will clean up the ghost jobs | 15:19 |
| pedroalvarez | :) | 15:19 |
| richard_maw | persia: unless we have a big warning message saying that our stratum hasn't included a path to a chunk morphology, I don't think it will have helped, as we produce so much output that any normal message would easily get lost | 15:22 |
| richard_maw | and we'd get far too many false warnings with that scheme anyway, since we auto-detect a lot of morphologies | 15:23 |
| persia | I think I agree with you. I still think being able to differentiate autogenerated from provided morphologies is important. | 15:23 |
| persia | Perhaps we need to trim other things, but I'm not convinced we should stop adding useful things just because we're generating so much useless stuff that it's better ignored. | 15:23 |
| richard_maw | I'd prefer to make the "morph" field mandatory, and move the build-systems into the definitions repository, though that will require us removing the "name" field from the chunk morphology | 15:25 |
| ssam2 | given an interface of text files containing yaml, I will find a way to confuse myself no matter what the exact structure :) | 15:26 |
| richard_maw | ssam2: you want a GUI? | 15:27 |
| paulsherwood | liw-orc: new jobs are not allowed, i assume that means it's not lorrying now? | 15:27 |
| liw-orc | paulsherwood, jobs are disallowed until I've cleaned out the ghost jobs | 15:28 |
| paulsherwood | ack | 15:28 |
| persia | richard_maw: I can see that being attractive, but 1) I still don't want my screen flooded with useless things, 2) I still want morph to tell me when it decides to do magic things, rather than being mysterious about it, and 3) the more we move to definitions, the less one can use morph without definitions. | 15:29 |
| persia | While some of this stuff may not belong in morph, I'd much rather not have definitions hugely cluttered (I'm already unhappy that I can't easily understand all the content). | 15:30 |
| persia | Ideally I'd like to be able to start a definitions repo from scratch, and expect things to mostly work. | 15:31 |
| *** gallit [~gallit@ANice-651-1-352-32.w86-205.abo.wanadoo.fr] has quit [Quit: Leaving] | 15:31 | |
| paulsherwood | persia: me too. what's stopping us? | 15:32 |
| richard_maw | nothing, as I understand the problem | 15:33 |
| persia | paulsherwood: I'm not sure. There was the idea of moving all the configuration extensions there, to make them easier to discover (but increase the footprint of a "bare" definitions). Moving build systems would be more. There's currently some scripts, some of which may be useful or important. | 15:34 |
| ssam2 | richard_maw: i can confuse myself using complex GUIs too | 15:34 |
| ssam2 | it's quite a talent I have | 15:34 |
| persia | It's the dataset that is confusing, not the interface. | 15:34 |
| liw-orc | there, jobs are allowed again | 15:38 |
| paulsherwood | liw-orc: tvm. i assume they'll kick in when the schedule catches up? | 15:41 |
| paulsherwood | 112GB :) | 15:41 |
| liw-orc | paulsherwood, yep, they'll kick when it's time | 15:42 |
| paulsherwood | great | 15:45 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds] | 15:55 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:01 | |
| paulsherwood | is php in baserock? | 16:22 |
| richard_maw | no | 16:22 |
| paulsherwood | do we want it? | 16:22 |
| paulsherwood | or do we hate it so bad we'll never allow it? :) | 16:22 |
| richard_maw | only as long as we have a paying customer, otherwise I think we prefer non-php solutions | 16:23 |
| paulsherwood | :) | 16:23 |
| paulsherwood | there was discusion on another channel about how to setup an openid provider, and this came up... http://simpleid.koinic.net | 16:24 |
| richard_maw | there's also myriad openid server applications listed on http://wiki.openid.net/w/page/12995226/Run%20your%20own%20identity%20server | 16:25 |
| persia | richard_maw: Do you have a preferred one from that list? | 16:25 |
| richard_maw | http://trac.nicolast.be/djangoid since it's python | 16:26 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:27 | |
| persia | Looks like it hasn't been touched in 8 years | 16:27 |
| * paulsherwood 'did' django in python recently, in case anyone needs that | 16:28 | |
| *** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has joined #baserock | 16:28 | |
| richard_maw | persia: if it works with Gerrit, I'm not sure we care | 16:29 |
| persia | The only other standalone app in python from that page is 5 years untouched and described as "needing cleanup". | 16:30 |
| paulsherwood | and storyboard, richard_maw :) | 16:31 |
| persia | So I suppose DjangoID is reasonable, although my preference is to have an active upstream for anything I use (if only to have someone to chat with when I run into issues). | 16:31 |
| paulsherwood | https://github.com/mitsuhiko/flask-openid | 16:45 |
| paulsherwood | has some more recent activity, at least | 16:45 |
| persia | Isn't that just a consumer? | 16:46 |
| paulsherwood | https://github.com/mitsuhiko/flask-openid/blob/master/example/example.py | 16:46 |
| paulsherwood | maybe. i skipped lunch, my brain is not present | 16:47 |
| persia | Looks like a consumer in that example (and moreso reading the exposed API) | 16:48 |
| persia | https://pythonhosted.org/Flask-OpenID/ (near the bottom) | 16:48 |
| ssam2 | richard_maw: do you want me to merge your 'Use git's remotes to determine unpushed branches' patch ? | 16:49 |
| ssam2 | I've reviewed and it looks good | 16:49 |
| richard_maw | I'm currently running tests on it to ensure merging didn't introduce a regression | 16:50 |
| ssam2 | oh, me too | 16:50 |
| ssam2 | i'll race you | 16:50 |
| richard_maw | I just finished | 16:50 |
| persia | Is the winner determined only by time, or by number of tests performed as well? | 16:50 |
| pedroalvarez | only by time assuming they were running the same test suite | 16:51 |
| richard_maw | the commit sha1 is aea1029044b7e0d4578f3896bf85898f33791c89 if you want to do the definitions.git update | 16:51 |
| richard_maw | ssam2: ^ | 16:54 |
| ssam2 | i'm happy for you to :) | 17:00 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:01 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:01 | |
| pedroalvarez | bleurgh... | 17:03 |
| pedroalvarez | morph controllerdaemon --config /etc/morph-controller.conf | 17:03 |
| pedroalvarez | ERROR: [Errno -2} Name or service not known | 17:03 |
| pedroalvarez | s/controllerdaemon/controller-deamon/ | 17:03 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving.] | 17:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!