07:35 <travis-ci> jruby/jruby (master:705834d by Charles Oliver Nutter): The build was canceled. https://travis-ci.org/jruby/jruby/builds/512969031 [211 min 57 sec]

12:56 <lopex> https://lwn.net/SubscriberLink/784124/2595e4df117dc86a/

12:56 <lopex> "The developers implementing case independence in the kernel decided to limit it to the UTF-8 encoding, presumably in the hope of solving the problem without going entirely insane"

12:59 <lopex> also https://elixir.bootlin.com/linux/v5.0/source/include/linux/dcache.h#L40

15:02 <enebo[m]> kares: you know of any reason not to update postgres jdbc adapter?

15:02 <enebo[m]> kares: I realized we no longer need java 6+7 jars too from that PR

15:20 <kares[m]> ene

15:21 <kares[m]> enebo: we do need older jars, since the driver might be used with older ARs (and thus e.g. on JRuby 1.7)

15:22 <kares[m]> enebo: a reason not to update is that we haven't released AR 5X without the postgres jdbc specific hack

15:23 <kares[m]> which is actually what Daniel is trying to achieve at https://github.com/jruby/activerecord-jdbc-adapter/pull/994

15:23 <kares[m]> guess he hit that while trying to get JNDI support for PG

15:45 <enebo> kares[m]: we do not use older ARS for 50+ though since they won't work will they?

15:45 <enebo> For those people should continue to use 1.4.x right?

15:46 <kares[m]> the JDBC driver version isn't limited with AR-JDBC

15:47 <enebo> oh yeah hmm

15:47 <kares[m]> we could do that now in the JDBC gem by requiring newer ruby_version

15:47 <enebo> yeah we could major rev and then put the floor to 2.5.x maybe

15:47 <kares[m]> but since there's a CVE and support for newer auth schemes in the jars there's no reason not to support Java 6/7

15:48 <kares[m]> esp. since its meant to be a thin wrapper around the jar -> support the same Java

15:48 <enebo> yeah that's true...I just looked at the rm/add on 3 jars and desired less

15:48 <enebo> I will let PR person know about this

15:49 <kares[m]> the PR seemed fine - we could push it as is (after verifying the jars are not tampered with)

15:49 <kares[m]> but we shall update AR not to rely on the PG driver hack or verify the hack is working

15:50 <kares[m]> which seems to be the case since the CI run ...

15:50 <enebo> yeah I guess it must work since master was green with it

15:50 <kares[m]> so I think its good to go unless I forget smt :)

15:50 <enebo> unless we don't test directly with those jars in ci and use a gem

15:50 <kares[m]> yeah

19:16 <OlleJonssonGitte> Hello, a stacktrace which has "block in <main>" instead of "block in (root)", is that normal? https://travis-ci.org/rspec/rspec-core/jobs/514297630#L1662

19:16 <OlleJonssonGitte> A stacktrace/an error (sorry for the imprecision)

19:20 <enebo> OlleJonssonGitte: I would not be surprised if we just have an older Ruby's error message there but raising in a block would be a simple one-liner where you can see and compare

19:34 <OlleJonssonGitte> I did some comparing, and there's _some indirection_ going on. The "boom" is rendered in an Aruba test. I'll keep this one "under investigation" before asking for more detailed assistance.

19:46 <enebo> OlleJonssonGitte: ./core/src/main/java/org/jruby/Ruby.java: static final String ROOT_FRAME_NAME = "(root)";

19:58 <OlleJonssonGitte> Appreciate it!

20:00 <headius[m]> Olle Jonsson (Gitter): if you can isolate where we differ it's easy to fix...I think we started doing <main> before MRI started doing (root) or vice versa and we never matched up

20:03 <OlleJonssonGitte> The other matrix elements of the test suite (all versions) pass, though. They're all kinds of versions.

21:26 <headius[m]> Olle Jonsson (Gitter): Huh that could be due to changes we've made regarding stack traces (fairly recently) or stuff done over the past year to improve how well we match CRuby trace elements