[00:36] <mwhudson> love commits like this https://github.com/google/autofdo/commit/963a8c1f55ed86db6b909ee603a46742b3980139
[00:37] <sarnold> "look how open source we are!"
[04:20] <blahdeblah> haha
[09:53] <schopin> Is there an archive of old Ubuntu point releases CD images, e.g. 20.04.3 ?
[09:54] <tumbleweed> https://old-releases.ubuntu.com/releases/20.04.3/
[10:56] <schopin> tumbleweed: thanks :)
[12:57] <vorlon> 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] <rbasak> 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] <vorlon> hmm
[13:08] <vorlon> ca-certificates also pulls in the openssl binary package as a dependency, which is probably more impactful than ca-certificates itself
[13:08] <rbasak> I thoguht it was the other way round
[13:08] <rbasak> I haven't checked in detail yet though.
[13:09] <rbasak> Ah no you're right.
[13:09] <rbasak> THere's also a Suggests/Enhances relationship.
[13:09] <vorlon> 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] <rbasak> Risk of potential. Got it :-P
[13:10] <vorlon> yeah sorry, 6am grammar
[13:10] <vorlon> alternative suggestion: bundle the specific CA in the ua-tools package
[13:10] <rbasak> I was more thinking about the "bloating" of minimal.
[13:10] <vorlon> that too
[13:10] <rbasak> But yeah, that'd be a workaround
[13:17] <rbasak> So what's the decision? OK, or require a workaround?
[13:31] <rbasak> vorlon: ^?
[13:31] <vorlon> rbasak: I would say they should work around
[13:32] <vorlon> bundling pinned CA certificates instead of using ca-certificates is not unprecedented
[13:34] <rbasak> orndorffgrant: ^ I don't see lamoura here
[13:53] <RikMills> 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] <vorlon> RikMills: ah well we have a way to use git commits as upstream tarballs as needed
[13:54] <RikMills> indeed
[14:07] <orndorffgrant> 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] <orndorffgrant> 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] <RikMills> vorlon: Eickmeyer[m] https://github.com/archlinux/svntogit-packages/tree/packages/digikam/trunk
[14:07] <RikMills> huh?
[14:07] <RikMills> oh, maybe just a compile fix and nothing else
[14:08] <Eickmeyer[m]> Yeah, that doesn't look like a solution.
[14:09] <Eickmeyer[m]> I think just pulling from master and calling it good might be the way forward. 8.0.0~alpha
[14:09] <Eickmeyer[m]> Howver, I will preface and say that ffmpeg5 support there is incomplete per the devs and is prone to crashes.
[14:09] <Eickmeyer[m]> So, out of the frying pan and into the fire, vorlon .
[14:11] <RikMills> 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] <RikMills> see how hot the fire is ;)
[14:13] <Eickmeyer[m]> We can do that. Right now I'm at ERR:SLEEPY, WOKEUP, NOT ENOUGH COFFEE
[14:15] <RikMills> 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] <Eickmeyer[m]> Well, it's been a rough transition as mwhudson would tell you.
[14:16] <Eickmeyer[m]> (Ping for no reason, sorry)
[14:16] <RikMills> indeed
[14:48] <vorlon> Eickmeyer: "prone to crashes" wow ok
[14:49] <vorlon> Eickmeyer: should I just try to cleanroom reimplement it and compare with what upstream has done?
[14:50] <Eickmeyer[m]> vorlon: I don't know. It just seems like upstream doesn't have a lot of faith in their code right now.
[14:51] <Eickmeyer[m]> Nor do they seem to have a lot of faith in ffmpeg5.
[14:53] <Eickmeyer[m]> 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
[15:04] <orndorffgrant> 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] <luis220413> What proxy configuration is used in Ubuntu builds in the dpkg-buildpackage phase?
[18:52] <sarnold> can you be more specific?
[19:00] <vorlon> guess not
[19:17] <luis220413> 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] <sarnold> luis220413: ah, the launchpad builders have no network access beyond ftpmaster.internal
[19:18] <sarnold> (well, I don't know how they do ntp, I could imagine they might have access to an internal ntpd)
[19:20] <luis220413> 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:21] <sarnold> luis220413: cosmic is dead
[19:21] <sarnold> luis220413: cosmic reached end of life in 2019 https://wiki.ubuntu.com/Releases
[19:21] <luis220413> sarnold: I know, but that was done for cosmic. I want that done for Bionic, that is supported until 2028.
[19:21] <sarnold> ah
[19:22] <sarnold> luis220413: it's probably best to file a new bug with a clear description of what needs to be done, and why
[19:24] <luis220413> 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] <luis220413> 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] <luis220413> 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] <sarnold> 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] <luis220413> sarnold: I already have a fast strategy (explained above) such that I can upload the patched packages today
[19:29] <luis220413> sarnold: I requested introduction of these packages in bug 1983018 (except for node-rollup)
[19:30] <jbicha> luis220413: are you trying to fix that CVE in Ubuntu directly? Could you coordinate with the Security Team?
[19:31] <luis220413> jbicha: I discussed with sarnold, that is a member of the Security Team.
[19:31] <jbicha> oh never mind
[19:32] <jbicha> my more specific question was if Security would want node-rollup built for bionic-security instead of the usual bionic-updates
[19:38] <luis220413> 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] <luis220413> Because I have a workaround (run rollup on Focal and copy the results to the source package for Bionic)
[19:39] <cjwatson> sarnold: there are various odds and ends in addition to ftpmaster.internal such as ntp, but broadly yes
[19:40] <sarnold> cjwatson: any chance those are public / in code somewhere I can skim? you know me, endlessly curious :)
[19:42] <rbasak> xnox: could you look at bug 1969247 for zfs-linux in Focal, please?
[19:43] <cjwatson> 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] <cjwatson> 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] <cjwatson> 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] <sarnold> 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] <sarnold> I guess that's not very cloudy
[19:49] <cjwatson> that would be pretty hard to maintain
[19:50] <cjwatson> restricted DNS view is much easier
[19:50] <cjwatson> (modulo the fact that only IS can see the view)
[19:50] <cjwatson> also /etc/hosts is terrible for workloads that involve lots of nested chroots/containers, like builds
[19:56] <sarnold> 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] <sarnold> cjwatson: thanks again for indulging my curiousity :)
[19:57] <cjwatson> 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] <sarnold> ooh vpn user specifications!