I'll take a look at it.
.Seth
On 15 Jul 2019, at 12:32, Michael Dopheide wrote:
> Updating myricom to build against the install tree looks like it's
> going to
> work and will be much cleaner.
>
> -Dop
>
>
> On Mon, Jul 15, 2019 at 9:46 AM Justin Azoff
> wrote:
>
>> Speaking of that, you m
Seth,
github.com/dopheide-esnet/zeek-myricom contains Jan’s changes as well as
removes the enum duplicate if you want to steal those.
Dop
On Tue, Jul 16, 2019 at 9:29 AM Seth Hall wrote:
> I'll take a look at it.
>
>.Seth
>
> On 15 Jul 2019, at 12:32, Michael Dopheide wrote:
>
> > Updatin
Ah, thanks! I'll pull from there.
.Seth
On 16 Jul 2019, at 10:37, Michael Dopheide wrote:
> Seth,
>
> github.com/dopheide-esnet/zeek-myricom contains Jan’s changes as
> well as
> removes the enum duplicate if you want to steal those.
>
> Dop
>
>
> On Tue, Jul 16, 2019 at 9:29 AM Seth Hall w
Does this branch look crazy to you at all?
https://github.com/sethhall/bro-myricom/tree/zeek-updates
My plan is to rename the whole project to zeek-myricom and set the alias
as suggested by Jon once I have some external validation that this
branch works for more people than just me. :)
.Set
It builds and works for me against master. Should we change the
bro-pkg/zkg requirement to > 2.0? It should be backwards compatible only
as far as when all the required includes, etc were included in the install
tree. Not sure how far back that change was made.
-Dop
On Tue, Jul 16, 2019 at 11:
On Tue, Jul 16, 2019 at 10:14 AM Michael Dopheide wrote:
>
> It builds and works for me against master. Should we change the bro-pkg/zkg
> requirement to > 2.0?
At a glance, I only see a "bro-pkg >=1.5.0" requirement due to use of
`aliases` metadata field.
> It should be backwards compatible o
Ok, I updated the dependencies listed bro-pkg.cfg to get the correct
bro-pkg and bro.
Are there suggestions about how I should merge this branch into master
and not break people installing this on current releases?
.Seth
On 16 Jul 2019, at 13:36, Jon Siwek wrote:
> On Tue, Jul 16, 2019 at
On Tue, Jul 16, 2019 at 10:55 AM Seth Hall wrote:
> Are there suggestions about how I should merge this branch into master
> and not break people installing this on current releases?
Best would be to actually test against 2.6 and master to see if anything breaks.
At a minimum, actually I see th
On Fri, Jul 12, 2019 at 7:15 PM Michael Dopheide wrote:
>
> Generally the idea is to be mostly backward compatible so people aren't
> forced to make any changes to external plugins, but looks like there's a
> couple small things we overlooked or had not tested that we'll want to fix
> before the
