[11:28] landing rocketfuel changes branch [11:29] tomwardill: Er [11:29] +getopt_output="$(getopt -o '' -l no-workspace,lpusername:,assume-yes -- "$@")" || exit 1 [11:29] ++eval set -- "$getopt_output" [11:30] Second line is a syntax error isn't it? [11:30] huh [11:30] err, sure I tested that [11:30] one mo [11:30] ... [11:31] You can switch it back to Needs Review if you're quick [11:31] yeah, just did [11:31] hopefully quick enough [11:32] Yeah [11:32] Also the "while :; do" indentation is still weird [11:32] Shouldn't it start at column 1? [11:33] oh, so it should [11:33] it was originally tabbed, not spaced [11:33] so that's what I thought you meant :) [11:33] Ah - no, I meant the vertical position :) [11:34] okay, both fixed [11:34] Cool, looks better now :) [11:34] * tomwardill clears throat... [11:35] "landing rocketfuel changes branch [11:35] " [11:35] (take 2) [12:56] tomwardill: Could you have a look at https://code.launchpad.net/~cjwatson/lp-source-dependencies/+git/lp-source-dependencies/+merge/378804 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378805 ? More attempts to get staging working [12:57] on it [12:58] +1 to both [12:58] Thanks [12:59] (I think we should seriously reconsider the policy of using sdists for most things and wheels only where necessary. Installing sdists involves executing code and is generally a much slower and much more complex operation than installing wheels. For pure-Python packages it makes basically no difference to auditability, or if anything probably improves it since you're just unpacking zip files ... [12:59] ... rather than doing complicated things with setup.py. For packages containing extensions we do indeed need to make sure that we trust the builds; but we could build them once somewhere trustworthy and commit that, which we have to do anyway in several cases.) [13:00] I remember wgrant being opposed at one point to lp-source-dependencies containing very many wheels, but it's possible I misunderstood him, that he's changed his mind, or that I can persuade him. :-) [13:01] For pure python maybe [13:01] But for extensions we'd have to do weird things to separate them by arch, series, etc. [13:02] We already do by arch [13:02] Series perhaps [13:02] Also a full build really doesn't take that long [13:02] Uh [13:02] It really does [13:02] It massively slows down our production deployments [13:03] That might advocate for wheels being included in the deployment artifact [13:03] (We mostly don't notice locally because most people don't rm -rf download-cache/wheels/) [13:04] I'm pretty sure the build on my desktop took under ten minutes [13:04] After I did that [13:04] Yeah, it's a lot worse on a lot of our hardware [13:05] The staging deployment hadn't even finished failing everywhere after I got up this morning, so it spent something like nine hours just doing five or so builds [13:05] There's a problem with pip's wheel caching - the wheels are cached by hash of the source path, so the download cache isn't preserved usefully when we sync it out to deployment targets [13:06] But maybe we could copy them out to some other directory with predictable paths and then use that in the deployment artifact [13:07] That is so weird [13:09] (sdists also involve dealing with the usual setup_requires nightmare) [13:10] Mostly much better with setuptools invoking pip to do that now, except that that's actually made things worse on Python 3 due to https://github.com/pypa/pip/issues/6264 [13:10] On Python 2 we dodged that bug due to luck [13:11] I think we're going to have to finish the job of abolishing our use of --system-site-packages [13:13] Which would make things much less confusing anyway, but there are a couple of remaining hard problems to solve [13:13] Basically python-apt and python-pil (and maybe python-tdb for code imports, but we can probably just add that to the virtualenv) [13:17] For python-apt I have an evil plan that looks more or less like https://paste.ubuntu.com/p/4xHRt4xZwS/ [13:18] We'd have to keep up with updates (but we have to do that anyway for lots of our Python dependencies) and there may be some care involved with libapt compatibility, especially across series, but those problems seem tractable [13:19] I'm not sure I'm comfortable taking that sort of approach for python-pil / pillow though, because ouch @ image parsing libraries on our security boundary [13:23] Aside from some build system stuff, we only use it for checking sizes of images uploaded in forms. I wonder if we could plausibly just call out to imagemagick for that [16:29] Thanks for the comments on my MP, cjwatson. I'm splitting the ArchiveSigningKey renaming into this new one: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/378826 while I'll check the other feedbacks [16:32] that discussion of development environments in London was ace, as it caused me to actually fix all the broken things in mine [16:34] pappacena: Great, thanks, will look [16:56] is this a good place to whine about Launchpad timeouts on specific operations? :) [16:57] Only if they come with OOPS IDs [16:57] and cake [16:58] https://oops.canonical.com/oops/?oopsid=OOPS-e0d2dfcb5398a0477ac9d343b669f4c1 🎂 [16:58] that's a sample OOPS but - it used to sporadically timeout when adding people to the sso-2f-testers team - these days it *always* times out (but still adds the person) [16:58] maybe the list of people is now too big? it's 1300 or so I think [16:59] Yeah, looks like it needs some bulk-loading. Could you file a bug and quote the OOPS ID please? [16:59] totally [17:00] * cjwatson probably won't have time but hopefully somebody else will :) [17:01] yes, and it's not a showstopper, just annoying [17:01] thanks! [17:06] https://bugs.launchpad.net/launchpad/+bug/1862670 [17:06] Bug #1862670: timeout/oops when adding people to a certain LP team (but adding still succeeds?) [20:30] cjwatson: I'm sorry did you just propose fixing a security issue by calling out to imagemagick? [21:46] wgrant: eh there's a reason I haven't just put together a patch for it yet ... [21:47] pillow also seems made of CVEs though [21:47] I happened to have a look at it and the last security update was, err, last week [21:48] and we only pick that up when we happen to restart appservers for other reasons [21:50] surely in 2020 CE there exists a simple thing to find the dimensions of images that isn't composed of cheese and security holes [21:56] https://pypi.org/search/?q=image+size has several things in pure Python that look 100x simpler and probably usable [21:59] Silly Zope question here, but... I'm trying to register a class as a component here, but I'm getting a strange error saying " __init__() takes exactly 4 arguments (1 given)". My configure.zcml directive looks quite similar to other examples in Launchpad... anyone knows what am I missing? [21:59] https://www.irccloud.com/pastebin/i7QTFuxN/configure.zcml [21:59] this is my configure.zcml [22:00] pappacena: what's ArchiveSigningKey's __init__? [22:00] ahm... it's empty [22:00] pappacena: normally something registered as a utility would have at most an __init__(self) without extra options [22:01] ahhh, no no! [22:01] pappacena: the thing in class= is really just a factory - whatever you put there is called with () to create the component that's registered as the utility [22:01] it's not empty... I've declared that receiving paremeters! 🤦‍♂️ [22:02] Ok, I moved one step... let me keep on doing things here. Thanks, cjwatson! [22:03] np