Hello, I am Petr Bena also known as Petrb (my SUL). I am a volunteer developer working on multiple projects, including Huggle, wm-bot and many others
Fri, Oct 22
Thu, Oct 14
Aug 13 2021
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.
Aug 12 2021
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.
Aug 6 2021
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:
Jul 4 2021
Jun 29 2021
Jun 28 2021
Jun 14 2021
Jun 13 2021
ok I think this is done
Jun 3 2021
recent changes notifications were all migrated but you may need to run @recentchanges-on to get them enabled
Jun 2 2021
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.
May 24 2021
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.
May 23 2021
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:
May 22 2021
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.
May 21 2021
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).
Nov 2 2020
Oct 5 2020
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.
Jul 29 2020
It seems that xmlrcsd crashed on wmflabs, I don't really know why. It's restarted.
Jul 22 2020
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.
Apr 25 2020
I'd like to at least connect beta releases to edge channel is there a way to do that?
Apr 24 2020
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
Apr 13 2020
lowering down since almost everything that devs are needed for was done, if you need any further help, please let me know
Apr 9 2020
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
Apr 6 2020
So the proposed fix should be implemented as this:
Apr 5 2020
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?
Mar 31 2020
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?
Mar 29 2020
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
Mar 27 2020
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 ;)