[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1077843: marked as done (popularity-contest: Have separate column for "installed but no atime")

Your message dated Thu, 27 Feb 2025 11:22:19 +0100
with message-id <Z8A82yN56O_u1JIF@seventeen>
and subject line Re: Bug#1077843: popularity-contest: Have separate column for "installed but no atime"
has caused the Debian Bug report #1077843,
regarding popularity-contest: Have separate column for "installed but no atime"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1077843: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077843
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: popularity-contest
Version: 1.77
Severity: wishlist
X-Debbugs-Cc: niels@thykier.net

Hi,
The popularity-contest provides the columns `Inst`, `Vote`, `Old`, `Recent` and `No Files`.
I feel it would be interesting to see how many are `Old` because the system has disabled `atime` on its mount point (either directly or because the mount point is read-only). For these systems, you can basically never get a `Vote` - at least you will see a `Recent` as I understand the current logic.
Therefore, I would like to see popularity-contest track whether the mount points would ever update its atime (the mount flags I know of that are relevant are `noatime` or `ro`[1]) when popularity-contest tracks whether it should count a given file as giving a Vote.
I see this proposal as an alternative to #87619 that does not rely on a new dependency (/etc/mtab, /proc/mounts, or `mount` can all provide the data)
As far as privacy concerns, it may warrant a configuration toogle. I have a minor preference for it being opt-out, but opt-in would be fine for me as well. 

Best regards,
Niels
[1]: As I understand it, `nodiratime` and `relatime` would both be non-issues as programs would still get some `atime` access.
--- End Message ---
--- Begin Message --- 
On Sun, Aug 04, 2024 at 06:51:58PM +0200, Bill Allombert wrote:
> On Sat, Aug 03, 2024 at 09:52:47AM +0200, Niels Thykier wrote:
> > Package: popularity-contest
> > Version: 1.77
> > Severity: wishlist
> > X-Debbugs-Cc: niels@thykier.net
> > 
> > Hi,
> > 
> > The popularity-contest provides the columns `Inst`, `Vote`, `Old`, `Recent`
> > and `No Files`.
> > 
> > I feel it would be interesting to see how many are `Old` because the system
> > has disabled `atime` on its mount point (either directly or because the
> > mount point is read-only). For these systems, you can basically never get a
> > `Vote` - at least you will see a `Recent` as I understand the current logic.
> 
> Yes, but I do not think this is a major issue, since it is uniform across
> all packages. For example
> 36    libc6                          233754 216998   545 16197    14 (Gnu Libc Maintainers)
> so this affects probably less than 0.5% of submissions.
> 
> > Therefore, I would like to see popularity-contest track whether the mount
> > points would ever update its atime (the mount flags I know of that are
> > relevant are `noatime` or `ro`[1]) when popularity-contest tracks whether it
> > should count a given file as giving a Vote.
> 
> So instead of undercounting votes by 0.5%, this would overcount them by 0.5% ?
> 
> This does not seem to be worth the effort.
> 
> > I see this proposal as an alternative to #87619 that does not rely on a new
> > dependency (/etc/mtab, /proc/mounts, or `mount` can all provide the data)
> 
> #87619 was reported at a time where relatime was not available and noatime
> was much more popular.

I close this report, thanks for using popularity-contest!

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--- End Message ---
Reply to: