On Thu, Jan 23, 2025 at 01:27:32PM -0500, Paul Tagliamonte wrote: > On Thu, Jan 23, 2025 at 11:16:25AM -0700, Soren Stoutner wrote: > > > This is not reported on https://tracker.debian.org/pkg/lighttpd > > > > I would not expect it to be. tracker.debian.org does not do any > > automatic > > checking of licensing information because it is too easy to hit false > > positives. > > > > > This is newly reported, as this file has been part of the lighttpd > > > > > debian package circa 2006. > > > > A lot of time licensing information is missed. One of the great things > > that Phil is doing is running lrc (licence recon, which is a relatively > > new tool that I don’t think was available in 2006) against every RFS > > package, which is illuminating a lot of tricky licensing issues. > > However, > > you should note that lrc is prone to a lot of false positives (because > > parsing licensing information is difficult, so it is not run > > automatically > > in places like tracker.debian.org. When you do find a false positive, > > you > > can override it similar to how you override incorrect lintian tags. > > I did not see this locally (and, to Glenn's point, it was burried in the > middle of a lot of chaff). I have already sponsored the package to sid. > I looked at the diff but didn't see any license changes in there. > > Taking off my "I sponsored this package hat" and putting on my "ftpteam > hat", there should be an RC bug if the debian/copyright file is > incomplete on lighttpd. > > Taking off my "ftpteam hat" and putting back on my "I sponsored this > package" hat, I checked the packaege as sponsored, and the > debian/copyright is correct here and mentions the quoted licenses, I > don't see a bug. Can someone point out the missing license information > in copyright?
Paul, thank you for sponsoring the upload and for your measured response. I burned some time on the trace posted by Phil before I sent -moreinfo to the bug, addressing various lintian info and warnings, adding the missing copyright, and updating the debhelper-compat version. Soren, tracker.d.o is a dashboard and displays package status, including links to bugs in BTS. Yes, bugs should be filed as bugs in BTS. The tracker will display the number of bugs, as well as various other information. That is why I suggested everything of interest that might block/disrupt package release should be findable starting at tracker.d.o, unless, of course, the issues have not yet been discovered during manual review. For bugs that are newly discovered, but previously existed in a package, the DD can evaluate if the bug should block the RFS package release, or if the bug should be filed in BTS to be addressed in a future release. Cheers, Glenn
