SilicaRice
hmm it would be nice to be able to distinguish "can't find peer" (i.e. couldn't find LeaseSet, or couldn't find peer's gateway) from "can't connect to peer" (i.e. can't connect to peer's gateway)?
SilicaRice
guess I'll just have to "warm up" the tunnel a bit
zlatinb
zzz: aand MR !62
zlatinb
and here it is built on the M1 zab.i2p/libjbigi.jnilib
zlatinb
so what do I do next? Just rename it according to ?? convention, stick it in jbigi.jar and it automatically works?
zzz
<zzz> the test is to figure out what name NBI wants, then name it that and put it in installer/lib/jbigi, then build updaterWithJbigi, then see if it extracts it out of jbigi.jar into $I2P on restart
zzz
<zzz> should be libjbigi-osx-armv8_64.jnilib based on how the linux one is named
zlatinb
and that's that, jbigi problem solved
zzz
so to review, there was no libjbigi.jnilib file in $I2P, you restarted with the update, and now there is, wrapper log reports the extraction, and it's the right file, and it's reported on /logs page
zlatinb
no I didn't do the u0pdater path, just rebuilt the easy install bundle and it loaded fine. I'll do the updater test now
zzz
should work the same. if $I2P is readonly (like for bundle), it will do the extract to /tmp every startup. On a standard install it will do the extract once to $I2P
zzz
iirc
zzz
on std. install wrapper log might give you some more info. either way the /logs page version info should be definitive
zlatinb
well wrapper didn't work at all because of missing native lib, but runplain worked as expected
zzz
oh yeah
zzz
last q, is it possible or necessary to apple code sign the jnilib file like we did for the windows dlls? the current jnilibs aren't signed afaik, they were built by tuna 6 years ago
zzz
I assume osx isn't complaining now
zlatinb
yes but the scripts in i2p-jpackage-mac force-sign everything including the jre
zlatinb
notarization requires same signer for all binaries
zzz
so the jnilibs are signed on-the-fly for the bundle?
zlatinb
yes
zzz
ok so that leaves the standard install. is there any benefit to signing the new one or the old ones before checking them in?
zzz
or any risk in doing so?
zlatinb
atm I don't think so, ofc with apple you never know
zlatinb
although what's more likely is they will forbid non-notarized code completely
zlatinb
also we don't offer standard install for download anymore on /download/mac
zzz
ok, didn't know the std. install went away
zlatinb
what was the command to run the benchmarks?
zzz
java -jar i2p.jar will give you a list
zzz
nativebiginteger was one, keygenerator too
zzz
anyway, agreed there's no reason to sign the jnilib before checkin
zlatinb
yeah the bundle has to have all binaries signed by whoever is notarizing
zzz
glad the NBI extraction just worked and we didn't have to mess with it
zzz
when you check it in please include info on the build environment and any benchmark results of interest
zlatinb
too late lol
zlatinb
the benchmarks are in line with what we saw on the rPi - ~40% faster modpow
zlatinb
one remaining problem is with updates - anyone who installed the intel bundle is stuck with it unless they manually change the news urls
zzz
you're free to write a news entry for your users with instructions, or the instructions could be just uninstall/reinstall
zlatinb
they would need to nuke router.config before re-installing, not simple
zlatinb
I'll probably add instructions on /download/mac for that special case
zzz
so an arm bundle gives two speed boosts, it's not emulated, plus jbigi
zlatinb
well the intel bundle had jbigi too but yes
zzz
guess we don't know if emulated jbigi was a benefit or not
zlatinb
hard to say unl]ess we buildin benchmarks to the console
zzz
oh yeah, you said you can't just java -jar ... to test
zlatinb
yeah rosetta requires a full] app bundle.. then does some jit and aot together
zzz
ok so you're going to propose this tomorrow as a new official product?
zlatinb
yes I can't think of any showstoppers at this time
zzz
just gotta work on the news feed, and find a couple testers
zlatinb
the changes to i2p.newsxml should be straight-forward
zlatinb
testers may be a bit harder because I don't want to do notarization unless I absolutely have to
zlatinb
so any tester would have to be able to use curl/wget
zzz
looks like next JRE fixes are in two weeks, probably want to wait for that
zlatinb
actually that's another thing for the meeting - I expect to be away from my main station until end of July
zlatinb
if there is a super urgent jre fix someone else will have to build it
zzz
speaking of bundles, eyedeekay what's the status of the windows one graduating out of beta? last discussed at the meeting 3 months ago:
zzz
(04:07:35 PM) zzz: great. you have a target date for when you will propose transition out of beta?
zzz
(04:08:02 PM) eyedeekay: As soon as users receive an automatic update I will consider it ready
zzz
zlatinb, I'd propose that it go up on the mac page as beta, and you put an entry in the news feed that you want people to report test results
zlatinb
Let me post on reddit and maybe in few days
zzz
and that will hopefully let us take it out of beta fairly quickly
zlatinb
I'm reluctant to notarize it unless I absolutely have to
zlatinb
notarization is always a pain
zzz
let's wait until after the meeting and maybe after 18.0.2
RiceSilica
request: SAM command "FIREWALL INFO" reply "FIREWALL STATUS RESULT=OK IPV4=[OK/FIREWALLED/SYMMETRIC_NAT] IPV6=[OK/FIREWALLED/SYMMETRIC_NAT]"
zzz
or maybe even after the 1.9.0 release, if it's that much of a pain
RiceSilica
or uh
zlatinb
its just that the notary keeps state for every attempt and I have to be careful what I submit
RiceSilica
[OK/FIREWALLED/SYMMETRIC_NAT/NONE]
RiceSilica
would be useful for selecting whether to use 0-hop (for ultra-low-latency connections)
zzz
RiceSilica, router status stuff not really appropriate for SAM, we have i2pcontrol API for that
RiceSilica
at least on the server side. the client can happy eyeballs it.
RiceSilica
(besides, if the server is v6-only and the client is v4-only, a 1-hop client tunnel would still be required, even if both sides were respectively "OK")
RiceSilica
i2pcontrol reports this stuff?
zzz
yes
RiceSilica
hmm
RiceSilica
it only reports it globally, not ipv4 vs ipv6
RiceSilica
yeah that would be an issue
RiceSilica
hmm...
RiceSilica
how does i2p handle the IPv4/IPv6 split? does it just prefer dual-stack tunnel participants or...?
RiceSilica
also, proposal: when using SAM, allow setting TCP_NODELAY, perhaps through the currently-unused i2p.streaming.profile option?
RiceSilica
that's TCP_NODELAY between the SAM bridge and the SAM client/server, rather than anything on the I2P side
RiceSilica
(but maybe another option name would be better for that)
RiceSilica
(or just set it by default because it's a local connection anyway)
eyedeekay
zzz we have automatic updates, there were a few bugs in how it handled external I2P installed which needed to be fixed in 1.7.5-1.8.0, 1.9.0 is IMO ready to start moving out of beta
eyedeekay
*will be
eyedeekay
1.8.0 probably was ready, but I didn't change it because of the issues when using an external, non-Jpackaged I2P in the 1.7.x series
eyedeekay
I had also considered changing the extension loadout before changing out of beta, but I'm going with the cautious assumption and keeping the extensions TBB-like