[02:45:27] who would like to be subscribed to my imagemagick policy.xml rant bug? [03:07:36] don't all speak at once [03:21:47] TimStarling: o.O I'm interested [03:24:50] excellent, thanks legoktm [03:25:33] just figuring out a few details [03:49:19] https://phabricator.wikimedia.org/T370610 [03:50:51] Huh, I had no idea that the filesystem was tmpfs [04:09:16] !log bd808@tools-bastion-12 tools.ircservserv Swtiched to running bot from buildservice container. [04:09:18] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.ircservserv/SAL [04:15:59] TimStarling: kind of embarassing that people just copy-pasted obvious placeholder values without modification :/ I +1'd your conclusion, though I haven't dug into the new buildpack stuff closely enough to know how/where to fix it [04:16:15] probably worth a Debian bug report too if there isn't one already [04:40:51] TimStarling: semi-relatedly, I'm wondering if you've looked into doing client-side cropping via imagemagick compiled to WASM, I've been meaning to look into that for file rotation [04:41:50] Imo I'm a bit unsure of how intensive it is on the user's CPU (re @wmtelegram_bot: TimStarling: semi-relatedly, I'm wondering if you've looked into doing client-side cropping via imagemagick compiled t...) [04:42:07] interesting idea [04:42:45] although I'd rather have VIPS or a similar image pipeline -- cropping usually doesn't need more than one scanline to be in memory [04:44:25] I think rotation would optimally need a number of scanlines in memory proportional to the sine of the angle [04:46:07] @sohom_datta: yes, there are definite tradeoffs by doing processing locally instead of remotely (the user now has to download the full image and re-upload it), but I think it also opens up other opportunities, like transforming files before upload, or making it easier for other gadgets/scripts to hook into. and you don't need to maintain a server implementation [04:47:23] rotation is usually done via exif though, so I'm not sure scanlines matter? [04:49:02] rotation by multiples of 90° can be done in EXIF, but often people are rotating by a few degrees to correct a slight error made by the photographer [04:49:14] right [04:49:19] making the horizon horizontal [04:57:43] seems like you might not even need imagemagick, you can do it with . https://legoktm.com/canvas-rotate.html (created by Claude) [08:43:45] that's an unfortunate behavior of imagemagick :/ [10:51:36] I see John Cristy is still around, doing his thing. Very few open pull requests [10:55:17] we could consider an upstream solution for the strictness of the system policy file [10:55:59] if Debian could declare their policy.xml to be "soft" or "non-strict" or "default", do you think they would do that? [11:02:23] TimStarling: we could try! [11:06:35] TimStarling: this is the source of the debian package. What file should I be looking at? https://salsa.debian.org/debian/imagemagick/-/tree/debian/bookworm/debian?ref_type=heads [11:07:45] there was a link on the task to https://salsa.debian.org/debian/imagemagick/-/blob/debian/bookworm/debian/patches/0007-Improve-policy-in-order-to-be-safer.patch [11:08:42] but I wasn't really rigorous about finding that file, I just clicked around until I found something that looked like it [11:15:20] OK, that patch is definitely it [11:15:27] TimStarling: just to clarify, would your proposal be to replace the policy with the chunk in the phab ticket? [11:17:51] maybe, but I don't think it would fly, let me write up a more detailed proposal which I think would work [11:18:02] TimStarling: are these perhaps related? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929826 https://github.com/ImageMagick/ImageMagick/issues/396#issuecomment-319569255 [11:21:13] yes [11:22:25] TimStarling: so my proposal would be [11:23:09] let's write about the requested change the debian bug, with the rationale. I'll talk to the maintainer, he is active in Debian and most likely will be willing to talk [11:23:24] TimStarling: you can write to the debian bug by emailing 929826@bugs.debian.org [11:24:26] oh, reported by Jidanni, we know him, I met him in Taipei in 2007 [11:24:49] great, that would make for a stronger case :-) [11:29:16] I would like Debian to be fixed, I ran into this issue in production at T344233 last year, it's going to keep coming up [11:29:17] T344233: Some custom generated thumbnails get massivily cropped - https://phabricator.wikimedia.org/T344233 [11:29:45] but my current problem is really with Heroku, which has its own policy.xml which is basically the debian one with comments stripped [11:30:02] a fix in Debian is not automatically going to filter down to Heroku, we would need another PR and discussion there [11:33:13] ok [11:33:30] I'm afraid I don't have the same "superpowers" within the heroku community [11:53:47] it's so easy to be paranoid about this sort of thing, but if you think it's feasible, I would suggest that Debian use the upstream resource limits, reverting the resource lines in that patch [11:55:41] can you think of another image processing utility with system-level maximum file sizes? it's odd [12:10:23] TimStarling: so, basically dropping the patch entirely? [12:17:21] referring to line numbers in the patch file: line 23-35 is the resource section, that would be dropped. Line 42 is an accident and should be dropped. 46 also an accident. [12:17:39] 52-54 should be dropped -- the comments are meant to indicate upstream default so this is the wrong place to add comments [12:17:49] maybe a backport error [12:19:28] lines 58-62 still have some value but could be merged with patch 0023 which disables certain file types [12:20:00] actually 62 is odd and should be re-examined [12:21:01] but 58-60, disabling network downloads by specifying URLs on the command line, can be kept [12:38:51] TimStarling: btw, since you mention VIPS, I met Lovell Fuller last week at a web standards meet up, he's London local and gave us a "anything you need" kind of offer, in case you have any things you'd like them consider! [12:39:43] He's one of the ~4 libvips maintainers. [12:43:09] I considered libvips for https://github.com/tstarling/pano-projector but there were some details I didn't like, can't remember what right now [13:03:45] I've had to touch libvips before to do some transcoding to HEIC and I did not have fun [13:04:40] I think that's an artefact of HEIC not being fun [14:12:48] komla was looking at your Wikimedia account migration email and it references `idm.wikipedia.org` which I can't seem to reach. Was that supposed to be `idm.wikimedia.org` ? [14:21:59] inflatador: yeah, it was [14:22:13] I'll bug him to send a correction once he's up and working [14:23:44] andrewbogott np, I think all of us have made that mistake at least once ;) [14:23:55] I sure have [14:43:27] !log deployment-prep fix /srv/git/operations/puppet yet again (T364492) via chown -R gitpuppet:gitpuppet on .git/, then use 'pgit' (gitpuppet wrapper) to reset to oot branch [14:43:30] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [14:43:30] T364492: Ownership confusion on cloud-local puppet servers - https://phabricator.wikimedia.org/T364492 [14:44:03] inflatador: yes, it should be wikimedia instead of wikipedia. It has been corrected. It went out to only a small batch. Thanks! [14:57:23] !log deployment-prep delete deployment-mediawiki11 and deployment-mediawiki12 (incl PuppetDB data + volumes) T361387 [14:57:27] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [14:57:28] T361387: Replace or delete deployment-mediawiki[11-12].deployement-prep.eqiad1.wikimedia.cloud - https://phabricator.wikimedia.org/T361387 [15:00:01] !log deployment-prep delete deployment-urldownloader03 T370466 [15:00:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [15:00:04] T370466: Remove or replace deployment-urldownloader03.deployment-prep.eqiad1.wikimedia.cloud (Buster deprecation) - https://phabricator.wikimedia.org/T370466 [15:00:05] !log xtools upgrading db server xtools-db01 -- T369723 [15:00:07] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Xtools/SAL [15:00:08] T369723: Update all trove VMs to a modern guest image - https://phabricator.wikimedia.org/T369723 [15:05:42] musikanimal: I just upgraded the xtools database, please let me know if anything misbehaves. [15:05:44] andrewbogott: could you +2 https://gerrit.wikimedia.org/r/c/operations/puppet/+/1055956 ? [15:06:11] thank you! [15:06:11] yep [15:07:36] almost there deleting yet another two instances [15:10:30] !log deployment-prep remove deployment-mwmaint02 T370582 [15:10:34] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [15:10:35] T370582: Remove or replace deployment-mwmaint02.deployment-prep.eqiad1.wikimedia.cloud - https://phabricator.wikimedia.org/T370582 [15:11:21] !log deployment-prep remove deployment-parsoid12 - T361386 [15:11:24] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [15:11:24] T361386: Remove or replace deployment-parsoid12.deployment-prep.eqiad1.wikimedia.cloud - https://phabricator.wikimedia.org/T361386 [15:11:26] komla ACK , thanks for the follow-up [15:30:00] !log deployment-prep remove deployment-push-notifications01 - T370459 [15:30:03] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/SAL [15:30:04] T370459: Remove or replace deployment-push-notifications01.deployment-prep.eqiad1.wikimedia.cloud (Buster deprecation) - https://phabricator.wikimedia.org/T370459 [16:07:01] TimStarling: got green light from the Debian maintainer. We will need some additional things, like a postinst script for the package, but should be doable [16:58:53] !log copypatrol upgrading db servers copypatrol-prod-db-01 and copypatrol-dev-db-01 to latest Trove guest image [16:58:55] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Copypatrol/SAL [17:00:54] !log tools moving the toolforge apt repo to tools-services-06 [17:00:56] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [17:42:58] !log tools moved the apt repo to service endpoint deb.svc.toolforge.org [17:43:00] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [17:43:22] Nemo_bis: can you please respond on https://phabricator.wikimedia.org/T367528? Or just tell me here that I can delete all the VMs in the dumps project? [17:52:00] andrewbogott: looks good thank you :) [17:52:11] cool [17:52:21] Think I'll wait until tomorrow to do the rest, just to be sure... [18:16:01] !log mwv-apt deleting project after discussion on https://phabricator.wikimedia.org/T367542 [18:16:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Mwv-apt/SAL [18:19:45] !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed 54ad2210a2 (l10n updates: ar, kaa) [18:19:46] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL [18:27:29] !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed 13c4824e3a (change Babel code of kaa from kk to uz) [18:27:32] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [19:52:46] andrewbogott: you probably can [19:53:19] Nemo_bis: I'd like to have some kind of record before I delete things, can you please comment on task? [19:53:21] I was hoping to look into it in the weekend but nope :| [19:54:24] done [19:55:01] thank you! [21:27:18] this developer account/sul thing is so confusing. i understand that the wikitech wiki username will change. how about logins for wmcs/toolforge, horizon? [21:31:05] gifti: you have two accounts now, an SUL account and a developer account. [21:31:15] The only thing that's changing is we're switching wikitech from using dev accounts to using sul accounts [21:31:17] does that make sense? [21:46:41] gifti: so that means toolforge/horizon/everything else will still use dev accounts like before. [23:28:23] i have a question about creating a new redirect for a service that is currently in the wmcloud.org namespace [23:29:01] is the "project puppet tab" that is referenced the one in my project (aka civicrm-prototype)? [23:30:13] for reference, i'm looking at https://wikitech.wikimedia.org/wiki/Nova_Resource:Redirects#Creating_a_new_redirect [23:54:48] dwisehaupt: that page seems to be documentation for a specific project, named 'redirects' [23:55:43] it's kind of a global cloud-wide service. If you want a redirect set up you can make me a ticket and I'll see how it goes :) [23:56:11] ok cool. yeah, i got there from here: https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_VPS_servers_from_the_internet#Delete_unused_web_proxies [23:56:38] we are looking at migratint the community-crm from wmcloud to a prodvps and i'm thinking a redirect to the new url would be nice. [23:57:07] it's not a requirement so if it's non-standard or a pain, i'm happy telling the internal users to learn the new url. [23:59:06] you should definitely move people to the new url regardless, but it's nice to have a safety net [23:59:11] is the new service already up and running?