We'v been porting Scap to Python3 latetly, and this _might_ be Unicode string confusion problem somewhere. I don't know that it is, though, nor can I see where it might be.

I note there is one remaining instance of yaml.load in Scap.

I believe scap apply-patches does this now.

This is obsolete, now that train-dev is using Docker.

This is already done.

I'd be A-OK with a truncated traceback if the alternative is Phatality not working.

I've abandonded the change. If someone else wants to finish, good.

@dancy is working on a Docker variant. VirtualBox is not on the radar.

Tag exists, SRE is on it.

Train seems to have been OK since yesterady, closing task.

https://gerrit.wikimedia.org/r/c/pgp-public-keys/+/683840

Rolled back to group0 due to T281480: SqlBlobStore no longer caching blobs (DBConnectionError Too many connections)

ACK, I'll make it a train blocker.

Filed T281482: PHP Warning: A non-numeric value encountered (from TMH ID3Handler), but not as a blocker.

Filed T281480: SqlBlobStore no longer caching blobs (DBConnectionError Too many connections), but not as a blocker.

Promoted train to group1.

Apparently this is the same as T281455: PHP Notice: Undefined variable: endTags. Closing as duplicate.

This was marked as a train blocker because I'm a klutz. Removing it as a train blocker.

Filed T281456: PHP Warning: Invalid argument supplied for foreach(), but not as a train blocker yet.

Filed T281455: PHP Notice: Undefined variable: endTags, but not as a blocker due only happening once.

Initial thought: one key per person, with all signatures. Signatures merged automatically: add new sig in new file, run make, gets merged into the one file for that person.

New blocker {T281361: TypeError: Argument 2 passed to Wikibase\Client\DataAccess\Scribunto\WikibaseLanguageIndependentLuaBindings::trackUsageForSitelink() must be an instance of Wikibase\DataModel\Entity\ItemId, instance of Wikibase\MediaInfo\DataMo}

There's a train blocker, but I'm promoting train to group0 to see how bad things get. I can roll back if need be.

Filed T281229: InvalidArgumentException: GrowthExperiments\Config\WikiPageConfigWriter::getCurrentWikiConfig failed to load config but not yet as a blocker

Filed T281226: PHP Notice: Only variables should be assigned by reference, making it a blocker.

Filed T281224: Property 'type' of non-object (in Kartographer) but not as a blocker.

Filed T281223: MediaWiki\Revision\RevisionAccessException: Failed to load data blob from tt:9375723: Bad data in text row 9375723. Use findBadBlobs.php to remedy.. If this problem persist, use the findBadBlobs maintenance script to investigate the issue and mark bad blobs. but not as a blocker.

We've tagged the bug fix release 3.17.1 and tested it on the beta cluster. We'd like it be built as a .deb and deployed to production, when there's time. Thanks!

Re-opening and editing, because I'm lazy.

I was hoping we could retire Scap before WMF moves to bullseye, but @thcipriani convinced me that it's better to not count on that: even if we get MW deployments to go to K8s, without Scap, it seems there's other software getting deployed with Scap.

We're going to tag a new version with fixes, and open a new task for that.

We had a problem on beta; {T279703: Scap "import scap.git" fails on beta in CI}. Until that's fixed, let's not not build or deploy the 3.17.0 release.

Would a train-dev environment with a k8s cluster do for this? There is not yet a k8s in train-dev, but I'm sure @dancy and I would be happy to collaborate on adding that. We'd probably need help in figuring out how to set up minikube or another small k8s thing.

In T272760#6965023, @LarsWirzenius wrote:

I note that subprocess was added in Python 2.4 and that it's certainly in Python 2.7. In fact, I wish Scap used nothing else to run other programs.

I note that subprocess was added in Python 2.4 and that it's certainly in Python 2.7. In fact, I wish Scap used nothing else to run other programs.

Meanwhile, we've decided to not port Scap to Python3, given that we expect to move MW deployment to K8s and not involve Scap anymore. I'm assuming this task can be closed. If I'm wrong, please re-open.

To make sure: I would expect that every commit in the "master" branch could be built into a .deb using a standard process. If that's not the case at some point, I think we need to fix it pronto. If SRE needs to make changes to Scap during the release building, I would like to hear about that.

I agree that the current Scap release process is sub-optimal. My preference would be to move to a process where the "master" branch is always as close to releasable as possible. Ideally the only things from preventing it from being released should be:

I've not managed to do anything for this task yet, but I have a question: since doc.wikimedia.org seems to primarly be a site with static content, why do we run PHP on it?

Sounds like a system or integration test. Would something like train-dev be useful?