[10:16:41] I'm going to reboot grafana1002.eqiad.wmnet (primary) in 14 minutes due to task T392804. [10:54:12] yikes, ack [11:51:30] moritzm: hello! it seems like https://sal.toolforge.org/log/50IHuJUB8tZ8Ohr01C-F was accidentally imported into bookworm-wikimedia instead of bullseye-wikimedia, and as a result I have some bookworm VMs that are unhappy because they're using an older version of python3-flask-sqlalchemy than what bookworm shipped [12:00:03] I'll have a look in a bit [12:40:42] Lucas_WMDE: re: my comment on targetDate still showing up, I think I understand now, today's invocation of daily is still running https://phabricator.wikimedia.org/T389344#10776245 [12:42:35] * Lucas_WMDE ’s head makes rail yard noises as two nicknames are linked with each other [12:42:41] huh, do they take *that* long? [12:43:05] wow, yeah, wmde-analytics-daily-early still has child processes [12:43:13] looks like it, lolsob? [12:43:14] that would do it then, I guess [12:48:21] moritzm: in reprepro, how do I copy something from a component to main? [12:48:46] reprepro -C component/dnsdist copy bookworm-wikimedia bookworm-wikimedia dnsdist doesn't work for me [12:49:03] it also seems wrong but then I don't know the right thing here so :) [12:51:15] hmm ok, so what happened was that remove bookworm-wikimedia dnsdist also removed the component (which now I recall the caveat) [12:51:20] no worries, I will reimport [12:51:26] with our version of reprepro we can't move between components unfortuantley [12:51:36] the version in trixie should be able to eventually [12:51:43] ok, that's good to know too! [12:51:48] so yeah, in the interim remove and readd is the only workaround [12:51:56] thanks [14:21:01] that reminds me, I should probably look at getting the opensearch plugin debs into CI [14:23:53] before I risk breaking our private repo again... I should write in there as gitpuppet, right? [14:25:03] creating new files? [14:25:16] or just changing anything? The latter just needs root [14:25:23] adding files [14:25:43] you can be root and then chown/chmod if needed [14:27:32] has anybody got any error like "OpenURI::HTTPError: 401 Unauthorized" when helm-linting in CI for deployment-charts? [14:27:41] I keep seeing this issue https://integration.wikimedia.org/ci/job/helm-lint/24477/console [14:43:35] elukey dunno if it's related, but I'm getting a 401 when I try to run wmf-update-known-hosts-production from my desktop [14:45:47] that sounds a lot like fallout from https://gerrit.wikimedia.org/r/c/operations/puppet/+/1139798 [14:47:28] jelto: o/ ---^ is it possible? [14:49:05] yes it's quite likely. I'll revert the change. But I'm wondering why CI is using gitiles [14:50:30] cc hashar ^ [14:51:23] wheee, it broke deployment-charts CI too [14:51:35] because it pulls some puppet hiera files from gitiles [14:51:54] great :) revert is on the way, one sec https://gerrit.wikimedia.org/r/c/operations/puppet/+/1139874 [14:53:00] (oh, oops, already noted, I'm late to the party as usual) [14:55:38] CI should be unblocked again (and wmf-update-known-hosts) [15:01:54] thanks! [15:09:13] confirmed that it works now [16:05:39] can you file a bug for it? I am not sure why CI / a script would rely on gitiles [16:05:47] rather than git over https :) [16:06:22] then I imagine it can be used to retrieve a single raw file [16:16:21] hashar: deployment-charts just wants a few raw files, yes