zzz
ping eyedeekay re: jbigi
eyedeekay
pong zzz
zzz
ok
zzz
so, while it would be nice to have the ability to build new jbigi binaries on windows...
zzz
it's not a part of our release process and shouldn't be a part of yours
zzz
the binaries are prebuilt in installer/lib/jbigi
eyedeekay
OK I'll switch to those
zzz
just take the jbigi.jar from the xxx-windows-only target and make sure it's in your build
zzz
it's all done for you
zzz
building all the binaries takes hours
zzz
whatever your issue is, don't try to fix it by building your own out of core/c
zzz
does that make sense eyedeekay ?
eyedeekay
Yeah sure, although I'm just slightly confused about "hours" is that on a much older machine? For me it was more like 20 minutes.
eyedeekay
Is hours what you experience on the laptop ~10 years old, the one that you own that I also own?
eyedeekay
I'm curious because that big a discrepancy might mean something is not getting built, and that I need to examine to see if I inadvertently broke something
zzz
take a peek at what zab did to force it into jpackage
zzz
eyedeekay, the build.sh script only builds ONE binary.
zzz
to generate binaries for all CPUs, you need mbuild-all.sh
eyedeekay
Oh that makes sense
zzz
we have 34 binaries :)
zzz
eyedeekay, it's been 7 years since we last updated them, last done by hottuna3, if you now have the ability we could plan to do it sometime this year
zzz
it's a big testing effort though and not any fun at all
zzz
windows wrapper also 7 years behind... that's considerably easier
zzz
actually 8 1/2 years, last done by kytv
eyedeekay
I don't know how far I would get off the bat, I assume I don't have all the cross-compilers I would need configured to get all 34 binaries built successfully yet but I did manage to get everything I tried to build(Linux amd64, Linux ARM, Windows amd64) to complete successfully
eyedeekay
The buildscript seems to run a suite of tests after completing
zzz
but you were building on windows, right?
eyedeekay
My changes from last night were to get it to work on Windows, but I built on Linux as well to make sure I didn't break other platforms fixing Windows
zzz
if you can build 1 on windows you can build all 34, no addtional tools or x-compilers needed
eyedeekay
OK then I guess I'm probably good to go
zzz
just grab the jbigi.jar from the standard build, get it into and back out of the installer, check the /logs page, done and done
zzz
also note that all our dll's in installer/lib/jbigi are signed by zab
zzz
tl;dr do it the easy way :)
eyedeekay
Can do, thanks for the help zzz
eyedeekay
Where should I start reading to build the Windows wrapper?
zzz
for another day, but installer/lib/wrapper/README.txt and installer/lib/wrapper/win64/README-x64-win.txt
zzz
basically, tanuki doesn't provide win64 binaries with a permissive license, so we have to build are own, also we stick our toopie icon in there
zzz
*our own
zzz
eyedeekay, also FYI I asked the translators to work on android and gave them a deadline of Sunday (time unspecified)
zzz
be sure to reserve some time this week to make sure android is happy
eyedeekay
OK will do
zzz
thanks, good luck with jbigi.jar
zzz
eyedeekay, I'm updating the roadmap, and pushing everything of yours to 2.2.0, sound right?
zzz
done
eyedeekay
Yes please
eyedeekay
Thank you
zzz
and for some reason the roadmap said this release would be 1.11.0 and git blame blamed me
Opicaak
zzz, may I get a description for i2cp.delayOpen and i2cp.newDestOnResume? Neither R4SAS or I could find anything about it in the docs.
zzz
Opicaak, R4SAS, while labeled as "i2cp" options, these are actually implemented in i2ptunnel
zzz
newdest is briefly mentioned in i2p-projekt.i2p/spec/configuration but delayopen is not, I'll fix that
zzz
anyway
zzz
delayOpen opens the local port as usual, but does not build tunnels until the first socket comes in
zzz
newDestOnResume only applies if closeOnIdle=true, and creates a new Destination before building new tunnels when the next socket comes in
Opicaak
I see, thank you
zzz
hopefully that makes sense, and happy to answer any other questions
zzz
as these two are implemented in i2ptunnel, they would not be available via SAM
zzz
as these two are implemented in i2ptunnel, they would not be available via SAM
zzz
you caught me at a good time, I'm in the middle of some other doc updates
Opicaak
Great timing, could you describe delayOpen? Not sure if I missed it when disconnected. Or should I just wait for updated docs?
zzz
delayOpen opens the local port as usual, but does not build tunnels until the first socket comes in
zzz
newDestOnResume only applies if closeOnIdle=true, and creates a new Destination before building new tunnels when the next socket comes in
zzz
hopefully that makes sense, and happy to answer any other questions
Opicaak
Thank you
Opicaak
Would be cool if there was a way to refresh circuit. Sometimes I get Denied or Banned for "excessive requests" when it was the first request I made. Getting new identity is pain and can't imagine others doing it, it has to be simple, just like Tor Browser has new circuit button, similar feature should be on i2p.
zzz
if you get denied on your first request, it's not a per-user throttle, and a new dest ("circuit") wouldn't help
zzz
also commented on the GH ticket
Opicaak
Well the user (or me in this case) would need new b32 address, right?
Opicaak
That's what I did to access the website.
zzz
not if it's a total-connections throttle
Opicaak
Oh, right
Opicaak
Thanks for the reply on github.
zzz
np
zzz
also, you're disconnecting here hella-lot, so you may wish to invesitgate why and tune things up further before your next release
zzz
I also recommend grabbing and testing latest i2pd source now as a part of your release prep
Opicaak
Could be i2pd 2.44.0 related? I've noticed those frequent disconnects and can't really figure out why it's happening.
zzz
I thought you weren't on 2.44, your last release was before that
Opicaak
Yes, last "release" is on 2.43.0, I'm on a pre-release, that is using 2.44.0
Opicaak
But thanks to this issue, I just noticed another issue with macchanger not executing properly.
zzz
well, I'm not a i2pd expert, and it's strange for me the one to be giving you all this i2pd advice, but they're doing an unscheduled release soon for a reason (as am I)
Opicaak
Looking forward to that
Opicaak
And thanks for all of the help.
zzz
give latest source a try, and your place for i2pd help is ilita #dev
Opicaak
Will do
zzz
that's your job as a "downstream", to always test with the latest upstream, report bugs back asap, and release shortly after they do
zzz
not just have somebody they've never heard of dump a huge wishlist on them
Opicaak
And have I? It's mostly to make i2p more usable, easy to access and better for everyone else, not me.
zzz
contribute and they might be more willing to give you what you ask for
Opicaak
I do believe I'm contributing already a lot.
Opicaak
I'm not exactly sure where you are coming from or why you made this 180, I'm really confused.
zzz
I know you never talked to me before a couple days ago. If you already have a good relationship with the i2pd dev team, that's great, and I'm sure it will continue
Opicaak
Not only have I spent a lot of time creating the OS, contributing knowledge and time, but it also costs me a lot of money. Servers, domain name and lost profits. I didn't have to create the OS at all, but seeing that noone made it in 20 years, I made it and haven't asked for anything - from anyone.
zzz
all I'm saying is that if they've never heard of you or your project, it's a big ask of them out of the blue
zzz
sorry didn't mean to come off 180
Opicaak
Obviously I'm not forcing them to implement anything, I personally don't care if they add anything I suggested, it's really not for me, but everyone else.
zzz
sure
zzz
and ofc you are contributing to the network and your users
zzz
just trying to get bitcoin and everybody on the same page so we can fix the network, not sure if there's other projects out there with 150 tunnels each
zzz
happy to have you hear, apologies again
zzz
*here
Opicaak
I'm just "advocating" for current and new i2p users.
Opicaak
like I said, I personally don't care if any of it gets added.
Opicaak
Just throwing some ideas around
Opicaak
For the new circuit feature, I could've made a browser addon, but there is no API in i2pd for it, so can't do that. Possibly in the future I might revisit it. But like you said, it's perhaps useless anyways.
T3s|4
Opicaak: for i2pd feature requests; please contact 'orignal' (not a misspelling) on #ls2, here. He is there now, as always :)
Opicaak
If the OS did contribute to the higher network load, then I'm sorry about that, I had no idea or intention it would cause this.
zzz
#ls2 is for joint discussions between java i2p and i2pd; for i2pd-specific stuff, please use ilita #dev
Opicaak
And about frequent IRC disconnects, it seems like using single in/out tunnel isn't ideal.
zzz
hmm
Opicaak
But that means the Client Tunnels are about 40 now, instead of 30-ish.
Opicaak
But still disconnects.
obscuratus
Opicaak: I'm not sure whether you're using Java I2P, I2PD, or something else, but, yeah, two tunnels (2 in and 2 out) makes a big improvement. It's tunable in each.
obscuratus
I thought two tunnels was the default in Java I2P, and three or more in I2PD.
Opicaak
I lowered it from 5 to 1, it was using about 150 client tunnels, but seems like using just one makes it really unstable, not only IRC but everything else too.
Opicaak
5 is the default for i2pd
obscuratus
5 is a touch high IMHO, but 1 tends to be unreliable.
obscuratus
Opicaak: 150 client tunnels just for IRC?
Opicaak
No, the entire OS.
obscuratus
OK.
Opicaak
Monero wallet, web browser, IRC, SMTP/POP, etc.
dr|z3d
Opicaak: check your irc client ping timeout value. for best results, you want it high, around 600s.
dr|z3d
from the I2P+ faq:
dr|z3d
Some IRC clients are configured to disconnect from the server if there's been no communication with the server for a period of time, which can sometimes be problematic for I2P IRC if the ping timeout value is set too low. Setting the ping timeout value in your client to a high value (e.g. 320 seconds) will often result in a more robust connection to the network. In hexchat you can configure the value by typing
dr|z3d
/set net_ping_timeout 320. This will write the value to your hexchat.conf file.
Opicaak
Thank you, it was at 60, this might have been the issue all along.
dr|z3d
more than likely.
dr|z3d
you'll probably still experience the occasional disconnect, but not as frequently.
Opicaak
I might need to restart hexchat actually, I've edited it in the config file.
dr|z3d
Regarding your OS, depending on how you have things configured, I2P or I2P+ might make more sense than i2pd, given the provision of included apps such as a bittorrent client (XD is crap), webmail client, basic webserver etc.
dr|z3d
and of course you also get the features you're looking for such as delayconnect, new key on reopen etc.