Also if you already have other templates that could be used, you just need to change the template names in the yaml file, you can easily find them when you search for huggle/warn-

Hello, sorry for coming so late to the party, what exactly do you need help with right now? I can already login to viwiki using Huggle, but obviously in read-only. If you want to enable write mode, I recommend translating the edit summaries in configuration file and importing / creating the warning templates:

Hello, yes, but where?

I guess my answer resolved this?

Ah yes, it's essentially tool tip for a forward button, which works just like in your web browser.

It seems that xmlrcsd crashed on wmflabs, I don't really know why. It's restarted.

I am wondering how we could implement this, so that this path can be specified on one place only. Because it needs to be defined both in Huggle source code somehow (so that Huggle knows where to look for extensions) as well as CMake so that it knows where to write the compiled extensions.

there is currently no maintainer for debian package format, it was replaced with snap format which is built automatically via Canonical's build farm. Unless someone takes over maintaining the .deb packages, I think we should obsolete it.

I'd like to at least connect beta releases to edge channel is there a way to do that?

I updated it to latest but I'd like to know how to automate this

how can I change everyone to edge? I just know how to update to specific version

lowering down since almost everything that devs are needed for was done, if you need any further help, please let me know

ok I couldn't find any issue after I removed it, I believe it's resolved now, this version with fix was not released yet, and even when it is, old versions of Huggle will still be used for a while though.

I can't really reproduce this, it seems it's not happening on Mac, but this should probably fix it: https://github.com/huggle/huggle3-qt-lx/commit/c6f964f60b2ba519e2643e21d060d61f7c6eebac

So the proposed fix should be implemented as this:

The thing is I don't understand how could the stack jump from DisplayRevid to PostProcessEdit(), the function DisplayRevid doesn't have any call to that in it:

it isn't easy to repoduce, my guess it happened once only and never since?

I see

I mean, try to get some inspiration from UNIX, it was invented around 1970 and most of old C code from that time still compile on modern UNIXes... that's what I call a stable API :P

There are multiple problems with this, it's burried in very old code that I wrote so long time ago I am not sure about the logic anymore. This commit removes it - https://github.com/huggle/huggle3-qt-lx/commit/8638b179899ff92b2a3ef2defcb6d17de511a791 but it needs some intensive testing, because I literally just removed the rvparse from API call and now I am observing what it broke.

but is that something very specific only to wikidata? I am not sure if there is parsedcomment in other wikis? Or is there?

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

Really curious what else did I break while fixing this bug :)

So I investigated this and found the reason, it's related to flow of current message system in connection with reverting:

note this bug is not "invalid" there is just no better closure reason, such as "unreproducible"

I have to close this task as it's impossible to reproduce for me, if you run to this issue again, please have a look which feed provider is active - XmlRcs, IRC or API. Also please copy paste full system log from Huggle. That's very important for me.

this task is very hard to reproduce

Sorry to be late to the party - regarding "undocumented options", we keep documentation for options on place that not every one is probably aware of, here: https://www.mediawiki.org/wiki/Manual:Huggle/Deploying/DefaultConfig.yaml and even the options you claim to be undocumented, are in fact there ;)

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

ha, seems this was forgotten during migration to new server

both instances were shut down, you can delete them in 14 days from now

❤️

So I successfuly migrated wm-bot core and bouncers, next step is to move MySQL DB, then instance wm-bot2 can probably be nuked.

NAT is not going to be possible as old instance is going to be deleted

I just spent couple of hours trying to get it to run with latest mono / dotnet core and there are some major issues with getting old 3rd dependencies running, so it will need a bit more time

I will try to implement this during this year's hackathon

I successfuly created a new instances for PG and wm-bot, now I need to migrate the data from old ones and then it should be done

Hello, sorry for the delay, all obsolete instances are gone now

Sorry I wasn't much available during holidays, there is a long-needed migration to new VM being prepared, hopefully in next few weeks I will get to it

Yes, that's where the code is and that's where you should fix it!

Yes, this task is still open, it's just extreme lack of active developers that resulted in nobody looking into this.

+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