Problem 0 here is that I can't find anything that looks remotely like a license inside of /data/project/request and the tool pre-dates the selection of a default license at tool creation time.

bd808: ·The Problem with the tool show up when you do a

tail review-lag.err

Table dewiki_p.flaggedpage_pending vanished. Whatever magic is needed, if this magic fixes the tool, all is fine.

Mentioned in SAL (#wikimedia-cloud) [2025-03-20T20:54:38Z] <lucaswerkmeister> added tools.toolforge-standards-committee to maintainers so non-root TFSC members are still able to process the request at T389540

In T389540#10659302, @Wurgl wrote:

bd808: ·The Problem with the tool show up when you do a

tail review-lag.err

Table dewiki_p.flaggedpage_pending vanished. Whatever magic is needed, if this magic fixes the tool, all is fine.

• T368939: [wikireplicas] Views flaggedpage_pending and flaggedtemplates are broken
• T368050: [wikireplicas] Automated tests for views -> T368050#9938892

In T277883#9817112, @gerritbot wrote:

Change #1025821 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Get rid of flaggedpage_pending table

https://gerrit.wikimedia.org/r/1025821

Merged on 2024-05-21. That's nearly a year ago. Maybe the view was there but dangling until recently?

Warning code of unknown license ahead.

#########################
# select and insert lag #
#########################

bot_wiki.query('select count(*) as lag, datediff(NOW(), STR_TO_DATE(MIN(fpp_pending_since), "%Y%m%d%H%i%s")) as diff, (select count(*) from dewiki_p.user_groups where ug_group="editor") as total_editors from dewiki_p.flaggedpage_pending where fpp_pending_since>20131230001539;')
pending_result = bot_wiki.fetch_one()
flagged_lag = str(pending_result[0])
flagged_lag_oldest = str(pending_result[1])
total_editors = str(pending_result[2])

I have no idea what the replacement for that is. @Ladsgroup may be able to say if there is some reasonable substitute.

Merged on 2024-05-21. That's nearly a year ago. Maybe the view was there but dangling until recently?

The errors started shortly after that: Last successful run was on Jun 10th. Took us a while to notice it, and then some more time to actually start the adoption process.

I have no idea what the replacement for that is.

According to https://www.mediawiki.org/wiki/Extension:FlaggedRevs/flaggedpage_pending_table, we should probably use the flaggedpages table instead

Yup, I removed it. The patch that removes it: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1025821 has a couple of examples of how to change it. e.g. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1025821/4/includes/backend/FlaggedRevsStats.php

In T389540#10659244, @bd808 wrote:

Problem 0 here is that I can't find anything that looks remotely like a license inside of /data/project/request and the tool pre-dates the selection of a default license at tool creation time.

That's unfortunate, but I'm not planning to reuse, distribute or share the code in any way, but just to fix the bug mentioned above. FNDE suing me for illegally creating a derivative work by fixing a bug is a risk I'm willing to take.

In T389540#10663104, @Tkarcher wrote:

In T389540#10659244, @bd808 wrote:

Problem 0 here is that I can't find anything that looks remotely like a license inside of /data/project/request and the tool pre-dates the selection of a default license at tool creation time.

That's unfortunate, but I'm not planning to reuse, distribute or share the code in any way, but just to fix the bug mentioned above. FNDE suing me for illegally creating a derivative work by fixing a bug is a risk I'm willing to take.

For a different reason, I was reading the ToU of WMCS/Toolforge today and it has this https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use#6._Keeping_your_software_Open_Source

If you do not specify an Open Source license for code that you have written and hosted on WMCS, you agree as part of using this service that you license it under the GNU General Public License version 3.

IANAL but maybe it makes things easier?

That provision was introduced in May 2023, and we know that FNDE logged in to Toolforge in Jan 2024 (T320003#9474901). That should be sufficient for the default license to apply, but I don't know how much TSC has decided to rely on it.

Any update? Or is there anything I can do to expedite the process?

In T389540#10685966, @Tkarcher wrote:

Any update? Or is there anything I can do to expedite the process?

The software is unlicensed. Historically that has been the stopping point for adoption requests as the Toolforge ToU says that code must be licensed under an OSI approved Open Source license and only the original author can remedy that.

The Toolforge-standards-committee could decide to change this precedent by deciding how and when to enforce the default license clause of the ToU mentioned in T389540#10664527 and T389540#10664553. Alternately the community could start new projects to replace the malfunctioning and unlicensed bot.

I have sent an email to the Toolforge-standards-committee internal mailing list calling for discussion of this task and the more general case of adoption of any tool found to contain code with unclear licensing.

In T389540#10664553, @AntiCompositeNumber wrote:

That provision was introduced in May 2023, and we know that FNDE logged in to Toolforge in Jan 2024 (T320003#9474901). That should be sufficient for the default license to apply, but I don't know how much TSC has decided to rely on it.

Nobody on the mailing list objected to this line of argument (and FNDE not only logged into Toolforge, some of the tool’s files were also touched after that date), so I’ll go ahead and say that we’re going to invoke the ToU clause and call the tool’s code GPLv3.

Which just leaves the hunt for secret information. I’ll see if I can make some headway there.

Well, there are three sets of credentials that I’ve found:

1. The password of FNBot on Wikimedia wikis. (Not a bot password!) I expect that, as in T392781, we’ll want to remove this from the relevant files and substitute the credentials of a new bot account?
   • Side note: I tested that login with the password worked, so FNDE potentially got a “login from unknown IP” email about that. Not sure if that was wise of me, but it’s too late to change it now…
2. The password of FNBot on https://test-cac.wmflabs.org/. Whatever that was, it seems to be dead now, so we can probably just wipe this without replacement?
3. A token for https://rcm-2.wmflabs.org/api/. I also have no idea what this is and it also seems to be dead, so we can probably wipe this too.

In T389540#10774116, @LucasWerkmeister wrote:

1. The password of FNBot on Wikimedia wikis. (Not a bot password!) I expect that, as in T392781, we’ll want to remove this from the relevant files and substitute the credentials of a new bot account?

Yes. Per https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy#Adoption:

Prior to granting access to an adopting user, obvious secret information such as SUL account passwords, database passwords, and OAuth secrets should be removed from the tool's home directory. If secrets are not removed, the Toolforge Standards Committee must contact appropriate on-wiki communities such as WP:BAG and Stewards to ensure that they are informed of the forcible transfer of ownership of the existing credentials.

It would be a pretty exceptional circumstance to retain the auth credentials while processing an adoption takeover. I don't think it really is the job of the committee to inject new secrets either. That is work for the group taking control of the tool. It does mean in this case that the bot tasks which are still working will stop until new credentials are applied, but I assume that is a reasonable disruption to trade for renewed maintenance of the system.

Sure, that’s fair :)

In T389540#10774116, @LucasWerkmeister wrote:

2. The password of FNBot on https://test-cac.wmflabs.org/. Whatever that was, it seems to be dead now, so we can probably just wipe this without replacement?
3. A token for https://rcm-2.wmflabs.org/api/. I also have no idea what this is and it also seems to be dead, so we can probably wipe this too.

FWIW, a global search suggests that these were part of the rcm Cloud VPS project and vanished at some point between the 2016 and 2018 Cloud VPS purges. (Not due to the purges – those just serve as convenient “checkpoints” where the list of instances was recorded.)

@LucasWerkmeister : I still hesitate to complete the adoption, as most parts of the bots still run smoothly as of today and would immediately stop once you delete the confidential data, putting pressure on me to get FNBot2 up and running asap. But as the list of small bugs and new feature requests is growing: Would it be possible to share the code (without the confidental data) with me prior to the adoption, so I can have a look already and prepare the necessary changes before the actual adoption? (I'm aware that large parts are visible already, but some folders like /mnt/nfs/labstore-secondary-tools-project/request/FNBot/review_bot/ are completely hidden)

In T389540#11583272, @Tkarcher wrote:

Would it be possible to share the code (without the confidental data) with me prior to the adoption

This sounds like a https://wikitech.wikimedia.org/wiki/Help:Toolforge/Right_to_fork_policy request. We never created a specific form for those requests as far as I know, but it would seem reasonable to track it as a separate thing than the adoption request. It would be good to reference T389540#10773653 in that request to keep track of the TFSC's decision to treat the codebase as GPLv3 licensed under the default license provision of the TOU.

it would seem reasonable to track it as a separate thing

Good idea. Done: T416678