| mwhudson | love commits like this https://github.com/google/autofdo/commit/963a8c1f55ed86db6b909ee603a46742b3980139 | 00:36 |
|---|---|---|
| ubottu | Commit 963a8c1 in google/autofdo "Update to the latest internal version." | 00:36 |
| sarnold | "look how open source we are!" | 00:37 |
| blahdeblah | haha | 04:20 |
| schopin | Is there an archive of old Ubuntu point releases CD images, e.g. 20.04.3 ? | 09:53 |
| tumbleweed | https://old-releases.ubuntu.com/releases/20.04.3/ | 09:54 |
| schopin | tumbleweed: thanks :) | 10:56 |
| 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? | 12:57 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| rbasak | So what's the decision? OK, or require a workaround? | 13:17 |
| rbasak | vorlon: ^? | 13:31 |
| vorlon | rbasak: I would say they should work around | 13:31 |
| vorlon | bundling pinned CA certificates instead of using ca-certificates is not unprecedented | 13:32 |
| rbasak | orndorffgrant: ^ I don't see lamoura here | 13:34 |
| 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:53 |
| vorlon | RikMills: ah well we have a way to use git commits as upstream tarballs as needed | 13:54 |
| RikMills | indeed | 13:54 |
| 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:07 |
| Eickmeyer[m] | Yeah, that doesn't look like a solution. | 14:08 |
| 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:09 |
| 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:11 |
| RikMills | see how hot the fire is ;) | 14:12 |
| Eickmeyer[m] | We can do that. Right now I'm at ERR:SLEEPY, WOKEUP, NOT ENOUGH COFFEE | 14:13 |
| 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:15 |
| 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:16 |
| vorlon | Eickmeyer: "prone to crashes" wow ok | 14:48 |
| vorlon | Eickmeyer: should I just try to cleanroom reimplement it and compare with what upstream has done? | 14:49 |
| 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:50 |
| Eickmeyer[m] | Nor do they seem to have a lot of faith in ffmpeg5. | 14:51 |
| 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 | 14:53 |
| ubottu | KDE bug 457121 in digikam "digikam 7.7.0 FTBFS against libavcodec59" [Normal, Unconfirmed] | 14:53 |
| 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 | 15:04 |
| luis220413 | What proxy configuration is used in Ubuntu builds in the dpkg-buildpackage phase? | 18:47 |
| sarnold | can you be more specific? | 18:52 |
| vorlon | guess not | 19:00 |
| 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:17 |
| 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:18 |
| 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:20 |
| ubottu | Bug 1790200 in node-rollup (Ubuntu) "Rollup build-depends on itself and needs to be bootstrapped" [Undecided, Confirmed] https://launchpad.net/bugs/1790200 | 19:20 |
| 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:21 |
| sarnold | luis220413: it's probably best to file a new bug with a clear description of what needs to be done, and why | 19:22 |
| 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:24 |
| 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:25 |
| ubottu | 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... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32798> | 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:26 |
| 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:28 |
| 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:29 |
| ubottu | 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:29 |
| jbicha | luis220413: are you trying to fix that CVE in Ubuntu directly? Could you coordinate with the Security Team? | 19:30 |
| luis220413 | jbicha: I discussed with sarnold, that is a member of the Security Team. | 19:31 |
| jbicha | oh never mind | 19:31 |
| jbicha | my more specific question was if Security would want node-rollup built for bionic-security instead of the usual bionic-updates | 19:32 |
| 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:38 |
| cjwatson | sarnold: there are various odds and ends in addition to ftpmaster.internal such as ntp, but broadly yes | 19:39 |
| sarnold | cjwatson: any chance those are public / in code somewhere I can skim? you know me, endlessly curious :) | 19:40 |
| rbasak | xnox: could you look at bug 1969247 for zfs-linux in Focal, please? | 19:42 |
| ubottu | 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| 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:49 |
| 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:50 |
| 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:56 |
| 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 | 19:57 |
| sarnold | ooh vpn user specifications! | 20:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!