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 [email protected]
immediately.)
--
1077843: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077843
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: popularity-contest
Version: 1.77
Severity: wishlist
X-Debbugs-Cc: [email protected]
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: [email protected]
> >
> > 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. <[email protected]>
Imagine a large red swirl here.
--- End Message ---
