I believe it's migrated now

yes it works now

Hello, sorry for late response. I don't have any Mac with new ARM based CPUs, so I can't really provide those. Might get my hands on one this year due to laptop rotations in company I work for, will see.

I merged this but hopefully one day we figure some more clean method to do this, maybe Qt has some date parsing function but from what I remember it always worked with OS locale and wasn't easily overriden to match wiki language

Did you check if project options parser-date-prefix and parser-date-suffix aren't able to deal with that? I remember I already implemented some sort of customization for the date parser specifically so that it can be tweaked for non-English projects. I would rather avoid hardcoding any language specifics into the core code.

Full log of huggle startup would help, it always contains the basic info needed for debug.

Hello, sorry for the late response, I am far less active these days within the Wikimedia world than I would like to be.

Hello, sorry for the late response, I am far less active these days within the Wikimedia world than I would like to be.

also this

I am trying to follow instructions here - https://wikitech.wikimedia.org/wiki/News/Toolforge_Stretch_deprecation#Move_a_grid_engine_webservice

@dcaro ok but can we somehow check if this URL https://huggle.toolforge.org/ is grid or k8s?

I found this related merge request in Huggle repo - https://github.com/huggle/huggle3-qt-lx/pull/351 where @Se4598 updated the updater URL from / to

I would like to explain what is this being used for right now and confirm that shutdown of this service is not critical for Huggle operation:

I think I added him, but the portal has changed significantly since last time I was doing this, so I am not sure if this is sufficient, he has "reader" permissions. I don't see options to give any more permissions other than full project admin role. Can you please try if you can ssh and use sudo?

fixed - someone started that nohup job while old one was still running, I cleared all running ./es2r.py and it fixed itself.

Hello, the problem was with python script that uses event source and forward data to redis. This event source system is not very reliable (which is one of main reasons why xmlrcs was created so that tools like wm-bot can use that instead of implementing unreliable protocol).

hello, xmlrcs was migrated to xmlrcs2 instance, I kept the old one just in case I forgot anything, but most likely it can be wiped out

hmm I will try to look into this soonish, I am quite busy these days, but from what I remember it's indeed nearly impossible to relogin when using bot password. But I can try to see what that meta=tokens query would do, maybe we are still logged in, just the tokens indeed got invalidated. I have to admit I never knew they can randomly be invalidated, I thought they are supposed to be valid for the time of whole session.

also keep in mind that querydump may contain data that some people consider sensitive (their on-wiki activity obviously and some tokens, that are most likely expired), so make sure you inspect whatever you are about to send. If you hit this bug, I will need just last few queries, here is example of querydump from my PC:

ok guys, it would really help if you could provide the querydump - I don't know which platform you are on, but if it's Windows, then you can just copy or modify Huggle shortcut and add --qd on end of it, then also change the working path to whatever path you want querydump to be stored in. You can also add a full path after like --qd C:\Temp\huggle.txt just make sure that huggle process will be able to write there.

btw you can try give it some absolute path instead like --qd /home/tobefree/snap/huggle/2773/.local/share/Wikimedia/Huggle/dump

That's because you are running it via snap, so it's running inside a container, therefore huggle is not allowed to create any files on real filesystem, it creates the dump in container overlay FS which is cleaned up by the snapd when it exits. You would need to run it natively without any such restrictions.

Also I would like to stretch out that Huggle is very specific in its error messages, what you see is product of https://github.com/huggle/huggle3-qt-lx/blob/a57125fca76d1f5daa98896e3a3c00f146b2e555/src/huggle_ui/reloginform.cpp#L146

Relogin form itself is triggered by function Configuration::Logout(WikiSite *site) which is called on multiple places, mostly when MW returns error code badtoken

Now to the bug itself - this is a very old bug that I am trying to fix, which is actually reason why many of debug switches were implemented. I don't really know if it's somewhere in MediaWiki or Huggle itself.

First of all, regarding the console outputs - these work only in console (--help etc) you won't see any output if you start the application using link from desktop, these switches are more useful on UNIX systems, here is example:

ok I think this is done

recent changes notifications were all migrated but you may need to run @recentchanges-on to get them enabled

I appreciate your swiftness but I am not sure if everyone else does ;) it took me few days to notice what is going on with freenode, and I am fairly active in IRC world, I assume it will take months to realize this for others. Also running wm-bot on freenode costs us nothing, so unless new freenode staff starts causing us some serious issues with bot operation, I'd keep it.

I created a new plugin that allows bridging freenode and libera - basically if you are admin in both channels, you can just run @bridge-on and bot will mirror messages in channel to second network. It's possible to create one way bridge as well (just don't run @bridge-on on other network). This works only if bot is present in same channel on both networks and if channel names are same.

I made a hack that will forward github messages via netcat to both instances of bot, but its still working with MySQL DB of freenode instance, so that's where the configuration of webhooks take place.

everyone has read access and everyone can submit pull requests, people who can merge pull requests:

I copied the old infobot DB's for all channels, including channels that bot is not in right now, that means when you @join the bot to these channels, their DB will prefill with freenode values.

also regarding "lack of maintainers" - I was never opposing having more maintainers of wm-bot (we actually have quite a team for such a small service) - if anyone can be trusted, has the necessary skills (knows GNU/Linux and IRC) and wants to help to maintain the bot, I am happy to give you access. Technical documentation is here: https://wikitech.wikimedia.org/wiki/Wm-bot I try to keep everything documented, and bot itself is fully open sourced: github.com/benapetr/wikimedia-bot

just few updates:

ok perhaps what would help me with deciding is knowing how urgent is this issue - do we need to fix it ASAP? if yes, I would just run another instance on same infrastructure, then we can migrate it later.

they are on "debian-10.0-buster (deprecated 2020-10-16) ", I don't mind installing them again, despite I am going to lose that nice hostname

@Legoktm I added you to horizon

ok, I am wondering if we keep them both on same VM, or just create a new one for libera, perhaps we could name it wm-bot-libera? From what I remember we also had dedicated postgre instance, but maybe postgre is now available as a service in cloud environment? that would be even better I think.

ok well, that's really sad news to me, I liked the old freenode. I am definitely going to support this new network that old staffers moved to. I already registered my nickname petan there.

Hello guys, sorry didn't notice this at all, I have no problems sharing the maintainer access to wm-bot with anyone, lots of people already asked in the past and I gave access to all of them (at least the trusted ones).

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?