=== vorlon` is now known as vorlon
[19:45] <doko> tdaitx: could you have a look at Debian #928185?
[19:45] <doko> and the code search results
[19:45] <doko> https://codesearch.debian.net/search?q=java.vendor.*Oracle
[19:46] <doko> so libspring-java isn't affected, it's a comment
[19:48] <doko> trying to convince myself that the gradle code is dead code
[19:59] <tdaitx> doko: looking into that
[20:06] <tdaitx> doko: from the code search results the only one that I can tell for certain to be affected is wss4j which will cause different behavior from before
[20:06] <tdaitx> I agree that libspring is not affected
[20:06] <tdaitx> and I am trying to understand that gradle test
[20:15] <tdaitx> I _believe_ that the test is mocking some stuff and checking that the "probe test" works as expected for the mocked entries it has, so that it does not matter what the actual jvm does
[20:15] <tdaitx> at the same time we don't seem to run any tests from gradle's platform-jvm project so no way to verify that
[20:16] <tdaitx> doko: so overall I would say that wss4j might need some patching
[20:19] <tdaitx> it could rely on java.specification.vendor instead
[20:20] <tdaitx> althought we would need to check what ibm/hp jvms report for java.specification.vendor
[20:22] <tdaitx> and yeah, changing the vendor flag is going to cause pain for some, but I believe it is important to set them to the right thing
[20:22] <tdaitx> although I understand why people have been using it - feels similar to the ppc64/ppc64el when folks were using the properties to tell the archs apart
[20:23] <tdaitx> maybe we should document that change somehow?
[20:28] <doko> well, it's a little bit late for that. But I would like not reverting that.
[20:33] <tdaitx> I don't believe there is a need to revert it - at least for now, might change my mind if someone has a really good point on it
[20:34] <doko> yeah, more a thing for Debian
[20:34] <tdaitx> but I think it is going to blow down as the ppc64/ppc64le changes and code will adapt to the new vendor flags
[20:44] <tdaitx> doko: btw, I remember you mentioned that scilab could be updated to 6.0.2 but the bug is there as well as reported by the user, I am still able to reproduce it (LP: #1825037)
[20:44] <tdaitx> I couldn't find anything (so far) in their bugzilla about this issue
[21:32] <vorlon> tdaitx: can you advise what we should be doing with the reverse-depends of clojure1.8 in the archive? Debian has removed clojure1.8 from unstable
[21:47] <doko> tdaitx: ENOCLUE, there is comment in the bug report claiming that it worked in disco ...
[21:48] <doko> anyway, afk now