I've been looking at this error recently:
Apr 25 12:51:08 cloudvirt2001-dev nova-compute[2572868]: 2024-04-25 12:51:08.870 2572868 ERROR ovsdbapp.backend.ovs_idl.transaction [-] OVSDB Error: {"details":"cannot delete QoS row 4f1bdbb2-2063-4789-9603-b53982670743 because of 1 remaining reference(s)","error":"referential integrity violation"}Those are running in containers, and the user does exist in the container:
taavi@cloudweb1004 ~ $ sudo docker exec -it striker.service id 900 uid=900(runuser) gid=900(runuser) groups=900(runuser)
Is debdeploy not handling that correctly?
The weight configured for php-parallel-lint is low enough that LibUp will only push that when there's something else to update with it.
Since /data/project is a symbolic link to /mnt/nfs/labstore-secondary-tools-project on Toolforge, some tools such as pnpm will write /mnt/nfs/labstore-secondary-tools-project instead of /data/project to the file, so that it cannot be executed in the container.
Which database is the query running against? fawiki? And are you running it on the analytics or web replicas?
In T363057#9738950, @Townie wrote:I have corrected the logo in a new file. Could you please deploy this fixed file? Thanks a ton!
You found what I did a few moments ago :-)
01:21:54 <taavi> uh, does https://meta.wikimedia.org/wiki/Special:CentralAuth/Taavi give a DBQueryError to anyone else? 01:22:09 <taavi> ah 01:22:10 <taavi> Wikimedia\Rdbms\DBQueryError: Error 1049: Unknown database 'kuswiki' 01:22:26 <taavi> so I created an account via mwdebug, and then turned it off, so now Special:CA fails until the patch is live everywhere 01:23:29 <zabe> yeah, it should no longer appear as soon as the patch is live
This task does not seem to have anything to do with email handling internals in MediaWiki?
Those would be issues in the SVG files provided (e.g. if I open the original file for https://commons.wikimedia.org/wiki/File:Text_logo_Viquip%C3%A8dia_750000.svg in a new tab, the text is clipped off). I can either deploy fixed files if those are uploaded to commons or revert back to the original logo.
Please email ca@wikimedia.org with the details.
Password reset have been disabled for a few months now, email addresses since I deployed that patch last week, and I just sent https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1023432 to disable password changes while logged in. After that we have SSH key changes, and T359820: Add developer account (un)blocking support to Bitu (which I forgot about earlier) as the only remaining functionality that writes anything to LDAP - there isn't anything in the login process that should need write access.
The logo change is now live (as of about an hour and a half ago, forgot to comment here!). I set myself a reminder for May 8th to revert it back.
In T362872#9734678, @aborrero wrote:In both cases, they don't mention anything about mutation. I assume this means that they cannot backfill (backmutate?) resouces that made it to the system before the policy was updated.
B: Fishbowl wiki hosted on wikikube, accounts in ldap. This option could be a final state OR a temporary state on the way to the SUL option.
Con (long-term): Allowing r/w ldap access from wikitech/wikikube may continue to introduce surprising edge cases for product maintenance.
This should be fixed on the next run.
Turns out that's a bug with the output parsing if the run crashes early enough. Now fixed with https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/39.
root@db1154:s1[(none)]> show slave status\G
Last_Error: Could not execute Write_rows_v1 event on table enwiki.pagelinks; Index for table 'pagelinks' is corrupt; try to repair it, Error_code: 1034; handler error HA_ERR_CRASHED; the event's master log db1196-bin.003644, end_log_pos 987579339It's at least trying to queue such jobs:
root@libup-runner08:~# journalctl -u libup-run.service | grep 2018 Apr 20 00:02:31 libup-runner08 libup-run[1450895]: Queuing mediawiki/skins/2018 (main) Apr 21 00:02:34 libup-runner08 libup-run[2819237]: Queuing mediawiki/skins/2018 (REL1_42) Apr 21 00:02:34 libup-runner08 libup-run[2819237]: Queuing mediawiki/skins/2018 (main)
I'm not sure why this is not making it into the web interface (I'll have a look at that later), but for now if I run it manually it's failing with:
$ /usr/bin/composer install --- stderr --- No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information. Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages.
It seems like you are trying to use UserMerge for 1.42 on a MediaWiki 1.41 install. Check that you have installed UserMerge for the correct MediaWiki version.
So this config setting has appeared in 5 repos again. I'm leaning towards just implementing support in LibUp, unless someone can figure out a way to keep it from being added back.
I believe I fixed this in https://gitlab.wikimedia.org/repos/ci-tools/libup/-/commit/f459a54b708ea0fd73001162bdf5c4df4fa6b7e3, please re-open if not.
Per the patch demo site, patch demo issues are tracked at https://gitlab.wikimedia.org/repos/ci-tools/patchdemo/-/issues.