Why am I subscribed to this?

In T211723#4956579, @Cirdan wrote:

OK. I will treat it as a learning opportunity and set up a test page while I get the bot back up and running. Do you have a schedule for the beta11 release?

Should be fixed in beta11.

Fixed in beta11. There was an error in detecting multiline formats that are inconsistent. It thought all multilines were inconsistent.

Fixed in beta11

Do you have an order of preferred formats. IABot attempts to recognize a date format among a defined list of acceptable formats. Please least from most commonly used to least commonly used so I can update the bot accordingly.

Dead is not a domain level status. It only applies that status to all known URLs currently in the DB. If you want to mark the domain itself as dead, you should blacklist it.

Something there caused the definitions data to break. Since I can't make out what caused it, we will have to rebuild it. I disabled Literatur though.

Template does not support archive-url and was ignored by IABot.

I've disabled handling of Literatur. You can disable templates to be handled by inputting "NULL" as the map.

This is an issue with the Literatur template configuration. IABot just doesn't know how to effectively handle this template.

Fixed in beta11.

What did you do when it disappeared. The definitions somehow became corrupted. You can fix it by clicking the refresh button. Unfortunately, when the data is corrupted like that all manual data is wiped during the refresh. Mappings will need to be redefined if needed.

Thanks for your patience. After rewriting the parsing engine and diligent testing, I can confirm this will be available in beta11.

@aborrero are you saying that my VM is down, or just not reachable? Because cyberbot-exec-iabot-01 is InternetArchiveBot, which I kind of need access to.

*cough* what? My instances were literally just moved several months ago. How can the RAID be failing there already?

Not hitting anymore Varnish error messages. Cyberbot's operation also appears to be stable now.

If it redirects to a live link, that would be why.

Question, when will this patch go live?

In T215375#4940048, @jrbs wrote:

In T215375#4940043, @Cyberpower678 wrote:

In T215375#4940010, @jrbs wrote:

@Cyberpower678 How did you confirm the account owner?

This is very odd and I see no reason why the password would suddenly stop working after a rename... I feel like it's more likely he just forgot it.

Could you ask them to email ca@wikimedia.org and we'll take it from there?

The user approached me via email and asked me to rename them to bring them in compliance with the username policy. Before proceeding, I asked them to login to their account and confirm the request by leaving a message on their talk page, which they did. So this is clearly not a case of forgotten password. Evidence of this request is https://en.wikipedia.org/w/index.php?title=User_talk:M_at_nethistory&diff=880667008&oldid=731251920&diffmode=source

Ah, that sounds perfect.

So with that being said, I can confirm the email address that should be associated with this account, and can be reasonably sure this is not a case of a forgotten password as they logged in just prior to being renamed.

That being said I will forward him to that email so he can get this fixed.

Great, thanks. :) I'll act on it when we get it.

In T215375#4940010, @jrbs wrote:

@Cyberpower678 How did you confirm the account owner?

This is very odd and I see no reason why the password would suddenly stop working after a rename... I feel like it's more likely he just forgot it.

Could you ask them to email ca@wikimedia.org and we'll take it from there?

This patch doesn't seem to actually fix the issue, just restructure some of the code to make it seemingly easier to exempt Cloud VPS/Toolforge IPs?

For the record, I have confirmed the account owner and have an email address for them.

In T214956#4917794, @Ahonc wrote:

PHP locale should know them, should not it?

січень — січня (January)
лютий — лютого (February)
березень — березня (March)
квітень — квітня (April)
травень — травня (May)
червень — червня (June)
липень — липня (July)
серпень — серпня (August)
вересень — вересня (September)
жовтень — жовтня (October)
листопад — листопада (November)
грудень — грудня (December)

Do you want to provide me with all of the months? I don't speak Ukrainian, so I can only do my best when implementing foreign languages. :-)

Updated configuration values. Should take effect in a few hours.

I'm also boldly raising the priority as from what I gather I'm likely one of many, many of which aren't even aware of what's happening and why.

@bd808 just invited me here. Ever since the Cloud VPS migration, Cyberbot has been hitting that rate limit rather frequently, despite its query rates being nowhere near the allowed rate limit, unless I have a rogue process somewhere that I'm not seeing. This only tells me that whatever IP range I am sharing is being blanket blocked, blocking everything behind it.

