On 2023-03-11 19:16:52 +0100, Axel Beckert wrote:
> > This message should have been displayed by aptitude.
> 
> Did you test "aptitude update" or "aptitude -u" or both?

I've tried 'u' from the aptitude TUI, "aptitude update" and
"aptitude -u". No messages.

> > Without it, the user who uses aptitude only may never be aware of
> > this change […]
> 
> This is wrong. Without doubt this type of information will be part of
> the release notes — which is usually the _primary_ source for these
> type of changes. I'm actually surprised that apt added such a message.

A sid user is not concerned by the stable releases, thus is not
supposed to read the release notes (and there would potentially
much duplicate information with past changes). The announces of
the main changes for sid (and testing) are normally done via the
NEWS.Debian files, and nothing has been announced there about
non-free-firmware.

> Besides that, the apt developers decided to output this only as LOW
> severity message on the "notice" level (prefix by "N:" and in normal
> font face; AFAIK the lowest level).
> 
> Aptitude shows "error" messages from apt to the user, but only those
> at the "WARNING" level or above (or at least only from somewhere above
> the "NOTICE" level). It is currently unclear to me if this is
> historically grown as apt (not aptitude) defines the _default_ message
> threshold by apt in /usr/include/apt-pkg/error.h as "WARNING" in at
> least three places. I at least currently assume that this is what
> aptitude uses when it calls DumpErrors. According the apt's changelog,
> "WARNING" was for quite some time also the lowest possible message
> level. ("NOTICE" and "DEBUG" levels got added in 0.7.26~exp8.)
> 
> I also do see some sense to suppress some less important messages in
> aptitude: All those messages would cause popup window in the TUI mode
> which the user has to acknowledge (aka "to click away"). That can get
> very annoying if there are too many low severity messages. So IMHO
> it's not so bad that aptitude only shows more important messages.

But do "NOTICE" messages occur often?

> Besides, it's the default threshold from apt.

What do you mean? There doesn't seem to be any default in
the "apt-config dump" output. So I get "NOTICE" messages
from apt by default.

> Then again, "aptitude -u" does not show any of the warnings (or
> notices) I currently get with "aptitude update", so "aptitude -u" only
> seems to cause popups of warnings which are caused directly during the
> download and not after a successful download. Cloning this as a
> separate bug report.
> 
> Anyway, back to the original topic. So I edited
> /usr/include/apt-pkg/error.h temporarily and replaced all but the
> first occurence (which is the definition) of WARNING with NOTICE and
> then compiled aptitude against it. aptitude update indeed
> showed notices now. But to my surprise not all of them, just this one:
> 
>   N: Skipping acquire of configured file 'main/binary-i386/Packages' as 
> repository 'file:/var/cache/apt-build/repository apt-build InRelease' doesn't 
> support architecture 'i386'
> 
> Not yet sure if this is a bug in the way how the missing notices are
> generated in apt or if it is a bug in aptitude not coping with the
> changed default message threshold. Likely needs deeper investigation
> (or better overview of the code), probably by Manuel. (I already put
> hours in investigating this IMHO rather minor issue, just to
> understand a bit how the innards of messages inside apt and aptitude
> are working.) Filing as yet another separate bug report against
> aptitude (for now at least), but with severity minor, as it currently
> does only show up after a hypothetical modification in apt.
[...]

FYI, the implementation is apt seems to have been done by this commit:

https://salsa.debian.org/apt-team/apt/-/commit/9712edf6151308148518058bfbd5ccd937509143

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Reply via email to