| jjardon | SotK: Ive just sent pacthes to solve the simple-network problem in the minimal systems, sorry for any inconvenience | 00:12 |
|---|---|---|
| *** rdale_ has joined #baserock | 02:30 | |
| *** rdale has quit IRC | 02:33 | |
| *** zoli__ has joined #baserock | 04:16 | |
| *** petefoth_ has joined #baserock | 04:22 | |
| *** petefoth has quit IRC | 04:24 | |
| *** petefoth_ is now known as petefoth | 04:24 | |
| *** zoli__ has quit IRC | 05:35 | |
| *** zoli__ has joined #baserock | 06:13 | |
| *** zoli__ has quit IRC | 07:21 | |
| *** zoli__ has joined #baserock | 07:28 | |
| *** sherm_ has joined #baserock | 07:33 | |
| *** zoli__ has quit IRC | 07:46 | |
| *** fay_ has quit IRC | 07:49 | |
| *** fay has joined #baserock | 07:49 | |
| *** fay is now known as Guest36005 | 07:50 | |
| *** zoli__ has joined #baserock | 07:52 | |
| straycat | pedroalvarez, gertty gives you a lot more log info if you run it with -d | 08:14 |
| straycat | (debug) >.> | 08:14 |
| *** Guest36005 is now known as fay_ | 08:16 | |
| SotK | jjardon: thanks, I'll look at them in a bit | 08:17 |
| SotK | there was no inconvenience really, I just thought I'd broken the deploy code for a bit :) | 08:18 |
| *** gfinney_ has joined #baserock | 08:22 | |
| *** gfinney_ has quit IRC | 08:24 | |
| *** gfinney has joined #baserock | 08:24 | |
| *** jonathanmaw has joined #baserock | 08:33 | |
| *** mdizzle has joined #baserock | 08:50 | |
| *** bashrc_ has joined #baserock | 09:03 | |
| straycat | What is the stance on gerrit, is this a trial run? Will there be some sort of vote? | 09:09 |
| * Kinnison imagines that ssam2, richard_maw, and pedroalvarez are best placed to discuss that | 09:13 | |
| franred | straycat, I though it was decided we are going to move to gerrit and abandon the ml | 09:18 |
| franred | ...as soon as possible and for the future patches | 09:19 |
| *** tiagogomes_ has joined #baserock | 09:21 | |
| straycat | franred, I don't know, it's not clear to me what happening, I assumed there'd at least be some sort of trial run where we get to try it and decide whether we want to use it | 09:22 |
| straycat | *what's | 09:22 |
| *** gary_perkins has joined #baserock | 09:24 | |
| *** fay_ has quit IRC | 09:33 | |
| *** fay has joined #baserock | 09:33 | |
| *** fay is now known as Guest91890 | 09:34 | |
| jjardon | What's the license of baserock definitions? | 09:37 |
| rjek | Good question. | 09:38 |
| bashrc_ | yes | 09:38 |
| bashrc_ | maybe there should be a license field | 09:38 |
| * Kinnison thinks the definitions should be under the ISC licence | 09:38 | |
| Kinnison | it's possible some of the scripts etc might be under something else | 09:39 |
| Kinnison | but ISC is the only sane option for making it easy to derive and modify for those who might not wish to release their system definitions | 09:39 |
| Kinnison | (IMO) | 09:39 |
| bashrc_ | better to make it unambiguous | 09:39 |
| *** Guest91890 is now known as fay_ | 09:41 | |
| * jjardon searchs for isc | 09:44 | |
| Kinnison | http://en.wikipedia.org/wiki/ISC_license | 09:45 |
| Kinnison | Think "BSD" but without the pesky owned-by-berkeley bit | 09:45 |
| *** edcragg has joined #baserock | 09:52 | |
| rjek | MIT-style. | 09:54 |
| rjek | "Don't pretend you made this, but don't blame me either. Otherwise, do whatever you like." | 09:54 |
| *** ssam2 has joined #baserock | 10:04 | |
| *** ChanServ sets mode: +v ssam2 | 10:04 | |
| tlsa | http://paste.baserock.org/azonevefel | 10:04 |
| tlsa | ^^ that's the output of the reproducibility certification tool | 10:04 |
| tlsa | showing the three types of problems it can catch | 10:05 |
| tlsa | the patches for `morph certify` are on gerrit | 10:07 |
| * SotK will look at them in a while | 10:09 | |
| tlsa | thanks :) | 10:09 |
| *** jmacs has joined #baserock | 10:10 | |
| *** a1exhughe5 has joined #baserock | 10:20 | |
| franred | http://mason-x86-64.baserock.org is failing because of http://gerrit.baserock.org/#/c/65/ - if someone does have spare time to review it, would be nice to merge it | 10:23 |
| richard_maw | eww, I'd forgotten how nasty lsof's build commands were | 10:26 |
| ssam2 | franred: looks fine, merged | 10:26 |
| pedroalvarez | does that mean that now it can't build with busybox tar? | 10:27 |
| * pedroalvarez checks | 10:27 | |
| franred | ssam2, thanks | 10:27 |
| ssam2 | pedroalvarez: probably does mean that | 10:27 |
| ssam2 | i'm not sure what to do about it | 10:28 |
| franred | other issue which is worth to investigate is if we are shipping licensed code using lsof - fedora stripes part of the tarball, see http://pkgs.fedoraproject.org/cgit/lsof.git/tree/lsof.spec | 10:28 |
| ssam2 | to be honest, if a system based on the minimal system requires GNU 'tar' to build, but uses Busybox 'tar' (or no 'tar' at all) at runtime, it's not a huge issue I think | 10:28 |
| straycat | 09:09 straycat$ What is the stance on gerrit, is this a trial run? Will there be some sort of vote? | 10:28 |
| straycat | 09:13 ! Kinnison imagines that ssam2, richard_maw, and pedroalvarez are best placed to discuss that | 10:28 |
| straycat | 09:18 franred$ straycat, I though it was decided we are going to move to gerrit and abandon the ml | 10:29 |
| straycat | 09:19 franred$ ...as soon as possible and for the future patches | 10:29 |
| straycat | ssam2, ^ | 10:29 |
| ssam2 | straycat: at the meetup, we discussed a plan for setting up Gerrit, but didn't discuss any formal process for deciding when it's 'done' or whether we should give up on the effort | 10:30 |
| ssam2 | do you want there to be a vote? | 10:30 |
| ssam2 | if so, do you have an idea of what the criteria should be for someone to be eligible to vote? | 10:30 |
| ssam2 | for the record, i'm fine with putting it to a vote once it's complete (once it sends emails, and perhaps is updated to 2.10, i think it'll be complete) | 10:36 |
| straycat | ssam2, My personal stance on this, is that while I was initially very excited by the benefits brought by gerrit the command line tooling I've tried (gertty, gerrymander) seems neither featureful nor mature, I'm also *very* worried by the fact that gerrit has no native concept of a patch series, so a vote seems necessary. I have no idea what the criteria should be for someone to be eligible to vote. | 10:36 |
| ssam2 | ok | 10:37 |
| ssam2 | I think it'd be useful to investigate how other projects that use Gerrit handle the fact that submitting a long series of related changes is awkward to do | 10:38 |
| ssam2 | a vote is probably a good idea, my view is certainly biased because i spent the last month working to set up Gerrit | 10:38 |
| straycat | heh :) | 10:39 |
| bashrc_ | straycat: +1 on the command line tooling | 10:45 |
| jjardon | For a vote you need an alternative (even i like mailing list, its not an option because one of the whole points of use gerrit is that it will check the patches build and give us a +1 or +2 automatically) | 10:45 |
| bashrc_ | but there is an API, so the commandline tooling issues can be solved | 10:45 |
| tlsa | when it finally pushed, I think my patch series was handled OK | 10:45 |
| Kinnison | tlsa: is there a URL you can give me so I can review your series? | 10:45 |
| * Kinnison would like to get a feeling of how reviewing a multi-patch series goes | 10:46 | |
| tlsa | I can vive you a link to the first patch, and you can click to the next | 10:46 |
| Kinnison | if that's the way it works, then sure | 10:46 |
| tlsa | http://gerrit.baserock.org/#/c/55/ | 10:46 |
| * Kinnison already knows how review feels in mutt, so wants to get the proper gerrit feel | 10:46 | |
| Kinnison | thanks | 10:46 |
| tlsa | see "related changes" on the right | 10:47 |
| tlsa | top is the last patch of the series | 10:47 |
| tlsa | the gerrit web UI is a bit poor, but maybe it improves with a later version | 10:47 |
| * Kinnison is confused | 10:50 | |
| Kinnison | last time I signed into gerrit, it used my openid | 10:50 |
| Kinnison | now it's sending me to openid.baserock.org | 10:50 |
| straycat | I like that I can easily get a list of what needs to be reviewd, but there are other systems such as patchwork that can do but still allow to use an ml. I find the sets of changes in a topic difficult to follow | 10:50 |
| Kinnison | How do I sign into my existing account? | 10:51 |
| straycat | *can do this | 10:51 |
| pedroalvarez | Kinnison: when was this last time? | 10:51 |
| pedroalvarez | I believe that now only our openid is allowed | 10:51 |
| Kinnison | pedroalvarez: Gosh, quite a while ago when sam was first testing gerrit | 10:51 |
| pedroalvarez | maybe when I was testing gerrit? (testgerrit.baserock.org)? | 10:52 |
| Kinnison | Perhaps it may even have been that long ago | 10:52 |
| pedroalvarez | in that case your account may not exist in this gerrit instance | 10:52 |
| Kinnison | Okay | 10:52 |
| * Kinnison creates yet another identity then | 10:53 | |
| Kinnison | gerrit doesn't like my ssh key :( | 10:55 |
| * Kinnison skips for now | 10:55 | |
| Kinnison | tlsa: I've added three comments to the first patch, can you see them? (They say 'draft' on my screen and I don't know why) | 10:59 |
| tlsa | I can't | 10:59 |
| * Kinnison wonders how to make it so you can | 10:59 | |
| pedroalvarez | Kinnison: i think you have to add a vote to send the comments | 11:00 |
| * straycat suggests that the set of people who have ever submitted a patch to baserock-dev OR submitted a review to baserock-dev ought to be eligible to vote | 11:00 | |
| * pedroalvarez suggests that only the subset that have tried gerrit | 11:01 | |
| straycat | That's unfair, not everyone has time to try gerrit | 11:01 |
| ssam2 | how can you vote on something that you know nothing about? | 11:02 |
| Kinnison | I think I'm with pedro here -- if you've not even tried gerrit how can you have an opinion on it? | 11:02 |
| rjek | It's possible to have opinions on vices without having partaken. | 11:02 |
| Kinnison | Opinions, yes. an explicit vote on whether to use it or not, IMO not so much | 11:03 |
| Kinnison | tlsa: Right, I had to hit 'reply' (which wasn't obvious in the least) to publish my comments | 11:03 |
| Kinnison | tlsa: can you see them now? | 11:03 |
| tlsa | yes! | 11:03 |
| Kinnison | cool | 11:03 |
| pedroalvarez | straycat: some people that have only used the mail list may be willing to move to something else and without trying it before | 11:04 |
| pedroalvarez | and viceversa | 11:04 |
| straycat | That's a fair point | 11:04 |
| pedroalvarez | I think is fair that they try it before they can choose one | 11:04 |
| straycat | It's difficult, it took me several days to decide how I feel about gerrit, several contributors don't have that much time to spare | 11:06 |
| tlsa | how do you send a v2 with gerrit? Just push it all again? | 11:06 |
| ssam2 | push it again with the same Change-Id | 11:07 |
| ssam2 | that's the main point of the Change Id | 11:07 |
| tlsa | so if I sqaush into it, it should retain the same change ID? | 11:08 |
| pedroalvarez | the change ID is part of the commit message, so if you can keep it when sqashing, then yes | 11:10 |
| tlsa | right | 11:10 |
| * richard_maw thought he saw something about allowing gerrit patches to have dependencies | 11:12 | |
| straycat | you can send changes with the same topic | 11:12 |
| richard_maw | Topics don't imply any dependency information | 11:12 |
| * Kinnison finishes reviewing tlsa's series | 11:12 | |
| straycat | no, you can have a change depend on another, i believe | 11:13 |
| Kinnison | That took roughly 20 minutes | 11:13 |
| Kinnison | subtract maybe 5 minutes for being confused about workflow, and call it 15m to review that 4 patch series | 11:13 |
| Kinnison | That's not awful but also not great | 11:13 |
| pedroalvarez | richard_maw: `git review -d 1234` being 1234 the number of the change that you want as dependecy | 11:14 |
| pedroalvarez | taken from here: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependency | 11:15 |
| Kinnison | ssam2: Is it possible to extend gerrit's review mechanism? | 11:15 |
| Kinnison | ssam2: I've given reviews, but because my responses were always -0 or +0, gerrit doesn't count those as reviews | 11:15 |
| * richard_maw wonders if git-review or one of its friends supports sending a patch series to give it both a common topic, and fill in all the dependencies to make it a chain | 11:16 | |
| ssam2 | i don't really understand what you mean | 11:16 |
| ssam2 | (to Kinnison) | 11:16 |
| ssam2 | for http://gerrit.baserock.org/#/c/55/ I don't see why you didn't just give a -1 | 11:17 |
| ssam2 | in Gerrit, I think -1 doesn't block merging | 11:17 |
| ssam2 | -2 blocks merging | 11:17 |
| Kinnison | I don't feel strongly enough to -1 it | 11:18 |
| Kinnison | or in the +ve case, to +1 it | 11:18 |
| tlsa | Kinnison: where did you find the 'reply' button? | 11:18 |
| Kinnison | (to me -1 means 'I veto this') | 11:18 |
| Kinnison | tlsa: near the top of the change page | 11:18 |
| ssam2 | Kinnison: ok. so I don't see why Gerrit should pay attention to taht | 11:18 |
| ssam2 | *that | 11:18 |
| ssam2 | to me, it's not a very useful review | 11:19 |
| Kinnison | Okay | 11:19 |
| ssam2 | i mean, the comments are useful, but if I see a patch with '-0', it tells me nothing | 11:19 |
| tlsa | Kinnison: replied to a comment | 11:19 |
| Kinnison | ssam2: to me, it means someone is uncomfortable with the patch, but doesn't believe that discomfort warrants veto | 11:19 |
| ssam2 | in Gerrit, that's what -1 means | 11:20 |
| ssam2 | someone in the Mergers group can still +2 and merge a patch which has 10000 -1s | 11:20 |
| ssam2 | but they cannot if it has a -2, so -2 is 'veto' | 11:21 |
| pedroalvarez | ssam2: but then we should consider if that person belongs to the mergers group :P | 11:21 |
| ssam2 | pedroalvarez: Gerrit only allows you to give -2 or +2 if you are in the Mergers group | 11:21 |
| *** Krin has joined #baserock | 11:21 | |
| * SotK reads Gerrit reviews as -2 == old -1, -1 == old -0, 0 == old +0 | 11:22 | |
| Kinnison | Okay, so as a non-merger I cannot raise a veto | 11:22 |
| * Kinnison can appreciate that | 11:22 | |
| * Kinnison adjusts his mental model as per sotk's comment | 11:22 | |
| Kinnison | tlsa: Since you don't get email notification yet, I have responded to your comment | 11:23 |
| Kinnison | ssam2: will 2.10 fix the lack of email notifications from gerrit? | 11:23 |
| tlsa | Kinnison: yeah, thanks | 11:23 |
| * straycat thought lack of email notification was due to lack of exim or similar in baserock | 11:23 | |
| Kinnison | straycat: oh right | 11:24 |
| Kinnison | exim is a pain to compile :( | 11:24 |
| tlsa | I think gerrit is not ideal, but not impossible to work with. (assuming yesterday's push trouble was a one-off freak.) | 11:24 |
| Kinnison | So far, it has required an adjustment in how I understand voting to work (not an issue) and has forced use of a browser (not ideal, but I understand 2.11 will fix that somewhat) | 11:24 |
| Kinnison | I've not tried submitting to it | 11:25 |
| * SotK had push trouble the first time he tried, but since then its been smooth | 11:25 | |
| Kinnison | But I know I'll dislike that | 11:25 |
| pedroalvarez | Kinnison: I don't remember how and where, but it was announced that people in the baserock-writers group will be welcome in the Mergers group. But we couldn't do that for the people that didn't have an account at the time. | 11:25 |
| pedroalvarez | Kinnison: if you want to be part of that group, you are welcome to | 11:25 |
| * SotK also had to adjust his mental model of voting to the above | 11:25 | |
| Kinnison | pedroalvarez: I understand (I also don't think I know enough about current definitions or the current morph/lorry/etc codebases to want to be in the group right now :) | 11:25 |
| pedroalvarez | being in the group doesn't mean that you have to make that kind of decissions though | 11:26 |
| * straycat isn't convinced that everyone in baserock-writers should be in mergers | 11:27 | |
| straycat | baserock-writers corresponds to being able to push to a repo in the baserock prefix on gbo, that's doesn't map exactly to mergers, even though it happens to grant merge powers on gbo | 11:28 |
| straycat | *that | 11:28 |
| pedroalvarez | i thought that people in the baserock-writers group could do merges in master as well | 11:28 |
| pedroalvarez | (as you said, sorry) | 11:29 |
| pedroalvarez | you are right, not everyone should be in that group | 11:29 |
| pedroalvarez | some people were only in baserock-writers group to be able to push branches to g.b.o. And that with gerrit is not needed anymore | 11:30 |
| *** petefoth_ has joined #baserock | 11:30 | |
| SotK | gah, ./check --full fails in master again | 11:31 |
| *** petefoth has quit IRC | 11:32 | |
| *** petefoth_ is now known as petefoth | 11:32 | |
| SotK | the copyright line in COPYING causes "ValueError: invalid literal for int() with base 10: ''" somehow | 11:34 |
| tlsa | "the comment on code --> draft --> return to main patch page --> reply --> post" saga is a bit laborious | 11:36 |
| SotK | hm, maybe its not that line | 11:36 |
| SotK | aha, there's a template line in there | 11:38 |
| SotK | I guess that the copyright checking script should ignore COPYING | 11:39 |
| *** radiofree has quit IRC | 11:50 | |
| *** radiofree has joined #baserock | 11:50 | |
| *** radiofree has quit IRC | 11:51 | |
| *** radiofree has joined #baserock | 11:51 | |
| franred | <franred> other issue which is worth to investigate is if we are shipping licensed code using lsof - fedora stripes part of the tarball, see http://pkgs.fedoraproject.org/cgit/lsof.git/tree/lsof.spec | 11:53 |
| franred | is something we have to worry about? ^^ | 11:53 |
| *** petefoth has quit IRC | 11:55 | |
| ssam2 | i've not got a clue | 11:56 |
| ssam2 | I think lawyers would generally us a polite cease and desist notice before filing an actual court case against us for violating whatever license it is | 11:57 |
| tlsa | I've rebased, squashing a change into the first commit of my series. Now the commit has two Change-Ids. | 12:01 |
| tlsa | Is that correct? | 12:01 |
| * SotK has no idea | 12:02 | |
| straycat | ! [remote rejected] HEAD -> refs/for/master (no new changes) | 12:02 |
| straycat | error: failed to push some refs to 'ssh://straycat@gerrit.baserock.org:29418/baserock/baserock/trove-setup' | 12:02 |
| ssam2 | tlsa: nope, pick one change-id | 12:02 |
| straycat | Am I seeing this because the object already exists in another branch? | 12:02 |
| tlsa | straycat: I had that yesterday | 12:02 |
| tlsa | do you have the git hook for adding change ids? | 12:02 |
| straycat | No, didn't know I needed one | 12:03 |
| tlsa | `scp -p -P 29418 <Username>@gerrit.baserock.org:hooks/commit-msg .git/hooks/` | 12:04 |
| straycat | >.> | 12:04 |
| straycat | why do i need that the gerrit guide i was reading said nothing about this? | 12:05 |
| pedroalvarez | I think that the change Id requirement can be disabled | 12:06 |
| SotK | http://gerrit.baserock.org/Documentation/user-changeid.html | 12:07 |
| straycat | that sounds good, it's not exactly convenient to have to copy some git hook in everytime i want to submit for review | 12:07 |
| SotK | its very annoying, I agree | 12:08 |
| pedroalvarez | can be annoying but before to reply resend a patch you had to get the message-id of the previous patch | 12:09 |
| * SotK sends a patch to fix ./check | 12:16 | |
| ratmice__ | ssam2: the lsof problem seems to be the dialects/ directory contains code copyrighted by sco, (and apple, and others), though it likely isn't even compiled into the resulting executable | 12:18 |
| ratmice__ | ssam2: so seems like they are covering the case of source distribution | 12:19 |
| ssam2 | ratmice__: ah, thanks for the explanation | 12:19 |
| ssam2 | yes, fedora produce SRPMS so need to worry about that | 12:19 |
| * bashrc_ thought that sco were defunct | 12:19 | |
| tlsa | I've experimentally pushed a v2 of my patch series to gerrit, and it worked fin | 12:21 |
| straycat | pedroalvarez, basically means i'll have some script that git clones then puts the hook in place for me i guess | 12:21 |
| tlsa | *fine | 12:21 |
| straycat | tlsa, i still get the same error | 12:26 |
| tlsa | have you rebased the patch series to add change-ids to the commit msg? | 12:26 |
| straycat | yeah, i needed to amend though >.> | 12:28 |
| SotK | still the same error? | 12:28 |
| straycat | no, now it's bitching that the emails don't match | 12:29 |
| * straycat sighs | 12:29 | |
| *** fay_ has quit IRC | 12:29 | |
| straycat | http://gerrit.baserock.org/#/c/67/ huzzah | 12:31 |
| * straycat does not think the benefits of this warrant the obviously needless complexity | 12:32 | |
| Zara | how do the methods compare if they're given to a new user? do we have a guinea pig new to both ML patching and gerrit? I found using git to send patches to the ML extremely fiddly at first (I'm thinking that people here might be so used to the ML that it seems simpler because it's familiar, rather than because it *is* simpler-- though that's speculation) | 12:42 |
| ratmice__ | ssam2: fwiw gleaned from $ tar Oxf lsof/lsof_4.83_src.tar | grep -i Copyright | egrep -vi '(Purdue|static)' on baserocks lsof.git | 12:45 |
| *** fay_ has joined #baserock | 12:45 | |
| ratmice__ | with the troublesome files all in the dialects/ subdir, they just nuke all the directories there except linux/ | 12:46 |
| jjardon | Zara: you have a good point there. People in general is biased for what they are used to use. That's why new comers feedback is important | 12:49 |
| persia | The main reason I've been a vocal gerrit advocate was the simplicity of submitting my first patches to a project using gerrit, as opposed to every other project to which I've contributed. | 12:51 |
| Kinnison | persia: It's certainly very good for that | 12:52 |
| * Kinnison is finding that it's also hard to determine if review comments have been addressed | 12:52 | |
| Kinnison | Though there's supposed to be ways to improve that | 12:53 |
| * Kinnison wonders how one gives an opinion on a patch series as a whole rather than on each individual patch in the series | 12:53 | |
| Kinnison | Again, I assume it'll have to be "process" (put it on the tip, or put it on the base fr.ex) | 12:53 |
| Kinnison | tlsa: Your v2 patch series doesn't address at least one of my comments | 12:55 |
| Kinnison | tlsa: Could you go back and decide on responses? | 12:56 |
| * SotK put it on the tip when he reviewed Javier's patch earlier | 12:59 | |
| jjardon | SotK: thanks for the quick review btw :) | 13:01 |
| Kinnison | My concern there is that everything-but-the-tip could be accidentally merged | 13:01 |
| * Kinnison is wondering if he should -1 every patch even if individual patches are "okay" | 13:02 | |
| straycat | Zara, try gerrit and compare :) | 13:02 |
| * Kinnison is quite happy to admit that he finds the ML more comfortable because it's the way he's worked for F/LOSS contribution for nearly a decade and a half | 13:02 | |
| Kinnison | But Gerrit is "usable" | 13:02 |
| straycat | persia, How exactly is it simpler? | 13:02 |
| straycat | Let's ignore the fact that I've lost the freedom of choice mail gave me over tooling, and the fact that this forces all review to be centralised on a single service | 13:03 |
| straycat | And the fact that tooling gerrit *does* have to support offline work is seemingly incomplete | 13:04 |
| * Kinnison wonders if someone wrote a tool to join gerrit to a ML | 13:04 | |
| * Kinnison has a quick google | 13:04 | |
| jjardon | as I said before, I think the whole point of using gerrit is that a machine will tell us if a patch is suitable to consider to merge or not. AFAIK you cannot do that with ML | 13:05 |
| straycat | So run the tests? Why is that hard? | 13:05 |
| Kinnison | jjardon: there's no reason that wouldn't be integratable with a ML using something like patchwork, but yes, tooling already exist for gerrit | 13:05 |
| Zara | straycat: I don't have any patches to send, though I could try with a dummy patch full of nonsense | 13:06 |
| Kinnison | I've not found a showstopper yet in my interactions with gerrit | 13:06 |
| straycat | Zara, okay with me :) | 13:06 |
| pedroalvarez | Zara: I've done the same when trying gerrit :) | 13:06 |
| jjardon | Kinnison: Id suggest 100% patchwork, but doesnt meet the requisite I said before | 13:07 |
| SotK | jjardon: no problem :) | 13:07 |
| Kinnison | jjardon: aye | 13:07 |
| jjardon | straycat: I do not really fancy spending hours building stuff (imageine a patch to upgrade glibc) | 13:08 |
| straycat | jjardon, for baserock/baserock/definitions I'm willing to concede that it's useful | 13:08 |
| straycat | I'm just saddened at the level of complexity this introduces to the review process | 13:09 |
| jmacs | It's perfectly possible to do automatic builds and merges based on a mailing list; it just needs some software to extract patches from it | 13:09 |
| jmacs | I think Kinnison was looking for something to do this yesterday | 13:09 |
| * Kinnison has looked and decided that over-all there's nothing nice | 13:10 | |
| Kinnison | But then again, I'm a very particular person :) | 13:11 |
| * SotK wonders how difficult it would be to write something useable as a trigger for Zuul which watches a mailing list | 13:12 | |
| straycat | SotK, or gets the output from patchwork? | 13:12 |
| SotK | indeed | 13:12 |
| ssam2 | I found submitting patches to gerrit a pain at first, but it's undeniably much easier to merge patches in Gerrit than it is to merge patches from the mailing list | 13:17 |
| ssam2 | and now we have git-review in baserock, submitting patches to morph.git or definitions.git or infrastructure.git for me is literally a case of typing `git-review` | 13:17 |
| * straycat doesn't find the current process for merging series difficult in the slightest | 13:17 | |
| * richard_maw finds keeping up with patches to review difficult though | 13:17 | |
| straycat | richard_maw, patchwork would solve that | 13:18 |
| ssam2 | I don't think anything solves that, except actually having people spending time regularly clearing the review backlog | 13:18 |
| ratmice__ | jjardon: not only the spending hours, but may not have access to all the types of systems baserock is intended to run on | 13:18 |
| ssam2 | only richard_maw seems to really spend time doing that right now | 13:18 |
| richard_maw | straycat: if it does, that's grand, I'm just saying that the current approach is difficult for me to keep up with, rather than saying Gerrit will fix it | 13:18 |
| straycat | SotK, pathwork reads the ml and constructs a list of stuff that needs to be reviewed from it | 13:19 |
| Zara | hm, following instructions, hit difficulty at 'developing your change'-- first bit said to use public key from host machine, but then it says that you develop change in devel vm (do you always have to?), sshing into gerrit. I'm guessing I also need to add the vm's public key to gerrit. | 13:19 |
| straycat | err, ssam2 rather ^ | 13:19 |
| Kinnison | Zara: You use *your* public key and use ssh agent forwarding typically | 13:19 |
| Kinnison | Zara: There's no need for your VMs to have their own keys | 13:20 |
| * SotK doesn't have a key in his VM, but does `ssh -A root@sotk-devel` | 13:20 | |
| Kinnison | Zara: ^^^ exactly that | 13:20 |
| * Kinnison is currently suffering because gerrit says my ssh key is invalid :( | 13:20 | |
| richard_maw | SotK: I do `while ! vmip="$(vm-ip br-dev qemu:///system)" || ! homely-ssh root@"$vmip" -A; do sleep 1; done` | 13:20 |
| Kinnison | Aah apparently this is fixed in 2.11 | 13:21 |
| Zara | Kinnison (and SotK): Okay, I don't know how I'd translate the instructions currently on the wiki to that. | 13:21 |
| richard_maw | SotK: but that's because I prefer not to have to retry logging in to my VM myself, and I CBA remembering the VM's IP address, and I don't run a system that has systemd-machined or libnss_mymachines | 13:21 |
| * SotK looks at the current instructions | 13:22 | |
| Kinnison | Hmm 2.11-rc1 was out a week or so ago | 13:22 |
| Zara | ah, nvm | 13:23 |
| Zara | figured it out, it was the way I was sshing into the vm to begin with | 13:23 |
| Zara | I was dooing 'ssh whatever' rather than 'ssh -A whatever' | 13:23 |
| Zara | all is well in the world. | 13:24 |
| Kinnison | https://gerrit.googlesource.com/gerrit/+/refs%2Fheads%2Fstable-2.11 implies that work is still going on apace on the 2.11 release | 13:25 |
| Zara | I vaguely remember people talking about the 'BAD COPYING' thing, should I do anything to make it go away? | 13:29 |
| Kinnison | merge master of morph? | 13:30 |
| Kinnison | I think SotK's fix got merged | 13:30 |
| SotK | yep, just now | 13:30 |
| Zara | ah, okay, this is just for a dummy test so I'll leave it for now | 13:30 |
| SotK | thanks for the quick reviews Kinnison and ssam2 | 13:30 |
| *** petefoth has joined #baserock | 13:32 | |
| Zara | I got 'missing Change-ID in commit message footer' | 13:35 |
| SotK | you need a change ID in your commits, there is a git hook which adds them for you | 13:36 |
| SotK | `scp -p -P 29418 <Username>@gerrit.baserock.org:hooks/commit-msg .git/hooks/` | 13:37 |
| Zara | ah, I thought I did that, but the wiki instructions are a little different, so maybe it's that | 13:39 |
| Zara | (wiki says /src/morph/.git/hooks) | 13:39 |
| franred | if you go to Projects -> Geneal -> click your project -> clone with commit hook - all of us would avoid confusion (for newbies) | 13:39 |
| franred | for example: git clone http://gerrit.baserock.org/baserock/baserock/morph && scp -p -P 29418 franred@gerrit.baserock.org:hooks/commit-msg morph/.git/hooks/ | 13:39 |
| franred | in http://gerrit.baserock.org/#/admin/projects/baserock/baserock/morph | 13:39 |
| SotK | Zara: the command I posted is intended to be run in your git checkout | 13:39 |
| SotK | if you made the commit before you got the hook you'll need to rebase and/or `git commit --amend` | 13:40 |
| SotK | franred: +10000000000 | 13:41 |
| SotK | :) | 13:41 |
| Zara | hm, the wiki seems to have things in the order 'clone, get hooks, create branch and checkout, then commit' | 13:43 |
| *** a1exhughe5 has quit IRC | 13:43 | |
| SotK | that seems right to me | 13:43 |
| Zara | I followed it in order. Weird. I'll try again in case it's me. | 13:44 |
| Kinnison | getting the wiki to be *clear* and *obviously correct* will help here | 13:44 |
| Zara | I think we should add fran's suggestion to the wiki | 13:45 |
| Zara | (that is, get the command from projects -> General) | 13:46 |
| tlsa | Kinnison: yep, my v2 was more an exercise in seeing what would happen when I pushed it. I only did anything with the first 2 patches of the series | 13:47 |
| Zara | ahh, the wiki instructions mustn't point to master of morph, since this time it's acting differently (copyright didn't hold it up) | 13:51 |
| Zara | oh, unless the fix *just* got merged | 13:51 |
| * Zara toddles off | 13:51 | |
| Kinnison | tlsa: I'll let you submit a v3 before I consdier again then | 13:53 |
| Kinnison | ssam2: Did you decide if you could grant the stream events permission to everyone? | 13:55 |
| Zara | hm, now I'm getting this at the 'push' step: fatal: Authentication failed for 'http://gerrit.baserock.org/baserock/baserock/morph/' | 13:55 |
| *** a1exhughe5 has joined #baserock | 13:56 | |
| SotK | ah, franred's command was an anonymous http clone, you'll need to set your remote to be the ssh url for the repo to be able to push | 13:56 |
| SotK | afaik anyway | 13:56 |
| franred | SotK, yes, it was | 13:57 |
| persia | straycat: As a first benefit, it doesn't require me to sort my MTA. While choice in tooling is nice, getting mail to work from most of the places I go is signficantly less so. | 13:57 |
| franred | but you can clone using ssh if you press the option | 13:57 |
| ssam2 | Kinnison: didn't investigate yet | 13:57 |
| Kinnison | Fair enough | 13:57 |
| Zara | okay, third attempt! :D | 13:58 |
| straycat | persia, Most people who use the internet seem to have worked out how to use email | 13:58 |
| persia | Yes. Most of them use some form of webmail. This is not amenable to patches. | 13:58 |
| jmacs | Why not? | 13:59 |
| persia | Most of the environments in which I have network access block port 25, and many block 587. | 13:59 |
| persia | jmacs: Because patches in HTML make git cry | 13:59 |
| persia | But even if one disables HTML, the problem is usually line wrapping, etc. | 14:00 |
| straycat | persia, So use whatever imap service your webmail provides | 14:00 |
| straycat | or, failing that, rent a vps and deploy your own mta | 14:00 |
| persia | straycat: IMAP doesn't support sending mail. | 14:00 |
| straycat | persia, you were talking about reading patches | 14:00 |
| persia | And yes, it is possible to sort MTA: my point is that it is annoying. | 14:00 |
| persia | I said that my first experience with gerrit for *sending* patches was lovely. | 14:01 |
| persia | For reviewing patches, I find it a bit annoying to fetch the special ref, etc. | 14:01 |
| Zara | patch sent | 14:01 |
| Zara | if you merge it, terrible things will happen | 14:01 |
| straycat | persia, That's nice for you, everyone else seems to manage just fine with mail. My first patches sending to the ml were just lovely because I can use email. I find it slightly annoying that instead of reviewing a series I have to review a dependant set of individual changes and am coerced into using some web ui, that said, now that I've been coerced I'm working out how to make this a less crappy experience than it already is. | 14:04 |
| persia | Excellent for you. But neither of us alone makes a decision. My renewed statement was in support of Zara's comment about the experience for the first-time submitter. I agree that for many of the workflows used by many of the developers of this channel, gerrit lacks tooling. | 14:05 |
| SotK | Zara: how would you compare the experiences? | 14:06 |
| Zara | so far, I've found gerrit easier, though that could mostly due to it being documented | 14:07 |
| Zara | mostly *be due | 14:07 |
| Zara | whereas for the ML I have 'git format patch' and 'git send email' commands, with flags, saved on my computer, that I adjust, because otherwise I have no way of guessing the flags. | 14:08 |
| ssam2 | one idea for how to handle features that are lots of individual commits is to merge them all to a staging feature branch | 14:12 |
| ssam2 | I've been dreading reviewing the OStree patches, because it's such a big series | 14:13 |
| ssam2 | but it doesn't really make sense to merge it piece by piece to 'master' | 14:13 |
| bashrc_ | gerrit is maybe ok and I think I can live without the web UI. I understand the limitations of high traffic mailing lists, having seen what happens for the kernel | 14:13 |
| ssam2 | maybe a good middle ground would be to submit it piece by piece to gerrit, but merge it to a staging/ostree branch instead | 14:13 |
| ssam2 | then when it's all working, staging/ostree can be merged to master | 14:14 |
| *** mdunford has joined #baserock | 14:15 | |
| straycat | After speaking with ssam2 and Kinnison there doesn't seem to be a better alternative | 14:15 |
| Zara | To sum up: That took me an hour, compared to at least 2 afternoons for the ML. *But* gerrit had comprehensive documentation on the wiki, which wasn't the case for the ML process. I like the fact that gerrit has a UI, where I can find the git commands. | 14:19 |
| Zara | *GUI, even. I also want to know if gerrit is compatible with editing baserock files on the host machine. | 14:21 |
| straycat | At least not if we want pre-merge testing for morph and definitions, personally I can live without pre-merge testing for morph, but maybe waiting a few minutes for check is too long | 14:21 |
| *** zoli__ has quit IRC | 14:24 | |
| SotK | given that I've sent patches to fix check in master twice in the last week or so, I'm looking forward to pre-merge testing for morph | 14:24 |
| SotK | Zara: what do you mean by "editing baserock files on the host machine"? | 14:25 |
| Zara | (I don't merge things, so I can only comment as someone submitting patches. So I'd vote for gerrit, given my focus is on UI; I think this makes baserock easier to use, and encourages wider contribution) | 14:25 |
| Zara | SotK: I cloning a baserock repo to the host, changing files on there and then pushing them. So not using the devel vm during this process (eg: I want to edit a README and for some reason I am irrationally attached to gedit or some other tool with a GUI) | 14:26 |
| Zara | haha, ignore that 'I' :P | 14:26 |
| Zara | I can't see why there would be a problem with that but there could be something I've missed. | 14:28 |
| SotK | you can do that just fine with both the ML and with Gerrit | 14:28 |
| bashrc_ | gedit is ok and has a lot of addons | 14:28 |
| * SotK used to be attached to gedit before he started working on Baserock and had to use VMs all the time too | 14:29 | |
| Zara | cool. :) wanted to check in case I discovered some weird incompatibility later. (I used 'irrationally' because I can't explain why I prefer it, but I prefer it a lot. Might just be from a generation used to GUIs.) | 14:29 |
| * SotK doesn't think liking GUIs is irrational :) | 14:32 | |
| Zara | hahaha, I just saw sam's review of my dummy patch, I'm heartbroken ;_; | 14:36 |
| pedroalvarez | heheh | 14:37 |
| pedroalvarez | Zara: do you want to test more things with that patch? | 14:37 |
| pedroalvarez | maybe send a second version? | 14:37 |
| straycat | My favourite editor is a gui, some guis are good, I'd argue the gerrit web ui is not an example of such a ui and that in coercing contributors to use this tool the project risks alienating them | 14:37 |
| straycat | Anyhow, I'm going to crawl under my rock, defeated | 14:38 |
| Zara | aw. :( I think the gerrit web ui needs work but I prefer it to none. | 14:38 |
| persia | I also aggressively dislike the gerrit web ui, and wish there was any alternative that provided the other features. | 14:38 |
| Zara | pedroalvarez: I'm okay for now, but if I'm struck by more artistic inspiration I'll be sure to patch appropriately. | 14:39 |
| persia | git-review seems OK for submission. I've seen people happy with gertty for reviewing, but we need to sort permissions, a certificate (would self-signed do?), etc. | 14:39 |
| Kinnison | I believe we're organising a certificate | 14:40 |
| *** wschaller has joined #baserock | 14:45 | |
| persia | I also believe we're organising permissions :) | 14:53 |
| Kinnison | :) | 14:54 |
| ssam2 | what do you mean by 'permissions'? | 15:07 |
| ssam2 | is this the streamEvents thing? | 15:07 |
| *** mdunford has quit IRC | 15:09 | |
| persia | ssam2: Yes, which I understood you to be doing as soon as you had time (but that didn't look that soon by wall-clock). | 15:11 |
| *** wschaller_ has joined #baserock | 15:17 | |
| ratmice__ | persia: for webmail (well gmail at least), the thing is that the user needs to set the appropriate mime type for patches in their browser | 15:18 |
| ratmice__ | not implying all webmail things may be able to send patches appropriately, but some can be configured to do so | 15:19 |
| *** wschaller has quit IRC | 15:20 | |
| *** mdunford has joined #baserock | 15:23 | |
| persia | ratmice__: Agreed. | 15:24 |
| ratmice__ | anyhow that is something that could be included in code submission guidelines. | 15:25 |
| bashrc_ | can settings be addd to morph at runtime? | 15:28 |
| bashrc_ | s/addd/added | 15:28 |
| pedroalvarez | bashrc_: what do you mean? | 15:28 |
| persia | bashrc_: There's command-line options to override many of the morph.conf values, if that is what you mean. | 15:29 |
| bashrc_ | ok, but can those options be added dynamically or do they need to be specified within app.py ? | 15:29 |
| persia | They are command-line options. So `morph foo bar baz quux ...` | 15:30 |
| bashrc_ | if I want a new commandline option do I need to edit add_settings in app.py ? | 15:31 |
| SotK | bashrc_: you mean can a morph plugin add a new option? | 15:31 |
| persia | If you need to override something not exposed to the command line nor to morph.conf, then yes, you have to modify code. If you encounter one of these, please expose it to a confugrable interface. | 15:31 |
| *** ssam2 has quit IRC | 15:35 | |
| *** mdunford has quit IRC | 15:49 | |
| *** bashrc_ has quit IRC | 15:49 | |
| *** franred has quit IRC | 15:49 | |
| *** sherm_ has quit IRC | 15:51 | |
| *** ssam2 has joined #baserock | 15:55 | |
| *** ChanServ sets mode: +v ssam2 | 15:55 | |
| *** mdunford has joined #baserock | 15:55 | |
| *** bashrc_ has joined #baserock | 16:01 | |
| *** sherm_ has joined #baserock | 16:02 | |
| *** ssam2 has quit IRC | 16:05 | |
| *** franred has joined #baserock | 16:05 | |
| *** sherm_ has quit IRC | 16:08 | |
| *** mike has joined #baserock | 16:08 | |
| *** mike is now known as Guest87179 | 16:09 | |
| *** franred has quit IRC | 16:10 | |
| SotK | Kinnison: I replied to your comments | 16:11 |
| SotK | it seems kinda weird to me that I can vote +1 on my own patches in Gerrit | 16:12 |
| *** franred has joined #baserock | 16:12 | |
| Kinnison | heh | 16:13 |
| paulsherwood | SotK: you could do that on the ML too... but please don't :) | 16:13 |
| SotK | I guess | 16:13 |
| *** bashrc_ has quit IRC | 16:17 | |
| pedroalvarez | https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#NonAuthorCodeReview | 16:17 |
| *** franred has quit IRC | 16:17 | |
| *** franred has joined #baserock | 16:18 | |
| *** bashrc_ has joined #baserock | 16:19 | |
| *** ssam2 has joined #baserock | 16:20 | |
| *** ChanServ sets mode: +v ssam2 | 16:20 | |
| Kinnison | SotK: I responded again | 16:24 |
| SotK | Kinnison: thanks, I will send a reworked series | 16:25 |
| Kinnison | :) | 16:25 |
| SotK | Kinnison: do you have time to take a look at the partial deploy stuff, since I imagine you'll have the same complaint about --partial there too (and `morph deploy CLUSTER CHUNK CHUNK STRATUM...` didn't make much sense to me)? | 16:26 |
| SotK | That is on the mailing list since it depends on my OSTree work (but comments on the approach would be useful) | 16:27 |
| Kinnison | partial deploy?! | 16:28 |
| Kinnison | That sounds odd | 16:28 |
| * Kinnison is almost 1200 mails behind on the ML sadly | 16:28 | |
| Kinnison | I'm unlikely to reach it today | 16:28 |
| SotK | heh | 16:28 |
| SotK | It is odd | 16:28 |
| doffm | Is there an aws deployment extension for baserock? | 16:29 |
| Kinnison | doffm: I don't think I've seen one | 16:29 |
| Kinnison | doffm: though if there is, that'd help me trial an idea I had | 16:29 |
| Kinnison | SotK: what happened re: mason via zuul and turbo-hipster? | 16:30 |
| Kinnison | SotK: almost an entire screenful of baserock-dev is dedicated to a patch series related to that which isn't merged or rejected | 16:31 |
| SotK | Kinnison: tlsa addressed the review comments and sent new patches for it IIRC | 16:32 |
| Kinnison | hmm | 16:32 |
| richard_maw | doffm: no, what's missing is a) enable support for being a XEN guest in the kernel, b) import the disk image build tools and add a write extension to generate images in the correct format and c) have that write extension generate a /boot/grub.cfg (or whatever it's called) since the AWS bootl-loader smells like GRUB rather than extlinux | 16:32 |
| Kinnison | SotK: So he did, pity he didn't say that on the old thread :) | 16:32 |
| * Kinnison sighs in relief as 36 is removed from the total of things he's tracking | 16:33 | |
| * SotK wonders if anyone reviewed that yet | 16:33 | |
| * richard_maw failed to do so last week | 16:34 | |
| richard_maw | but since more patches are going to gerrit instead, I may stand a chance of getting through the mailing list backlog | 16:34 |
| bashrc_ | ah, I may be getting somewhere. Adding gerrit settings to morph/app.py does indeed get past some of the errors I've been seeing | 16:40 |
| *** zoli__ has joined #baserock | 16:43 | |
| pedroalvarez | I wonder what are you trying to achieve | 16:50 |
| pedroalvarez | mixing gerrit settings with morph doesn't sound "right" | 16:50 |
| *** a1exhughe5 has quit IRC | 16:51 | |
| *** wschaller___ has joined #baserock | 17:00 | |
| * SotK looks up what the magic numbers mean in the OSTree stuff | 17:02 | |
| *** wschaller_ has quit IRC | 17:03 | |
| rjek | http://bazel.io/ | 17:04 |
| rjek | That all sounds quite familiar | 17:04 |
| *** wdutch has joined #baserock | 17:06 | |
| tlsa | Kinnison: sent v3 | 17:11 |
| tlsa | and replied to most of your orig comments | 17:12 |
| SotK | rjek: it does indeed | 17:12 |
| *** zoli__ has quit IRC | 17:13 | |
| ssam2 | the input format looks a bit more complex than Baserock definitions | 17:15 |
| perryl | yeah, the user manual seems rather...convoluted | 17:15 |
| rjek | They're not as clear, certianly | 17:16 |
| radiofree | the coloured dmesg output in the new util-linux is beautiful, thanks for upgrading it | 17:17 |
| ssam2 | the concepts of the actual engine must be similar though. I remember someone who works at Google once describing an internal tool that sounded like it worked in a similar way to Morph, when I told them about Baserock | 17:18 |
| ssam2 | but this was a couple of years ago, and it seemed the tool was private at that time | 17:18 |
| Zara | http://bazel.io/docs/governance.html | 17:18 |
| ratmice__ | not sure, it says that all builds are incremental | 17:20 |
| mwilliams_ct | ssam2: if I understand the hacker news post, the internal tool is called Blaze and this is a release of some of Blaze | 17:21 |
| jjardon | radiofree: yw | 17:21 |
| ssam2 | it may be a lot smarter than Morph if it can do incremental builds while also being certain they are reproducible | 17:21 |
| ssam2 | that would be awesome | 17:21 |
| ratmice__ | there was a talk that cary coutant did a while back, on incremental linking in gold, where he briefly discussed some of the google build stuff iirc | 17:22 |
| rjek | rummage in its sources for ideas and inspiration | 17:22 |
| ratmice__ | IIRC rather than storing like entire sets of source trees they more rely on checking out one source file + include files rather than having an entire dedicated staging area | 17:24 |
| ratmice__ | so, the compiles I think are a lot more parallel | 17:24 |
| jjardon | sorry, I always get confused about this: if I want a binary in /bin in the final system, should I use --bindir=/bin or --bindir="$DESTDIR"/bin in configure time? | 17:24 |
| bashrc_ | it looks like setting values within the firehose plugin isn't early enough to prevent configuration settings from not being recognised | 17:24 |
| pedroalvarez | jjardon: /bin | 17:25 |
| jjardon | pedroalvarez: thanks | 17:26 |
| * jjardon fixing patch | 17:26 | |
| *** Krin has quit IRC | 17:26 | |
| * jjardon just discovered how amazing "git review" is | 17:26 | |
| CTtpollard | git-review is nice | 17:27 |
| ratmice__ | so like, compiles happen in parallel on various machines, and the object files get sent to the linker machine which links in object files as they come in | 17:28 |
| ratmice__ | anyhow I believe the systems must be quite different | 17:28 |
| ssam2 | that does sound very different | 17:31 |
| ssam2 | and a lot more complex | 17:31 |
| ratmice__ | http://linuxfoundation.ubicast.tv/permalink/108/iframe/ | 17:34 |
| ratmice__ | that was the talk iirc (been some time since i've watched it, so hopefully recalling correctly) | 17:35 |
| tlsa | more like distcc then? | 17:36 |
| bashrc_ | is there some process needed to enable a plugin, other than setting MORPH_PLUGIN_PATH ? | 17:37 |
| richard_maw | you can either do that, or put the plugin in morphlib | 17:37 |
| tlsa | morphlib/plugins | 17:38 |
| bashrc_ | the values from --config seem to take effect before the plugin is enabled, causing errors | 17:39 |
| *** mdizzle has quit IRC | 17:39 | |
| ssam2 | if that's so, it must be a bug in cliapp. But I think we'd have already spotted it if that were the case | 17:45 |
| ratmice__ | tlsa: not sure, one thing is for certain they don't need to take legacy build systems into account :) | 17:45 |
| bashrc_ | I guess I'll need to read the morph code to confirm the order in which things are defined | 17:48 |
| richard_maw | bashrc_: what exactly do you want to do? | 17:48 |
| bashrc_ | read some config settings with --config, where the settings are for a plugin | 17:53 |
| bashrc_ | exec ${MORPH} firehose "$@" --config=/etc/firehose.conf | 17:54 |
| bashrc_ | if the settings are defined in the plugin enable, the morph command crashes saying it doesn't recognise the settings fields | 17:55 |
| *** pdar has quit IRC | 17:55 | |
| *** tiagogomes_ has quit IRC | 17:56 | |
| richard_maw | That's odd, the distbuild plugin adds settings, and we add config files like that for various distbuild bits like you are trying to do, and it adds settings in the `def enable(self)` function | 17:56 |
| bashrc_ | I'll look at how disbuild does it | 17:56 |
| richard_maw | from what you describe, it sounds like it does exactly the same thing as you | 17:57 |
| *** pdar has joined #baserock | 17:58 | |
| *** bashrc_ has quit IRC | 18:01 | |
| *** gfinney has quit IRC | 18:04 | |
| *** Guest87179 has quit IRC | 18:08 | |
| *** ssam2 has quit IRC | 18:16 | |
| *** zoli__ has joined #baserock | 18:27 | |
| Kinnison | tlsa: I'll try and look at it tomorrow | 18:30 |
| *** wschaller___ has quit IRC | 19:08 | |
| *** edcragg has quit IRC | 19:10 | |
| *** gary_perkins has quit IRC | 19:35 | |
| *** rdale_ has quit IRC | 19:59 | |
| *** zoli__ has quit IRC | 20:54 | |
| *** bjdooks has quit IRC | 21:48 | |
| *** bjdooks has joined #baserock | 21:49 | |
| *** robtaylor has quit IRC | 23:18 | |
| *** robtaylor has joined #baserock | 23:18 | |
| *** zoli__ has joined #baserock | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!