+1 Experienced and trusted

this diff information is retrieved by RC feed provider, it's not computed by Huggle

wm-bot uses space as parameter separator, so I think in this case:

xmlrcsd crashed for some reason

@Rfarrand hi Rachel, did you get the e-mail from him? Can you please have a look in that?

In T226575#5284998, @Urbanecm wrote:

@Petrb There's no need in sharing the IP in a private way, at the end, it'll still be public. Two ways how to get this done:

• upload a patch against operations/mediawiki-config, file wmf-config/throttle.php (should be self-explanatory) and ping me to deploy it
• make the IP available to me somehow (in this case, I'll need datetimes as well - whole Wikimania?)

range is here: https://phabricator.wikimedia.org/P8657

@Az1568 here is the range https://phabricator.wikimedia.org/P8657

This is still happening

BTW just to clarify why this task is open for so long time with no update - it's simply not clear to me how to, step by step, implement most of this stuff that was proposed into Huggle's interface. Perhaps this should be split into multiple separate tasks that each defines what should be changed.

There is - this was requested long time ago and JS extension was written for that purpose see https://www.mediawiki.org/wiki/Huggle/JS

it seems the warning is already in place

That means - I believe it's a server side issue, nothing that can be easily fixed on client side

I suppose that the connection is left open but for some reason server stops sending any new data to these "old" connections?

this is how .net was setup in past

https://github.com/benapetr/wikimedia-bot/commit/5725ff30e62ace47ad2599f72b6f9e7886bb0618

Please keep in mind that Huggle considers only recent templates, see this option

OK - there is actually a unit test for this, maybe we can expand it.

Please reopen if this solution doesn't work for your use-case

For example:

Not sure if this is going to work since you are using deprecated config format (new one is yaml), but according to documentation at https://www.mediawiki.org/wiki/Manual:Huggle/Deploying/DefaultConfig.yaml

found only one

Here is first floor - https://commons.wikimedia.org/wiki/File:CZ_NTK_first_floor_map.svg

here is code: https://github.com/benapetr/wikimedia-hackathon2019/blob/master/ntk_shape.svg

I created this basic SVG shape, some stairs are missing though. I will expand it with text labels tomorrow for each level. I hope it will do, but it's a SVG so it can be easily improved.

OK I will try to turn this into some SVG, each level has same wall layout (almost same) so it's more or less making that one grid and then it's just different labels. Hopefuly this weekend it's gonna be finished

@Aklapper @Malyacko have SVG version of your drawing? can you share?

https://github.com/huggle/XMLRCS/commit/414512851d4a73c0b2afdbec174725bbd54d8078

Yes the problem is probably somewhere on Event Streams side, this code: https://github.com/huggle/XMLRCS/blob/master/src/es2r/es2r.py no longer seem to receive any new pages.

https://github.com/huggle/huggle3-qt-lx/commit/c02a2ff841f31a78ecd358e192c92999c2a4f1ce

FYI here are IP ranges: https://phabricator.wikimedia.org/P8134

that's normal behaviour, feed will download N last edits, no matter of time and then it will keep adding only newer edits, so on wikis with low amount of edits per minute, it may download even hours or days old edits.

updated instructions and 3.4.6 windows installers

woot - I found the problem - SSL libs we are shipping are compiled with VS 2013 and therefore require vcredist for VS 2013 to be installed on system. Most of Windows installations that are reasonably old and have many apps installed probably have them, but clean state Windows 10 do not.

DLL dump from broken instance:

Using https://download.sysinternals.com/files/ListDlls.zip I figured out that on my machine (where I build windows installer) installed Huggle loads both DLL libraries needed for SSL to work. On my test Windows clean install, after running exactly same installation both DLL's aren't loaded even if they are present in same folder as huggle.exe

ok here we go: https://phabricator.wikimedia.org/P8134

@Az1568 hello, I already know the IP range but I would rather not post it publicly to avoid any unexpected DDoS attacks during conference time, is there a way for me to deliver it privately to you?

Canonical file is always here: https://petr.insw.cz/huggle/huggle.ova

I think this task makes sense even if it never occured to me to hit this kind of problem. I don't see any valid use-case to make it possible to have 2 commands with same name but different letter case, so it shouldn't break stuff.

So according to response I got from staff, they will create a separate temporary network with SSID of our choosing (any ideas @Rfarrand? NTK-Wikimedia was proposed by them, IDK if it has to have NTK prefix).

today I briefly visited NTK just to confirm some basic info, there are multiple wi-fi's in place and all of them are restricted and not publicly accessible, which is unexpected, but I suppose that they will generate some conference-wide login for us or unrestricted temporary network. The networks in place are separate, one of 2.4GHZ and other one 5GHZ, info in screenshots: