[05:46] <tjaalton> Eickmeyer: missing context.. which issue?
[10:59] <Laibsch> How do I reactivate crash reporting for a package for which I previously deactivated it (by ticking the box "do not make reports of this type anymore", not sure about the exact message)?
[11:04] <cpaelzer> Laibsch: I'm not sure about this, but your button-clicking might have been converted to a file in /etc/apport/blacklist.d/ which you could now remove?
[11:04] <Laibsch> Thank you, cpaelzer.  I will have a look.
[11:06] <Laibsch> Unfortunately, nothing apparently relevant there.  And I believe this won't be system-wide but only apply for the user.
[11:08] <Laibsch> "find ~/.config/|grep apport" is empty, too
[12:11] <ahasenack> schopin: hi, did you take a look at freeradius wrt openssl 3? The upstream commits?
[12:11] <ahasenack> I saw your comment in the bug
[12:11] <ahasenack> upstream seems very annoyed at the openssl3 diffs
[12:12] <schopin> ahasenack: morning! I had a look but I think it'd be a pain to backport, since they weren't centralized in a PR.
[12:12] <ahasenack> right, random commits here and there
[12:12] <ahasenack> many without a pr, just "cowboyed"
[12:12] <schopin> Which is why I'm really hoping for 3.0.26
[12:13] <ahasenack> we can see if current tip works
[12:13] <ahasenack> the test failure is for sure fixed, but that doesn't exercise the whole stack
[12:13] <ahasenack> I'm already admitting we will have to go ahead of debian
[12:14] <ahasenack> we could package something like 3.0.26~gitXXXXXXX, or 3.0.25+gitXXXXX
[12:14] <schopin> That's a possibility, indeed :/
[13:24] <ahasenack> ...and firefox crashed again
[13:24] <ahasenack> bryceh: ^
[13:24] <ahasenack> not radeon, though
[13:25] <ahasenack> just can't drag tabs anymore
[13:25] <ahasenack> feels like early 2000 again
[13:37] <didrocks> sarnold: once you are around, I checked https://termbin.com/hb49. On adsys itself, 0.8 fixes the unchecked error when we upgraded to new govet compared to this 0.7 traces. The rest is false positives to me or unwanted errors. I checked the errors not checked in the vendored dependency and hasn’t spot anything serious or impacting us.
[13:46] <cpaelzer> ahasenack: I think paride reported the same with memory pressure making most of his tabs stop rendering and needing to reload when he gets back to them
[13:47] <paride> yes it keep happening: no crashes but it constantly unloads tabs from memory
[13:47] <ahasenack> I got that dialog to either wait or force quit
[13:47] <paride> which slows things down by a lot and it's also interfering with notifications
[13:47] <ahasenack> and it was unresponsive, not even text input worked
[13:47] <ahasenack> I'm on impish, btw
[13:47] <paride> didn't get that one
[13:47] <ahasenack> whatever the tab was displaying was working (well, I didn't look for animated gifs), but frozen
[13:48] <paride> I'm on Jammy but the FF version is the same I believe
[13:48] <ahasenack> I mean, it was displayed, no rendering faults or empty sapces
[15:27] <Eickmeyer> tjaalton: The post is on ubuntu-devel@ regarding what we're working on now re: /boot overfill. (see also #ubuntu-meeting for xnox's comments)
[15:28] <Eickmeyer> That should give you context.
[15:28] <tjaalton> ah
[15:49] <rbasak> Eickmeyer: so one catch with making /boot bigger. I don't think it'd apply to existing users upgrading up, would it? So if it turns out it's a good thing to do, it might still be dangerous to assume that all users therefore have a bigger /boot.
[15:49] <rbasak> Eickmeyer: so one catch with making /boot bigger. I don't think it'd apply to existing users upgrading up, would it? So if it turns out it's a good thing to do *and the change is made*, it might still be dangerous to assume that all users therefore have a bigger /boot.
[15:51] <Eickmeyer> rbasak: No, it wouldn't apply to new users. Nothing can be done about them, the ship has sailed. BUT, going forward it's still a good thing for new users. Also, best to respond to the ML post. :)
[15:51] <Eickmeyer> That's where discussion has been requested.
[15:56] <rbasak> Eickmeyer: yeah sure. I don't mean to suggest it not be changed if that's the right thing to do regardless of that catch :)
[15:57] <rbasak> (and I didn't want to be misunderstood like that which is why I didn't reply there)
[15:58] <Eickmeyer> rbasak: Ah, makes sense. :)
[16:02] <bdmurray> However, the release upgrader does check to see if your /boot partition has room to hold new kernels and will present some warning / stop upgrades if it is too small.
[17:42] <rbasak> Is it just me or is jammy-proposed quite broken now? build-essential isn't installable?
[17:47] <rbasak> Hmm. In my view, libc6 2.34-0ubuntu3 is still in the release pocket, but the new libc6 also isn't in the proposed pocket.
[17:47] <rbasak> That'll be why.
[17:48] <rbasak> I suppose that's a caching race.
[17:49] <rbasak> (and races between suites are still possible in apt)
[18:47] <rbasak> (^ it now works again)
[19:05] <teward> bdmurray: memtest86, was that synced down and made available on the daily ISOs or do I have to go run a live env and then handle things
[19:05] <teward> for testing memtest86+ that you emailed about
[19:09] <bdmurray> teward: Its in the manifest for today's daily. https://cdimage.ubuntu.com/ubuntu/daily-live/20220215/jammy-desktop-amd64.manifest
[19:13] <teward> check, so it should already work out of the box with 'test memory' on the options on the ISO then.
[19:14] <teward> thanks bdmurray wasn't sure if it synced down or not (and lazy)
[19:14] <bdmurray> I think I sync'ed it on Friday, I guess I could have been more explicit in my email. ;-)
[19:29] <ahasenack> tjaalton: sergiodj merged sssd, btw, it's uploaded
[19:31] <tjaalton> ahasenack: nice
[20:40] <Eickmeyer> JulianAndresKlod: Bug 1914278 has a debdiff \o/
[20:46] <sarnold> yikes, 175kb?
[20:49] <Eickmeyer> sarnold: Yeah, contains quite a few changes.
[20:50] <Eickmeyer> Very representative of PackageKit 1.2.5 releasing soon (hopefully).
[20:54] <Eickmeyer> sarnold: They basically had to rewrite a ton of the apt backend.