@eyedeekay
&eche|on
&zzz
+Irc2PGuest38623
+RN
+RN_
+Stormycloud
+T3s|4
+cumlord
+dr|z3d
+eche|off
+mareki2p
+not_bob_afk
+orignal
+postman
+qend-irc2p
+snex
+wodencafe
Arch
BubbRubb
Chrono
Danny
DeltaOreo
FreefallHeavens_
HowardPlayzOfAdmin1
Irc2PGuest43798
Irc2PGuest63779
Irc2PGuest70600
Over
Sisyphus
Sleepy
T3s|4_
Teeed
aargh1
ac9f_
acetone_
b3t4f4c3__
bak83_
combed_tree328
dr4wd3
duanin2
duck
john231
leopold__
poriori_
profetikla
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
vivid_reader56
w8rabbit
weko_
x74a6
xHarr
qend-irc2p
dr|z3d: But then the existing tunnels will be restarted, and doing it outside of an API feels a bit like a workaround, doesn't it?
zzz
you could write a socks-to-sam or http-to-sam proxy in an hour each, you don't need to ask anybody else
dr|z3d
re tunnel restart, not sure, orignal will know.
qend-irc2p
zzz, absolutely, I agree - it's definitely possible to write a SOCKS-to-SAM or HTTP-to-SAM proxy in an hour. But if it's implemented once in the router or as part of the official tooling, it can be reused by many developers, significantly lowering the entry barrier. Otherwise, everyone ends up spending that same hour individually - adding up to hundreds of hours across the community :)
zzz
then publish your code after you write it ))
snex
or you can publish your proxy and people can just use it
zzz
and in practice, there's always a http proxy at port 4444, so no need to worry about a programmatic interface for it
qend-irc2p
Without a standard solution, many developers will create their own ad-hoc implementations. But having a well-designed, built-in solution - developed by someone experienced - ensures it's robust, reliable, and available out of the box
zzz
SAM's been around almost 20 years, nobody's asked
zzz
got the debug logging for the console done, they switched to slf4j, had to write a service provider.
dr|z3d
*thumbs up*
zzz
eepsite on jetty 12 is next
zzz
but far enough that I think november 2.11.0 target is doable
zzz
it's as ugly as predicted but starting to get my head around it
dr|z3d
well, we have skipped 2 complete versions, so you knew it wasn't going to be painless :)
zzz
11->12 was the big one
dr|z3d
dang, that's chunky.
zzz
eyedeekay, gitea down
StormyCloud
server is physically on, so must be something software related
zzz
he's been fighting it for a week
zzz
but thanks for checking
eyedeekay
I'm reaching it here, just a sec
zzz
eyedeekay, what's all the new output chatter from gitssh about onions and garlics and mirrors and ports?
zzz
and what is it doing, and why is it so slow?
eyedeekay
log leak, should be fixed this morning, Should
zzz
ok, I know that I keep saying that gitssh "seems" slower than with gitlab, both before and after the usual dialog
zzz
are there a bunch of hooks that are running inline that are slowing things down?
eyedeekay
not it's nearly identical
eyedeekay
It's a standard tunnel, 1 hop, connected to openssh,
zzz
it's not the communcation that's slow. It's that it seems to be doing things in the background that take several seconds, both before and after the usual "remote:" lines
zzz
wip jetty 12 PR up git.idk.i2p/I2P_Developers/i2p.i2p/pulls/512 console only, eepsites broken
dr|z3d
nice, zzz, smells like progress :)
snex
Isn’t this going to break eepsites that use custom jetty configs either way?
zzz
hopefully not, we'll write a migration tool
dr|z3d
eyedeekay: maybe cron job, nulling the logs every so often with echo > /location/to/logs.txt .. once an hour? up to you.
zzz
as we just did for the refid issue, that migrator will run when 2.9.0 first runs
eyedeekay
dr|zed that's not how the log is leaking, thanks anyway
dr|z3d
oh
dr|z3d
maybe just log to console then? would that plug the leak? docs.gitea.com/administration/logging-configuration
dr|z3d
also make sure gitea's running in production mode, not developer mode.
eyedeekay
It's running in prod mode, I got in a hurry and set some erroneous logs in my soft-fork, should run straight-and-true until release in the shape that it's in now, will refrain from messing with it until after