[09:22:04] !log tools.zppixbot-test Prod Bot to 210s timeout refs T250861 - rolling timeout to 300s [09:22:06] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.zppixbot-test/SAL [09:22:07] T250861: Raise timeout value for IRC Bots - https://phabricator.wikimedia.org/T250861 [10:19:23] mmm [10:19:26] I've been reading this https://www.mediawiki.org/wiki/GeoHack#Nice_URLs [10:19:53] and now I wonder what happens with this kind of stuff when using the new domain: `{{fullurl:toollabs:geohack/en/52 30 N 13 23 E type:city(3431700)|title=Berlin}}` [11:21:18] We've changed the domains and setup redirects several times. Also most links comes from template which are more flexible [11:22:21] A headache for developers who used in their tools [11:23:48] Also, what happens with robots.txt? [11:59:26] Dispenser: what do you mean? [12:00:23] if you previously had `tools.wmflabs.org/yourtool/robots.txt` now that should be available in `yourtool.toolforge.org/robots.txt` [12:02:29] Before admins would administer robots.txt (e.g. denying misbehaving bots e.g. MSN craw); now developers have to administrate it. [12:03:46] I guess we could symlink a global robots.txt [12:05:25] Ok, we needed it in the Toolserver days [12:18:11] I don't think we have `tools.wmflabs.org/robots.txt` now a days [12:19:24] but anyways, the key point of introducing the new domain is precisely the domain isolation. If we need now a per-tool robots.txt that's a side effect that we should embrace and accept :-) Dispenser [12:49:27] On the note of expected root files; we probably should also include a default favicon.ico [14:43:59] I wouldn't suggest doing that - most browsers don't ever update them once one is found [14:58:08] arturo: I think the fullurl functionality will be handled by T247432 when we roll that out. [14:58:09] T247432: Preserve the ability to make interwiki links to Toolforge tools under the host based routing scheme - https://phabricator.wikimedia.org/T247432 [15:00:20] https://tools.wmflabs.org/robots.txt seems to be broken today, but it did exist previously. I have had some small thoughts about how we might provide defaults for that and other well known urls on the new per-project domains, but not enough to have an solutions to propose yet [15:02:25] (referring to Dispenser's last comment) [16:52:14] !log tools tagged docker-registry.tools.wmflabs.org/maintain-kubeusers:beta to latest to deploy to toolforge T247455 [16:52:18] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [16:52:18] T247455: Dumps not accessible from container pods - https://phabricator.wikimedia.org/T247455 [16:54:25] !log tools deleted the maintain-kubeusers pod to start running the new image T247455 [16:54:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [18:18:27] !log tools.train-blockers updating to 12f5873 [18:18:30] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.train-blockers/SAL [19:48:32] !log toolsbeta ran the scary rewrite-psp-preset.sh script across toolsbeta T247455 [19:48:36] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Toolsbeta/SAL [19:48:37] T247455: Dumps not accessible from container pods - https://phabricator.wikimedia.org/T247455 [19:50:03] hey ppl, we are trying to do some cross-database queries on the mariaDB on toolforge, but apparently this is not possible (at least following the standard procedure of FROM db.table), do you know a way to do this within toolforge? [19:51:55] dsaez: I think I need more context. It should be possible to query say enwiki_p and commonswiki_p in the same query right now. (Not guaranteed to be possible forever) [19:57:05] dsaez: my guess is that you are not using the "_p" suffix on the database names. [20:33:48] !log tools.integraality Deploy latest from Git master: eabbac8, b74b352 (T248788) [20:33:51] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [20:39:03] bod808, will try. In fact what we want to do is query commons_p and save results in our own db (users db) [20:39:58] dsaez: the user dbs are on physically separate servers. There is no way to do a cross join from a wiki replica to a db on toolsdb [20:41:32] bd808 ok, let me explain the full problem, we want to do a long query on the commons table, but answer is too long, so we want to split in several queries and save somewhere... what would you recommed? [20:43:00] a python script :) I think you have the right idea, there is just no way to do that using only sql and a single database connection. [20:43:19] got you, thanks! [21:28:51] !log tools running the rewrite-psp-preset.sh script across all tools T247455 [21:28:54] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [21:28:55] T247455: Dumps not accessible from container pods - https://phabricator.wikimedia.org/T247455 [22:13:19] !log tools running a fixup script after fixing a bug T247455 [22:13:23] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [22:13:23] T247455: Dumps not accessible from container pods - https://phabricator.wikimedia.org/T247455