Bug Triage Report - Friday 25th of September
Hi, I was looking at 17 bugs recently updated, as usual most of them already under control. In fact a lot of them were SRUs being released so fixes are coming :-) Of the 17 one was worth to mention: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1896740 This is a crash that seems to be fixed in Groovy Andreas took a look (thanks) and identified that: - this should be backportable - but is hard to recreate Next step would be to provide a PPA for the reporter to try for a while (as it occurs often for him, but he neither has a clear trigger to cause it) => Subscribed and tagged server-next. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Wednesday Triage Report (2020-09-23)
Hi, On Thu, Sep 24, 2020 at 12:07 AM Sergio Durigan Junior wrote: > > Hi, > > This Wednesday I did my first triage, replacing Rafael. > > The only noteworthy bug I have is this one: > > - https://pad.lv/1676328 - *(Confirmed) [sssd] - sssd_be is leaking > memory > > There has been a comment by yet another person confirming the bug. This > is obviously not server-next, but I don't have anything meaningful to > reply to the user for now. Andreas, you mentioned in the bug that you > were going to look at the changes in 1.16 and see if anything comes up; > do you remember doing that? I know it's been a while, but... I didn't find good immediate candidates -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: boxfort migration issue
On Thursday, September 24 2020, Bryce Harrington wrote: > Sergio, if I recall correctly, you mentioned Friday that you wanted to > get some experience with package removals for your core dev application? Hey Bryce, You do recall correctly :-) > In doing +1 maintenance I ran across a migration item where I think a > removal would be involved, so if you're interested you might take a > look. Here's my notes: > > * boxfort (0.0.0-git20200105-3e16c0a-6 to 0.0.0-git20200808-ac0507b-3) > - missing build on armhf: libboxfort, libboxfort-dev > - Two issues (I think...) from 0.0.0-git20200808-ac0507b-1 > + Debian limited architectures for libboxfort-dev from "any" to just > "amd64 arm64 i386" > + Debian stopped building libboxfort > - libboxfort binary package needs to be removed from the archive > - Possibly libboxfort-dev:armhf binary package needs some sort of > attention (not sure) > > https://wiki.ubuntu.com/ArchiveAdministration#Removals describes the > technicals of how to remove a package as an archive administer, but I > think what you'd need to do actually is file a bug against the package > in question and subscribe the ubuntu-archive team. If you look at bug > reports that team is subscribed to you can probably find an example > removal request for inspiration. > > If you do plan on taking it let me know, otherwise I'll try to tackle it > at some point tomorrow or Friday. Thanks! I can take a closer look at it tomorrow and proceed with the removal process, yeah. I will let you know how things go. Thanks a lot :-). -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: Wednesday Triage Report (2020-09-23)
On Thursday, September 24 2020, Bryce Harrington wrote: > On Wed, Sep 23, 2020 at 11:05:50PM -0400, Sergio Durigan Junior wrote: >> Hi, >> >> This Wednesday I did my first triage, replacing Rafael. >> >> The only noteworthy bug I have is this one: >> >> - https://pad.lv/1676328 - *(Confirmed) [sssd] - sssd_be is leaking >> memory >> >> There has been a comment by yet another person confirming the bug. This >> is obviously not server-next, but I don't have anything meaningful to >> reply to the user for now. Andreas, you mentioned in the bug that you >> were going to look at the changes in 1.16 and see if anything comes up; >> do you remember doing that? I know it's been a while, but... > > The confirmation isn't really adding new info to the bug that would help > move it forward. (Indeed, the bug was never really pinpointed down to a > specific test case or root cause - who knows if the drive-by me-too is > seeing the "same" memory leak or some other bug that also leaks.) So, > the bug probably doesn't really need a status update from us - if we > don't have any new info a reply could just be more noise. Thanks for the detailed reply, Bryce. So, the reason I thought this bug deserved to be mentioned is because, IIUC, the ball is (at least partially) in our court. It seems to me that Andreas was investigating it and that we aren't waiting on input from the users at me moment, although, as you said below, the bug is hard to reproduce and fix. > However, if you're feeling generous one thing I sometimes do with this > sort of bug is think about what the next action would be to move it > forward in its lifecycle. "If you'd like to help move this bug forward, > it looks to me like it is currently blocked because __." Right. I thought about that, but it seemed best to ping Andreas first, just in case there is some progress that I'm unaware of. > From the linked bug report it says the issue was in 1.13.4 but resolved > in 1.13.5 (git) as tested on 2016-11-30. There was never actually a > 1.13.5 release, but there are commits in the upstream 'sssd-1.13' branch > after 1.13.4 was tagged. So, a brute force git bisection search between > the 1.13.4 tag and sssd-1.13's tip might discover the solution. > > > https://github.com/SSSD/sssd/commits/sssd-1-13?after=c7636e4721cb52f1b36bf93a3f27a247f3f9231f+270&branch=sssd-1-13 > > > Bugs that take a long time to reproduce can be a PITA to git bisect > though, and it's certainly possible the leak requires more than a single > leak fix. Looking through the git tree I spot a number of leak fixes, > e.g. just from a few months after the release: > > https://github.com/SSSD/sssd/commit/e22cbe9326073e6d42fe2118661fa6daaed8638c > https://github.com/SSSD/sssd/commit/2fb750062a665dbf318b5ffb2e53f1060e43b8dc > https://github.com/SSSD/sssd/commit/312d211e03b9f3769a0362f1767cc59792e32746 > > So another approach might be to just blindly cherrypick anything between > 1.13.4 and 2016-11-30 11:31:50 mentioning "memory" or "leak" and throw them > in a package and stick it in a ppa for testing. But this is now more > into bug-work than triaging, and without a reliable test case to > reproduce it, it's just stabbing in the dark. Good advice. IIUC, that's kind of what Andreas tried to do in the PPA he mentioned. Thanks for taking the time to better explain the process! Cheers, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Triage report (2020-09-24)
Found only 8 bugs, marked one as Invalid, the rest are under control and didn't require any triage action. Paride -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
