12:07 <headius[m]> jnr-ffi 2.1.13, jnr-enxio 0.26, jnr-unixsocket 0.29, and jnr-posix 3.0.55 have been released to address PPC issues in jnr-ffi and jnr-posix

12:15 <headius[m]> enebo: if you get a chance review https://github.com/jnr/jnr-posix/pull/145

12:16 <headius[m]> I added a signature for fcntl(int, Fcntl, int) that duplicates another I added years ago called fcntlInt but I wanted this other one for a couple reasons

12:17 <headius[m]> 1. there's a previously-deprecated signature fcntl(int, Fcntl, int...) that never actually passed any of the int varargs along... that was a cause of one of the PPC failures. By adding this fcntl signature anyone still calling that deprecated signature with a single int will get the right result (either by recompiling or because I fixed this one pattern in the deprecated code)

12:18 <headius[m]> eh formatting, that's two reasons really... it fixes this issue if you recompile and it fixes this issue if you don't

12:18 <headius[m]> I'm not sure why I added fcntlInt instead of this overload... hopefully it wasn't a problem with overloads conflicting

12:18 <headius[m]> alternatively we could deprecate that, and possibly remove the deprecated signature that didn't work

12:35 <travis-ci> jruby/jruby (master:324278e by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/678136723 [141 min 32 sec]

21:25 <headius[m]> sunuva

21:25 <headius[m]> I missed a dependency in jnr-unixsocket

21:25 <headius[m]> enebo: we need a single jnr master project of some kind

21:25 <headius[m]> this is even more annoying with the dependency convergence requirement

21:26 <enebo[m]> I have never been a fan of this many sliced stuff but if there is a nice way to aggregate then I am all for that

21:26 <headius[m]> I don't know that there is, I just want to find one

21:26 <enebo[m]> I am also ok with releasing same copy of stuff with different version numbers

21:26 <headius[m]> JRuby itself is a multi-module project and it doesn't have to be so complex for jnr

21:27 <enebo[m]> 1.38 of the entire jnr tree who cares what has changed

21:27 <headius[m]> I was actually thinking we'd just roll everything to the first major version none of them have reached, like 4.0

21:27 <headius[m]> and just have a jnr project with subprojects or submodules that build at the same time

21:28 <enebo[m]> sounds reasonable

21:28 <headius[m]> re-released jnr-unixsocket with updated jnr-posix

21:28 <enebo[m]> one problem with jnr is some projects are litered into multiple deps which also dep on each other

21:29 <enebo[m]> hmm litered

21:29 <enebo[m]> what did I actually mean to type there :)

21:29 <headius[m]> littered?

21:29 <enebo[m]> no I don't think so

21:29 <headius[m]> yeah you got me

21:29 <enebo[m]> jnr-constants I think is in 2 deps and one of those deps depends on the other

21:29 <enebo[m]> or something like that

21:30 <enebo[m]> some weird tree in the sense that some changes ripple more than others

21:30 <headius[m]> I don't think there's any circular dependencies but it's not consistent

21:30 <enebo[m]> I think from a management standpoint having all them in one repo as n artifacts which all build would just be trivial to manage

21:30 <headius[m]> like jnr-enxio does a bunch of posix calls but doesn't use jnr-posix

21:30 <enebo[m]> yeah I did not mean circular

21:31 <headius[m]> jnr-unixsocket uses both jnr-posix and jnr-ffi, and then does Channel stuff via jnr-enxio which skips jnr-posix

21:31 <enebo[m]> just an indirect dep which has to be updated in both

21:31 <headius[m]> so it's a little bit of a mess

21:31 <enebo[m]> so you have to update all three at same time or the tree is out of date

21:31 <headius[m]> yeah

21:31 <enebo[m]> one artifact will be wrong

21:47 <headius[m]> enebo: this is a big item we may want to consider doing before 9.3: https://github.com/jnr/jnr-constants/issues/68

21:47 <headius[m]> as it is now we're just going to be broken on PPC because it has differing values for some constants

21:47 <headius[m]> we're less broken with my fixes but I can't do anything about the bad constants