[07:21] Hey, I just noticed that on the "FrontPage" of the wiki at , the "Privacy... in Launchpad" item has faulty markup which leads to everything that follows it getting made bold or non-bold loosely at random - but even after having logged in the page is still immutable to me, so I'm just gonna mention here what exactly needs changed. ... [07:21] ... ">~+'''[[PrivacyConfidentialityAndDisclosure | Privacy, confidentiality and disclosure]] in Launchpad" just needs the closing "+~" markup appended right after this. I even managed to find the revision where this snuck in.. in 2012 XD - https://help.launchpad.net/FrontPage?action=diff&rev1=106&rev2=107 [07:57] krytarik: Thanks! Now if I can get that wiki to let me log in ... [08:06] krytarik: Fixed, thanks [08:08] Yay, thanks! === cpaelzer__ is now known as cpaelzer [09:58] cjwatson: did mattermost just go down? [09:58] tomwardill: working for me [09:58] oh no, it's back [09:58] sigh. [12:12] hi, we're consistently getting "No space left on device" for ceph builds in the cloud archive - https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/wallaby-updates/+packages?field.name_filter=ceph&field.status_filter=published&field.series_filter= [12:13] surprisingly armhf passed! but is there anything we might be able to do if this is a builder issue? [12:40] All builders have the same disk provisioning. What you can often do is adjust the build to remove intermediate build results as it goes along [12:40] armhf is probably just creating smaller object files because 32-bit [12:41] I see you already have a "running out of disk space on riscv64" tweak along those lines; you could just extend that to all arches? [13:39] cjwatson: I'll take a look at that, thanks for the suggestion === dilfridge is now known as Brother_Maynard === Brother_Maynard is now known as dilfridge [19:19] So my discovery of a markup issue on the wiki yesterday was in context of creating a dark theme for every corner of Launchpad (for CGit I got a dedicated general one though), and while I can't be too sure yet there aren't some remaining bits it doesn't cover, I believe it'd be pretty much ready for deployment and wonder how the interest would be to add dark theme support to Launchpad proper? ... [19:19] ... It's currently in the form of a web browser userstyle and I've just pasted it to: http://paste.openstack.org/show/VjUumeFOOGBCd5h1wHja/ [19:21] oo cool [19:25] krytarik: Not opposed but I wonder how this would interact with the mid-term goal of converting Launchpad to Vanilla [19:25] I'd be a bit concerned about potentially putting more obstacles in the path of that, since it's already likely to be pretty complex - does Vanilla have dark theme support? [19:26] Since I'm seeing ubuntu.com in all its usual bright glory at least, it doesn't seem so no. >_< [19:29] I think I'd at least want to know that there would be a forward path there, so it would be great if you or somebody could discuss this with Canonical's web team [19:30] We haven't started on a port there yet, and it's obviously a very large job, but it seems like part of the most likely path towards things like better mobile-friendlines [19:30] s [19:30] And I wonder if the base theming gets changed to that, if that makes the dark theme CSS actually less complex to cover everything than how it is currently.. XD [19:37] Got it, but adding dark theme support wouldn't really be a thing that can't be just trivially undone at any point, since one would just add an '@media (prefers-color-scheme: dark) {...}' rule for it and put the whole dark theme CSS in there. [19:38] Whether directly or via includes or such, the latter of which we've done for a CGit instance. [19:53] Right, that's true, but I don't want it to be another potential regression that'd need to be overcome [19:54] Right. [19:54] cgit may be easier since I doubt it would be vanillaized directly [19:55] But then it'd look even less integrated than currently.. :3 [19:57] It's true, but its integration is slightly a lost cause :) [19:57] We always at least half-planned to have an integrated code browser instead, but that's a decent-sized project and cgit was/is an adequate stopgap [19:57] But integration wouldn't start from cgit, I don't think [20:00] Hahaha, I guess that's true indeed, and tbh I think CGit proper is the better solution for browsing the whole repo.. [20:01] https://loki.unit193.net/cgit/users/unit193/cgit-assets.git/ - is what we've got currently. [20:03] cgit's not awful in itself, certainly, but ultimately we'd like something that can be inline with the normal webapp [20:03] more github-like, if you will [20:04] Still, nothing concrete is planned there [20:04] Yeah, I understand. [20:05] Speaking of which, any plans for updating it to a somewhat current version? [20:05] cgit? We just run what's in bionic [20:06] We should upgrade the git backend to focal at some point [20:06] That would come with an upgrade to a focal version of cgit along the way [20:06] Yeah, and syntax highlighting is the thing I always miss the most on it. [20:06] I'm not sure whether any of my colleagues have looked into this as yet; I haven't [20:07] That doesn't need a newer version, it needs us to sort out apparmor confinement or something similar to mitigate risks of the highlighter getting out of hand [20:07] Oh, ok. [20:08] And/or seccomp [20:08] Anyway, kids' bedtime [20:08] Ok, see you! [20:09] very happy to help mentor somebody in things like adding confinement so we can enable syntax highlighting [20:09] just not quite right now :)