@eyedeekay
&eche|on
&kytv
+R4SAS
+RN
+acetone
+dr|z3d
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
FreefallHeavens
Gid
Irc2PGuest13560
Irc2PGuest1893
Irc2PGuest32938
Irc2PGuest4253
Irc2PGuest8259
Leopold
Minogami
Onn4l7h
Sleepy
Soni
T3s|4_
Teeed
aargh1
admin
anon4
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
idk
itsjustme_
j6
limak
not_bob_afk
polistern
poriori_
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
u5657
user100
x74a6
zzz
eyedeekay, git.idk.i2p 500
zzz
dr|z3d, I see you're pulling in our MRs before we are... would appreciate it if you could assist us by noting your test results on the original MRs
zzz
even a simple 'LGTM' is helpful
dr|z3d
yeah, pulling early zzz in the hope the concurrency issue resolve. as for what I've pulled, all looks ok from here.
zzz
great. just trying to think of ways to get things working a little smoother here
zzz
if you're going to be linux-next bleeding edge, then explict feedback on our MRs would help the MR authors and reviewers
zzz
also, once you comment, presumably you'll get an email if the MR is updated, which you otherwise might miss
dr|z3d
your stuff looks uncontroversial, not much to say on those commits. and the rest of the stuff looks like reversions in one shape or another.
zzz
at the very least, you glanced at it and found it worthy; if you tested that it does what it claims, even better.
zzz
right now we have no idea
dr|z3d
I'm waiting for the moment I can say "yes, finally my flags work again and my router doesn't blow up when I attempt to lookupRouterInfoLocally. we're not there yet.
zzz
nor are you commenting on the MRs you don't pull early for (perhaps) apparent flaws
zzz
I'm saying with more explicit feedback from you on our gitlab we might get to that moment sooner :)
dr|z3d
I hear you. If I have anything meaningful to report, I'll comment on the MRs. For now I don't, other than LGTM. :)
dr|z3d
eyedeekay's getting stack traces from where they might be helpful, so I'm not just sitting here doing nothing.
dr|z3d
*me
zzz
thanks. I'm trying to figure out the trick to getting my reviewer to review (((
eyedeekay
Omg it's getting to be every damn update now, gitlab is killing me with this
zzz
yeah dr|z3d backchanneling stack traces to idk is fine but if neither of you is entering a ticket then I'm wasting my time doing the ticket and looking like a crazy person being the only one filing tickets
dr|z3d
I'd use the work meticulous. You don't look crazy.
dr|z3d
I'm also not entirely sure of the scope of the traces, whether they're helpful or not, which is why I'm sending them up the chain before putting them on gitlab.
zzz
great
dr|z3d
If you want to get eyes on them as well, I'll post them here.
zzz
I think more dev-in-the-daylight would be helpful, yes
zzz
and I'm gently suggesting that some process improvement, all around, will be necessary to get the next release out, not on any particular schedule, but _ever_
eyedeekay
Ok gitlab's back
zzz
thanks eyedeekay
eyedeekay
Going through and commenting on some of these new MR's
eyedeekay
Gitlab updates have been troublesome lately, they break something important about once every 4 days
zzz
yikes, maybe don't update that often?
eyedeekay
Delicate balance it seems, they also seem to put out a critical security advisory about once a week
zzz
:(((
eyedeekay
I try to time it so we get them fast but not so fast I can't see it coming, but there was no ticket for this one because the fix for the last one was to disable migrating the databases when updating and the fix for this one was to re-enable it and then disable runners
eche|off
yeah, we got severyl issues with upgrading gitlab over here, to
eche|off
and off again...
eyedeekay
Big pain in the but
eyedeekay
Gitea has SAMv3 compatibility now though
zzz
as I noted in #405 yesterday, I did some debugging, and I think the gitlab POST errors are a websocket problem
eyedeekay
Sound probable I disabled POST limits, using a standard tunnel usually bypasses the ws issues, want me to set you up a standard tunnel so you can see the difference between the 2?
zzz
nah, I think the next step is for you to reproduce it and compare in-net and clearnet behavior, and see why /-/cable is returning 404
zzz
I don't think it's an actual POST, but something post-like. Because the submission works every time behind the scenes, the webpage just thinks it errored
zzz
so I think it maybe needs the websocket to get the confirmation? not sure
zzz
you probably know a lot more about how it works, and can make sense of the firefox network console
eyedeekay
Ok will do and add my findings to the ticket today
zzz
great. still probably low priority, just annoying