[00:36] love commits like this https://github.com/google/autofdo/commit/963a8c1f55ed86db6b909ee603a46742b3980139 [00:36] Commit 963a8c1 in google/autofdo "Update to the latest internal version." [00:37] "look how open source we are!" [04:20] haha [09:53] Is there an archive of old Ubuntu point releases CD images, e.g. 20.04.3 ? [09:54] https://old-releases.ubuntu.com/releases/20.04.3/ [10:56] tumbleweed: thanks :) [12:57] Eickmeyer: I'm not a user of digikam so I'm not the one to judge whether disabling video support is acceptable; but I like RikMills 's answer on the mailing list much better, can we pull in 8.0 alpha? [13:07] vorlon: do you have an opinion on ua-tools growing a dependency on ca-certificates? From a quick glance, it's currently in desktop-minimal and seeded in server somehow, but not in standard or minimal. [13:07] hmm [13:08] ca-certificates also pulls in the openssl binary package as a dependency, which is probably more impactful than ca-certificates itself [13:08] I thoguht it was the other way round [13:08] I haven't checked in detail yet though. [13:09] Ah no you're right. [13:09] THere's also a Suggests/Enhances relationship. [13:09] and we've seen behavior differences in the recent past in libssl with or without the openssl package installed due to it shipping /etc/ssl/openssl.cnf, so there's some risk of regression potential there [13:10] Risk of potential. Got it :-P [13:10] yeah sorry, 6am grammar [13:10] alternative suggestion: bundle the specific CA in the ua-tools package [13:10] I was more thinking about the "bloating" of minimal. [13:10] that too [13:10] But yeah, that'd be a workaround [13:17] So what's the decision? OK, or require a workaround? [13:31] vorlon: ^? [13:31] rbasak: I would say they should work around [13:32] bundling pinned CA certificates instead of using ca-certificates is not unprecedented [13:34] orndorffgrant: ^ I don't see lamoura here [13:53] vorlon: I don't think they have a formally tagged alpha yet or tars. Just some appimages built from master branch as far as I can tell [13:54] RikMills: ah well we have a way to use git commits as upstream tarballs as needed [13:54] indeed [14:07] rbasak: got it, thanks for the ping and that all makes sense. The depends was because a significant portion of uaclient functionality needs it, but not all of it. E.g. the apt messaging around ESM works without ca-certs, but `ua attach` requires it. So we'll just remove the Depends for this release. In future releases we'll focus on making sure [14:07] everything that can work without ca-certs will, and make sure the functionality that does need it fails gracefully with a helpful error message. Does that sound good? [14:07] vorlon: Eickmeyer[m] https://github.com/archlinux/svntogit-packages/tree/packages/digikam/trunk [14:07] huh? [14:07] oh, maybe just a compile fix and nothing else [14:08] Yeah, that doesn't look like a solution. [14:09] I think just pulling from master and calling it good might be the way forward. 8.0.0~alpha [14:09] Howver, I will preface and say that ffmpeg5 support there is incomplete per the devs and is prone to crashes. [14:09] So, out of the frying pan and into the fire, vorlon . [14:11] well shall we just disable video support in 7.7 for now, buying time to build v8 in a PPA and recuits some testers? [14:12] see how hot the fire is ;) [14:13] We can do that. Right now I'm at ERR:SLEEPY, WOKEUP, NOT ENOUGH COFFEE [14:15] though as ffmeg 5 has already smooth updated its way to the release pocket, there may be no rush to fix the 7.7 build? [14:16] Well, it's been a rough transition as mwhudson would tell you. [14:16] (Ping for no reason, sorry) [14:16] indeed [14:48] Eickmeyer: "prone to crashes" wow ok [14:49] Eickmeyer: should I just try to cleanroom reimplement it and compare with what upstream has done? [14:50] vorlon: I don't know. It just seems like upstream doesn't have a lot of faith in their code right now. [14:51] Nor do they seem to have a lot of faith in ffmpeg5. [14:53] vorlon: Maybe "prone to crashes" was a misremembering (it's early), but here's the conversation: https://bugs.kde.org/show_bug.cgi?id=457121 [14:53] KDE bug 457121 in digikam "digikam 7.7.0 FTBFS against libavcodec59" [Normal, Unconfirmed] [15:04] oy I skimmed to fast and missed the "bundling pinned CA certificates ... is not unprecedented" message. we'll consider this as well in a future release [18:47] What proxy configuration is used in Ubuntu builds in the dpkg-buildpackage phase? [18:52] can you be more specific? [19:00] guess not [19:17] sarnold: Search for "dpkg-buildpackage" in this build log: https://launchpadlibrarian.net/337764430/buildlog_ubuntu-artful-amd64.node-rollup_0.47.4-3_BUILDING.txt.gz [19:18] luis220413: ah, the launchpad builders have no network access beyond ftpmaster.internal [19:18] (well, I don't know how they do ntp, I could imagine they might have access to an internal ntpd) [19:20] sarnold: Can you bootstrap node-rollup in Bionic (from the version in bionic-proposed in the publishing history) as requested in bug 1790200 for cosmic? [19:20] Bug 1790200 in node-rollup (Ubuntu) "Rollup build-depends on itself and needs to be bootstrapped" [Undecided, Confirmed] https://launchpad.net/bugs/1790200 [19:21] luis220413: cosmic is dead [19:21] luis220413: cosmic reached end of life in 2019 https://wiki.ubuntu.com/Releases [19:21] sarnold: I know, but that was done for cosmic. I want that done for Bionic, that is supported until 2028. [19:21] ah [19:22] luis220413: it's probably best to file a new bug with a clear description of what needs to be done, and why [19:24] sarnold: I want this for node-deepmerge (only in Jammy and Kinetic) to build in Bionic. But I can backport it to Focal in my PPA, copy the rollup output to a Bionic backport and it will build. [19:25] sarnold: I need this to fix CVE-2021-32798 in jupyter-notebook, that is a XSS vulnerability rated critical by the upstream project. [19:26] The Jupyter notebook is a web-based notebook environment for interactive computing. In affected versions untrusted notebook can execute code on load. Jupyter Notebook uses a deprecated version of Google Caja to sanitize user inputs. A public Caja bypass can be used to trigger an XSS when a victim opens a malicious ipynb document in Jupyter Notebook. The XSS allows an attacker t... [19:26] sarnold: I need node-deepmerge to fix CVE-2021-32798 in jupyter-notebook, that is a XSS vulnerability rated critical by the upstream project. [19:28] luis220413: introducing a new package to an existing release can happen but it's very rare; I don't even know what to suggest as your next step [19:29] sarnold: I already have a fast strategy (explained above) such that I can upload the patched packages today [19:29] sarnold: I requested introduction of these packages in bug 1983018 (except for node-rollup) [19:29] Bug 1983018 in node-sanitize-html (Ubuntu) "Backport to Ubuntu 18.04 (and in some cases 20.04)" [Undecided, New] https://launchpad.net/bugs/1983018 [19:30] luis220413: are you trying to fix that CVE in Ubuntu directly? Could you coordinate with the Security Team? [19:31] jbicha: I discussed with sarnold, that is a member of the Security Team. [19:31] oh never mind [19:32] my more specific question was if Security would want node-rollup built for bionic-security instead of the usual bionic-updates [19:38] luis220413: Security updates only build with the release and security pockets enabled. Therefore, node-rollup would have to be built for bionic-security, but is not needed. [19:38] Because I have a workaround (run rollup on Focal and copy the results to the source package for Bionic) [19:39] sarnold: there are various odds and ends in addition to ftpmaster.internal such as ntp, but broadly yes [19:40] cjwatson: any chance those are public / in code somewhere I can skim? you know me, endlessly curious :) [19:42] xnox: could you look at bug 1969247 for zfs-linux in Focal, please? [19:42] Bug 1969247 in zfs-linux (Ubuntu) "fallocate with FALLOC_FL_ZERO_RANGE produces zero-size files on zfs in Jammy" [High, Fix Released] https://launchpad.net/bugs/1969247 [19:43] sarnold: we should _really_ document it publicly - maybe when we get to the next-generation user docs project. For the time being you could derive it from lp:canonical-is-firewalls [19:44] sarnold: the intentional ones are those where `services/lp/buildd/builders` is allowed as a source; there may also be a handful of broader rules that include all of scalingstack or something (but those are probably things like infrastructure addresses) [19:46] sarnold: there are also restricted DNS views that play into this a bit, but even I don't have easy access to the contents of those, I'd need to ask IS. (of course those aren't a security barrier) [19:49] cjwatson: oh that's interesting, I was guessing they'd use /etc/hosts for the small handful of things they'd be allowed to use :) [19:49] I guess that's not very cloudy [19:49] that would be pretty hard to maintain [19:50] restricted DNS view is much easier [19:50] (modulo the fact that only IS can see the view) [19:50] also /etc/hosts is terrible for workloads that involve lots of nested chroots/containers, like builds [19:56] cjwatson: heh, there's enough abstractions in this that it's hard to tell quite what is allowed :) eg nothing in it quite says "this can do ntp and talk to the archive" to me [19:56] cjwatson: thanks again for indulging my curiousity :) [19:57] sarnold: once you're used to reading it it's very helpful, but if you don't live your life around this sort of thing then I appreciate it might not be obvious just from the configs [20:00] ooh vpn user specifications!