Re: Ubuntu Error Tracker data retention
On Thu, 2022-05-12 at 13:38:38 -0700, Brian Murray wrote: > The Ubuntu Error Tracker receives crash reports from all releases of > Ubuntu which are not out of standard support. These crash reports are > then aggregated into buckets where some meta-information (package > version and release of Ubuntu) about those crash reports is collected. > The crash data in the Ubuntu Error Tracker is kept until the release > reaches its end of standard support, however not all the data from each > individual crash gets scrubbed and there is still some detailed > information for crashes from releases as old as Ubuntu 12.04. > > I plan on changing this policy so that all the information from > individual crash reports (basically what is in the .crash file) is > removed when the release reaches its end of standard support. That would > mean that all the information for crashes from Ubuntu 21.10 would be > removed in July of 2022 and for Ubuntu 18.04 it would be removed in > April of 2023. Keeping in mind that a crash bucket would still indicate > that old release and package version were affected are there any > objections to this change in data retention? We are now supporting LTS releases for 5 additional years via ESM and so from the security team's perspective 16.04 will be supported* until 2026 and 18.04 until 2028. I can imagine it would be useful to still have error reports retained and collected for these releases during this ESM period to help identify any possible regressions introduced via ESM security updates. So as a general rule, for the LTS releases can we please retain and support them in the Ubuntu Error Tracker for 10 years? Or alternatively for a more flexible solution, just use the eol-esm date from /usr/share/distro-info/ubuntu.csv in distro-info-data when it is present otherwise fallback to the eol date (since the eol-esm column is only populated for LTS releases from what I can see). > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Error Tracker data retention
The Ubuntu Error Tracker receives crash reports from all releases of Ubuntu which are not out of standard support. These crash reports are then aggregated into buckets where some meta-information (package version and release of Ubuntu) about those crash reports is collected. The crash data in the Ubuntu Error Tracker is kept until the release reaches its end of standard support, however not all the data from each individual crash gets scrubbed and there is still some detailed information for crashes from releases as old as Ubuntu 12.04. I plan on changing this policy so that all the information from individual crash reports (basically what is in the .crash file) is removed when the release reaches its end of standard support. That would mean that all the information for crashes from Ubuntu 21.10 would be removed in July of 2022 and for Ubuntu 18.04 it would be removed in April of 2023. Keeping in mind that a crash bucket would still indicate that old release and package version were affected are there any objections to this change in data retention? Thanks, -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: autopkgtest running wrong version of tests?
On Thu, May 12, 2022 at 04:08:48PM +0200, Graham Inggs wrote: > That was a manual retry triggered by vorlon on 2022-05-09 [1]. The > only trigger was boost1.74/1.74.0-14ubuntu4, but > icinga2/2.13.2-1build2 in release is not installable with the new > boost in -proposed, so britney tries a fallback: > > WARNING: Test dependencies are unsatisfiable with using apt pinning. > Retrying with using all packages from kinetic-proposed Thanks! I missed that it wasn't installable with the new boost and that it was falling back. > So I think things are working as expected. FTR, I think we agreed in IRC that the fallback is wrong to not also fall back on the source tree being used, resulting in the mismatch that was my red herring. But as you said, I guess it's better than no fallback. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended
Hi, On Thu, May 12, 2022 at 10:53 AM Utkarsh Gupta wrote: > > Hi Andreas, > > On Thu, May 12, 2022 at 6:17 PM Andreas Hasenack > wrote: > > This reminded me that frr is also affected by this: > > https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162 > > > > And frr is in main now. I'll work on it. > > Ah. D'you think there could be somewhat of a common solution here? > Or are each of them going to be very different from each other? I don't know yet :) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: autopkgtest running wrong version of tests?
Hi Robie On Thu, 12 May 2022 at 09:46, Robie Basak wrote: > On +1 maintenance this week, I noticed an unusual failure of icinga2 on > kinetic with a trigger of boost1.74/1.74.0-14ubuntu4: > > https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/arm64/i/icinga2/20220509_190945_354db@/log.gz That was a manual retry triggered by vorlon on 2022-05-09 [1]. The only trigger was boost1.74/1.74.0-14ubuntu4, but icinga2/2.13.2-1build2 in release is not installable with the new boost in -proposed, so britney tries a fallback: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from kinetic-proposed You'll notice on 2022-05-01, britney triggered icinga2/2.13.3-1 and boost1.74/1.74.0-14ubuntu4 together and the test was successful. So I think things are working as expected. Regards Graham [1] https://autopkgtest.ubuntu.com/packages/icinga2/kinetic/arm64 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended
Hi Andreas, On Thu, May 12, 2022 at 6:17 PM Andreas Hasenack wrote: > This reminded me that frr is also affected by this: > https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162 > > And frr is in main now. I'll work on it. Ah. D'you think there could be somewhat of a common solution here? Or are each of them going to be very different from each other? - u -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended
Hi, On Tue, May 10, 2022 at 5:07 AM Evren Yurtesen wrote: > > Hi Robie and Utkarsh, > > > This issue is not isolated to tomcat9 package. For example, jetty9 package > logging does not work. Rsyslog says: This reminded me that frr is also affected by this: https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162 And frr is in main now. I'll work on it. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
autopkgtest running wrong version of tests?
On +1 maintenance this week, I noticed an unusual failure of icinga2 on kinetic with a trigger of boost1.74/1.74.0-14ubuntu4: https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/arm64/i/icinga2/20220509_190945_354db@/log.gz icinga2 does have an unusual test here. It runs its own binary and verifies that the output from "--version" matches the upstream release version it sees in debian/changelog from the source tree. "Source tree" means the one it's given during the test run, which includes debian/tests/* and debian/changelog. This is resulting in the following unexpected behaviour: Ubuntu's infrastructure calls the test with [unrelated options removed]: autopkgtest --apt-pocket=proposed=src:boost1.74 --apt-upgrade icinga2 autopkgtest then runs "apt-get source icinga2" (or the equivalent), pulling icinga2 2.13.3-1 from kinetic-proposed. But when it installs icinga2 for the test, the pinning specified by --apt-pocket means that it installs icinga2 2.13.2-1build2 from the release pocket. Since the test is given the source tree from 2.13.3-1, it expects "icinga2 --version" to return 2.13.3, but it returns 2.13.2 and so the test fails. Is the test wrong, or are we running the test wrong? It seems to me that with the test being embedded into the source, it's reasonable for the test to assume that it's testing the actual build it itself ships. Otherwise a new test could for example test a new binary that ships with a new upstream release, and it would fail when running against older builds from the same package. I suppose a hint would be appropriate here, or do you think that something else needs doing instead? This looks like an issue that also needs fixing generally, since it suggests that we're often running the wrong version of the test suite when using "triggers". Although admittedly running a "too-new" test suite is certainly not as bad as running a "too-old" one. Thoughts? Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