In T214313#4897303, @faidon wrote:

Per our earlier conversations (T208986, T174596, T209011), I think we should just use the WMCS public IP space to make these kind of exceptions (which also could be dedicated for Toolforge), and not make rate-limit exceptions on 172.16.0.0/12 space.

IMHO between all those "short-term" fixes we're just getting deeper into tech debt for everyone, and we should just cut our losses short and just do the right thing here :)

Well IABot can save to the Wayback Machine, and it probably will, but it's primary job to find an archive for the URL and add it to the Wikidata entry.

To answer your questions, IABot will be using the wbgetentities and wbeditentity API calls on MW.

In T143488#4843283, @Multichill wrote:

In T143488#4677644, @Cyberpower678 wrote:

I am currently at that Hackathon in Thompson 150 right now. If you care to meet me during lunch break I will be happy to work on this with you.

That didn't work out. Can you please have a look at my previous questions? You don't seem to be working on it and the task does not contain enough information for others to work on this.

It's there, it's just a limitation of the bootstrap theme. Try changing to a different theme.

You would go to the Parameter mapping and it will pull up individual maps. Blank fields use the default map for the wiki. You can also use "#REDIRECT[[enwiki]]" or some other acknowledged wiki-code to use a map from that wiki instead.

In T208188#4801099, @Anomie wrote:

Looks like you somehow reposted T208188#4795556? It was already answered above.

In T208188#4794513, @Anomie wrote:

In general, there shouldn't be scripts in the site's common.js that are hitting external APIs. If such scripts are needed for some reason, the necessary domains could be added to $wgCSPHeader after being evaluated by the Security team.

[Error] [Report Only] Refused to connect to https://archive.org/services/context/books?url=https://en.wikipedia.org/wiki/Easter_Island because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
[Error] Origin https://en.wikipedia.org is not allowed by Access-Control-Allow-Origin.
[Error] XMLHttpRequest cannot load https://archive.org/services/context/books?url=https://en.wikipedia.org/wiki/Easter_Island due to access control checks.
[Log] The requested service https://archive.org/services/context/books?url=https://en.wikipedia.org/wiki/Easter_Island failed: 0, error (index.php, line 160)
[Error] Failed to load resource: Origin https://en.wikipedia.org is not allowed by Access-Control-Allow-Origin. (books, line 0)

It is being enforced. I have the console errors to go with it.

In T208188#4794513, @Anomie wrote:

In general, there shouldn't be scripts in the site's common.js that are hitting external APIs. If such scripts are needed for some reason, the necessary domains could be added to $wgCSPHeader after being evaluated by the Security team.

And having just finished reading this ticket, it seems we are heading towards user authorized exemptions. It brings up the question what about scripts going into the site's common.js that may make queries to external APIs. That would even the hit the readers or break the JS for non-users.

I would very much love to see a whitelist implemented. I for one would like to xtools.wmflabs.org and archive.org whitelisted as it's blocking an existing, and trusted, gadget from working, and blocking a new one that I'm trying to port for Internet Archive.

The bot operates on more than two dozen languages and each implement deadurl in their own way. The code is universal on these wikis and adding specific code just for enwiki just to simply suppress a parameter is not beneficial to the maintenance cost.

It's not acknowledges as an valid archive because IABot doesn't know anything about it. Can you provide details?

This doesn't appear to be happening anymore.

Appears to be getting filled now.

Unfortunately, this can't be acted on as the data is now in IABot. Please re-report if it happens again, and leave untouched so it ca be investigated.

It's not doable as the same code is used on multiple wikis which makes it impossible to manage. There's no harm it being there, and this has been the standard since IABot was designed 3 years ago.

Whitelist status removed.

IABot is not capable of this at this time. It should be tasked to a different search and replace bot for now.

I just submitted a vote to poll 750 successfully.

Why am I getting emails to this task?

Yep definitely a result of fixing the previous bug, but since this doesn’t break anything, I won’t rush out a fix for this.

Best I can do for now is to prevent the submission of new jobs and let the current jobs run to completion.

In T203304#4559985, @Cirdan wrote:

OK, thanks for explaining. Can't the jobs be put to the end of the queue then at least? Or is that not possible either?